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

Интеграции

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

Возможные причины

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. Если проблема не решилась, создайте обращение в техническую поддержку.

Ошибка "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.

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

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

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

Возможные причины

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

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

Варианты решения

Первый вариант — нет данных о полном имени

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

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

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

Второй вариант — неверный ID теста и нет данных о полном имени

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. Выберите атрибут Карантин и значение Да.

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

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

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

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

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

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

Возможные причины

Существует ограничение в 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, но не вижу их в ТестОпс

Варианты решения

Первый вариант — проблема с вложениями в локальных директориях

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

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

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

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

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

Второй вариант — пропуск вложений в настройках allurectl

Проверьте настройки allurectl на стороне CI-системы. Если используется опция пропуска вложений, то 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 → Аутентификация.

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

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

Варианты решения

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

• Если вы используете IdP для аутентификации пользователей (LDAP, SAML 2.0, 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. Это сбросит сессии всех пользователей, и они выйдут из системы.

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

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

Важно

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