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

Выделим следующие возможности 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.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.2. Автоматически созданная ошибка.

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

увеличить изображение
Рис. 15.3. Отслеживание изменений по ошибке.

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

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

Рис. 15.4. Управление подписками.

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

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

увеличить изображение
Рис. 15.5. Настройка получателей оповещений.

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

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

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

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

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

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

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

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