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

Ошибки интеграции

Проблемы с подключением

Тестовое подключение не проходит успешно

Почему это может произойти

1. Указанные вами учетные данные неверны.
2. Нет связи с интегрируемой системой.
3. API был обновлен на стороне интеграции.

Как исправить

Указанные вами учетные данные неверны

1. Проверьте, что вы правильно скопировали/ввели пароль или токен, требуемый для интеграции.

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

2. Проверьте, что формат имени пользователя соответствует ожидаемому формату интеграции:

   1. Убедитесь, что имя пользователя указано верно.
   2. Внимательно прочитайте описание интеграции, в котором указано, что именно нужно использовать в качестве имени пользователя. Это может быть или имя пользователя, или электронная почта, и в большинстве случаев они не взаимозаменяемы.

Нет связи с интегрируемой системой

Для проверки связи потребуется привлечь ваших DevOps-инженеров или иных инженеров, ответственных за инфраструктуру.

При отсутствии связи с интегрируемой системой в интерфейсе ТестОпс может появиться сообщение Не удается установить соединение.

Для устранения проблемы выполните следующие действия:

1. Соберите логи из сервиса testops.
2. Проверьте логи на наличие ошибок, таких как java.net.UnknownHostException.

Если таких сообщений в логах нет, попробуйте включить отладочное логирование для интеграций:

1. Добавьте новую переменную окружения LOGGING_LEVEL_IO_QAMETA_ALLURE_TESTOPS_INTEGRATION со значением debug.

2. Перезапустите инстанс (сервис должен получить новые параметры).

3. Попробуйте снова выполнить операцию, которая не удалась.

4. Соберите логи из сервиса testops.

5. Проверьте логи на наличие следующих ошибок:

   • 400 bad request;
   • HTTP FAILED;
   • java.net.UnknownHostException.

   Эти ошибки обычно имеют более подробное описание над и под строкой ошибки.

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

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

Если у вас возникли сложности при работе с логами, создайте новое обращение с типом запроса Требуется поддержка на сайте help.qatools.ru, указав при регистрации ваш корпоративный адрес электронной почты.

API был обновлен на стороне интеграции

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

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

   Отладочное логирование для интеграций должно быть включено.

2. Если в логах нет признаков проблем с подключением, создайте новое обращение с типом запроса Требуется поддержка на сайте help.qatools.ru, указав при регистрации ваш корпоративный адрес электронной почты.

Тест-кейсы

Дерево тест-кейсов отображается некорректно

Как исправить

Попробуйте мигрировать данные деревьев на новую структуру с помощью API. Если проблема не решилась, создайте обращение в техническую поддержку.

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

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

Результаты тестов помечены как «невозможно привязать»

Причина

Результаты тестов в запуске ТестОпс будут помечены как «невозможно привязать» в следующих случаях:

• Указанный AS_ID (ALLURE_ID) не существует в инстансе ТестОпс. Этот атрибут управляется ТестОпс, вы не можете использовать произвольные ID.
• Отсутствует действительный AS_ID (ALLURE_ID), а также полный путь (селектор тест-кейса) в результатах теста. Селектор используется для однозначного сопоставления результата теста с тест-кейсом. Если вы используете стороннюю интеграцию, она может игнорировать этот параметр. Это параметр необязателен при работе с Allure Report, но очень важен для работы ТестОпс.

Возможное решение

Нет данных о полном имени

Чтобы импортировать результаты тестов, не содержащие данных о полном имени тест-кейса, нужно указать AS_ID (ALLURE_ID) в коде, чтобы он появился в результатах тестов.

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

Для проверки зависимостей, пожалуйста, проверьте официальные репозитории проекта Allure Report на GitHub или документацию проекта.

Неверный AS_ID (ALLURE_ID) и нет данных о полном имени

Allure ID можно указывать только в коде. Если ваш тестовый фреймворк не поддерживается IDE JetBrains, вам нужно создать ручной тест-кейс, скопировать его ID и указать его в коде. При загрузке результатов этот ручной тест-кейс будет заменен данными автоматизированного тест-кейса.

Отсутствуют результаты — Пустой запуск — Неверная или пустая директория с результатами тестов

Симптом: Если запуск выполняется из CI, он будет пустым. Если запуск выполняется из ТестОпс, он будет содержать результаты тестов в статусе «В процессе», которые при закрытии запуска перейдут в статус «Неизвестный». Проверьте, правильный ли путь указан для загрузки результатов тестов.

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

Вы также можете выполнить команду ls -a во время сборки, чтобы увидеть текущую директорию ТестОпс-агента. Если в этой директории нет результатов теста, укажите правильный путь.

Как исправить

Вам нужно указать правильную директорию с результатами тестов.

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

Отсутствуют результаты — Пустой запуск — Файлы существуют на CI-сервере, пути правильные, но файлы не загружаются

Если вы видите следующие строки в логах ТестОпс-агента:

Launch [LL], job run [rr], session [ss]:files ignored [0], indexed [XX], processed [0], errors [XX]

или

[Allure] [xxx] Session [xx] total indexed [N], ignored [0], processed [0], errors [N]

где indexed больше нуля, processed равен нулю, errors больше нуля,

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

Как исправить

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

Для плагина (например, для Jenkins или TeamCity) вам нужно добавить параметр indexExistingFiles: true для индексирования существующих файлов.

withAllureUpload(indexExistingFiles: true, name: '${SOME_JOB_NAME}', projectId: '', serverId: '', tags: '') {
    // ...
}

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

Отсутствуют результаты — Запуск не пуст — Некоторые результаты отсутствуют — Тесты помещены в карантин

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

Последствия помещения тестов в карантин

1. Тест в карантине не будет отображаться на главной странице запусков.

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

   В карточке результата теста в правой нижней части экрана вы увидите кнопку Убрать из карантина.

2. Тест в карантине не будет учитываться в аналитике и при расчетах статистики.

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

Как проверить — Тест-кейсы — Фильтр

1. Перейдите в раздел Тест-кейсы.
2. Нажмите на поле поиска над списком тест-кейсов.
3. Выберите атрибут Карантин и значение Да.

В списке тест-кейсов вы увидите все тест-кейсы, находящиеся в карантине. В каждом из них в секции Карантин будут указаны:

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

Как проверить — Результаты тестов — Карточка результата теста

В открытом запуске в карточке результата теста вы увидите кнопку Убрать из карантина в правой нижней части экрана.

Как исправить

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

Если проблема с неуспешным тестом решена, вы можете убрать его из карантина. В противном случае вы можете спросить человека, поместившего тест в карантин, зачем он это сделал.

Отсутствуют результаты — Размер файла результата

Существует ограничение в 2 000 000 байт для файла результата теста (*-result.json).

Если размер файла с результатами превышает 2 000 000 байт, ТестОпс не будет обрабатывать его как файл с результатами, а рассмотрит его как вложение. Это сделано намеренно, чтобы избежать сбоев из-за недостатка ресурсов при обработке большого количества файлов.

Как проверить

Посмотрите вашу папку allure-results, чтобы проверить, есть ли там файлы *-result.json размером более 2 000 000 байт.

Как исправить

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

Отсутствуют результаты — Ошибки при загрузке

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

Как проверить

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

Вам нужно проверить следующее:

• настройки обратного прокси-сервера (если он есть), описанные здесь:

  • тайм-ауты;
  • ограничения на передачу данных.

• сетевые тайм-ауты на маршрутизаторах/брандмауэрах, аналогичные тайм-аутам на обратном прокси-сервере;

• сетевые настройки на маршрутизаторах/брандмауэрах, аналогичные ограничениям на размер передаваемых данных на обратном прокси-сервере;

• правила блокировки (черные списки, белые списки и т. д.).

Как исправить

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

Отсутствуют результаты тестов — Перезапуски

Если у вас генерируется множество файлов *-results.json для разных тестов, но после загрузки в запуске отображаются только один результат теста, это может происходить по следующим причинам:

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

Как проверить

1. Перейдите в раздел Запуски.
2. Найдите и откройте ваш запуск.
3. Перейдите на вкладку Результаты тестов.
4. Выберите ваш результат теста.
5. В карточке результата теста перейдите на вкладку Перезапуски.
6. Если на этой вкладке есть повторные запуски, а вы запускали тест только один раз, то вам нужно обновить ваш код.

Как исправить

Непараметризованный тест

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

1. Явно укажите Allure ID для ваших тестов в коде.
2. Переименуйте ваши тестовые методы, чтобы они назывались по-разному.

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

Параметризованный тест

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

Вот пример для Java:

<...>
    private static final String OWNER = "test-framework";
    private static final String REPO = "test-repository";
<...>
    @Story("Создать задачу")
    @ParameterizedTest(name = "Создать задачу с помощью API")
    @ValueSource(strings = {"First Note", "Second Note"})
    public void shouldCreateUserNote(String title) {
        parameter("owner", OWNER);
        parameter("repo", REPO);
        parameter("title", title);

        steps.createIssueWithTitle(OWNER, REPO, title);
        steps.shouldSeeIssueWithTitle(OWNER, REPO, title);
    }

Для приведенного выше примера информация о параметрах owner, repo и title будет записана в файл результата теста в раздел parameters:

"parameters": [
  {
    "name": "owner",
    "value": "test-framework"
  },
  {
    "name": "repo",
    "value": "test-repository"
  },
  {
    "name": "title",
    "value": "First Note"
  }
],

Эти параметры будут обработаны ТестОпс, и для одного тест-кейса вы увидите несколько результатов теста:

Затем будет создан следующий тест-кейс:

Обрезанные значения в полях результата теста

При работе с автоматизированными тестами в ТестОпс имейте в виду, что любое поле автоматизированного теста может содержать максимум 255 символов. Остальные символы будут обрезаны при загрузке результата теста в ТестОпс.

Автоматизированные тесты застряли в статусе «В процессе» при запуске или перезапуске

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

Например, если вы объявили две переменные окружения при запуске теста (OS=iOS и VER=123), но значение одной из них изменилось во время выполнения (например, оно определяется динамически и поэтому всегда будет иметь другое значение), ТестОпс создаст новый результат теста при получении файла результата и будет продолжать ждать результат с правильными значениями (который никогда не придет).

То же самое произойдет, если ТестОпс получит результат теста с другим значением параметра.

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

Вложения результатов тестов

Вложения отсутствуют в ТестОпс, но доступны в Allure Report

Я вижу вложения в Allure Report, но не вижу их в ТестОпс

Как проверить: вложения в папках

1. Перейдите к источнику вашего результата теста (CI-пайплайн, локальная папка, проект IDE и т. д.).

   Для этого примера предположим, что результаты хранятся в папке allure-results.

2. Проверьте, что все вложения находятся в корне папки allure-results. Если allure-results содержит подпапки с вложениями, то эти вложения не будут отображаться в ТестОпс.

Как исправить: вложения в папках

Настройте ваш проект так, чтобы все файлы хранились в папке allure-results без подпапок.

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

Как проверить: настройки allurectl

Проверьте настройки allurectl на стороне CI-сервера. Если используется опция пропуска вложений, то allurectl пропустит загрузку вложений для успешно пройденных тестов.

Как исправить: настройки allurectl

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

Как проверить: правила очистки

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

Как исправить: правила очистки

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

Сервисы не запускаются

Сервис ТестОпс не запускается (блокировка базы данных)

Если вы видите одно из следующих сообщений в логе:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'liquibase' defined in class path resource org.
springframework.beans.factory.BeanCreationException: **Error creating bean with name 'liquibase'** defined in class path resource [org/springframework/boot/autoconfigure/liquibase/LiquibaseAutoConfiguration$LiquibaseConfiguration.class]:
Invocation of init method failed;
nested exception is liquibase.exception.LockException:
Could not acquire change log lock.

liquibase.lockservice: Waiting for changelog lock...
liquibase.lockservice: Waiting for changelog lock...
liquibase.lockservice: Waiting for changelog lock...
liquibase.lockservice: Waiting for changelog lock...

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

Чтобы это исправить:

1. Остановите сервис ТестОпс.

   Пример для Docker Compose:

   docker compose stop testops

2. Войдите в базу данных testops с помощью psql (psql -h <хост> -U <имя пользователя> <название базы>):

   psql -h 127.0.0.1 -U testops testops

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

   SELECT * FROM databasechangeloglock;

4. Найдите и удалите блокировку, которая мешает запуску сервисов:

   UPDATE databasechangeloglock SET locked=FALSE, lockgranted=NULL, lockedby=NULL WHERE id=1;

5. Запустите ранее остановленные сервисы ТестОпс.

   Пример для Docker:

   docker compose start testops

Сервис ТестОпс падает или использует слишком много процессорных ресурсов при выполнении большого количества API-запросов

Если для доступа к API вы используете API-токен, который создали в меню пользователя, вам нужно переключиться на аутентификацию OAuth (используя JWT как Bearer token). Более подробную информацию можно найти в разделе Аутентификация в статье об API.

Ошибки в интерфейсе с кодом 409

Ошибка "Request failed with status code 409" при попытке переместить тест-кейс в другой проект

Эта ошибка может появиться, если автоматизированный тест-кейс с такими же атрибутами уже существует в целевом проекте.

Пример:

1. Вы загружаете два результата теста в Проект A. ТестОпс создает два новых тест-кейса, которые имеют ID со значением 1 и 2.
2. Вы переносите один из созданных тест-кейсов (ID = 2) в Проект B.
3. Вы загружаете результаты для тех же двух тест-кейсов в Проект A. Один из тест-кейсов уже существует в Проекте A (ID = 1), но второй был перенесен, поэтому будет создан один новый тест-кейс (ID = 3).

Теперь, если вы попытаетесь перенести тест-кейс с ID = 2 из Проекта B обратно в Проект A, произойдет ошибка, так как идентичный тест-кейс (за исключением ID) уже существует в Проекте A.

Проблемы с входом пользователей

Не удается войти в ТестОпс как администратор

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

• Если вы используете IAM-систему для аутентификации пользователей (LDAP, SAML2, OpenID) в качестве основного способа аутентификации, вход в систему с локальной учетной записью должен быть выполнен по адресу https://<URL>/login/system.

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

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

Ошибка 401: CSRF Token Missing

Если вы видите ошибку "Request failed with status code 401. The expected CSRF token could not be found" в браузере в инструментах разработчика (DevTools), когда пользователь не может войти в ТестОпс, проблема, скорее всего, связана с «застрявшей сессией» в Redis.

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

Чтобы решить проблему:

1. Выполните команду:

redis-cli FLUSHALL

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

1. В качестве альтернативы вы можете перезапустить сервис Redis. Это приведет к тому же результату, что и команда FLUSHALL.

ТестОпс не хранит в Redis никаких постоянных данных, перезапуск удалит только данные о пользовательских сессиях.

Важно

Оба действия приведут к сбросу пользовательских сессий. Не забудьте проинформировать пользователей заранее или выполните действия после рабочего дня.