Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
В этой статье описываются часто используемые термины, используемые в отчете о тестировании конвейера и аналитике тестов, а также советы по улучшению тестирования в Azure Pipelines.
| Срок | Definition |
|---|---|
| Duration | Время, прошедшее при выполнении тестового, тестового выполнения или всего выполнения теста в конвейере сборки или выпуска. |
| Owner | Владелец тестового или тестового запуска. Владелец теста обычно указывается в качестве атрибута в коде теста. Сведения о сопоставлении атрибута владельца для поддерживаемых форматов результатов теста см. в статье "Публикация результатов теста". |
| Сбой сборки | Ссылка на сборку с первым вхождением последовательных сбоев тестового случая. |
| Сбой выпуска | Ссылка на выпуск с первым вхождением последовательных сбоев тестового случая. |
| Результат | Существует 15 возможных результатов для результата теста: прерывание, блокировка, ошибка, сбой, неуклюзивный, в ходе выполнения, нет, неприменимо, не применяется, не влияет, передано, приостановлено, время ожидания, не указано и предупреждение. Ниже приведены некоторые распространенные результаты. - Прервано: выполнение теста резко завершается из-за внутренних или внешних факторов, например плохого кода, проблем с средой. - Сбой: проверьте, не встречайте нужный результат. - Неуклюзивный: тестирование без окончательного результата. - Не выполнено: тест помечается как пропущенный для выполнения. - Не повлияло: проверка, не затронутая изменением кода, которое активировало конвейер. - Передано: проверка выполнена успешно. - Время ожидания: длительность выполнения теста, превышающая указанное пороговое значение. |
| Тест Flaky | Тест с недетерминированным поведением. Например, тест может привести к разным результатам для одной конфигурации, кода или входных данных. |
| Фильтр | Механизм поиска результатов теста в результирующем наборе с помощью доступных атрибутов. Подробнее. |
| Группировка | Помощь в организации представления результатов теста на основе доступных атрибутов, таких как требования, тестовые файлы, приоритет и многое другое. Как тестовый отчет , так и аналитика тестов обеспечивают поддержку группирования результатов теста. |
| Процент передачи | Измерение успешности результата теста для одного экземпляра выполнения или в течение определенного периода времени. |
| Приоритет | Указывает степень важности или критическости теста. Приоритет обычно указывается в качестве атрибута в тестовом коде. См. задачу "Опубликовать результаты теста ", чтобы просмотреть сопоставление атрибута Priority для поддерживаемых форматов результатов теста. |
| Анализ тестов | Представление исторических тестовых данных для предоставления значимых аналитических сведений. |
| Тестовый случай | Уникально идентифицирует один тест в указанной ветви. |
| Тестовые файлы | Групповые тесты на основе способа их упаковки; например, файлы, библиотеки DLL или другие форматы. |
| Тестовый отчет | Представление одного экземпляра тестового выполнения в конвейере, в котором содержатся сведения о состоянии и справке по устранению неполадок, возможности трассировки и т. д. |
| Результат теста | Один экземпляр выполнения тестового случая с определенным результатом и подробными сведениями. |
| Тестовое выполнение | Логическое группирование результатов теста на основе: - Тест, выполняемый с помощью встроенных задач: все тесты, выполняемые с помощью одной задачи, например Visual Studio Test, Ant, Maven, Gulp, Grunt или Xcode , будут сообщаться при одном тестовом запуске. - Результаты, опубликованные с помощью задачи "Опубликовать результаты теста": предоставляет возможность группировать все результаты теста из одного или нескольких файлов результатов теста в один запуск или отдельные запуски для каждого файла. - Результаты тестов, опубликованные с помощью API: API обеспечивают гибкость для создания тестового запуска и упорядочивания результатов тестирования для каждого запуска по мере необходимости. |
| Прослеживаемость | Возможность трассировки вперед или назад к требованию, ошибке или исходному коду из результата теста. |
Лучшие практики
Обеспечение надежности приложений требует комплексного тестирования в Azure Pipelines, а модульные тесты и тесты интеграции являются важными. Тестирование интеграции в облачных средах, особенно бессерверных приложений, вызывает проблемы из-за распределенных архитектур, неправильно настроенных разрешений IAM и проблем интеграции между службами.
Чтобы устранить эту проблему, рассмотрите возможность локального выполнения кода при взаимодействии с подлинными службами Azure, упрощении реалистичных тестов и включении средств отладчика, подходящих для автоматического тестирования. Для реализации этого подхода требуется подготовка временных ресурсов Azure. В идеале создайте отдельные учетные записи для каждой среды; Кроме того, динамическая подготовка в конвейерах Azure возможна, хотя это увеличивает время выполнения и требует тщательного планирования вывода ресурсов. Чтобы свести к минимуму конфликты именования, избегайте явного именования ресурсов, если это не необходимо, и включите имена сред в имена ресурсов.
Помощь и поддержка
- См. нашу страницу устранения неполадок
- Получите советы по Stack Overflow и получите поддержку через сообщество разработчиков