Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘Visual Studio’

Работа с контейнерами и сервисами на основе Docker и Visual Studio Team Services

Posted by Шамрай Александр на Март 22, 2017

Реклама

Posted in Microsoft, Team Foundation Server, Uncategorized, Visual Studio | Отмечено: , , , , , | Leave a Comment »

Руководство по Закодированным Тестам ИП. Повышение производительности Закодированных тестов ИП

Posted by Шамрай Александр на Сентябрь 9, 2013

Введение

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

Лучшей практики программирования

Установите имя Name/ID для всех элементов управления, которые будут использоваться в закодированном тесте ИП. Это особенно важно для формы или страницы с большим количеством одинаковых типов элементов управления. Поиск элемента управления с идентификатором выполняется гораздо быстрее, чем поиск на основе внутреннего текста или другого атрибута. Например, поиска ссылки на веб-странице с несколькими тысячами ссылок без использования идентификатора может занять до 50 секунд. Тот же поиск для ссылки с идентификатором — секунды.

Тюнинг Поиска – Совпадение с точной иерархией

Установите Playback.PlaybackSettings.MatchExactHierarchy = true. Изменение этого параметра сразу же ничего не изменит в производительности тестов, которые по-прежнему будут проходить. Этот параметр также делает менее устойчивым тест перед изменениями, потому что модуль воспроизведения будет искать элемент точной по той иерархии, в какой он был найден перед падением теста. Идея здесь заключается в установке переключателя так, чтобы модуль воспроизведения искал соответствие только точной иерархии, и мы сможем заметить для некоторых тестов сбои (предположительно завершатся с ошибкой более медленнее тесты). Тесты, которые упадут, проходят через длительные пути поиска, и мы должны будем реструктурировать их, насколько это возможно, для использования критерия точного соответствия, таким образом улучшая общее тестирование. Можно переключить этот параметр в значение true для большинства тестов, но оставить как false, для тестов, выполняемых в более динамичном пользовательском интерфейсе, который не может быть реструктуирован для использования с точным совпадением.

Тюнинг Поиска – Ожидание готовности

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

Параметры воспроизведения, которые влияют на время выполнения

Следующие параметры на основе таймера могут повлиять на время выполнения теста. Их можно настроить, основываясь на среде и характеристиках приложения. Все время в миллисекундах.

Общее время, на которое движок воспроизведения «приостанавливается» между действиями, по умолчанию установлено 100 миллисекунд, это также минимальное значение.

Playback.PlaybackSettings.DelayBetweenActions = 200; //200 milliseconds

Общее время, которое модуль воспроизведения тратит на поиск элемента, по умолчанию — 120 секунд.

Playback.PlaybackSettings.SearchTimeout = 20000; //20 seconds

Общее время, которое модуль воспроизведения будет ожидать готовности элемента управления, по умолчанию 60 секунд.

Playback.PlaybackSettings.WaitForReadyTimeout = 30000; //30 seconds

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

Playback.PlaybackSettings.ThinkTimeMultiplier = 2;

Определение задержек при поиске

Используйте средство ведения журнала HTML для устранения проблем производительности, связанных с:

  • Интеллектуальным сопоставлением
  • Ненужных движений мыши с и без параметра «Продолжить при возникновении ошибки».
  • Задержек при ожидании готовности
  • Пропуском промежуточной активации элементов

Чтобы включить HTML журнал установите настройку EqtTraceLevel больше 0 в файле QtAgent32.exe.config.

  • Для EqtTraceLevel со значением >= 3 скриншоты снимаются для каждого действия.
  • Для EqtTraceLevel со значениями 1 и 2 скриншоты снимаются только для действий с ошибкой.

<system.diagnostics>

<switches>

<!— You must use integral values for «value».

Use 0 for off, 1 for error, 2 for warn, 3 for info, and 4 for verbose. —>

<add name=»EqtTraceLevel» value=»4″ />

</switches>

</system.diagnostics>

Если вы хотите отключить создание скриншотов независимо от уровня EqtTraceLevel, добавьте следующую запись ключа в файле конфигурации:

<appSettings>

<add key=»EnableSnapshotInfo» value=»false»/>

<add key=»StopTestRunCallTimeoutInSeconds» value=»5″/>

<add key=»LogSizeLimitInMegs» value=»20″/>

<add key=»CreateTraceListener» value=»no»/>

<add key=»GetCollectorDataTimeout» value=»300″/>

</appSettings>

ПРЕДУПРЕЖДЕНИЕ

Способ включения ведения журнала HTML изменился между RC и RTM Visual Studio 2012. В RC также нужно установить ключ EnableHtmlLogger. Процесс для включения функции в RC является следующим:

Чтобы включить средство ведения журнала HTML в релиз-кандидате (RC), установите EqtTraceLevel > 0 в файле QtAgent32.exe.config. Установите EqtTraceLevel > 3 для создания скриншотов для каждого действия.

<system.diagnostics>

<switches>

<!— You must use integral values for «value».

Use 0 for off, 1 for error, 2 for warn, 3 for info, and 4 for verbose. —>

<add name=»EqtTraceLevel» value=»4″ />

</switches>

</system.diagnostics>

Мы также должны установить EnableHtmlLogger=true для включения возможности ведения журнала HTML.

<appSettings>

<add key=»EnableHtmlLogger» value=»true»/>

<add key=»EnableSnapshotInfo» value=»true»/>

<add key=»StopTestRunCallTimeoutInSeconds» value=»5″/>

<add key=»LogSizeLimitInMegs» value=»20″/>

<add key=»CreateTraceListener» value=»no»/>

<add key=»GetCollectorDataTimeout» value=»300″/>

</appSettings>

Ниже снимок экрана HTML Logger и мы сразу видим, что выполняются движения мыши, и я могу видеть пример задержек ожидания готовности, оценивая время в левой колонке:

Рисунок – HTML Logger – Активность мыши

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

Рисунок HTML Logger – Продолжение при ошибке

Вот пример, когда используется Интеллектуальное сопоставление. Модуль воспроизведения по существу говорит нам, что он не нашел именно то, что он искал, но есть что-то похоже. Также обратите внимание, что этот шаг занимает более 19 секунд.

Рисунок HTML Logger – Интеллектуальное сопоставление

Этот рисунок демонстрирует результаты, когда включено MatchExactHierarchy.

Рисунок HTML Logger – Точное совпадение с иерархией

Избегание записи ненужных действий

При тестировании веб-страницы для изменений подсказки или меню, движок записи ищет изменения свойств во время движения мыши, чтобы выяснить, если есть необходимость записать наведение. Поведение по умолчанию модуля записи может привести к записи длительных зависаний. Если вы не хотите тестировать функциональность наведения, измените файл CodedUITestBuilder.exe.config и добавьте следующее:

<add key=»ImplicitHoverLevel» value=»1″>

Если вы хотите тестировать поведение, рассмотрите следующие ограничения.

  • IgnoreClassNameChanges = 2 — изменения имен класса CSS будут игнорироваться
  • IgnoreMouseMoveChanges = 4 — изменения свойств перемещения мыши будут игнорироваться
  • IgnorePostHoverChanges = 8 — изменения свойств после наведения указателя мыши (как использование таймера для изменения свойства) будут игнорироваться.

Эти вещи могут быть или могут не быть вместе, например

  • IgnorePostHoverChanges = 6 — изменение свойств при движении мыши и изменения имен класса CSS будут игнорироваться

http://blogs.msdn.com/b/shivash/archive/2011/01/24/hover-recording-in-coded-uitest-builder-and-microsoft-test-manager.aspx

MaxDepth

Если вы пишете код поиска и используете возможности интеллектуального совпадения можно и следует рассмотреть возможность использования свойства MaxDepth для ограничения глубины в дереве элементов управления, когда поисковая система ищет заданный элемент управления. Если элемент управления не может обоснованно использовать глубину уровня 3, установите MaxDepth 2 и оградите движок воспроизведения от необходимости поиска глубже, чем элемент управления может быть в дереве элементов управления.

myCell.SearchProperties.Add (** другие свойства поиска **)

myText.SearchProperties.Add (WpfText.PropertyNames.MaxDepth, 1);

http://blogs.MSDN.com/b/tapas_sahoos_blog/Archive/2011/05/10/Test-Automation-for-Silverlight-DataGrid-in-Coded-UI-Test.aspx

WebWaitForReadyLevel

WebWaitForReadyLevel по умолчанию равно 0, что является наиболее надежным параметром таймера и отслеживает поведение AJAX. Отслеживание выполняется путем инъекции сценария в страницу. Установка WebWaitForReadyLevel 1 упускает инъекцию отслеживания сценария таймера. Установка WebWaitForReadyLevel 2 упускает вставку отслеживания сценария AJAX. Эти значения могут быть или могут не быть вместе, установка WebWaitForReadyLevel значений 1, 2 или 3 помогут улучшить производительность, но тест будет менее надежные. Если добавление этих инъекций сценариев вызывает любые изменения поведения к приложению, попробуйте установить параметр WebWaitForReadyLevel в 4 для проблем с таймером, или 8 для проблемы ajax, или 12 в обоих случаях. Это не будет иметь большого влияния на производительность.

Измените файл QtAgent32.exe.config, чтобы изменить эти настройки:

<appSettings>

<add key=»EnableHtmlLogger» value=»true»/>

<add key=»EnableSnapshotInfo» value=»true»/>

<add key=»WebWaitForReadyLevel» value=»3″ />

<add key=»StopTestRunCallTimeoutInSeconds» value=»5″/>

<add key=»LogSizeLimitInMegs» value=»20″/>

<add key=»CreateTraceListener» value=»no»/>

<add key=»GetCollectorDataTimeout» value=»300″/>

</appSettings>

Более детально о повышении производительности Закодированных Тестов ИП

http://blogs.msdn.com/b/vstsqualitytools/archive/2009/08/10/configuring-playback-in-vstt-2010.aspx

http://blogs.msdn.com/b/visualstudioalm/archive/2012/02/01/guidelines-on-improving-performance-of-coded-ui-test-playback.aspx

http://blogs.msdn.com/b/vstsqualitytools/archive/2011/07/06/improving-the-performance-of-your-coded-ui-tests.aspx

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , , , , | Leave a Comment »

Практические занятия по Visual Studio 2012 ALM

Posted by Шамрай Александр на Июнь 21, 2013

Ниже приведены практические работы, которые использовались в Новосибирске и Хабаровске. Английские исходники и виртуальная машина для данных работ находится п ссылке: http://aka.ms/VS11ALMVM

Гибкое управление проектами в Visual Studio Team Foundation Server 2012

Разработка оптимального ПО — создание раскадровок и сбор отзывов от заинтересованных лиц с помощью Visual Studio 2012

Делаем работу разработчиков более продуктивной с Team Foundation Server 2012

Изучение кода с использованием инструментов архитектуры в Visual Studio Ultimate 2012

Визулизация ветвления и объединения в Visual Studio Team Foundation Server 2012

Отладка с использованием IntelliTrace в Visual Studio Ultimate 2012

Модульное тестирование с помощью Visual Studio 2012 MS Test, Nunit, X-unit.net и Code Clone

Диагностика проблем в промышленной среде с помощью IntelliTrace и Visual Studio 2012

Проектирование и выполнение ручных тестов с использованием Microsoft Test Manager 2012

Введение в тестирование с использованием закодированных автоматических тестов в Visual Studio Ultimate 2012

Posted in Семинары | Отмечено: , | Leave a Comment »

Руководство по управлению тестовыми выпусками

Posted by Шамрай Александр на Май 14, 2013

Перевел очередное руководство от рейнджеров. Данное руководство рассказывает о возможных вариантах управления выпусками для тестирования такими как переход от выпуска к выпуску, от итерации к итерации, управление тестами в рамках нескольких ветвей, а также описывает различные варианты отчетности. Руководство содержит концептуальное описание сценариев управления тестированием, а также лабораторные работы. Полный набор материалов по руководству управления тестовыми выпусками можно скачать здесь: http://vsartestreleaseguide.codeplex.com/

Содержание

Практические задания

Posted in Microsoft, Team Foundation Server, Test Release Management Guide, Visual Studio | Отмечено: , , , , | Leave a Comment »

Руководство по управлению тестовыми выпусками. Вступление

Posted by Шамрай Александр на Май 14, 2013

<<Перейти к содержанию

Предисловие

Мы создавали продукт Управления жизненным циклом приложения (ALM) Visual Studio 2010 с видением как разрушить проблемы, которые препятствуют качеству приложения. Microsoft Test Manager (MTM) — ключевой инструмент в этом арсенале, который обеспечивает тестировщиков средой комплексного тестирования, где они могут просто выполнять управление всеми тестовыми случаями, их выполнение и создание отчетов о своих мероприятиях. Поскольку адаптация MTM выросла, управление версиями — область, к которой у многих пользователей MTM часто есть вопросы. Какие есть наиболее успешные практики, которые основываются на размере проекта или методологии разработки? Как мне структурировать свои планы тестирования? Как мне генерировать надлежащие отчеты для выпуска? Учитывая число артефактов тестирования, доступных для использования и различных практик управления версиями, это довольно сложная проблема для обсуждения.

Руководство по Управлению Тестовыми Выпусками Рейнджеров рассматривает эти вопросы и обеспечивает ряд лучших практик, которые охватывают весь поток операций — от создания тестового набора до генерации отчетов о тестировании для каждого выпуска. И кто лучше создаст руководство, чем эксперты, которые экстенсивно используют продукт в проектах различной природы? Это Рейнджеры. Они дистиллировали свой опыт реального использования MTM, с глубоким использованием новой функциональности копирования доступную в ALM Visual Studio 2012, и придумали всестороннее руководство, вместе с практическими работами. Истории покрывают палитру вариантов выпуска и обеспечивают детализированное руководство о том, как структурировать артефакты для различных выпусков, а также как беспрепятственно переходить от выпуска к выпуску. Пользователи с различным уровнем знаний и опыта сочтут этот документ ценным в их путешествиях с MTM.

Anutthara Bharadwaj

Введение

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

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

  • Принимает методологию Microsoft Visual Studio Scrum (обеспечиваются примеры основанные на шаблоне процесса Visual Studio 2012 Scrum),
  • Не ссылается на общие практики Microsoft Test Manager (см. ссылки),
  • Адресуемые сценарии просты так, чтобы общие принципы и методы не были скрыты большим количеством рабочих элементов и специфически сложной ситуацией

Эти ограничения были приняты так, чтобы руководство могло успешно:

  • Кратко передать существенные принципы.
  • Гарантировать распознавание и знакомство с концепциями и практиками.
  • Сохранить документ довольно кратким и простым для чтения.

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

Рейнджеры Visual Studio ALM

Рейнджеры ALM Visual Studio — специальная группа с членами из Группы продуктов Visual Studio, Microsoft Services, Microsoft Most Valuable Professionals (MVP) и Лидеров Сообщества Visual Studio. Их миссия состоит в том, чтобы предоставить внештатные решения недостающих возможностей и руководств. Постоянно растущие Материалы Рейнджеров доступны онлайн.

Участники

Anutthara Bharadwaj, Bob Hardister, Brian Blackman, Clemens Reijnen, Hassan Fadili, Jens Suessmeyer , Lukasz Gratkowski, Mattias Sköld, Ravi Shanker, Sai Charan Chirravuri

<<Перейти к содержанию

Posted in Microsoft, Team Foundation Server, Test Release Management Guide, Visual Studio | Отмечено: , , , , | Leave a Comment »

Руководство по управлению тестовыми выпусками. Приложение

Posted by Шамрай Александр на Май 14, 2013

<<Перейти к содержанию

Ссылки

Руководство Microsoft MSDN по управлению тестированием http://msdn.microsoft.com/en-us/library/ms182409.aspx
Копирование и клонирование Тестовых Наборов и Тестовых Случаев http://msdn.microsoft.com/en-us/library/vstudio/hh543843.aspx
Руководство по инструментам тестирования Visual Studio http://vsartesttoolingguide.codeplex.com
Инструмент миграции для Тестовых случаев от Shai Raiten (обрабатывает общие шаги) http://blogs.microsoft.co.il/blogs/shair/archive/2011/03/20/test-case-migrator-between-projects-wpf-metro.aspx
Инструмент отчетности Test Scribe http://visualstudiogallery.msdn.microsoft.com/e79e4a0f-f670-47c2-9b8a-3b6f664bf4ae
Расширение Test Scribe http://testscribeextended.codeplex.com
SQL Server Reporting Services http://msdn.microsoft.com/en-us/library/ms159106.aspx
Страница часто задаваемых вопросов по отчетности управления тестовыми случаями Microsoft http://blogs.msdn.com/b/vstsqualitytools/archive/2011/10/14/test-case-management-tcm-reporting-frequently-asked-questions-part-1.aspx
http://blogs.msdn.com/b/vstsqualitytools/archive/2011/11/11/test-case-management-tcm-reporting-frequently-asked-questions-part-2.aspx
Сообщество Расширений Отчетов TFS http://communitytfsreports.codeplex.com
Идентификация влияния изменений кода на тесты http://msdn.microsoft.com/en-us/library/dd264992.aspx

Другие ресурсы Рейнджеров ALM

Понятие Рейнджер ALM – http://aka.ms/vsarunderstand

Домашняя страница Рейнджеров Visual Studio ALM – http://aka.ms/vsarmsdn

Решения Рейнджеров Visual Studio ALM Ranger Solutions – http://aka.ms/vsarsolutions

<<Перейти к содержанию

Posted in Microsoft, Team Foundation Server, Test Release Management Guide, Visual Studio | Отмечено: , , , , | Leave a Comment »

Руководство по управлению тестовыми выпусками. Отчетность

Posted by Шамрай Александр на Май 13, 2013

<<Перейти к содержанию

Темы
  • Введение в отчетность
  • Документирование плана тестирования и тестовых случаев
  • Отчетность о ходе тестирования по плану тестирования
  • Поддержка отчетности для сценариев, затронутых в этом руководстве

Цель этой главы состоит в том, чтобы дать представление об улучшении функций Microsoft Test Manager и Team Foundation Server для документирования и отчетности по тестовым действиям и результатам управления тестовыми выпусками.

Microsoft Test Manager хранит подробные записи каждого выполнения тестовых случаев. Это позволяет сделать отчетность управления тестовыми выпусками вашего проекта согласно вашим потребностям. Поскольку большинство тестовых артефактов не сохраняются как рабочие элементы, вы не можете использовать запросы по рабочим элементам для выполнения всех требуемых отчетов для управления тестовыми версиями.

Для документирования и создания отчетов о тестовых активностях и результатах тестирования есть несколько различных источников отчетности, которые Вы можете использовать. Три общих отчета:

  • Отчеты SQL Server Reporting Services (SSRS)
  • Отчеты Excel
  • TestScribe

Отчеты SQL Server Reporting Services

Вы можете получить доступ к отчетам SSRS из папки Reports Командного Обозревателя, Командный Веб-Доступ через браузер и через добавление Цифровых панелей к командному сайту проекта портала SharePoint. Есть много предопределенных отчетов, и вы можете также создать свои собственные специализированные отчеты.

Создание отчетов о выполнении тестирования по плану тестирования

В любой момент во время спринта вы можете отследить прогресс тестирования плана тестирования. Отчет о выполнении работ Плана тестирования обеспечен как часть шаблона процесса Visual Studio 2012 Agile. Отчет о выполнении работ Плана тестирования может использоваться для всех сценариев, описанных в этом руководстве. Это затрагивает следующие вопросы:

  • Сколько тестирования команда выполнила?
  • Команда, вероятно, закончит тестирование вовремя?
  • Сколько тестов осталось для выполнения?
  • Сколько тестов прошло?
  • Сколько тестов не прошло?
  • Сколько тестов заблокировано?

Пример Отчета о Выполнении Работ Плана Тестирования SSRS

Создание пользовательских отчетов SQL Server Reporting Services

Microsoft Test Manager хранит подробную запись каждого выполнения тестовых случаев. Это позволяет сделать отчеты Управления Тестовыми Выпусками вашего проекта согласно вашим потребностям. См. информацию в библиотеке MSDN для SQL Server Reporting Services.

Отчеты Excel

К ним можно получить доступ из папки Документы из Командного Обозревателя или Веб-доступа. Существует несколько предопределенных отчетов и вы можете также создать ваши собственные с помощью функций сводных таблиц Excel на основе куба Team Foundation Server Analysis Services.

Отчет Excel — Тестовая Активность

Отчет Тестовая Активность может помочь для контроля числа ручных тестов, которые команда выполнила в течение всего времени. Этот отчет доступен только после того, как команда создаст планы тестирования и начнет выполнять тесты с помощью Microsoft Test Manager. Вы можете использовать отчет Тестовая Активность, чтобы понять, как хорошо команда выполняет тесты. Этот отчет основывается на PivotChart, которые показывают последние четыре недели данных, которые были получены по результатам тестов и сохранены в хранилище данных. Это затрагивает следующие вопросы:

  • Тенденция ручных тестов, которые команда выполняет, последовательно увеличивается?
  • Вы идентифицируете какие-либо вопросы в тестовой активности, которое вы не смогли учесть?

Отчет Excel Тестовая Активность

Отчет Excel Анализ Тестовых Сбоев

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

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

Отчет Excel Анализ Тестовый Сбоев

TestScribe

Вы можете использовать инструмент TestScribe для документирования вашего плана тестирования и тестовых случаев. TestScribe – это расширение Microsoft Test Manager и его можно найти в галерее Visual Studio. После того, как Вы загрузите и установите TestScribe, вы увидите новый выбор Tools в выпадающем списке центра тестирования.

Меню Tools TestScribe

Использование TestScribe для документирования планов тестирования и тестовые случаев

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

Пример результирующего документа TestScribe для плана тестирования

Сводный отчет TestScribe Тестового Запуска

С помощью плагина TestScribe вы можете генерировать Сводный Отчет Запуска Тестов, чтобы получить обзор результатов выполнения тестов. Сводный Отчет Запуска Тестов выводит графики для:

  • Тестовых результаты
  • Тестовых сбоев по типу
  • Тестовых сбоев по анализу
  • Анализ тестовых сбоев упущенных тестировщиком

Также перечисляются тестовые запуски, непроанализированные тестовые сбои и ошибки, связанные с запуском тестов.

Пример Сводного отчета TestScribe о запуске тестов

Примечание Сводный отчет Тестового запуска может быть сгенерирован на основе любого числа выполнений тестов. Это позволяет создать сводку результатов тестов по определенному построению, определенному тестировщику или сводке по активностям тестирования начиная с определенной даты, просто сортируя и выбирая соответствующие тестовые запуски. (Чтобы выбрать несколько тестов, нажмите и держите SHIFT или клавишу CTRL).

Пример Сводного отчета TestScribe нескольких тестовых запусков

Предупреждение Сводный отчет Тестовых Запусков представляет только данные по выполнению тестов. Он не показывает число тестовых сценариев, которые не протестировали. Кроме того, выполнение тестового случая несколько раз будет показано несколько раз в отчете. Например, выполнение и прохождение тестового случая дважды соответственно покажет 2 пройденных тестовых случая.

Итоги

Этот раздел обеспечил введение в создание отчетов для управления тестовыми выпусками и некоторые отчеты в качестве примера относительно:

  • Документирования плана тестирования и тестовых случаев.
  • Отчетности о ходе тестирования по плану тестирования.
  • Поддержки отчетности для сценариев, затронутых в этом руководстве.

<<Перейти к содержанию

Posted in Microsoft, Team Foundation Server, Test Release Management Guide, Visual Studio | Отмечено: , , , | Leave a Comment »

Руководство по управлению тестовыми выпусками. От Выпуска к Выпуска

Posted by Шамрай Александр на Май 8, 2013

<<Перейти к содержанию

Темы
  • Переход к следующему выпуску
  • Упаковка и настройка выпусков
  • Клонирование тестовых случаев для нового плана тестирования
  • Управление сбоями регрессионных тестов

В этом сценарии «выпуск» означает, что версия разрабатываемого программного обеспечения завершена. Больше разработки, объединения, построения, тестирования или разработки программного обеспечения не будет проводиться в этой версии программного обеспечения. Продукт был «поставлен» и следующий спринт – это первый спринт следующей версии программного обеспечения.

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

  • Наш персонаж Кристину, которая является лидером команды тестирования в проекте.
  • Проект использует Microsoft Visual Studio Scrum 2.0 как шаблона процесса.
  • Проект использует декларативную классификацию рабочих элементов. Путь итерации — … \Release 1\Sprint 1.
  • Путь области не используется.
  • Кристин использует один план тестирования на итерацию.
  • Программное обеспечение разработано, протестировано и выпущено на рамках той же ветви (где используется не более, чем одна ветвь управления исходным кодом).

В нашем примере для проекта продукт выпускается в конце спринта 2.

Переход к следующему выпуску имеет некоторую схожесть с переходом к следующему спринту. Например, следующие требования управления тестовыми выпусками для перехода в следующий спринт также применимы при переходе в следующий выпуск. Лидер команды тестирования проекта Кристина должна:

  • Завершить эту работу максимально быстро и эффективно.
  • Обеспечить отчеты для выпуска 1 спринта 2, которые точны и полны.
  • Гарантировать, что план тестирования относительно спринта 1 из выпуска 2 настроен для обеспечения корректной отчетности по тестированию.
  • Убедиться, что отчетность для спринта 2 из выпуска 1 не будет затронута действиями выпуска 2 и спринта 1.

Однако, у Кристин есть следующие дополнительные требования, которые она не имела для спринта «без выпуска»:

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

Сценарий От Выпуска к Выпуску

Наш пример для проекта только что завершил спринт 2 выпуска 1, и выпуск 1 поставляется. Наш пример для проекта продвигается сразу к следующему выпуску, «выпуск 2». Кристина должна теперь создать план тестирования относительно спринта 1 выпуска 2. Снова, работа управления тестовыми версиями вовлечена в переход к следующему спринту нового выпуска, использует много общего из перехода к следующему спринту в том же выпуске. Кристина должна рассмотреть следующие элементы при определении содержания нового плана тестирования:

  • Регрессионное тестирование работы выпуска 1.
  • Новые тестовые случаи для запланированной работы по реализации в выпуске 2.
  • Незавершенное тестирование и работа, задержанная для выпуска 2.

Рекомендуемые практики

Проектный пример идет дальше к выпуску 2 и начинает планирование спринта 1. Как лидер команды тестирования Кристина должна будет:

  • Рассмотреть пользовательские истории из выпуска 1 и определить, какие будут регрессией, протестированной в первом спринте выпуска 2.
  • Закрывающиеся артефакты тестирования выпуска 1.
  • Определить, какие тестовые сценарии будут необходимы для первого спринта следующего выпуска.
  • Рассмотреть проектирование следующего плана тестирования для выполнения структурных улучшений и учета любых изменений в требованиях к отчетности.

Поскольку спринт 2 является последним спринтом выпуска, считаем план тестирования спринта 2 как план тестирования относительно целого выпуска. Это будет часто целесообразно, потому что последний спринт выпуска будет, вероятно, включать все тестирование, требуемое для приемки. В примере для проекта Кристина переименовала плана тестирования спринта 2 в «Спринт 2 Плана тестирования — для Выпуска 1». Он используется для проверки и принятия всей функциональности и возможностей выпуска 1.

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

Примечание Рекомендуемые практики приведены на концептуальном уровне. Они предназначены для передачи природы решения, а не обеспечения точных шагов выполнения работ. См. Управление Тестовыми Выпусками от Выпуска к Выпуску в Лабораторных Работах для ознакомления с процедурами и практическими примерами выполнения управления тестовым выпусками от релиза у релизу.

Клонируйте Выпуск 1

В конце выпуска оцените состояние работ и обновите артефакты тестирования соответственно так, чтобы:

  • Отчеты показывали выпуск 1 как закрытый.
  • Планирование спринта от выпуска 1 к выпуску 2 могло быть легко выполнено.
  • Все артефакты тестирования находились в корректном состоянии и присвоены корректному пути итерации.

Используйте MTM для обновления и закрытия плана тестирования выпуска 1.

Действие Руководство
Оценить Состояние Работ Идентифицируйте:

  • Пользовательские истории, которые будут повторно протестированы в спринте 1 выпуска 2.
  • Тестовые сценарии, которые будут регрессированы в спринте 1 выпуска 2.
  • Проверенные тестовые сценарии.
  • Неполные тестовые сценарии, для которых работа была задержана для спринта 1 выпуска 2.
  • Тестовые сценарии не выполненные в выпуске 1, для которых работа была задержана для спринта 1 из выпуска 2.
Проверить Состояние Тестового Случая и Путь Итерации
  • Все активные тестовые случаи находятся в Активном состоянии.
  • Все активные тестовые случаи назначены на путь итерации спринта 2 (… \Release1\Sprint2).
  • Проверьте, что тестовые случаи, которые никогда не выполнялись, назначены в журнал.
Проверить Состояние Общих Шагов и Путь Итерации
  • Все активные общие шаги находятся в Активном состоянии.
  • Все активные общие шаги назначены пути итерации спринта 2.
  • Проверьте, что общие шаги, которые никогда не выполнялись, назначены в журнал.
Обновить План Тестирования Выпуска 1
  • Установите состояние тестирования «проверенным» наборам в «Завершено».
  • Установите состояние тестирования для плана тестирования выпуска 1 в «Завершено».
  • Установите состояние для свойств плана тестирования выпуска 1 в «Неактивный».

Обновление и закрытие плана тестирования выпуска 1

Создайте базовую линию

Метод создания базовой линий меняется в зависимости от метода, используемого для классификации рабочих элементов (см. раздел ранее «Альтернативная Классификация Рабочих Элементов»). Следующая таблица подытоживает различия в зависимости от того, используются ли Декларативная Модель или Последняя Модель для классификации рабочих элементов.

Модель Создание базовой линии
Декларативная Базовая линия будет состоять из рабочих элементов, присвоенных спринтам под узлом пути итераций выпуска 1.
После выпуска эти рабочие элементы становятся базовой линией и больше не изменяются.
Последняя Базовая линия будет состоять из рабочих элементов, присвоенных:

  • Корневому пути области.
  • Спринтам под путем итерации узла выпуска 1.
Эти рабочие элементы становятся базовой линией, как только их путь области установлен в выпуск 1 (… \Release1). Рабочие элементы под этим узлом пути области могут тогда быть установлены только для чтения.

Различия в зависимости от Декларативной Модели и Последней Модели

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

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

Настройте новый план тестирования

Во время планирования выпуска 2 вы должны создать план тестирования относительно потребностей спринта 1 и затем добавить наборы, и тестовые случаи добавленные к плану так, чтобы:

  • Выбранные регрессионные тестовые случаи могли быть выполнены для пользовательских историй, завершенных в выпуске 1.
  • Новые тестовые случаи могли быть выполнены для пользовательских историй, назначенных спринту 1 из выпуска 2.

Используйте MTM для создания и настройки плана тестирования спринта 1.

Действие Руководство
Создать План Тестирования
  • Включайте номер спринта в имя плана.
  • Установите состояние тестирования плана тестирования спринта в «Планируется».
  • Установите даты начала и окончания плана тестирования так, чтоб они соответствовали датам начала и окончания спринта.
  • Установите путь итерации плана тестирования в \project\Release2\Sprint1.
  • Создайте один или более наборов для новых тестовых случаев, разработанных для возможностей выпуска 2.
  • Не создавайте набор для регрессионных тестовых случаев выпуска 1. Он будет создаваться, когда тестовые сценарии выпуска 1 будут клонироваться.
Клонировать Тестовые Случаи
  • Используйте команду TCM.exe Suites /Clone, чтобы создать набор регрессионных тестов в новом плане тестирования.
  • Команда /Clone:
    • Копирует тестовые случаи и общие шаги, используемые этими тестовыми случаями.
    • Создает ссылки от клонированных тестовых случаев к новым общим шагам.
    • Создает связанную ссылку от клонированного до исходного элемента.
  • Откройте Visual Studio Command Prompt из папки Visual Studio Tools во Все Программы, Microsoft Visual Studio 2011 и Visual Studio Tools.
  • Измените каталог на «… \Microsoft Visual Studio 2012\Common7\IDE»
  • Выполните TCM Suites /?, чтобы получить синтаксис для использования команды TCM Suites /Clone.

Создание и настройка плана тестирования спринта 1

Примечание Для 2012 RTM команда TCM Suites /Clone поддерживала только статические наборы тестов. С Обновлением Visual Studio №1, мы также поддерживаем опцию «/CloneRequirement»
Примечание Команда TCM Suites /Clone доступна только в Team Foundation Server 2012. Для Visual Studio 2010 возможно использование Test Case Migrator Tool от Shai Raiten. См. раздел Ссылки в приложении.
Действие Руководство
Назначить Новые Тестовые Случаи
  • Переименуйте «скопированный» набор тестов в новом плане.
  • Проверьте, что тестовые случаи и общие шаги в новом наборе являются новые рабочими элементами.
  • Проверьте связи и путь итерации в клонированных тестовых случаях и общи шагах:
    • У клонированный рабочий элемент должен быть связан ссылкой на исходный рабочий элемент.
    • Клонированные тестовые случаи должны быть связаны с клонированными общими шагами.
    • Путь итерации клонированных элементов должен быть \project\Release 2\Sprint 1.
Когда проект готов для начала тестирования спринта 1
  • Установите состояние тестирования плана тестирования спринт 1 в «Выполняется».

Проверка клонированных тестовых случаев

Примечание Примечание – создание регрессионных тестовых случаев
Тестовые случаи, которые являются частью базовой линии выпуска 1, были дублированы. Эти дубликаты используются в выпуске 2 для поддержки регрессионного тестирования и чтобы завершить любое тестирование, не выполненное в выпуске 1. Новые функции в Обновлении Visual Studio №2 создадут запись в истории в тестовом случае, когда выполняется клонирование. До этого вы можете пометить эти копии, используя пользовательский код причины, добавляя пользовательское поле индикатор, комментарий к истории или некоторым другим способом, таким образом, будет просто идентифицировать их при назначении в план тестирования.

Регрессионное тестирование

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

  • Регрессионный тестовый случай в текущем спринте был клонирован из снимка базовой линии.
  • Регрессионный тестовый случай тестирует требование (пользовательскую историю или элемент журнала продукта) в снимке базовой линии
  • Рассмотрите предупреждение ранее об использовании наборов основанных на требованиях и сносок для функций, представленных в Обновлении №1 и Обновлении №2 для Visual Studio 2012.
  • Регрессионное тестирование не принимает изменения в требованиях.
  • Не изменяйте рабочий элемент требования в снимке базовой линии, когда изменения требования должны быть внесены: клонируйте рабочий элемент требования в журнал или текущий спринт и пометьте изменения.

Когда Регрессионные Тесты Не Проходят

Создайте ошибку для регрессионного тестового случая. Затем рассмотрите использование одного из следующего ниже.

Примечание Примечание – соответствующие ссылки к требованиям и ошибкам
За исключением второго пункта, не сохраняйте ссылки в исходных тестовых случаях к требованиям (пользовательские истории и элементы журнала продукта) и ошибкам при клонировании тестовых случаев и общих шагов.
  1. Добавьте соответствующую ссылку от клонированного тестового случая к требованию. У этого подхода относительно меньше видимости. Ошибка не будет обнаруживаться в отчетах о состоянии требований, потому что у регрессионного тестового случая нет ссылки Тестирует/Тестируется к требованию в текущем спринте.
  2. Для большей видимости связывайте клонированный тестовый случай к выпущенному требованию, используя тип ссылки Тестирует/Тестируется. Это просто, эффективно и действительно отображается в отчетах о состоянии требования. Однако, это также подразумевает работу для выпущенного требования, нарушая изоляцию базовой линии.
  3. Для большей видимости и полной поддержки изоляции базовой линии, клонируйте рабочие элементы требования для нового спринта. Пометьте «нет никаких изменений» в требовании. Свяжите клонированный тестовый случай с новым требованием, используя тип ссылки Тестирует/Тестируется.

Итоги

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

<<Перейти к содержанию

Posted in Microsoft, Team Foundation Server, Test Release Management Guide, Visual Studio | Отмечено: , , , | Leave a Comment »

Руководство по управлению тестовыми выпусками. Работа с Несколькими Ветвями в Рамках Одного Выпуска

Posted by Шамрай Александр на Май 7, 2013

<<Перейти к содержанию

Темы
  • Влияние ветвления кода на управление тестовыми выпусками
  • Управление артефактами тестирования при работе с несколькими ветвями
  • Ветвление для разработки
  • Ветвление для выпусков

Этот сценарий описывает управление тестовыми выпусками тестирования при работе с несколькими ветвями. ALM Visual Studio Rangres публикуют лучшие практики управления и изоляции изменений кода в различных ситуациях. Эти рекомендации опубликованы в Руководстве по Ветвлениям ALM Visual Studio Rangres. Руководство по ветвлениями покрывает различные планы ветвления, подходящие для различных ситуаций.

Основной План Ветвления из Руководства по Ветвлениям ALM Visual Studio Rangres

Это руководство будет рассматривать управление тестовыми выпусками для основного плана ответвления, который включает ветвление для разработки и ветвление для выпуска. В примере для проекта будет использоваться для иллюстрации управление тестовыми выпусками при работе с несколькими ветвлениями. Профиль примера проекта включает следующие:

  • Наш персонаж Кристину, которая является лидером команды тестирования в проекте.
  • Проект использует Microsoft Visual Studio Scrum 2.0 как шаблона процесса.
  • Проект использует декларативную классификацию рабочих элементов. Путь итерации — … \Release 1\Sprint 1.
  • Путь области не используется.
  • Та же версия программного обеспечения это:
    • Разработанное и протестированная интеграция для ветви DEV.
    • Пройдены системные тесты для ветви MAIN.
    • Приемочные тесты пройдены и выпущено в ветви RELEASE.
    • Отдельные отчеты тестирования необходимы для ветвей DEV, MAIN, и RELEASE.

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

  • Обновить артефакты тестирования максимально быстро и эффективно.
  • Обеспечить отчеты, которые точны и полны для каждого ветвления.

Этот сценарий дает представление о том, как управлять артефактами тестирования, когда код ответвляется и объединяется.

Сценарий — Работа с Несколькими Ветвями

В примере для проекта тестирование реализации и интеграционное тестирование возможностей проводится на ветви DEV. Кристина устанавливает план тестирования для проведения интеграционного тестирования. Несколько из возможностей в ветви DEV готовы к системному тестированию и за следующие несколько дней будут объединены с ветвлением MAIN для системного тестирования.

Кристина должна рассмотреть следующее:

  • Тестовые случаи, если таковые имеются, запущенные в ветви DEV, которые должны также быть выполнены в ветви MAIN
  • Создание новых тестовых случаев, которые будут использоваться для системного тестирования в ветви MAIN

Кристина должна также подготовиться к приемочному тестированию, когда создается ветвь RELEASE. Приемочные тесты определены менеджером по продукту. Кристине будут необходимы следующие типы тестовых случаев для того, чтобы протестировать ветвь RELEASE:

  • Новый набор приемочных тестовых случаев.
  • Маленький набор случаев дымового тестирования повторно используемого от тестирования выполненного в ветви MAIN.
  • Тестовые сценарии для любых ошибок, найденных и исправленных во время приемочного тестирования.

В итоге:

  • Тестирование реализации возможности и интеграционное тестирование проводятся в ветви DEV.
  • Системное тестирование проводится в ветви MAIN.
  • Приемочное тестирование (UAT) проводится в ветви RELEASE.

Рекомендуемые практики

При работе с несколькими ветвлениями Кристина как лидер команды тестирования должна будет:

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

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

Примечание Рекомендуемые практики приведены на концептуальном уровне. Они предназначены для передачи природы решения, а не обеспечения точных шагов выполнения работ. См. Управление Тестовыми Выпусками с Несколькими Ветвлениями в Лабораторных Работах для ознакомления с процедурами и практическими примерами выполнения управления тестовым выпусками с несколькими ветвлениями.

Настройте план тестирования для интеграционного тестирования

Используйте отдельный план тестирования для тестирования ветви DEV в текущем спринте. Создайте этот план тестирования как часть планирования спринта как описано в разделе «От Спринта к Спринту» ранее.

Настройте план тестирования для системного тестирования

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

Примечание Не дублируйте тестовые случаи в той же версии программного обеспечения. Это сделает более трудным создание отчетов и отслеживание базовых линий.

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

Используйте MTM, чтобы создать новый план тестирования для поддержки системного тестирования в ветви MAIN.

Действие Руководство
Создать План Тестирования
  • Включайте имя ветвления и номер спринта в наименование плана.
  • Установите состояние тестирования плана тестирования в «Планируется».
  • Назначьте даты начала и окончания для плана тестирования так, чтоб они соответствовали датам начала и окончания спринта.
  • Настройте путь итерации плана тестирования в текущий спринт.
  • Настройте отличные тестовые наборы для уникальных вместо общих тестовых случаев.
Назначить Общие Тестовые Случаи
  • Добавьте необходимые тестовые случаи, где эти тестовые случаи уже используются в других планах тестирования текущего спринта.

Создание нового плана тестирования для поддержки системного тестирования в ветви MAIN

Примечание Чтобы снова использовать един тестовый случай, просто добавьте существующие тестовые случаи, которые уже используются, из одного плана в другой план. Чтобы снова использовать весь набор, используйте функцию «Создание тестовых наборов с помощью ссылок на существующие тестовые случаи», показанную в разделе От Спринта к Спринту ранее
Действие Руководство
Проверить Клонированные Тестовые Случаи в Новом Плане Тестирования
  • Добавьте тестовые случаи из элементов журнала, которые запланированы для тестирования в ветви MAIN во время спринта.
  • Установите их путь итерации на текущий спринт.
Проверить Статус, Состояние и Связи
  • Проверьте чтобы план тестирования, наборы, тестовые случаи и общие шаги находились в корректном статусе и состоянии, и что они связаны с корректными пользовательскими историями.
Проверить путь итерации
  • Проверить чтобы все тестовые случаи и общие шаги в плане тестирования были установлены для текущего спринта.

Для повторного использования одного тестового случая просто добавьте существующие тестовые случаи

Когда вы будете готовы начать тестировать построения из ветви MAIN, установите состояние тестирования плана тестирования в «Выполняется».

Настройте План Тестирования для Приемочного Тестирования

Когда создается ветвь RELEASE:

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

Используйте MTM, чтобы создать новый план тестирования для поддержки приемочного тестирования в ветви RELEASE.

Действие Руководство
Создать План Тестирования
  • Включайте имя ветви и номер спринта в наименование плана.
  • Установите состояние тестирования плана тестирования в «Планируется».
  • Установите даты начала и окончания для плана тестирования так, чтоб они соответствовали датам начала и окончания спринта.
  • Установите путь итерации плана тестирования на текущий спринт.
  • Настройте отличные тестовые наборы для уникального вместо общих тестовых случаев.
Назначить Общие Тестовые Случаи
  • Добавьте необходимые тестовые случаи где эти тестовые случаи уже используются в других планах тестирования текущего спринта.
Назначить Новые Тестовые Случаи
  • Добавьте тестовые случаи из элементов журнала, которые запланированы для тестирования в ветви RELEASE.
  • Установите их путь итерации в текущий спринт.
Проверить Статус, Состояние и Ссылки
  • Проверьте чтобы план тестирования, наборы, тестовые случаи и общие шаги находились в корректном статусе и состоянии, и что они связаны с корректными пользовательскими историями.
Проверить Путь Итерации
  • Проверьте чтобы у всех тестовых случаев и общих шагов в плане тестирования для спринта 1 установлен корректный путь итерации.

Создание нового плана тестирования для поддержки приемочного тестирования в ветви RELEASE

Когда проект будет готов начать тестировать сборки из ветви RELEASE, установите состояние плана тестирования ветви RELEASE в «Выполняется».

Итоги

Этот раздел описает управление тестовыми выпусками для поддержки работы с несколькими ветвями на основе основного плана ветвления Руководства по Ветвлениям ALM Visual Studio Rangres. Были также приведены рекомендуемые практики для управления артефактами тестирования этого сценария.

<<Перейти к содержанию

Posted in Microsoft, Team Foundation Server, Test Release Management Guide, Visual Studio | Отмечено: , , , | Leave a Comment »

Руководство по управлению тестовыми выпусками. От спринта к спринту

Posted by Шамрай Александр на Май 6, 2013

<<Перейти к содержанию

Темы
  • Переход к следующему спринту
  • Закрытие и планирование спринта
  • Примеры отчетов Управления Тестовыми Выпусками

В большинстве проектов разработки программного обеспечения, которые применяют гибкий подход, разработка выполняется в многократных спринтах или итерациях. Каждый спринт обычно предназначается для того, чтобы поставить инкремент функциональности программного обеспечения, который включает указанные требования (пользовательские истории или элементы журнала продукта) и исправленные ошибки. Тестирование программного обеспечения играет ключевую роль в каждом из этих спринтов, потому что команды тестирования должны проверить, был ли полный объем итерации поставлен и оттуда определить находится ли проект в хорошем состоянии. Итеративное тестирование включает написание тестовых случаев, организацию их в планы тестирования, назначение для выполнения и создания отчетов о результатах тестирования. Управление этими тестовыми активами может быть реальной проблемой, если нет никакого плана управления выпусками тестирования, которое служит руководством, когда Ваша команда переходит от одного спринта к другому.

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

  • Наш персонаж Кристина, которая является лидером команды тестирования в проекте.
  • Проект использует Microsoft Visual Studio Scrum 2.0 как шаблон процесса.
  • Проект использует декларативную классификацию рабочих элементов, где путь итерации …\Release 1\Sprint 1.
  • Путь области не используется.
  • Кристина использует один план тестирования на итерацию.

Сценарий от Спринта к Спринту

Наш пример для проекта только что завершил спринт 1. Программное обеспечение теперь готово к выпуску, и проект переходит к спринту 2.

Кристина, как лидер команды тестирования, должна теперь создать план тестирования относительно спринта 2, который включает:

  • Регрессионное тестирование завершенной работы спринта 1
  • Новые тестовые сценарии для запланированной реализации в спринте 2

Кроме того, Кристина должна учесть незаконченное и задержанное тестирование. Во-первых, есть тестовые сценарии, где необходимо больше тестирования. Во-вторых, есть тестовые сценарии, выделенные спринту 1, где протестированные пользовательские истории были задержаны для спринта 2.

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

Примечание «Базовая линия» тестового случая – это точное состояние или снимок рабочего элемента тестового случая в определенный момент времени. Team Foundation Server действительно обеспечивает историю рабочих элементов, но не поддерживает управление версиями рабочих элементов. Поэтому, поддержка базовой линии тестирования не означает внесение изменения в план тестирования определенной базовой линии и его тестовые случаи после того, как базовая линия будет установлена. См. предупреждение ранее относительно наборов на основе требований и как Microsoft рассматривает это в Обновлении 2 для Visual Studio 2012.

Кристина должна:

  • Завершить эту работу максимально быстро и эффективно.
  • Обеспечить отчеты спринта 1, которые точны, полны и готовы к предстоящей ретроспективе по спринту 1.
  • Гарантировать, что план тестирования относительно спринта 2 настроен для обеспечения корректной отчетности по тестированию.
  • Убедиться, что отчеты для спринта 1 не будут затронуты активностями спринта 2.

Рекомендуемые практики

В примере для проекта первый шаг должен определить, как будут проверены пользовательские истории, присвоенные спринту 1, и какие тестовые случаи спринта 1 будут выполнены как регрессия во время выполнения спринта 2. Нужно рассмотреть следующие вопросы:

  • Какие тесты должны быть включены в план спринта 2?
  • Тестирование спринта 1 отслеживается?
  • Как прогресс тестирования в конце спринта должен быть показан?
  • Как регрессионные тестовые случаи должны быть организованы в плане тестирования?

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

Примечание Рекомендуемые практики показаны на концептуальном уровне. Они предназначены для передачи природы решения, а не обеспечения точных шагов выполнения работ. См. Управление Тестовыми Выпусками от Спринта к Спринту в Лабораторных Работах для ознакомления с процедурами и практическими примерами выполнения управления тестовым случаями от спринта к спринту.

Закрытие Спринта 1

В конце спринта 1 используйте MTM для обновления и закрытия плана тестирования спринта 1.

Действие Руководство
Оценка Состояния Работ
  • Все тестовые случаи имеют корректные пути итерации и области
  • Даты плана тестирования, пути итерации и области корректны

Идентифицируйте:

  • Проверенные тестовые случаи, которые будут регрессированы в спринте 2.
  • Проверенные тестовые случаи, которые не будут регрессированы в спринте 2.
  • Неполные тестовые случаи, где работа была задержана для спринта 2.
  • Тестовые случаи невыполненные в спринте 1, т.к. работа была задержана для спринта 2.

Обновление и закрытие плана тестирования спринта 1

Планирование Спринта 2

Во время планирования спринта 2 вы должны создать план тестирования относительно спринта 2 и затем добавить наборы и тестовые случаи к плану так, чтобы:

  • Тестовые случаи могли быть выполнены для каждой пользовательской истории, выделенной спринту 2.
  • Выбранные регрессионный тестовые случаи могли быть выполнены для пользовательских историй, завершенных в спринте 1.

Используйте MTM для создания и настройки плана тестирования спринта 2.

Действие Руководство
Создать План Тестирования Спринта 2
  • Включите номер спринта в имя плана
  • Установите состояние тестирования плана тестирования спринта в «Планируется».
  • Установите даты начала и окончания для плана тестирования, чтобы они соответствовали датам запуска и окончания спринта.
  • Установите путь итерации плана тестирования в \project\Release1\Sprint2.
Назначить Тестовые Случаи из Плана Тестирования Спринта 1
  • Используйте функцию «Создание тестовых наборов с помощью ссылок на существующие тестовые случаи», чтобы скопировать все наборы с плана тестирования спринта 1 в плана тестирования спринта 2 (за исключением тех наборов, для которых Вы не планируете выполнять их тестовые случаи в спринте 2).
  • Удалите из наборов любые тестовые случаи, которые Вы не планируете выполнять в спринте 2.
  • Измените путь итерации оставшихся тестовых случаев в плане тестирования спринта 2 из \project\Release1\Sprint1 до \project\Release1\Sprint2.

Создание и настройка плана тестирования спринта 2

Примечание Остающиеся проблемы с отчетностью по работам тестирования
Оставшейся работой тестирования, являются любые тестовые случаи в текущем плане тестирования спринта (спринт 1 в примере выше) в состоянии «готово», которые не были выполнены или провалены.Остающаяся работа будет продолжать отображаться в отчете Описание Пользовательских Историй SQL Server Reporting Services (SSRS) и подобных отчетах, если это не будет удалена из старых планов тестирования. Это может быть приемлемо. Если Вы хотите избежать этого:

  • Переместите (а не копируйте) невыполненные и проваленные тестовые случаи в новой плану тестирования.
  • Измените путь итерации тестового случая и пользовательской истории, которую он тестирует, на следующий спринт.

Использование возможности «Создание тестовых наборов с помощью ссылок на существующие тестовые случаи» для повторного использования тестовых случаев между планами

Действие Руководство
Назначить Новые Тестовые Случаи на Спринт 2
  • Добавьте тестовые случаи из элементов журнала, которые запланированы для тестирования в спринте 2.
  • Установите их путь итерации в … \Release1\Sprint2.
Проверить Статус, Состояние и Ссылки
  • Проверьте чтобы план тестирования, наборы, тестовые случаи и общие шаги находились в корректном статусе и состоянии и что они связаны с корректными пользовательскими историями.
Проверить Путь Итерации
  • Проверьте чтобы у всех тестовых случаев и общих шагов в плане тестирования относительно спринта 2 есть корректный путь итерации. … \Release1\Sprint2.

Добавление тестовых случаев, проверка планов, наборов и общих шагов

Когда проект будет готов к тестированию в спринте 2, установите состояние плана тестирования спринта 2 в «Выполняется».

Примечание Даже при том, что тестовые случаи перемещены в следующий спринт, результаты остаются в спринте, в котором они были выполнены. Как только тестовый случай был присвоен другому спринту и выполнен, результаты связываются с тем же спринтом. Это позволяет Team Foundation Server обеспечивать точную историческую отчетность по результатам тестирования.

Итоги

Этот раздел описал простой сценарий управления выпусками тестирования от спринта к спринту. Он привел рекомендуемые практики для управления артефактами тестирования этого сценария.

<<Перейти к содержанию

Posted in Microsoft, Team Foundation Server, Test Release Management Guide, Visual Studio | Отмечено: , , , | Leave a Comment »

 
%d такие блоггеры, как: