Seminar:VSTS: тестирование

Материал из Wiki Test Lab
Перейти к: навигация, поиск

Назад    Главная
 


Источник

Дальше »


Содержание

15. VSTS: тестирование

Система отслеживания ошибок. Создание описания ошибки. Связь изменений исходных текстов ПО и ошибок. Система оповещений. Модульные тесты. Пакеты тестов. Автоматическое тестирование Web-приложений.


Выделим следующие возможности VSTS по тестированию:

  • интегрированная система отслеживания ошибок;
  • средства разработки модульных тестов;
  • средства организации тестовых пакетов;
  • автоматическое тестирование Web-приложений (в том числе и нагрузочное).

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

Система отслеживания ошибок

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

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


На рис. 15.1 представлено описание жизненного цикла элемента работы "ошибка" (Bug) из шаблона процесса VSTS под названием MSF for Agile 4.2. У этого типа элемента работы определено три состояния:

  • Active – ошибка нуждается в исправлении,
  • Resolve – ошибка исправлена,
  • Close – ошибка проверена и исправление принято.

На стрелках-переходах указана причины, в силу которых ошибка перешла в данное состояние. Опишем некоторые, самые часто встречаемые переходы.

В состояние Active ошибка попадает, во-первых, после своего создания – то есть тестеровщик нашел новую ошибку и создал соответствующий элемент работы (это начальное действие на картинке не показано). Далее, в это состояние ошибка может попасть из состояние Resolved, после того, как тестеровщик проверил исправление программиста и обнаружил, что тесты все равно "падают" (причина Test failed). Если исправление ошибки было проведено некорректно (поведение системы не соответствует желаемому), то ошибка переходит в состояние Active по причине Wrong Fix. Если же способ закрытия ошибки является неприемлемы (например, тестер не согласен, что данная ошибка является дубликатом другой), то используется причина Resolution Denied. Наконец, ошибка может перейти в стояние Active, если она вновь стала появляться – причины Reactivation и Regression. При этом для тестеровщика важно не создавать новую ошибку, а понять, что это старя, закрытая, вновь проявилась. Эта информация поможет разработчикам быстрее разобраться с исправлениями – проглядеть те изменения исходных текстов, которые закрывали эту ошибку и исправить их. При этом может очень эффективно работать связь, которую обеспечивает VSTS для элементов работ и изменениями в средстве контроля версий – что подробно обсуждалось в лекции о поддержке в TFS конфигурационного управления.


15-01.jpg

Рис. 15.1. Жизненный цикл.
В состояние Resolve ошибка переходит, во-первых, после того, как разработчик ее исправил. В это состояние разработчик может перевести ошибку еще и по тому, что это не ошибка, а свойство (тестеровщик неправильно понял требования к системе или проектную спецификацию) – причина As Designed. А также потому, что ошибка повторяет другую, найденную ранее ошибку (Duplicate), ошибка не воспроизводится у разработчика (Unable to reproduce) и т.д.

В состояние Close ошибка переходит, во-первых, когда тестеровщиек принял ее исправление (причина Fixed). Во-вторых, когда он согласился с мнением разработчика, что она повторная (Duplicated), не воспроизводится (Unable to reproduce) и пр. По этим же причинам сам разработчик может перевести ошибку в состояние Close прямо из состояния Active. Правда, это может быть не любой разработчик, а, например, технический руководитель проекта или архитектор. Все остальные разработчики могут не иметь прав переводит ошибки самостоятельно в состояние Close, а обязаны действовать через тестеровщиков.

Как создается описание ошибки. Создание новой ошибки может происходить либо с помощью пункта меню в Team Explorer "Team/Add Bug…", либо посредством добавления связанных элементов работы для задач, при реализации которых ошибки были обнаружены. Кроме того, провал автоматической сборки или прогона тестов может служить триггером для автоматического создания ошибки. Окно для описания ошибки показано на рис. 15.2.


15-02.jpg

Рис. 15.2. Автоматически созданная ошибка. Связь изменений исходных текстов ПО и ошибок. В лекции про конфигурационное управление мы подробно рассмотрели связь изменения исходников кода с элементами работы. Теперь посмотрим на то, как ошибка связан с этими изменениями (то есть мы смотрим на ту же задачу, но с другой стороны – со стороны элементов работы, и выбираем один специфический тип элемента работы – ошибку). Все изменения в коде, связанные с исправлением определенной ошибки, легко можно отследить используя закладку "Links" в диалоге описания ошибки. Так, на рис. 15.3 показано, что ошибка связана с пакетом изменений, внесенным в систему контроля версий.

15-03.jpg

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

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

15-04.jpg

Рис. 15.4. Управление подписками. В TFS, как показано на рис. 15.5, поддержаны следующие типы автоматических оповещений.

  • При изменении элемента работы (оповещение отправляется при изменении любого реквизита). Этот вид оповещений позволяет оперативно узнавать о появлении новых элементах работы и об изменении существующих. Например, разработчик может оперативно получать сообщения о переведенных на него ошибках.
  • Внесение изменений в систему контроля версий. Как правило, этот тип оповещения используется архитекторами или техническими лидерами команды для контроля качества вносимого кода посредством регулярной проверки вносимых изменений.
  • При автоматическом или ручном изменении атрибута "качество" в описании результатов автоматической сборки1). Этот тип оповещений позволяет руководителям проекта узнавать об изменении состояния проекта.
  • При завершении процесса автоматической сборки, не зависимо от результатов. Данный тип оповещений полезен для всех участников проекта.

15-05.jpg

Рис. 15.5. Настройка получателей оповещений. Оповещения, рассылаемые TFS, содержат только базовую информацию о произошедшем событии и ссылку, позволяющую просмотреть детали о события через Internet Explorer, на Share Point портале проекта. В частности, информация о результатах автоматической сборки и о тех ошибках, исправления которых вошли в соответствующую ей версию исходных кодов проекта, представлена на рис. 15.6.


15-06.jpg

Рис. 15.6. Результаты автоматической сборки.

Модульные тесты

Модульные тесты как средство повышения качества программного обеспечения появились достаточно давно, однако они долго оставались не поддержанными продуктами Microsoft. Впервые поддержка модульных тестов появилась в Visual Sutiod 2005 и доступна в изданиях Professional и выше (в том числе, и во всех изданиях группы Team).

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

Исторически одним из первых популярных инструментов, ориентированных на организацию модульного тестирования, был jUnit для Java-приложений, клонированный затем под многие другие платформы. Для платформы .NET пионером здесь являлся nUnit, который до сих пор занимает лидирующую позицию в этой нише. Однако, лидерство nUnit серьезно пошатнулось с появлением поддержки модульных тестов в Visual Studio. По сравнению с классическими системами Visual Studio обладает рядом следующих преимуществ.

  • Поддержана полная интеграция в пользовательский интерфейс, включая запуск и анализ результатов (для других систем интеграция доступна за отдельные деньги и не так обширна).
  • Реализованы возможности для легкой интеграции в средства автоматической сборки (только для TFS Team Build).
  • Предложены дополнительные средства для описания процедуры развертывания теста (больное место большинства остальных систем) и конфигурации других аспектов выполнения.
  • Имеются средства автоматической генерации сигнатур тестов и средств доступа к приватным частям тестируемых классов.
  • Поддержано управление тесnовыми данными, а также тестами, использующими данные на уровне платформы.


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


Пакеты тестов

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


15-07.jpg

Рис. 15.7. Пакет с иерархией тестов. Для создания тестового пакета можно воспользоваться меню "Create New Test List", как показано на рис. 15.8, и после этого откроется окно для задания имени нового пакета и определения его места в иерархии тестовых пакетов (см. рис. 15.9). В том случае, если для решения уже создан файл метаданных, пакет тестов будет добавлен к нему, если же файла метаданных еще создано не было, он будет создан автоматически.

15-08.jpg

Рис. 15.8. Создание списка тестов.

15-09.jpg

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

15-10.jpg

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


15-11.jpg

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


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


15-12.jpg

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


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

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

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

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

Если же тестовое окружение распознало элемент интерфейса, то такой тест-скрипт оказывается более "живучим". Это происходит на уровне перехвата сообщений на уровне операционной системы (в частности, 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", выбрав в возникшем диалоге (рис. 15.13) тип теста Web Test.


15-13.jpg

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


15-14.jpg

Рис. 15.14. Запись шагов тестреровщика Web-приложения в Internet Explorer. После окончания записи будет автоматически сгенерирован тест, включающий все отправленные на сервер http-запросы и все полученные ответы (см. рис. 15.15). При этом генератор автоматически добавит некоторые правила, по которым будет проверятся корректность работы теста.

15-15.jpg

Рис. 15.15. Редактор Web-теста. Для каждого из шагов теста можно, с помощью визуального редактора, добавить дополнительные проверки или опции, управляющие ходом выполнения: поиск подстроки в ответе сервера (тексте полученного HTML), валидацию HTML через задание регулярного выражения, проверка наличия или отсутствия определенных тегов или атрибутов на странице и т.д. Допускается также возможность разработки собственных правил на любом .NET языке. В тех же случаях, когда гибкости редактора недостаточно, можно сгенерировать С# код для данного теста и реализовать необходимую логику "вручную".

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

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

15-16.jpg

Рис. 15.16. Web-тесты в пакетах тестов.


Дальше »

Личные инструменты