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

Azure DevOps Services | Azure DevOps Server 2022 г. - Azure DevOps Server 2019 г. | TFS 2018

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

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

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

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

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

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

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

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

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

   

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

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

   

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

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

   

4. Настройте мини-приложение Requirements quality с необходимыми параметрами и сохраните его.

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

   

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

   

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

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

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

   

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

   

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

   

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

   

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

   

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

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

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

   

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

   

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

   

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

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

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

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