Поделиться через


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

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

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

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

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

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

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

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

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

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

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

    Выбор тестов для связывания с требованиями

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

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

    Выбор рабочего элемента требований

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

  3. После связывания требований с результатами теста можно просмотреть результаты теста, сгруппированные по требованию. Требование — это один из многих вариантов "Группировать по", предоставляемых для упрощения навигации по результатам теста.

    Группировать результаты по требованиям

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

    Создание панели мониторинга группы

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

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

    Настройка мини-приложения

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

    Отслеживание требований без тестов

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

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

    Выбор тестов для связывания с требованиями

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

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

    Выбор рабочего элемента требований

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

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

    Создание панели мониторинга группы

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

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

    Настройка мини-приложения

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

    Отслеживание требований без тестов

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

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

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

    Связывание ошибок с тестами

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

    Запись сведений об ошибке

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

    Просмотр ошибки на вкладке

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

    Тестовые ссылки в ошибке

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

    Представление полной страницы вкладки

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

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

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

    Просмотр неудачного выпуска

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

    Сбой при выполнении теста

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

    Просмотр фиксаций кода

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

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

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