Skip to content
Main Navigation
Автоматизированное тестирование
Интеграции
Ручное тестирование
Дашборды и аналитика
Ресурсы
Документация
Блог
События
Последнее из блога
Управление дефектами
Управление дефектами
Разбираем понятия дефекта, ошибки и отказа, чтобы эффективно описывать их в баг-репортах, учитывать в тестировании и улучшить работу команды и баг-трекера.
Тестирование производительности
Тестирование производительности
Изучаем методы и средства для оценки быстродействия системы, а также определяем, когда и как лучше всего проводить тестирование: с помощью нагрузочного или стрессового подхода.
Настройка вебхуков в ТестОпс для Slack
Настройка вебхуков в ТестОпс для Slack
Гайд по настройке вебхуков в ТестОпс на примере создания сообщений для канала в Slack.
Перейти в блог
ТарифыПартнерыСвязаться с нами
Sidebar Navigation

Описание ТестОпс

О продукте

Информация о релизах

Миграция с других решений

Термины и определения

Часто задаваемые вопросы

Установка ТестОпс

Архитектура

Установка и первый запуск

Обзор

Kubernetes

Docker Compose

DEB-пакеты

RPM-пакеты

База данных

S3-хранилище

Конфигурация

Обзор

Сеть

Аутентификация

Обзор

Локальная аутентификация

LDAP

OpenID и Azure AD

OpenID и Keycloak

SAML 2.0

Настройка SMTP

Резервное копирование и восстановление

Начало работы

1. Создайте проект

2. Запустите ручной тест

3. Запустите автотест

4. Создайте комбинированный запуск

5. Обработайте результаты тестов

Обзор ТестОпс

Обзор

Дашборды

Тест-кейсы

Общие шаги

Тест-планы

Запуски

Результаты тестов

Дефекты

Джобы

Меню пользователя

Тест-кейсы

Статусы воркфлоу

Сценарий ручного теста

Параметры ручного теста

Вложения

Теги

Тестовые слои

Ссылки

Задачи из таск-трекеров

Сторонние тест-кейсы

Участники

Связанные тест-кейсы

Кастомные поля

Ключи маппинга

Импорт

Запуски

Окружение

Обновление метаданных

Сравнение запусков

Категории ошибок

Проект

Обзор

Управление доступом

Деревья

Вебхуки

Администрирование

Обзор

Участники

Группы

Очистка данных

Журналы аудита пользователей

Интеграции

Обзор

CI-серверы

AWS CodePipeline

Azure DevOps

Bamboo

Bitbucket

CircleCI

GitHub

GitLab

Jenkins

TeamCity

TeamCity (allurectl)

Таск-трекеры

GitHub

GitLab

Jira Data Center

Jira Software Cloud

Kaiten

Redmine

Wrike

Yandex Tracker

YouTrack

Системы управления тестированием

TestRail

Xray

Zephyr Scale

Экосистема ТестОпс

allurectl

AQL

API

Устранение неполадок

SaaS

ТестОпс как SaaS

Миграция в облако ТестОпс

On this page

Результаты тестов ​

Результат теста — одна попытка выполнения тест-кейса во время запуска. Результат теста создается либо вручную, либо автоматически путем загрузки файла с результатами теста. В самом простом случае результат теста можно представить как запись, содержащую дату и время попытки выполнения теста и ее статус (например, Успешный или Неуспешный).

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

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

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

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

Статусы тестов в запусках ​

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

При выполнении тест-кейса вручную новый (незавершенный) результат теста изначально получает временный статус В процессе, который затем меняется инженером по тестированию на другой статус. Для результатов автоматизированных тестов статус загружается из файла с результатами теста (см. также статью Статусы тестов в документации Allure Report).

Статусы тестов в запусках:

  • Успешный (зеленый) — тест завершился успешно.
  • Неуспешный (красный) — тест столкнулся с неожиданным поведением в тестируемой системе. Это означает, что сам тест кажется действительным (не сломан), но его выполнение завершилось ложным утверждением.
  • Пропущенный (серый) — тест был включен в тест-план, но не был выполнен по какой-то причине.
  • Сломанный (оранжевый) — тест не прошел из-за дефекта теста. Этот статус отличается от статуса Неуспешный тем, что тест не смог проверить поведение продукта так, как было задумано, поэтому сбой может или не может указывать на фактический дефект продукта.
  • Неизвестный (фиолетовый) — статус теста не был явно указан. В ручном тесте это означает, что запуск был закрыт, пока тест все еще был В процессе. В автоматизированном тесте это, скорее всего, связано с ошибкой в адаптере Allure Report, который использовался во время запуска.

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

Сортировка и фильтрация результатов тестов ​

При просмотре запуска вы можете сортировать и фильтровать список входящих в него результатов тестов так же, как список тест-кейсов.

Чтобы отсортировать список результатов тестов:

  1. Нажмите Опции.
  2. В меню Сортировать по выберите атрибут, по которому нужно отсортировать результаты.
  3. В меню Направление выберите направление сортировки.

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

Например, чтобы оставить в списке только автоматизированные тесты:

  1. Нажмите на поле поиска.
  2. Выберите Тип в появившемся списке.
  3. Выберите значение Автоматический.

Более подробную информацию о работе с фильтрами можно найти в разделе Тест-кейсы.

Групповые операции ​

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

  1. Выберите результаты тестов, используя Ctrl или поставив галочки слева от них.
  2. В появившейся панели снизу нажмите Статус, чтобы изменить статус, или ⋯, чтобы выбрать другое действие.

Меню групповых операций позволяет:

  • менять статусы тестов;
  • назначать исполнителей;
  • перезапускать тесты;
  • связывать результаты с дефектом;
  • помещать тест-кейсы в карантин;
  • добавлять и удалять теги;
  • экспортировать результаты в CSV;
  • удалять результаты тестов из запуска.

Если запуск закрыт, в меню групповых операций будет доступно только действие Экспорт CSV.

Поддерживаемые форматы файлов ​

ТестОпс поддерживает несколько форматов файлов для загрузки результатов автоматизированных тестов. Эти файлы можно загружать через веб-интерфейс или c помощью allurectl:

  • формат Allure Report 2.x — *-result.json, *-container.json, *-attachment.*;
  • формат Allure Report 1.x — *.xml (поддерживается для совместимости со старыми адаптерами и интеграциями);
  • формат отчетности Cucumber — *.json;
  • формат отчетности JGiven — *.json;
  • формат отчетности JUnit XML — *.xml;
  • формат отчетности Visual Studio — *.trx (устаревший, не рекомендуется использовать);
  • формат отчетности XCTest — *.xcresult (поддерживаются только файлы из XCode 11 и выше);
  • формат отчетности xUnit.net — *.xml.

Сопоставление результатов с тест-кейсами ​

Когда вы загружаете результаты тестов, для каждого результата ТестОпс выполняет одно из трех действий:

  • Создает новый автоматизированный тест-кейс, если это первая загрузка результатов для этого тест-кейса.
  • Обновляет существующий тест-кейс, если вы уже загружали для него результаты.
  • Отмечает результат как «Невозможно привязать», если он содержит неверные данные для сопоставления (см. ниже).

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

Если тестовый фреймворк не предоставляет готовый идентификатор для тест-кейса, адаптер создает хэш на основе сигнатуры тестовой функции и дополнительной информации, которая может помочь сделать идентификатор более уникальным (например, названия пакета).

Этот процесс можно представить следующим образом:

testCaseId = md5(fullName + sort(params))

где fullName — это название функции с дополнительной информацией (например, название_модуля#название_функции), а params — параметры функции.

Затем, после загрузки результата, ТестОпс попытается найти и обновить тест-кейс с указанным идентификатором. Если тест-кейса с таким идентификатором не существует, ТестОпс создаст новый тест-кейс.

Примечание

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

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

Чтобы этого избежать, после первичной загрузки результатов тестов вы можете указать в вашем коде идентификатор тест-кейса, который отображается в интерфейсе ТестОпс:

Важно

Вы не можете указать идентификатор, который еще не существует в ТестОпс. В таком случае загруженные результаты получат статус «Невозможно привязать» и тест-кейсы не будут созданы или обновлены.

java
@Test
@AllureId("123")
public void myTest() {
   step("Step 1", () -> {});
}

После запуска теста адаптер создаст файл с результатами, в котором будут указаны следующие поля:

json
"testCaseId": "db57b9d129d73c4b4d9a1d1023774f53",
"labels": [
   {
      "name": "as_id",
      "value": "123"
   }
]

testCaseId — это идентификатор тест-кейса, созданный адаптером (хэш данных, предоставленных тестовым фреймворком). В примере выше вместо testCaseId будет использован указанный явно идентификатор тест-кейса из ТестОпс — as_id (или allure_id в некоторых адаптерах).

Pager
Previous pageЗапуски
Next pageДефекты

Logo © 2025 Все права защищены. Сайт принадлежит компании ООО «Инструменты тестирования»