Материал: ВВПИ. Лекции

Рис. 14.10. Редактор список тестов.

Тестовые пакеты могут использоваться как для ручного прогона тестов определенной тематики (команда «Run checked», рис. 14.11), так и для автоматического прогона в рамках автоматической сборки.

Рис. 14.11. «Ручной» запуск пакета тестов.

Указать тесты, которые будут запускаться при определенной сборке можно при создании файла с описание сборки MsBuild, или в последствии через модификацию проекта MsBuild. В первом случае достаточно на соответствующем шаге мастера выбрать файл метаданных и отметить галочками интересующие пакеты тестов (рис. 14.12). Во втором случае необходимо открыть проект MsBuild в редакторе XML, найти элемент MetaDataFile, или в писать необходимые пакеты вручную:

141

<MetaDataFile Include="$(BuildProjectFolderPath)/../../TestSolution/TestSolution.vsmdi"> <TestList>BAT/Main flow</TestList>

</MetaDataFile>

Рис. 14.12. Выбор пакета тестов при автоматической сборке.

Автоматическое тестирование Web-приложений

Capture & Playback подход. Этот подход к тестированию пользовательских интерфейсов выглядит очень эффектно и основан на следующей идее. Тестеровщик проходится мышкой по окнам, пунктам меню и другим элементам интерфейса. Специальная программа записывает его шаги и потом их воспроизводит в пакетном

именно было нажато мышкой на экране и создает соответствующий код в специальном скрипте. Потом этот скрипт «прогоняется» в пакетном режиме, воспроизводя действия тестеровщиков. Весь вопрос в том, каким образом распознается клик тестеровщика мышкой. Идеально, когда этот клик связывается с соответствующим элементом управления интерфейса. То есть если тестеровщик нажал кнопку в каком-то диалоге, то в скрипте эта информация сохраняется в полном объеме. Другая, более грубая ситуация имеет место тогда, когда тестовое окружение не может распознать, какой элемент

142

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

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

Если же тестовое окружение распознало элемент интерфейса, то такой тест-скрипт оказывается более «живучим». Это происходит на уровне перехвата сообщений на уровне операционной системы (в частности, Windows). Но для того, чтобы это было возможно, код приложения должен быть написан «правильным» образом. Далеко не все интерфейсные приложения написаны «правильно».

То, насколько успешно для конкретного приложения можно применить данный подход, определяется несколькими факторами. Основным является то, какая используется платформа (например, Java Swing, AWT, Windows Forms, WPF, etc.) и дополнительные библиотеки с элементами пользовательского интерфейса. Наиболее зрелой платформой с этой точки зрения на данный момент является MS Windows Forms.

Capture & Playback при тестировании Web-интерфейсов. В случае с тестированием Web-интерфейса ситуация с точностью распознавания элементов управления (interface controls) значительно проще, чем при тестировании произвольного пользовательского интерфейса. Взаимодействие с сервером происходит по строго описанному протоколу HTTP, что позволяет при записи перехватить отправляемые и получаемые сообщения. Кроме того, визуальное представление страницы задано в структурированном формате HTML, что позволяет легко опознать отдельные элементы на странице.

В издание Visual Studio Team Edition for Software Testers включен дополнительный пакет, облегчающий автоматизацию тестирования Web-приложений методом Capture & Playback. Он позволяет, как автоматически генерировать просты тестовые сценарии на основе записи действия пользователя, так и писать более точные тесты на любом языке платформы .NET.

Добавить новый Web-тест к решению можно с помощью команды «Test/New Test», выбрав в возникшем диалоге (рис 14.13) тип теста Web Test.

143

Рис. 14.13. Создание Web-теста.

После создания нового теста автоматически будет запущена процедура записи сценария теста в браузере (см. рис. 14.14). На этом этапе достаточно ввести www-адрес приложения, которое следует протестировать, после чего выполнить тестовый «проход» по Web-интерфейсу непосредственно в браузере.

144

Рис. 14.14. Запись шагов тестреровщика Web-приложения в Internet Explorer.

После окончания записи будет автоматически сгенерирован тест, включающий все отправленные на сервер http-запросы и все полученные ответы (см. рис. 14.15). При этом генератор автоматически добавит некоторые правила, по которым будет проверятся корректность работы теста.

145