Рабочее место тестера проекта, основные функции тестера и набор инструментальных средств тестирования, методы тестирования, стадии тестирования, связь с разработчиком, архитектором и менеджером проекта

Тестирование в VSTS

В Visual Studio Team System есть средства для проведения тестирования вручную и автоматически. Также предоставляются возможности занесения результатов тестирования в базу данных, построения графиков, учета и анализа найденных ошибок и т. д.

Для создания какого-либо теста нужно вначале создать тестировочный проект (test project). Впрочем, его можно не создавать отдельно - мастер создания тестов предложит сделать это автоматически. В Visual Studio Team System тестировочные проекты предназначены специально для хранения тестов различных типов. Каждый тестировочный проект связан с определенным языком из поддерживаемых в Visual Studio (Visual Basic, C#...), на котором будут писаться тестовые сценарии (test scripts). Чтобы создать новый тест, нужно выбрать пункт меню "Test – New Test... " и в открывшейся форме

Рис. 17.1. Типы тестов в VSTS

В VSTEST поддерживается шесть основных типов тестов:

• unit test (модульный тест) – программный тест, при выполнении которого вызываются методы класса и проверяются возвращаемые ими значения;
• manual test (тест, выполняемый вручную) – проводится тестировщиком, а не выполняется автоматически;
• generic test (пользовательский тест) – выполняется внешним приложением, вызываемым из Visual Studio ;
• web test (веб-тест) – производятся вызовы http-приложения для проверки его функциональности;
• load test (нагрузочный тест) – одновременно и многократно выполняются модульные, пакетные, пользовательские или веб-тесты;
• ordered test (пакетный тест) – последовательно выполняются тесты из заданного списка.
• Database test (тест базы данных) – используется для тестирования функций, триггеров, индексов и любых других объектов БД.

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

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

Модульное тестирование

Модульным тестом называется программный код, специально написанный для проверки качества и функциональности конкретной функции разрабатываемого продукта. Visual Studio 2005 Team System автоматически создает каркасы модульных тестов, которые затем наполняются кодом. Такие тесты являются низкоуровневыми и вполне могут быть заменены стандартными процедурами трансляции. В рамках данного проекта разработчик самостоятельно может проверить работоспособность отдельных модулей на этапе кодирования и отладки. По этой причине в данном проекте модульные тесты не реализованы.

Тестирование, выполняемое вручную

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

Очевидно, что такая технология не слишком эффективна, поэтому она также не использовалась в рамках данного проекта.

Веб-тестирование

Веб-тест представляет собой последовательность http -запросов. Веб-тесты работают на протокольном уровне. При выполнении теста движок (web test engine) выполняет эти запросы, сохраняет и анализирует ответы от сервера (response). При запуске веб-теста взаимодействия с браузером не происходит, все тесты выполняются движком на более низком, протокольном, уровне. Во время создания веб-теста при помощи записи действий пользователя открывается браузер (в любом случае Internet Explorer ) с дополнительным окном в левой части – Web Test Recoder, который является частью VSTEST. В нем отображаются все действия пользователей в виде http-запросов. В верхней части этого окна находятся кнопки для управления записью: Record, Pause, Stop, Add a Comment и Clear All Requests.

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

Рис. 17.2. Запись веб-теста

Кнопка Record нажата по умолчанию, то есть запись ведется непосредственно после нажатия кнопки "OK" в окне создания нового теста. После ввода в адресную строку адреса одной из страниц тестируемого сайта в окне Web Test Recorder появляется ее отображение в виде http -запроса. Кнопки Stop и Pause предназначены для окончания или остановки записи соответственно. Пока нажата кнопка Pause, пользователь может произвести какие-либо действия на тестируемом сайте. Таким образом, по желанию тестировщика можно записывать не все действия, а только те, во время исполнения которых кнопка Pause не нажата. Нажав кнопку Add a Comment, можно добавить к последовательности запросов в Web Test Recorder текстовый комментарий – довольно удобная возможность при составлении веб-тестов больших размеров. При дальнейшем редактировании или при запуске веб-теста комментрарии помогут разобраться, что именно происходит на данном этапе теста. Ведь намного легче понять человеческий текст, чем последовательность http -запросов. Кнопка Clear All Requests – крайняя справа на панели Web Test Recorder – предназначена для очистки веб-теста от всех запросов, которые уже были сохранены.

Каждый запрос, записаный в Web Test Recorder, обладает набором свойств. Эти свойства отображаются на панели Properties, которая, как правило, расположена в правом нижнем углу экрана.

Рис. 17.3. Панель свойств запроса

В случае создания более мощных веб-тестов простого списка http-запросов может быть уже недостаточно. В этом случае веб-тест можно представить в виде скрипта, кода (coded web test). Таким образом, перед тестировщиком открываются гораздо более широкие возможности: можно реализовать конструкции ветвления, циклы и т.п. Для представления веб-теста в виде кода нужно нажать кнопку Generate Code на панели инструментов на закладке веб-теста.

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

В нижней части формы с результатами теста находится пять закладок: Web Browser, Request, Response, Context и Details. На закладке Web Browser можно увидеть то, что увидит пользователь в окне браузера при выполнении запроса, на котором находится курсор. На закладках Request и Response находятся заголовки и тела запроса и ответа от сервера соответственно. На закладке Context хранится дополнительная информация о запросе. Результаты работы правил находятся на закладке Details.

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

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

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

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

Нагрузочные тесты создаются подобно другим типам тестов путем выбора из меню "Test – New Test – Load Test". Затем устанавливаются различные параметры сценария тестирования. В таком сценарии содержатся: нагрузочный профиль, список тестов, пользовательский профиль, список браузеров, список сетей, набор счетчиков и параметры запуска.

Нагрузочный профиль определяет, какого рода нагрузку на приложение должно имитировать исполнительное ядро. Установка Constant Load (Постоянная нагрузка) загружает приложение по максимуму, т.е. сымитирует одновременную работу максимально возможного числа пользователей. Данная установка предназначена для тестирования устойчивости приложения при пиковой активности пользователей, но не позволяет определить другие его характеристики. Масштабируемость можно исследовать с помощью установки Stepped Load (Инкрементальная нагрузка). При этом можно задавать начальное количество пользователей, шаг приращения и наибольшее их количество. В таком случае средство Load Test Runner, используемое для выполнения тестов, станет постепенно увеличивать нагрузку на приложение, пока не будет достигнут заданный максимум, и можно проанализировать, как изменяется производительность системы с ростом числа ее пользователей.

Пользовательские тесты

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

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

Пакетные тесты

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