Прослеживаемость требований

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Ознакомьтесь с глоссарием, чтобы понять терминологию тестового отчета.

Гибкие команды, выполняющих автоматизированные тесты

Гибкие команды имеют характеристики, в том числе, но не ограничиваются следующими

• Более быстрые циклы выпуска
• Непрерывное тестирование в конвейере
• Незначимый объем ручного тестирования; ограничено изучением тестирования
• Высокая степень автоматизации

В следующих разделах рассматриваются возможности трассировки с точки зрения качества, ошибки и источника для команд Agile.

Качество трассировки

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

1. В разделе результатов на вкладке "Тесты " сводки сборки или выпуска выберите тесты, которые необходимо связать с требованиями и выбрать ссылку.

   

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

   • Выберите подходящий рабочий элемент из списка предлагаемых рабочих элементов. Список основан на последних и обновленных рабочих элементах.
   • Укажите идентификатор рабочего элемента.
   • Найдите рабочий элемент на основе текста заголовка.

   

   В списке показаны только рабочие элементы, принадлежащие категории "Требования".

3. Команды часто хотят закрепить обобщенное представление трассировки требований к панели мониторинга. Используйте мини-приложение "Требования качества " для этого.

   

4. Настройте мини-приложение "Качество требований" с необходимыми параметрами и сохраните его.

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

   

5. Просмотрите мини-приложение на панели мониторинга команды. В нем перечислены все требования в область, а также скорость прохождения тестов и количество неудачных тестов. При выборе счетчика неудачных тестов откроется вкладка "Тесты " для выбранной сборки или выпуска. Мини-приложение также помогает отслеживать требования без связанных тестов.

   

Возможность трассировки ошибок

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

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

   

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

   

3. Просмотрите ошибку с результатом теста непосредственно в контексте на вкладке "Тесты ". На вкладке " Рабочие элементы" также перечислены все связанные требования для результата теста.

   

4. Из рабочего элемента перейдите непосредственно к связанным результатам теста. Тестовый случай и конкретный результат теста связаны с ошибкой.

   

5. В рабочем элементе выберите "Тестовый случай " или "Тестовый результат ", чтобы перейти непосредственно на страницу "Тесты " для выбранной сборки или выпуска. Вы можете устранить сбой, обновить анализ в ошибке и внести изменения, необходимые для устранения проблемы, как применимо. Хотя обе ссылки переходят на вкладку "Тесты", по умолчанию отображается раздел "Журнал " и "Отладка " соответственно.

   

Возможность трассировки источника

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

1. На вкладке "Тесты " выберите тестовый сбой для анализа. В зависимости от того, является ли это сборка или выпуск, выберите столбец "Сбой сборки " или "Сбой выпуска " для теста.

   

2. Откроется другой экземпляр вкладки "Тесты" в новом окне с первым экземпляром последовательных сбоев для теста.

   

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

   

Традиционные команды с помощью планового тестирования

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

Справка и поддержка

• См. нашу страницу по устранению неполадок
• Получите советы по Stack Overflow и получите поддержку через Сообщество разработчиков