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

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

Posts Tagged ‘Visual Studio’

Вебинар «Организация конвейера по производству ПО на основе VSTS» — Видео

Posted by Shamrai Alexander на Декабрь 13, 2017

Видео

Презентация

Реклама

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

Отображение формы рабочего элемента TFS/VSTS в Visual Studio 2017

Posted by Shamrai Alexander на Май 8, 2017

<< Перейти в раздел «Team Foundation Work Item Tracking FAQ»

По умолчанию формы в Visual Studio не отображаются в самой IDE, когда мы просматриваем результаты работы запроса по рабочим элементам. Т.е. при двойном нажатии на строку результата нас «перебрасывает» на веб-форму на веб-сайте проекта TFS/VSTS:

При этом открывается запрос, который был открыт в Visual Studio, и выделение позиционируется на соответствующий рабочий элемент. Если нет желания использовать такой метод, то можно вернуться к старому механизму работы. Для этого необходимо перейти в настройки Visual Studio (ToolsàOptionsàWork Items) и выбрать в пункте Open work items in пункт Visual Studio (compatibility mode):

В результате таких действий и результат запросов по рабочим элементам, и сами рабочие элементы будут отрываться непосредственно в Visual Studio.

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

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

Posted by Shamrai Alexander на Март 22, 2017

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

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

Posted by Shamrai Alexander на Сентябрь 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 Shamrai Alexander на Июнь 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 Shamrai Alexander на Май 14, 2013

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

Содержание

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

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

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

Posted by Shamrai Alexander на Май 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 Shamrai Alexander на Май 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 Shamrai Alexander на Май 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 Shamrai Alexander на Май 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 »

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