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

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

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

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

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

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

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

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

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

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

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

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

Нет маршрута к интегрируемой системе

Примечание

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

Это может привести к сообщению Не удается установить соединение в интерфейсе.

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

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

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

1. Включите отладочное логирование для интеграций.

   • добавьте новую переменную окружения LOGGING_LEVEL_IO_QAMETA_ALLURE_TESTOPS_INTEGRATION со значением debug.
   • перезапустите развертывание (сервис должен получить новые параметры)
   • попробуйте выполнить операцию, которая не удалась
   • соберите логи из сервиса testops
   • проверьте логи на наличие ошибок
     • 400 bad request
     • HTTP FAILED
     • java.net.UnknownHostException
   • Ошибки выше обычно имеют более детализированное описание выше и ниже строки ошибки
   • UnknownHostException обычно означает, что ТестОпс не имеет подключения к системе, которую вы описали в настройках интеграции.

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

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

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

Примечание

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

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

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

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

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

Соглашения

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

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

Причина

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

Получен недействительный AS_ID (ALLURE_ID) в результатах

• ALLURE ID еще не существует в БД ТестОпс, этот атрибут управляется базой данных ТестОпс, и вы не можете использовать пороизвольные ID.
• В БД для текущего проекта нет указанного в результате теста ALLURE_ID, или в результатах теста нет полного пути (селектора теста) для теста, результаты которого загружаются в первый раз. Полный путь (селектор) используется для однозначного сопоставления результата теста с тест-кейсом. Если вы используете какую-либо стороннюю интеграцию, она может игнорировать этот параметр, и это будет работать с Allure Report, но это важно для работы с ТестОпс.
  • Подобные ситуации могут встречаться, если вы используете неофициальную интеграцию с Allure Framework.

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

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

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

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

Для проверки зависимостей, пожалуйста, проверьте официальные репозитории проекта Allure Report на GitHub: https://github.com/allure-framework или документацию проекта https://allurereport.org

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

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

Отсутствующие результаты - Пустой запуск - Неправильный или пустой каталог источника результатов тестов

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

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

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

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

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

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

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

Если вы видите следующие детали логов в плагине или в логах allurectl:

Launch [LL], job run [rr], session [ss]:files ignored [0], indexed [XX], processed [0], errors [XX]
or
[Allure] [xxx] Session [xx] total indexed [N], ignored [0], processed [0], errors [N]

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

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

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

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

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

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

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

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

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

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

   • Тем не менее, вы увидите результаты такого теста, если перейдете в раздел Дерево конкретного запуска с тестом в карантине.
   • Вы увидите кнопку Поместить в карантин с перечеркнутым глазом в панели описания результата теста (внизу).

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

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

Как проверить - Дашборды - Тренд тест-кейсов в карантине

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

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

1. Перейдите в раздел Тест-кейсы вашего проекта.
2. Активируйте панель фильтров
3. Создайте фильтр и установите Карантин = Да
4. В списке тест-кейсов вы увидите список тест-кейсов в карантине.
5. Каждое описание правила карантина тест-кейса будет содержать информацию о человеке, который пометил этот тест как заглушенный, и дату, когда это было сделано.

Как проверить - Результаты тестов - Панель описания теста

В панели описания результата теста для результата теста в открытом запуске вы увидите активную кнопку Поместить в карантин с перечеркнутым глазом.

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

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

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

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

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

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

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

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

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

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

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

На самом деле, это должно быть пунктом №1 в списке, но как есть, так есть.

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

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

Вам понадобится либо ваш сетевой администратор, либо DevOps, либо любой другой человек, ответственный за настройку сети, настройку обратного прокси, настройку брандмауэров.

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

• настройки для обратного прокси (если есть), описанные здесь
  • тайм-ауты
  • ограничения на передачу данных
• сетевые тайм-ауты на маршрутизаторах/брандмауэрах, аналогичные тайм-аутам обратного прокси
• сетевые настройки на маршрутизаторах/брандмауэрах, аналогичные ограничениям обратного прокси для размера передачи данных
  • например ограничения по NAT/port_usage со стороны сетевого оборудования или ПО.
• правила блокировки (черные списки, белые списки и т.д.)

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

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

Отсутствующие результаты тестов - Повторы

Симптомы: Есть несколько / много файлов *-results.json для нескольких тестов, но в результатах тестов запуска есть только один результат теста.

Это может произойти, если...

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

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

1. Перейдите к результатам тестов запуска Запуски => Конкретный запуск => вкладка Дерево
2. Выберите ваш тест-кейс
3. В панели тест-кейса перейдите на вкладку повторы
4. Если ваш результат теста имеет повторы и это был только один запуск теста, кажется, вам нужно обновить ваш код.

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

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

1. Явно назначьте Allure ID обоим вашим тестам в вашем коде.
2. Убедитесь, что методы тестов названы по-разному.
3. Лучше применить оба вышеуказанных способа.

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

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

<snip>
    private static final String OWNER = "allure-framework";
    private static final String REPO = "allure2";
<snip>
    @Story("Create new issue")
    @ParameterizedTest(name = "Create issue via 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": [
        {
          "name": "owner",
          "value": "allure-framework"
        },
        {
          "name": "repo",
          "value": "allure2"
        },
        {
          "name": "title",
          "value": "First Note"
        }
      ],

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

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

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

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

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

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

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

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

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

Кроме того, Allure Framework позволяет отмечать параметры тестов как скрытые или как "исключенные", такие параметры не будут влиять на высчисление historyId результата и могут быть динамическими, при использовании таких параметров, если перезапуск произошел с другими значениями, то это не повлияет на склеивание результатов. Более подробно о признаках параметров вы можете прочитать в документации для вашей интеграции с Allure Framework на сайте проекта.

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

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

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

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

1. Перейдите к источнику вашего результата теста (CI pipeline, локальная папка, проект IDE и т.д.).
2. Для этого примера предположим, что результаты хранятся в папке allure-results.
3. Проверьте, что все вложения находятся в корне папки allure-results. Если ваша allure-results содержит подпапки с вложениями, то правильно, что вы не видите их в ТестОпс.

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

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

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

Как проверить: конфигурация allurectl

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

Как исправить: конфигурация allurectl

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

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

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

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

Вы можете использовать вложения для более новых запусков или собрать их из артефактов 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:

   docker compose stop testops

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

   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://demo.qatools.cloud/login/system.

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

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

Ошибка 401: CSRF Token Missing

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

Проблема, скорее всего, связана с "застрявшей сессией" в Redis, который используется для хранения пользовательских сессий. Корень такой "застрявшей сессии" может быть в разных часовых поясах, в которых работает пользователь, т.е. ТестОпс находится в TZ1, компьютер пользователя в TZ2, а пользователь использует VPN-соединение, конечная точка которого находится в TZ3. Эта смесь часовых поясов может вызвать создание сессии, которая всегда истекла с самого начала или еще не активна с точки зрения экземпляра ТестОпс.

1. Попробуйте команду redis-cli FLUSHALL:

redis-cli FLUSHALL

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

или альтернативно вы можете

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

Данные Redis для использования с ТестОпс не должны быть постоянными (т.е. без PVC), поэтому перезапуск удалит все данные о текущих пользовательских сессиях.

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