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

Рис. 14.15. Редактор Web-теста.

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

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

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

146

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

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

147

Лекция 16. VSTS: поддержка различных моделей процесса

Поддержка шаблонов процесса

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

При создании в VSTS каждого нового проекта, сразу после выбора имени проекта, пользователь выбирает шаблон процесса разработки для этого проекта. Весь последующий процесс создания проекта определяется этим шаблоном. Шаблон может быть отдельно разработан или подправлен существующий.

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

1.Классификация (Classification) – описание областей работы, итераций и настройка интеграции с Microsoft Project. Области работы – это способ для категоризации работ в проекте. Примером области работы может быть как направление деятельности (разработка, тестирование, документирование и т.д.), так и работа над определенной частью проекта (серверная часть, клиент, инфраструктура и т.д.).

2.Отслеживание элементов работы (Work Item Tracing) – описание типов элементов работы, включая задание их жизненного цикла, определение набора элементов работы и запросов, создаваемых по умолчанию для нового проекта.

3.Отчеты (Reports) – описание отчетов проекта на специальном XML-языке RDL (Report Definition Language). Имеющиеся в шаблоне отчеты по умолчанию можно использовать «as is», а также исправлять и дополнять. Создание полностью нового вида отчетов является довольно трудоемкой работой.

4.Портал (Portal) – настройка шаблона портала в SharePoint с тестовым описанием процесса разработки, а также набором рабочих документов проекта (планов, дизайн-спецификаций и пр.). На основании этого шаблона будет автоматически формироваться портал для каждого нового проекта.

5.Группы и права доступа (Groups & Permissions) настраиваются для использования системы управления версиями, а также для различных правил жизненного цикла элементов работы.

6.Контроль версий (Source Control) – набор настроек для системы контроля версий, включая набор политик внесения изменения, позволения или запрещения множественного взятия файлов на редактирование и т.д.

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

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

148

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

Инструменты настройки. Для управления шаблонами процесса разработки используется утилита Process Template Manager (рис. 15.1), доступная из меню TFS Settings (эта утилита устанавливается вместе с Team Explorer). Этот менеджер позволяет загружать и выгружать шаблоны, а также определять шаблон, используемый для новых проектов по умолчанию.

Рис. 15.1. Менеджер шаблонов.

С точки зрения реализации шаблон процесса разработки является набором XMLфайлов, которые, пожалуй, никому не захочется редактировать «вручную». К счастью, существует инструменты, позволяющие значительно упростить этот процесс17. Эти инструменты входят в уже упоминавшийся нами выше пакет Power Tools. Эти инструменты доступны из меню Tools/Process Editor (см. рис. 15.2). Кратко перечислим и охарактеризуем их.

Редактор типов элементов работы, который позволяет редактировать определения типов элементов работы, включая наборы реквизитов и жизненный цикл. Может быть использован как для редактирования файлов с описанием типов элементов работы, экспортированных с помощью Process Template Manager, так и для редактирования типов, находящихся внутри одного шаблона процесса. Кроме того, этот редактор может быть использован для импорта/экспорта типов элементов работы в/из шаблон процесса, что особенно полезно при распространении сделанных изменений по разным проектам. Более подробно этот редактор уже рассматривался выше.

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

17 http://msdn.microsoft.com/en-us/vsts2008/aa718802.aspx.

149

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

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

Просмоторщик реквизитов элементов работы – это небольшая утилита, позволяющая просмотреть все используемые реквизиты всех типов элементов работы.

Рис. 15.2. Инструменты редактирования шаблона процесса.

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

18 Заметим, что помимо настраиваемых глобальных списков в TFS существуют и встроенные системные списки, связанные с различными аспектами деятельности: группы и пользователи, состояния элементов работы и причины перехода, списки итераций и областей работы и т.д.

150