• Название:

    выучить


  • Размер: 0.05 Мб
  • Формат: ODT
  • или
  • Сообщить о нарушении / Abuse

Установите безопасный браузер



1.2. Принципы работы Web-приложений12.1. Архитектура "клиент-сервер"

Вычислительные сети в зависимости от способов взаимодействия входящих в них компьютеров можно разделить на две группы — централизованные и одноранговые.

Централизованные сети строятся на основе архитектуры "клиент-сервер", которая предполагает выделение в сети так называемых "серверов" и "клиентов". К клиентам относятся рабочие станции (компьютеры) сети, которые не имеют непосредственных контактов друг с другом и могут общаться между собой только через сервер. Все локальные ресурсы рабочих станций не могут быть использованы никакой другой рабочей станцией.

На основе данной модели и строятся различные Web-сервисы. Пользователи с помощью браузера (программы просмотра HTML-документов) могут посылать запросы на компьютеры, выступающие в роли серверов. Причем серверы могут находиться как в локальной сети (интранет), так и в глобальной Сети (Интернет).

Взаимодействие между клиентом и сервером в Web-технологиях в основном происходит на основе протокола HTTP (HyperText Transfer Protocol — протокол передачи гипертекстовых документов). HTTP является текстовым протоколом, т.е. HTTP-запросы представляют собой последовательности символов в коде ASCII.

В общем виде запрос имеет следующую структуру.

метод  URI   HTTP-версия Дополнительная   информация

Здесь метод — это текстовое название действия или способа передачи данных на сервер. Самыми часто используемыми являются методы GET и POST. Подробнее о них пойдет речь в главе 7.

URI (Universal Resource Identifier — универсальный идентификатор ресурса) имеет следующий формат:

[путь] [файл] [?параметр-значение [&параметр-значение [& . . ] ]

Необязательные части URI заключены в квадратные скобки. Путь до запрашиваемого файла указывается относительно корневого каталога сервиса WWW (он задается при настройке Web-сервера).

Параметры, перечисляемые после знака вопроса, — это данные, передаваемые на сервер с помощью метода GET. При этом название и значение параметра разделяются знаками равенства (=), а пары параметр-значение — амперсандами (&).

Параметр запроса HTTP-версия определяет версию протокола HTTP, в соответствии с которой будут обмениваться данными клиент и сервер.

К дополнительной информации, которую может передать клиент, относятся такие данные, как IP-адрес клиента, название программы-клиента, предпочитаемый язык, на котором должен быть написан запрашиваемый документ, и т.п.

В качестве примера рассмотрим HTTP-запрос на получение индексной (начальной) страницы с сервера.

GET   /   HTTP/1.1

Accept-Language:   en-us

Connection:   Keep-Alive

Host:    82.179.73.32

User_Agent:   Opera/7.54    (Xll;   Linux   i686;   U)       [en]

Если запрашиваемая страница доступна на сервере, то его ответ может быть, например, таким.

HTTP/1.1   200   OK

Server:   Apache/2.0.52    (Gentoo/Linux)

Connection:   Keep-Alive

Date:    Sat,    5   Mar   2005   10:27:16   GMT

Content-Type:   text/html

Accept-Ranges:   bytes

Content-Length:   2964

Last-Modified:   Sat,    5   Mar   2005   10:27:16   GMT

Cookie:   uid=456578

<HTML>

</HTML>

В ответе сервера сначала следует HTTP-заголовок, который содержит код ответа (в данном случае 200 — это значит, что запрашиваемый документ доступен, и сервер начинает его передачу). Далее следует различная служебная информация, и после пустой строки начинается сам документ. Причем, этот документ необязательно текстовый — это может быть и бинарный (двоичный) файл, например изображение или архив.

___________________________________________________________________________________________________________


Для разработки приложений под Android предоставляется четыре основных строительных блока, которые используются в различных сочетаниях. Для подробного описания назначения каждого из блоков потребуется большой том, но кратко на этом деле можно остановиться:

Блок Activity (действие)



Этот блок представляет отдельный экран в приложении, который реализован в виде экземпляра, наследуемого от базового Activity. Блок позволяет отображать пользовательские элементы интерфейса и обрабатывать возникающие последовательно события. 

Блок Intent Receiver (приемник намерений)



Данный блок используется, когда нужно, чтобы программы реагировала на какие-то внешние события, такие как звонок телефона. Приемник намерений не имеет отдельного пользовательского интерфейса, зато умеет использовать менеджер извещений для оповещения пользователя о том, что что-то произошло. Удобно то, что нет необходимости самостоятельно запускать программу каждый раз, когда произошло внешнее событие. Сразу как IntentReceiver прореагирует на событие, операционная система самостоятельно запустит приложение. Это существенно повышает удобство и функциональность, как операционной системы, так и сопутствующих приложений, и является одной из причин того, скачать программы для android 2.2 сегодня удобно, выгодно и актуально.

Блок Service (служба)



Данный блок является компонентом, позволяющим работать программе в фоновом режиме без необходимости в использовании интерфейса пользователя. Примером может послужить фоновое проигрывание музыки. Служба работает до тех пор, пока пользователь ее не остановит. Это дает возможность максимально комфортно работать сразу с несколькими программами.

Блок Content Provider (контент-провайдер)



Все типы программ хранят свои данные в базах данных, файлах и в прочем подобном. Данный блок служит удобным механизмом, с помощью которого данные пользовательских приложений могут совместно эксплуатироваться остальными. Блок ContentProvider реализует большое количество методов для работы с данными, к которым имеет свободный доступ операционная система.
Практически все Android-приложения запускаются в своих собственных Linux-процессах. Процесс создается тогда, когда программе нужно выполнить какой-то код, и дальше уже остается запущенным до тех пор, пока приложение используется. После завершения процесса система чистит свою память для ее эффективного использования другими программами.
Существенной особенностью софта для Android является то, что период жизни процесса самой программой не контролируется. Этим занимается операционная система методом определения влияния различных компонентов текущего приложения на нормальное выполнение других работающих программ, и кроме этого - влияния выполняемого процесса на количество памяти в системе.

Операционная система Android и ее программы уникальны своей производительностью, легкостью и доступностью конструирования. В них нет ничего сложного, и именно в этом их секрет популярности.

Правила написания тест кейсов

Как и предполагал в предыдущих постах, выкладываю эти нехитрые правила. Своим созданием они обусловлены были достаточно большой вероятностью появления в нашей организации тестировщиков с небольшим опытом, либо без такового вообще. Поэтому постарался адаптировать простые истины под нашу специфику: 

1. у каждого тест кейса (ТС) уникальное имя и ID (Без этого никуда- ибо различать и не путать тест кейсы необходимо, а при наборе их в тестран такие вещи не исключение. Не забываем, что на один юз кейс может быть написано достаточно много очень похожих тест кейсов, но проверяющих совсем разные вещи или работающих в разных условиях. Необходимо их различать.) Напомню, что нумерацию тест кейсов я вводил на стадии формирования дерева юз кейсов. Делалось это примерно так: Уникальный номер тест кейса состоит из буквы (С- клиент(client), A -администратор (admin))и семи цифр. Если в указанном ниже номере присутствует менее семи цифр, необходимо добавить нужное количество нулей в конец номера. Например, тест кейс, где производится верификация количества попыток логина при неправильном пароле (первый в списке), имеет номер C1111100, второй C1112100:
1. Общие тесты приложения:
1.1 Логин:
1.1.1 Некорректный:
1.1.1.1 Некорректный пароль:
1.1.1.1.1 Количество попыток;
1.1.1.2 Корректный пароль:
1.1.1.2.1 Количество попыток;
В моем случае основной состав дерева был уже сформирован, когда пришло время браться за нумерацию. Поэтому прикинуть необходимое количество цифр для номера труда не составило. Однако необходимо помнить о вероятных перестановках структуры дерева и практически 99%ных добавлениях новых тест кейсов, и предусмотреть возможные перекомбинации номеров. 

2. Должен быть указан приоритет ТС (поговорим отдельно), цель (цель проверки- что именно проверяем), источник информации(спек, список требований (ссылки на требования в системе управления требованиями), и т.д.), категория (например, функциональный, юзабилити, стресс и др.), тип (ручной, автоматический), версия.

3. Предустановки- обязательны. (как правило, каждый ТС должен быть доступен для выполнения как в составе съюта, так и в составе произвольного набора ТС; так и в отдельности от других ТС). Соответственно должны (могут) быть описаны действия по завершению ТС, но не входящие в его тело- "постустановки" (особенно для автоматизированного тестирования). 

4. Версия ТС- обязательна для заполнения и отслеживания. Формируется от "0.01". Версии изменения самих шагов (непринципиальные): +0.01. Версии изменения последовательности шагов (наряду с изменениями внутри некоторых шагов): +0.1 (с округлением: 0.14->0.20).Версии глобальных изменений (или крупных и многочисленных изменений в соответствии с предыдущим вариантом) +1.00 (1.23->2.00).

5.нумерация шагов- по порядку. Без комментариев :)

6. Действие (Action)- конкретное описание конкретного действия (необходимо предусматривать возможность разностороннего получения одного и того же результата (в минимальных отступлениях, например, контекстное меню и выбор меню из тулбара), и предоставлять выбор при выполнении ТС. Для более полного охвата функционала от итерации к итерации тестирования.) Необходимо помнить, что чрезмерный разброс действий- крайне недопустим. Так же необходимо учитывать то обстоятельство, что по ручным ТС пишутся автоматические скрипты (TS). Поэтому необходимо учитывать инвариантность выполнения ТС скриптом. (То есть если в некотором скрипте была описана последовательность действий через, например, контекстное меню, то- в другом логично реализовать это через вызов меню из тулбара, и наоборот.). В отдельных случаях (например, при тестировании в ТС конкретно вызова функции\метода из меню тулбара) должна быть описана именно эта последовательность действий и никакая другая. Так же это должно быть отражено в названии и, главное, в цели самого ТС.

7. Ожидаемый результат (Result)- конкретное описание состояния приложения или конкрентой его части. должно включать в себя не только описание текущего объекта(ов), но и окружающую среду. Например, при тестировании ввода текста в ворде должно быть описано не только то, что текст введен, но и то, что он имеет стандартный формат, не выделен, не курсив и т.д., а также, что ворд имеет стандартный вид (отображены стандартные кнопки\панели, и не имеет "специальных" "отклонений", которые могут быть вызваны дополнительными действиями пользователи или машины).

8. В Любом корректном ТС должно быть не более 10-12 шагов. Отдельные исключительные случаи оговариваются отдельно.

9. При написании ТС необходимо руководствовавться всей доступной информацией для отражения последних (и возможных!) изменений приложения. Необходимо закладывать на будущее вероятность изменений приложения и заранее обдумывать принцип построения ТС для последующей модификации (если таковая понадобиться) при наименьших временных и ресурсных затратах.

10. Шаги в ТС должны быть описаны четко и понятно даже для неподготовленного человека, но тем не менее должны быть описаны в соответствии с принятым глоссарием, который формируется параллельно. При принятии решений о переименовании того или иного объекта или действия все ТС должны быть модифицированы централизованно.

11. Модификация ТС осуществляется централизовано и только при необходимости внесения критичных изменений. (нет необходимости перебирать все ТС ради изменения названия кнопки). Некритичные изменения должны накапливаться, хранится в общем доступе и отслеживаться. Количество накапливаемых изменений ограничено и должно быть регулярно согласовано.

12. Поиск шагов(слов, действий) в ТС должен осуществляться автоматическими средствами поиска (например, ctrl+F). Здесь есть, конечно, некая зависимость от среды, где хранятся ТС.

13. При нахождении нужного места(шага) необходимо убедиться в его неактуальности и потребности изменений. (так как в ТС могут быть описаны специфические вызовы функций (например, вызов старого функционала)).

14. Недопустим Copy\Paste и последующее сохранение ТС (при создании нового или модификации существующего ТС). Допустим вариант: создание, Copy\Paste, внесение изменений в атрибуты ТС (номер, название, цель, и тд), внесение изменений в тело ТС, и только потом сохранение. Хотя выгоднее писать каждый ТС с нуля, все мы помним о времени.

15. Все ТС должны быть структурированы и сгруппированы по тестируемому функционалу.

16. Допускается создание необходимого количества съютов, для регрессионного тестирования. Вопрос должен обсуждаться индивидуально для каждого случая. Помня о времени, затрачиваемом на разработку вообще и на тестирование в частности, правильнее будет собрать набор только из ТС, которые необходимо протестировать, а не из всех подряд.

17. ТС должны писаться в соответствии с расстановкой приоритетов- в начале должны быть описаны ТС "приемочного" типа. Таким образом будет производится дымовое тестирование приложения. Нет смысла тестировать неработоспособное приложение. Затем пишутся ТС, покрывающие основной функционал приложения и другие.

18. Все баги, дефекты, недочеты должны быть сколлекционированы (баги в систему багтрекинга, по недочетам, неточностям- отсылка писем, сообщений, вопросов). ТС должен быть написан, даже если существует баг, непозволяющий его выполнить на данный момент. При этом в ТС ставится пометка, что он bloked by #### (номер бага) и незакончен для редактирования(в системе багтрекинга этому багу проставляются номера ТС, на которые он влияет, чтобы после фикса бага не искать их; теем не менее должен быть проведен автоматический поиск по ТС, так как на момент постинга бага в систему окончательно не известно- все ли ТС тестирующие эту область написаны.Могут быть написаны новые ТС.). Как только баг пофиксен- ТС должен быть закончен и включен в исполняемые съюты.

19. план написания ТС- пополняемый и изменяемый. При открытии новых областей, которые должны быть протестированы, в начале корректируется план, вносятся изменения, характеризующие изменения и дополнения в съютах. А затем уже непосредственно пишутся и вносятся в систему новые ТС, изменяется старая структура. Все действия должны быть согласованы. Например, в тфс это делалось просто линками между соответствующими объектами тфс.

20. Все существенные изменения должны быть задокументированиы автором изменений и хранится в связке с каждым ТС, который был модифицирован. То есть должны быть: дата , автор, характер изменений (или сами изменения). Можно взять за основу комментарий к чекину, но чекинить за один раз придется по одному модифицированному ТС.

21. Все ТС должны быть в актуальном состоянии. Допускается "запаздывание" актуализации при неясном окончательном функционале. Не допускается начало работ по актуализации ТС при неясном окончательном функционале. Никому не нужна лишняя бесполезная работа.

22. Все баги должны быть покрыты ТС-ами. Все требования должны быть покрыты ТС-ами. Весь описанный функционал должен быть покрыт ТС-ами. В идеале :)

23. Все результаты выполнения тестирования должны хранится в системе учета и хранения результатов. Или в любом доступном, подходящем месте.

24. Необходимо исключать повторение действий, уже описанных в других ТС. Там, где это невозможно, допустимо описывать необходимые действия в предустановках или в теле ТС. (например, приложение находится в таком-то состоянии, открыто такое-то окно, с такими-то свойствами, то есть без указания конкретных действий).

25. Сначала должны быть описаны положительные ТС, потом отрицательные. Допускается одновременное внесение в план обоих типов ТС.

Все эти правила написаны для того, чтобы минимизировать время, затрачиваемое на объяснение простых истин, чтобы исключить ненужные рабочие активности, и чтобы в результате получить базу работоспособных, легкомодифицируемых тест кейсов.

Тест План (План тестирования)

Тест план (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Рекомендации по написанию Тест Плана

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

  • Test Plan Template RUP

  • Test Plan Template IEEE 829

  • Присмотревшись внимательнее становится ясно, что оба документа описывают одно и тоже, но в разной форме. В случае, если вам не подходит стандартный шаблон или вы решили придумать свой собственный, более подходящий для вас формат документа, то из опыта можем сказать, что хороший тест план должен как минимум описывать следующее:

  • Что надо тестировать?

  • описание объекта тестирования: системы, приложения, оборудования

  • Что будете тестировать?

  • список функций и описание тестируемой системы и её компонент в отдельности

  • Как будете тестировать?

  • стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования

  • Когда будете тестировать?

  • последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки

  • Критерии начала тестирования:

  • готовность тестовой платформы (тестового стенда)

  • законченность разработки требуемого функционала

  • наличие всей необходимой документации

  • ...

  • Критерии окончания тестирования:

  • результаты тестирования удовлетворяют критериям качества продукта:

  • требования к количеству открытых багов выполнены

  • выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)

  • выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)

  • ...

  • Ответив в своем тест плане на вышеперечисленные вопросы, можно считать, что у вас на руках уже есть хороший черновик документа по планированию тестирования. Далее, чтобы документ приобрел более менее серьезный вид, предлагаем дополнить его следующими пунктами:

  • Окружение тестируемой системы (описание программно-аппаратных средств)

  • Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.)

  • Риски и пути их разрешения

  • Виды тест планов

    Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

  • Мастер Тест План (Master Plan or Master Test Plan)

  • Тест План (Test Plan), назовем его детальный тест план)

  • План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.) (Шаблон плана приемо-сдаточных испытаний от RUP)

  • Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.

    В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.

    Рецензия и Утверждение

    Для увеличения ценности вашего тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде "процедуры утверждения". Как пример, приведем список участников проектной группы, утверждение которых мы считаем необходимым:

  • Ведущий тестировщик

  • Тест менеджер (менеджер по качеству)

  • Руководитель разработки

  • Менеджер Проекта

  • Каждый из перечисленных участников проекта, перед утверждением, проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать Ваш тест план более полным и качественным.

    Вывод

    Воспользовавшись вышеуказанными советами, у вас будет больше шансов написать хороший документ, нежели придумывать все самим.

    Нагрузочное тестирование

    Современное программное обеспечение просто обязано бесперебойно работать под колоссальными нагрузками. Любого рода проблемы, связанные с плохой производительностью, могут стать причиной отказа клиентов от использования вашего ПО. В связи с этим, проведение качественного нагрузочного тестирования должно стать обязательным, для обеспечения стабильности работы ваших приложений.

    Теперь давайте ответим на вопрос: "Что же такое нагрузочное тестирование?", и постараемся более подробно описать процесс проведения нагрузочного тестирования.

    Нагрузочное тестирование (Load Testing) или тестирование производительности (Performance Testing) - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.

    Начиная работу в области нагрузочного тестирования, следует четко понимать, что это не просто запись и прогон (Record and Playback) скриптов, а более сложный процесс:

  • Во-первых, нагрузочное тестирование - это серьезная исследовательская и аналитическая работа

  • Во-вторых - это реальное автоматизированное тестирование, требующее серьезных навыков программирования, а также знания сетевых протоколов и различных серверов приложений и баз данных

  • В-третьих - существуют разные виды нагрузочного тестирования, ставящие перед собой разные цели

  • Далее предлагаю вам пункт за пунктом углубиться в тестирование производительности:

  • Терминология в нагрузочном тестировании

  • Цели нагрузочного тестирования

  • Этапы проведения нагрузочного тестирования

  • Разработка модели нагрузки

  • Инструменты для нагрузочного тестирования

  • Также рекомендуем почитать статьи специалистов по нагрузочному тестированию:

  • Модель нагрузки, как отправная точка при тестировании производительности (Алексей Булат)

  • Конфигурация тестового стенда для нагрузочного тестирования (Алексей Булат)

  • Основные аспекты создания скриптов для нагрузочного тестирования (Алексей Булат)

  • Конечно, прочитать все это - не достаточно, чтобы сказать: "Я стал знатоком или экспертом в области тестирования производительности", для этого вам понадобится не один год и не один проект. От себя мы можем только пожелать вам удачи на этом нелегком пути. Если же у вас появятся вопросы, вы можете смело обратиться к нам. Специалисты группы ПроТестинг могут провести консультации по тестированию и обеспечению качества программного обеспечения


    ___________________________________________________________________________________________________________

    Автоматизированное тестирование программного обеспечения - основные понятия

    Автоматизированное тестирование программного обеспечения (Software Automation Testing) - это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования.

    Специалист по автоматизированному тестированию программного обеспечения (Software Automation Tester) - это технический специалист (тестировщик или разработчик программного обеспечения), обеспечивающий создание, отладку и поддержку работоспособного состояния тест скриптов, тестовых наборов и инструментов для автоматизированного тестирования.

    Инструмент для автоматизированного тестирования (Automation Test Tool) - это программное обеспечение, посредством которого специалист по автоматизированному тестированию осуществляет создание, отладку, выполнение и анализ результатов прогона тест скриптов.

    Тест Скрипт (Test Script) - это набор инструкций, для автоматической проверки определенной части программного обеспечения.

    Тестовый набор (Test Suite) - это комбинация тест скриптов, для проверки определенной части программного обеспечения, объединенной общей функциональностью или целями, преследуемыми запуском данного набора.

    Тесты для запуска (Test Run) - это комбинация тест скриптов или тестовых наборов для последующего совместного запуска (последовательного или параллельного, в зависимости от преследуемых целей и возможностей инструмента для автоматизированного тестирования).