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




Скачать 209.17 Kb.
НазваниеТесты Пакеты тестов
Дата публикации08.03.2013
Размер209.17 Kb.
ТипТесты
uchebilka.ru > Бухгалтерия > Тесты

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


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

Поддержка шаблонов процесса. Инструменты настройки. Обзор существующих шаблонов. MSF for Agile Software Development. Scrum.

Содержание


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

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

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

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

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

  • Обзор существующих шаблонов

  • MSF for Agile Software Development

  • Scrum



Выделим следующие возможности 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, а его реализация соответствует большинству стандартных пакетов в этой области, мы не будем останавливаться на этой возможности более подробно.
^

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


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



Рис. 15.7.  Пакет с иерархией тестов.

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



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



Рис. 15.9.  Свойства нового списка тестов.

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



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

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



Рис. 15.11.  "Ручной" запуск пакета тестов.

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


Include="$(BuildProjectFolderPath)/../../TestSolution/TestSolution.vsmdi">

BAT/Main flow





Рис. 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.  Создание Web-теста.

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



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

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



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

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

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

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



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

^

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


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

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

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



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

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

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

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

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

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



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

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

Обзор существующих шаблонов


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

  • MSF for Agile Software Development – один из двух шаблонов, входящих в поставку TFS. Описывает достаточно простой вариант методологии MSF, используемый для разработки небольших проектов. Входит в стандартную комплектацию TFS.

  • MSF for CMMI – шаблон, используемый для более компаний, подразумевающий большее число типов элементов работы, а также больше формальных процедур разработки. Входит в стандартную комплектацию TFS.

  • Conchango SCRUM – шаблон, описывающий широко известную гибкую методологию SCRUM. Не входит в стандартную комплектацию TFS.
^

MSF for Agile Software Development


В этом шаблоне используются стандартные роли MSF, которые подробно обсуждались выше. В рамках поддержки процесса MSF for Agile соответствующий шаблон объявляет следующие основные типы элементов работы.

  • Сценарий (scenario) – функциональное требование к системе в виде некоторого сценария взаимодействия пользователя и системы, описанное на естественном языке как последовательность действий. Сценарий описывает только линейный путь развития событий, а для описания различных ветвлений используются дополнительные сценарии.

  • Требование к качеству сервиса (Quality of Service Requirement, QoS) – описание нефункционального требования к системе (то есть требования, которое не может быть выражено в терминах сценария взаимодействия), например, быстродействие и эффективность использования памяти.

  • Задача (Task) – задание на выполнение некоторой ограниченной по объему работы в проекте. Для каждой роли задачи могут иметь свою специфику: для разработчика это написание кода, реализующего часть сценария или направленного на достижение определенного качества, а для тестера – написание тестовых сценариев.

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

  • Риск (Risk) – некоторый аспект управления проектом, который может оказать влияние на ход проекта (как правило, негативное).

По умолчанию вместе с активацией этого шаблона на портале Share Point разворачиваются следующие документы.

  • План разработки в Microsoft Project, настроенный на импорт элементов работы, относящихся к области работы "Разработка". Используется для планирования работы разработчиков.

  • План разработки тестов – то же самое, только направленно на планирования работы тестеров.

  • Список проблем – список выявленных проблем, которые необходимо отслеживать (элементов работы с проставленным флагом "Is Issue").

  • Список (Check List) основных требований к проекту и их текущий статус.

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

Кроме того, для поддержки процесса используются следующие отчеты.

  • Ошибки по приоритету – показывает процентное соотношение в проекте ошибок разной степени серьезности и, таким образом, позволяет оценить степень эффективности тестирования.

  • Рейтинг ошибок – показывает соотношение вновь открытых ошибок к закрытым и оставшихся открытых. Позволяет судить о "здоровье" продукта.

  • Сборки – позволяет оценивать изменение качества сборок.

  • Скорость проекта – отчет, демонстрирующий насколько активно закрываются элементы работы, т.е. насколько быстро команда решает поставленные перед ней задачи.

  • Индикаторы качества – объединяет несколько индикаторов, включая количество дефектов, уровень тестового покрытия и т.д.

  • Отчет о нагрузочном тестировании – показывает результаты нагрузочного тестирования.

  • Регрессия – показывает тесты, которые проходили раньше, но теперь стали падать.

  • Реактивация – показывает то, сколько элементов работы заново переходит в активное состояния после исправления.

  • Связанные элементы работы – еще один способ просмотра связей элементов работы друг с другом.

  • Оставшаяся работа – показывает количество элементов работы, которые закрываются, а которые остаются и появляются с течением времени.

  • Незапланированная работа – показывает соотношение сделанного к запланированному и к незапланированному.

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

Scrum


Шаблон для работы в методологии Scrum был разработан сообществом разработчиков, в настоящий момент поддерживается компанией Conchagp и доступен здесь http://scrumforteamsystem.com. В этом шаблоне используются стандартные роли Scrum, которые подробно обсуждались выше. Определяются следующие элементы работы.

  • Product Backlog Item – высокоуровневое описание определенной функционального или нефункционального требования. Содержит описание, приоритет, установленный Produсt Owner, а также предварительную оценку трудоемкости. Во многом аналогичен сценарию MSF for Agile.

  • Sprint – содержит информацию о текущем или запланированном Sprint, включая текущее состояние и объем доступных для спринта ресурсов.

  • Sprint Backlog Item – более низкоуровневое описание задачи, сформированное самой командой. Аналогична задаче MSF.

  • Bug – ошибка, обнаруженная при тестировании. Ошибки становятся частью Product Backlog и получают приоритеты от Product Owner.

  • Sprint Retrospective – описание некоторого элемента (например, проблемы, удачного нововведения), идентифицированного в рамках Sprint Review Meeting и требующего дальнейшего изучения или выполнения некоторых действий.

  • Impediment – нечто, реально или потенциально мешающее эффективной работе команды. Во многом аналогично риску из MSF.

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

Среди поставляемых с шаблоном отчетов следует выделить следующие.

  • Bugs Count – показывает количество ошибок, отсортированных по состоянию и степени влияния на процесс тестирования.

  • Bugs Fixed and Found – соотношение найденных ошибок к закрытым.

  • Bug History – показывает количество открытых ошибок в соответствии с их влиянием на процесс тестирования, а также изменение этого количества со временем.

  • Bug Priority – показывает распределение ошибок по отношению их влияния на процесс тестирования.

  • Bug Resolution Time – показывает насколько быстро исправляются найденные ошибки.

  • Development To Test cycle time – демонстрирует, сколько проходит времени между выполнением работы и началом тестирования по этой работе.

  • Product Burndown – отчет, демонстрирующий, как быстро снижается количество работы, которую нужно сделать в контексте Product Backlog. Может показывать прогресс по дням или спринтам, а также позволяет увидеть общую тенденцию и предсказать дату завершения работ.

  • Product Cumulative Flow – показывает общее состояние Product Backlog в виде соотношения открытых и закрытых элементов, а также их изменения со временем.

  • Sprint Burndown и Сumulative Flow – тоже самое, только для Sprint Backlog.

Отдельного упоминания заслуживает система Task Board for Team System, которая позволяет визуализировать представления основного средства управления и мониторинга в Scrum – доски с задачами. Эта система получает информацию о всех элементах Sprint Backlog с сервера и визуализирует их в виде стикеров на доске, позволяя изменять их состояния путем перетаскивания, см. рис. 16.3. Этот продукт можно бесплатно скачать по ссылке http://www.scrumforteamsystem.com/en/TaskBoard/default.aspx.



Рис. 16.3.  Доска задач




Добавить документ в свой блог или на сайт

Похожие:

Тесты Пакеты тестов iconПсихологический портрет Ххххнко Ххххны Хххховны, 29 лет, не замужем,...
По исполнению тестов в целом: тесты выполнены аккуратно, без нарушения инструкций

Тесты Пакеты тестов iconЕ. П. Савченко научная редакция, предисловие и комментарии
Книга представляет собой идеальное учебное пособие для тех кто занимается конструированием тестов (психологических, профессиональных,...

Тесты Пакеты тестов iconТранспортные пакеты и блок-пакеты пилопродукции пакетирование, маркировка,...
Настоящий стандарт распространяется на транспортные пакеты и лок-пакеты пилопродукции из древесины хвойных и лиственных пород, изготавливаемые...

Тесты Пакеты тестов iconМетоды профориентологии
Объективные тесты с выбором ответа. К ним относятся интеллектуальные тесты, тесты специальных способностей, а также тесты достижений,...

Тесты Пакеты тестов iconВ. П. Устинов Использование тестов достижений и критериально-ориентированных тестов
Использование тестов достижений и критериально-ориентированных тестов при оценке зун и срс в вузах : учеб метод пособие / В. П. Устинов....

Тесты Пакеты тестов iconЛитература Составить 12 тестов по теме: «Крокує осінь золота»
Савчук Л. П. §§ 22-25 выучить, выполнить 2 упражнения на выбор Стр. 109-110 выполнить тесты на отдельных листках

Тесты Пакеты тестов iconПрактическое задание sft. Ext. 04 Разработка тестов и тестовых сценариев revision history
Сам тест критического пути (насколько хватит времени – расписывайте идеи из чек-листа в полноценные тесты)

Тесты Пакеты тестов iconПрактическое задание sft. Ext. 04 Разработка тестов и тестовых сценариев revision history
Сам тест критического пути (насколько хватит времени – расписывайте идеи из чек-листа в полноценные тесты)

Тесты Пакеты тестов iconСборник тестов по курсу "Экономическая теория"
Из приведенных вариантов ответов только один может быть правильным. Тесты оцениваются по балльной системе, которая учитывается при...

Тесты Пакеты тестов iconТесты с номерами 1 200 и задачи №№1 100 приведены ниже
В задание контрольной работы входит: Записать номера правильных ответов на вопросы тестов с номерами, заданными вариантом; Решить...

Вы можете разместить ссылку на наш сайт:
Школьные материалы


При копировании материала укажите ссылку © 2013
контакты
uchebilka.ru
Главная страница


<