У нас был переработан раздел тест-план, теперь вкладки "планирование" и "выполнение" объединены.

Теперь на одной странице Вы можете создавать наборы тестов,  сразу же назначать на них тестировщиков и проходить.

1) url – адрес развёрнутой Test IT, копируется из адресной строки без слэша в конце.

2) privateToken – API-токен, создаётся в разделе «Настройки профиля» - «Безопасность». Показывается один раз.

3) projectId – уникальный идентификатор проекта, в который будут загружены результаты автотестов. Можно получить двумя способами:

• На странице проектов нажать на три точки справа у нужного проекта и нажать «Скопировать ID»

• Открыть инструменты разработчика в браузере (F12 / Ctrl+Shift+C) и обновить страницу, находясь в проекте. В теле ответа на запрос «Configurations» будет указан project_id

4) configurationId – уникальный идентификатор конфигурации, которая будет применена к карточкам автотестов. Можно получить двумя способами:

• На странице конфигураций нажать на три точки справа у нужного проекта и нажать «Скопировать ID»

• Аналогично project_id узнать через инструменты разработчика

5) testRunId – уникальный идентификатор прогона (тест-рана), который нужен для работы адаптера в режимах 0 и 1. При режиме адаптера 2 его указывать не нужно. Получить его можно на странице «Прогоны»:

6) testRunName – кастомное название прогона, который будет создан при использовании адаптера в режиме 2. Ниже пример стандартного и кастомного значения:

7) adapterMode – режим работы адаптера, всего их три:

• Режим 2 – при запуске автотестов в этом режиме в Test IT автоматически будет создан новый прогон (тест-ран), в который будут загружены результаты всех обнаруженных в репозитории автотестов.
• Режим 1 – в этом режиме результаты всех автотестов будут загружены в один конкретный прогон, который уже есть в системе. Для этого дополнительно нужно указать id этого прогона.
• Режим 0 – в этом режиме адаптер фильтрует автотесты по id прогона и конфигурации и запускает не все автотесты, а только те которые содержатся в прогоне, id которого передается. То есть пользователь в UI выбирает конкретные тесты для запуска, нажимает «Запустить автотесты», выбирает конфигурацию и вебхук (опционально), далее создается новый прогон, айди которого нужно передать, и адаптер запустит только те тесты, которые находятся в этом прогоне, то есть только выбранные в UI.

ВАЖНО! В некоторых тестовых фреймворках адаптер не поддерживает режим 0, а только режимы 1 и 2. Среди этих фреймворков:
nose, jest, mocha, playwright, testcafe, xunit, specflow, jvm-cucumber, jbehave, go, xctest

Аналогично adapterMode 2 нет в xunit и specflow

8) certValidation – включение (true) или выключение (false) валидации сертификата

9) automaticCreationTestCases - отвечает за создание ручных тестов, связанных с автотестами, которые Вы проливаете в систему. У Вас стоит стандартное значение, значит создаваться карточки ручные не будут. Можете указать true и у Вас помимо библиотеки автотестов также появятся ручные карточки в библиотеки тестов, они сразу будут корректно связаны 1 к 1 и Вы сможете добавлять эти тесты в тест-план (карточки автотестов в тест-план добавить нельзя, только ручные). Если у Вас уже написанные ручные тесты, которые Вы хотите автоматизировать, тогда Вам данный параметр лучше отключить.

10) automaticUpdationLinksToTestCases - если поставить true, то адаптер будет проверять указанные в коде декораторы woritemsID (то есть айди ручных тестов, которые мы привязываем к автотесту прямо в коде) и удалять в Test IT связи ручных и автотестов, если эти связи теряют актуальность, то есть когда они не соответствуют workitemsIds, указанным в коде. Если False или не задан, то связи автотеста с тест-кейсами не разрываются при отсутствии аннотации workItemIds

11)importRealtime – если поставить true, то тесты будут выгружаться в TestIT по мере их прохождения (то есть у вас есть 38 автотестов, их результаты в режиме реального времени будут проливаться в систему). Если false, то по прохождению всех тестов они все разом выгрузятся в систему.

При выскакивании ошибки "Тег с выбранным именем уже существует" нужно проверить привязан ли параметр к проекту, необходимо перейти в "настройки проектов":

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

Если внутри тест-плана не отображаются тест-поинты, необходимо проверить установлена ли конфигурация по умолчанию:

Чтобы поставить конфигурацию по умолчанию необходимо отрыть ее в режиме редактирования:

Также вручную  можно добавить необходимую конфигурацию в тестовый-набор:

Далее из списка выбираем нужную конфигурацию:

После добавления конфигурации тест-поинты отобразятся внутри тест-плана

ВАЖНО! Если в разделе "конфигурации" у Вас пусто, то нужно создать новую конфигурацию или посмотреть в архив > конфигурации 

Актуально для пользователей TestIT Enterprise.

Выполните команды в папке с проектом:

docker-compose -f docker-compose.yml -p <имя_проекта> exec <имя_контейнера> psql -U <имя_администратора_postgres> -d authdb -a -c "UPDATE \"AspNetUsers\" SET \"PasswordHash\"='AQAAAAEAACcQAAAAECcIyHvyOizImicKdyRomOoh1G8MBfN9p/yzdUEve6AjRGpZWB5DP8WzLsrNbOoiLw==', \"IsDeleted\"=false, \"IsDisabled\"=false where \"UserName\"='admin' AND \"UserType\"='LOC';"

Логин администратора postgres по умолчанию - postgres
Пароль для пользователя admin (LOC) будет выставлен на пароль по умолчанию - Qwerty123

"UserName\"='admin' можно заменить на любого локального пользователя и, поcле применения команд, у него так же будет пароль Qwerty123

или так:
1. docker exec <имя_контейнера> bash
2. psql -U <имя_администратора_postgres> -d authdb -a -c "UPDATE "AspNetUsers" SET "PasswordHash"='AQAAAAEAACcQAAAAECcIyHvyOizImicKdyRomOoh1G8MBfN9p/yzdUEve6AjRGpZWB5DP8WzLsrNbOoiLw==', "IsDeleted"=false, "IsDisabled"=false where "UserName"='admin' AND "UserType"='LOC';"

Если БД внешняя:
1. psql -U <имя_администратора_postgres> -d authdb -a -c "UPDATE \"AspNetUsers\" SET \"PasswordHash\"='AQAAAAEAACcQAAAAECcIyHvyOizImicKdyRomOoh1G8MBfN9p/yzdUEve6AjRGpZWB5DP8WzLsrNbOoiLw==', \"IsDeleted\"=false, \"IsDisabled\"=false where \"UserName\"='admin' AND \"UserType\"='LOC';"

Для взаимодействия с TestIT посредством открытого API, понадобится авторизоваться с помощью приватного API токена.
В данной инструкции рассмотрим авторизацию в штатном инструменте “Swagger”, а так же на примере стороннего сервиса “Postman“.

Авторизация в Swagger:

В первую очередь, нужно сгенерировать приватный API токен.

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

Скопируйте API токен и перейдите в «Swagger». Переход осуществляется посредством нажатия на кнопку «Документация API».

После перехода на страницу Swagger, нажмите на кнопку «Authorize» и укажите скопированный раннее токен вместе с ключом (PrivateToken) в следующем формате:
PrivateToken cmJKUkRMNGJLa25Kd2l

Авторизация в стороннем сервисе на примере Postman:

Скопируйте ваш API токен по шагам из первого раздела данной инструкции.

В окне редактирования вашего запроса, откройте раздел «Authorization» и укажите следующие данные:
Type - Api Key
Key – Authorization
Value – PrivateToken ваш токен
Add to – Header

Для корректной работы интеграций с сервисами, размещёнными за закрытым сетевым контуром, могут потребоваться IP-адреса системы Test IT Cloud - и добавление их в белый список.

Наше облако хостится в Yandex Cloud, соответственно, потребуется завайтлистить весь пул адресов Яндекса.

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

• Google Chrome. Нажмите на три вертикальные точки в правом верхнем углу браузера, перейдите в «Настройки», затем в раздел «Конфиденциальность и безопасность» и «Удалить данные браузера». Выберите  «Всё время», поставьте галочку «Изображения и другие файлы, сохранённые в кэше» и нажмите «Удалить данные».
• «Яндекс Браузер». Откройте меню (нажмите на три линии в правом верхнем углу), перейдите в «Настройки», затем в «Системные», прокрутите вниз до «Очистить историю». Выберите «За всё время», поставьте галочку «Файлы, сохранённые в кэше» и нажмите «Очистить».
• Safari. Выберите в верхнем меню пункт «Разработка» и нажмите «Очистить кэши». Если пункт не отображается, нажмите в верхнем меню «Safari», затем «Дополнение» и отметьте пункт «Показывать меню „Разработка“».
• Microsoft Edge. Откройте меню, нажав на три горизонтальные точки в правом верхнем углу браузера. Выберите «Параметры» или «Настройки», затем «Удалить данные о просмотре веб-страниц», «Выбрать элементы для удаления». Поставьте галочку «Кэшированные образы и файлы» и нажмите «Удалить сейчас».

После полной очистки браузера вкладки проекта отобразятся корректно

Приглашение пользователей в TestIT Cloud

1. Перейдите на страницу id.testit.software/workspaces и нажмите на панели пространства, в которое необходимо пригласить пользователя.
2. Откройте раздел «Приглашение пользователей» и нажмите «Пригласить».

3. В появившемся модальном окне укажите электронную почту и системную роль сотрудника.

*Обратите внимание, что приглашать пользователей может только владелец пространства.

Если сотруднику назначена роль отличная от "Администратор", то после того, как сотрудник принял ваше приглашение, осталось добавить его в проект, в котором он будет работать:

1. Откройте нужный проект, разверните раздел «Настройки» и перейдите во вкладку «Пользователи».
2. Нажмите «Добавить», в модальном окне выберите пользователя из выпадающего списка и укажите его проектную роль.

Все готово, сотрудник может приступать к работе!

Удаление пользователей из пространства в TestIT Cloud

Удалять пользователей, в привычном понимании этого действия, в TestIT Cloud нельзя, поскольку каждый аккаунт это индивидуальная сущность с подтвержденным e-mail и собственным паролем.
Вы можете забрать у пользователя доступ к пространству, чтобы освободить слот лицензии для нового сотрудника.
Для этого  достаточно снять с пользователя все системные роли:

Перейдите в раздел «Администрирование», во вкладку «Системные роли» и снимите чекбокс с сотрудника, которого хотите убрать.

Удалить профиль пользователя, в привычном понимании этого действия, в TestIT Cloud нельзя, поскольку каждый аккаунт это индивидуальная сущность с подтвержденным e-mail и собственным паролем.
Но, Вы можете не переживать, мы связаны с вами политиками конфиденциальности в рамках пользовательского соглашения и лицензионного договора, поэтому ваши данные не достанутся третьим лицам =)

Инфраструктурная проверка k8s:
Проверить, что все ключевые Pod/Deployment в namespace имеют статус Running/Ready.Проверить migration Job: статус Completed.

1. Проверить логи webapi, auth, background-service на error/exception/fail.
2. Проверить доступность UI через Ingress и корректную авторизацию (Local/LDAP/OpenID).

Полезные команды:
1. Проверить ресурсы namespace
kubectl get deploy,sts,pods,svc,ingress,jobs -n
2. Найти проблемные Pod
kubectl get pods -n
kubectl get pods -n | grep -E "CrashLoopBackOff|ImagePullBackOff|Pending|Error"
3. Проверить migration Job
kubectl get jobs -n
kubectl logs job/ -n
4. Проверить ошибки в логах core-сервисов
kubectl logs deploy/testit-webapi -n --since="30m" | grep -Ei "error|exception|fail"
kubectl logs deploy/testit-auth -n --since="30m" | grep -Ei "error|exception|fail"
5. Проверить внешний доступ
kubectl get ingress,svc -n
kubectl describe ingress -n

Проверка контейнеров docker:
Убедитесь, что после поднятия системы все необходимые контейнеры запущены при помощи docker ps -a

Контейнеры в статусе up– testit-frontend, testit-background-service, testit-avatars.api, testit-webapi, testit-globalsearch-service, testit-license-service, testit-auth-cache, testit-ldapwebapi, testit-improxy, testit-influxdb, testit-rabbitmq, testit-db, testit-minio, testit-gotenberg Контейнеры в статусе exited – testit-globalsearch-migrationtool-data, testit-globalsearch-migrationtoo-context Проверка на наличие error в контейнерах - docker logs <имя или id контейнера> | grep -i error

Проверки UI:

• Вход в систему.
• Загрузка аватара.
• Проекты: создание, атрибуты, добавление пользователя, интеграции.
• Тест-кейс: параметр, изображение в шаге, вложение, ссылка.
• Тест-план: создание, массовый запуск, генерация отчета.

Авторизация:
Проверить вход в систему (в зависимости какие провайдеры входа есть) – Local, LDAP, OpenID (может происходить долгая загрузка страницы, если ранее Вы были авторизованы в Test IT, то стоит обратить внимание на ссылку она должна быть выглядеть следующим образом “https:<ваш домен>/auth” или проверить в инкогнито)

Загрузка аватарок: 
Справа сверху нажимаем на иконку профиля > настройки профиля
В открывшейся вкладке загружаем фото

Проекты:
1. Создать проект на вкладке «проекты»
2. В проекте создаем тест-кейс/Чек-лист/Общий шаг
3. В проекте создаем конфигурацию
4. Создание проектных атрибутов/добавление глобальных атрибутов
5. Добавление пользователя в проект
6. Подключение интеграции (Таск-трекер, ИИ)

Тест-кейс:
1. В тест-кейсе создаем параметр
2. Добавляем изображение в шаге
3. Прикладываем в тест-кейс файл/архив
4. Добавляем ссылку в разделе «ссылки» 

Тест-план:
1. Переходим внутри проекта на вкладку тест-план создаем тест-план наполняем его тест-кейсами
2. Проставляем результаты тестов (можно массовыми действиями)
3. Генерируем отчет на основе тест-плана

Devtool (F12 или CTRL+SHIFT+I):
Проверить что в запросах нет ошибок

Критерий успеха

• Нет неготовых Pod и незавершенных migration Job.
• Нет критичных ошибок в логах core-сервисов.
• UI сценарии выполняются без блокирующих ошибок.

Рекомендуемые системные требования:

CPU 16 ядер серверного класса с поддержкой виртуализации и тактовой частотой 2.2 ГГц и выше

RAM 16 GB

Network 100 Mbit/s

SSD минимум 100 GB

SWAP отключен

Docker Engine 17.12.0 и выше

Docker Compose V2 и выше

ОЗУ рекомендуем брать х1.5, так как формула не учитывает расход ресурса на поддержание работы ОС сервера

Если у вас до 100 пользователей ТМС - то их должно хватать.

Подготовили формулу для расчета сайзинга.

CPU, % = 1.7793682795702017 * x_testers + 220.17887911673282 + 34.60618279570265 * x_cicd + 131.94166666663241 + 66.42065217390495 * x_managers + 29.91630434784424

Memory, MB = 2.8511366854344384 * x_testers + 14.103620631720517 * x_cicd + 153.93974694293502 * x_managers + 7067.5608723958385

где, x_testers - количество параллельно работающих тестировщиков/автотестировщиков,

x_cicd - количество параллельно работающих CI загружающих автотесты и результаты,

x_managers - количество параллельно работающих менеджеров с дашбордами.

Итого мы имеем:

1. CPU берем рекомендуемые или считаем по формуле

2. ОЗУ берем рекомендуемые или считаем по формуле

3. ОС - Ubuntu 22.04 или CentOS 8 (тестируем на Ubuntu 22.04)

4. Docker Engine 17.12.0 и выше

5. Docker Compose V2 и выше

В Test IT используется следующая формула подсчета стабильности тестов:

100% - M/N * 100%

Где N - число всех переходов между статусами автотеста (100 последних прохождений или все, если их меньше 100)
M - число переходов между статусами автотеста, в которые статус изменился

Примеры:

• No result - "-"
• Passed - "100%"
• Passed Passed - "100%" (0/1), где 0 = M, 1 = N
• Passed Failed - "0%" (1/1)
• Passed Failed Passed - "0%" (2/2)
• Passed Failed Passed Failed - "0%" (3/3)
• Passed Failed Passed Failed Failed - "25%" (3/4)

Формула учитывает переходы между статусами, а не просто процент успешных прогонов. Даже если из 10 прогонов только 1 неуспешный, важна последовательность изменений статусов. Если тест переходил из "Успешен" в "Провален" и обратно, это два изменения статуса M="2" при N="9" переходах (так как первый результат не учитывается). Тогда стабильность: 100 - (2/9) * 100 = 78%

Количество последних прогонов - это параметр, который регулирует выборку, на основе которой анализируются результаты автотестов. Условно автотест был запущен 1000 раз, но здесь указано число 100, а значит предыдущие 900 не будут ни на что влиять, а будут влиять только последние 100. Отсюда как раз берется число N из формулы (N - это "Количество последних прогонов минус один")

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

Изменить владельца пространства можно из профиля текущего владельца пространств, в соответствующем разделе. 

1. Нужно перейти в настройки пространства:

2. Затем, в настройки аккаунта:

3. Далее, в открывшемся разделе "Личные данные" можно изменить имя, фамилию, и электронную почту владельца пространства:

Важно, чтобы адрес новой электронной почты не был зарегистрирован в Test IT Cloud!

1. Создать сертификат при помощи команд ниже:

openssl genrsa -out имя_сертификата.key 2048 - запрос на создание сертификата;

openssl req -new -key имя_сертификата.key -out test.csr - создание файла запроса для сертификата;

openssl x509 -req -days 365 -in имя_сертификата.csr -signkey имя_сертификата.key -out имя_сертификата.crt - получение файлов сертификата;

openssl x509 -in имя_сертификата.crt -text -noout - проверка сертификата;

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

2. Передать права файлам .crt и .key при помощи команды chmod 644 имя_сертификата.key имя_сертификата.crt ;

3. Положить эти файлы в папку volume’а /var/lib/docker/volumes/название_проекта_ssl-volume;

4. Внести изменения в файл .env в папке с TestIT - раскомментировать и исправить:

SSL_CERTIFICATE=/etc/nginx/ssl/имя_сертификата.crt

SSL_CERTIFICATE_KEY=/etc/nginx/ssl/имя_сертификата.key

REDIRECT_TO_HTTPS=true

5. Перезапустить проект через docker compose down/up;

6. Проверить в браузере переход на https и выдачу следующего окна (могут отличаться в зависимости от инструментов/настроек ИБ):

При настройке интеграции Yandex.Tracker, на этапе создания приложения если в правах нет доступа: "чтение из трекера" и "запись в трекер".
Переходим по данной ссылке oauth.yandex.ru/client/new, далее регистрируем приложение

Сохраняем приложение и продолжаем настройку интеграции согласно инструкции

Для записи системных логов в файл в k8s к каждому нашему сервису надо добавить в values:

Serilog__WriteTo__1__Name: File

Serilog__WriteTo__1__Args__path: logs/system.logs

Serilog__WriteTo__1__Args__rollingInterval: Day

Serilog__WriteTo__1__Args__retainedFileCountLimit: 3

Serilog__WriteTo__1__Args__formatter__type: Serilog.Formatting.Json.JsonFormatter,

Serilog Serilog__WriteTo__1__Args__formatter__renderMessage: true

Для записи логов аудита добавить к webapi и auth тоже в values:

Application__UserActionAudit__Enable: true

Application__UserActionAudit__Path: ... # default value 'logs/user-action.log'

1. Начиная с версии 5.3 по умолчанию все логи пишутся в консоль (и логи аудита и системные логи)

2. Логирование файла всё ещё доступно, но регулируется переменными

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

4. Если мы хотим дополнительно писать только логи аудита в файл, то нужны переменные Application__UserActionAudit. На данный момент их ротация не конфигурируется и захардкожена на 1 день

5. Настройки ротации для Serilog (т.е. логирование вообще всего) доступно на уровне переменных

Добавились методы:

• /api/v2/backgroundJobs/{id}/status
• /api/v2/projects/{projectId}/testPlans/attributes/{attributeId}
• /api/v2/projects/{projectId}/workItems/search/grouped
• /api/v2/projects/{projectId}/testPlans/attributes put

в следующих методах изменилось название параметра, сперва идет старый метод, следом - новый:

• /api/v2/projects/{id}/attributes/templates/{templateId} post, delete
  • /api/v2/projects/{projectId}/attributes/templates/{templateId} post, delete
• /api/v2/projects/{id}/attributes/templates/search post
  • /api/v2/projects/{projectId}/attributes/templates/search post
• /api/v2/projects/{id}/attributes get, post, put
  • /api/v2/projects/{projectId}/attributes get, post, put
• /api/v2/projects/{id}/attributes/search post
  • /api/v2/projects/{projectId}/attributes/search post
• /api/v2/projects/{id}/attributes/{attributeId} get, delete
  • /api/v2/projects/{projectId}/attributes/{attributeId} get, delete
• /api/v2/projects/{id}/configurations get
  • /api/v2/projects/{projectId}/configurations get
• /api/v2/projects/{id}/export/json post
  • /api/v2/projects/{projectId}/export/json post
• /api/v2/projects/{id}/export/zip post
  • /api/v2/projects/{projectId}/export/zip post
• /api/v2/projects/{id}/export post
  • /api/v2/projects/{projectId}/export post
• /api/v2/projects/{id}/export/testPlans/json post
  • /api/v2/projects/{projectId}/export/testPlans/json post
• /api/v2/projects/{id}/export/testPlans/zip post
  • /api/v2/projects/{projectId}/export/testPlans/zip post
• /api/v2/projects/{id}/import/json post
  • /api/v2/projects/{projectId}/import/json post
• /api/v2/projects/{id}/import/zip post
  • /api/v2/projects/{projectId}/import/zip post
• /api/v2/projects/{id}/import post
  • /api/v2/projects/{projectId}/import post
• /api/v2/projects/{id}/sections get
  • /api/v2/projects/{projectId}/sections get
• /api/v2/projects/{id}/testPlans/attributes get, post
  • /api/v2/projects/{projectId}/testPlans/attributes get, post
• /api/v2/projects/{id}/testPlans/attributes/search post
  • /api/v2/projects/{projectId}/testPlans/attributes/search post
• /api/v2/projects/{id}/testPlans/search post
  • /api/v2/projects/{projectId}/testPlans/search post
• /api/v2/projects/{id}/testPlans/{name}/exists get
  • /api/v2/projects/{projectId}/testPlans/{name}/exists get
• /api/v2/projects/{id}/testPlans/analytics get
  • /api/v2/projects/{projectId}/testPlans/analytics get
• /api/v2/projects/{id}/testPlans/delete/bulk post
  • /api/v2/projects/{projectId}/testPlans/delete/bulk post
• /api/v2/projects/{id}/testPlans/restore/bulk post
  • /api/v2/projects/{projectId}/testPlans/restore/bulk post
• /api/v2/projects/{id}/testPlans/purge/bulk post
  • /api/v2/projects/{projectId}/testPlans/purge/bulk post
• /api/v2/projects/{id}/workItems get
  • /api/v2/projects/{projectId}/workItems get
• /api/v2/projects/{id}/workItems/search post
  • /api/v2/projects/{projectId}/workItems/search post
• /api/v2/projects/{id}/workItems/search/id post
  • /api/v2/projects/{projectId}/workItems/search/id post
• /api/v2/projects/{id}/workItems/tags get
  • /api/v2/projects/{projectId}/workItems/tags get

Отредактировано описание для следующих методов:

• /api/v2/configurations/purge/bulk
  • добавили описание для статуса 200
• /api/v2/configurations/createByParameters
  • обновили саммари
  • обновили описание ошибки 403
  • убрали описание респонса 200
• /api/v2/parameters
  • убрали описание для статуса 201
  • добавили описание для статуса 200
• добавили "deprecated": true
  • /api/v2/projects/{id}/testPlans/attribute/{attributeId}
  • /api/v2/projects/{id}/testPlans/attribute
• добавлены респонсы 400, 401, 404 в документацию
  • /api/v2/workItems/{id}/restore
  • /api/v2/workItems/{id}/purge

Добавлены следующие модели:

• WorkItemExtractionModel
• WorkItemGroupGetModel
• WorkItemGroupModel
• WorkItemGroupType
• WorkItemLocalFilterModel
• WorkItemLocalSelectModel

Изменения в моделях:

• AttachmentModel
  • Добавлено поле IsTemp
• AutoTestPutModel
  • id сделали не обязательным, нулабле
• BackgroundJobGetModel
  • добавили обязательное поле createdDate
• BackgroundJobType
  • добавили значения "ExportProjects", "ImportProjects"
• LinkModel, LinkPutModel
  • id сделали не обязательным, нулабле
• ParameterModel, ParameterPostModel, ParameterPutModel, ParameterShortModel
  • добавили документацию к полям value, name
• SectionPostModel, SectionPutModel
  • добавили обязательное поле attachments
• SectionWithStepsModel
  • добавили не обязательное поле attachments, нулабле
• TestPointByTestSuiteModel, TestPointShortModel
  • в документации поле title изменено на description, расширены значения полей
  • добавлено не обязательное поле workItemMedianDuration
• WorkItemsExtractionModel
  • переименовано в WorkItemExtractionModel

Для загрузки результатов с помощью импортера нужно указать url пространства:

У каждого пространства свой уникальный url.
1) Необходимо открыть или создать файл tms.config.json, указан в нем необходимые переменные:

2) Запускаем importer, выбор импортера зависит от операционной системы win/osx/linu

3) По завершению работы импортера, внутри TestIT создаться проект с перенесенными в него кейсами

Если у Вас в пространстве отсутствует кнопка пригласить: 

1) Проверьте являетесь ли Вы владельцем пространства, это можно проверить перейдя в раздел - id.testit.software/workspaces у пространства должна быть шестеренка:

2)Убедитесь хватает ли слотов лицензии для приглашения пользователей, это можно проверить перейдя в "настройки пространства" > "управление пространством",  в поле "пользователи" отобразиться количество лицензий:

Важно! если у Вас ранее был тариф lite и Вы оплатили одну лицензию, то пространство будет доступно только владельцу.

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

Либо Вы при создании параметра указываете проект, в котором он будет использоваться:

Либо Вы редактируете уже существующий параметр, нажав на три точки справа. Там можно привязать новый проект. Параметр можно привязать сразу к нескольким проектам.

После этого у Вас в списке параметров для каждого параметра будут подписаны проекты, в которых он доступен.

И при создании конфигурации внутри ПРИВЯЗАННОГО ПРОЕКТА, можно будет указать параметр.

С параметризованными тестами в Test IT нужно работать следующим образом, так как создается один автотест, его id не меняется, так как ExternalID создается автоматически на основе namespace + classname + названия тестового метода, и они будут совпадать в случае параметризованного автотеста, поэтому для каждого набора входных значений параметров нужно создавать отдельную карточку.
Сделать это можно с помощью указания аннотации @ExternalId(), в которой нужно обязательно подставлять значения параметров. Тогда каждая итерация будет создавать в Test IT отдельный автотест и связанный с ним ручной тест. Сами ручные тесты можно добавить в тест-план, для корректного отображения информации о прохождении автотестов.

Пример как должен выглядеть тест:

@DataProvider(name = "TestDP")
private static Object[][] testDP() {
return new Object[][]{
{1, 1},
{1, 2}
};
}

@ExternalId("{a},{b}")
@DisplayName("Test with {a},{b}")
@Test(dataProvider = "TestDP")
public void test(int a, int b) {
Assert.assertEquals(a, b);
}

Все будет выглядеть следующим образом:

Проливаем параметризованный автотест в Test IT, создается его карточка (при указании параметра automaticCreationTestCases="true" , будут созданы ручные карточки, которые связаны с автотестами)

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

В существующем ручном тесте нужно добавить параметры автотеста, и подставить только один набор значений в табличку. Связать такую карточку можно и вручную на вкладке "Связанные автотесты". Либо можно еще раз пролить автотесты из IDE, указав аннотацию @WorkItemIds

Примера двух ручных карточек для двух наборов параметров:

Затем связываем с соответствующими автотестами: 

После добавляем в тест-план и запускаем их:

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

Необходимо проверить доступ с помощью сurl к ТМС, сделать это можно следующим образом:
1) Получить ключ авторизации путем кодирования в base64:

https://decodeit.ru/base64/ (ввести пару login:password, копировать полный результат, использовать как строку

Authorization: "Basic bG9naW46cGFzc3dvcmQ="

где bG9naW46cGFzc3dvcmQ= - результат кодирования.)

2) Затем вызвать запрос с передачей данного хедера, можно через Postman, можно через curl:

curl -X GET " -H "Authorization: Basic bG9naW46cGFzc3dvcmQ="

Перед установкой или обновлением версии адаптера, проверьте свою версию продукта TestIT на нашем gitgub - Test IT · GitHubЗдесь можно найти необходимый Вам адаптер (рассмотрим на примере Pytest)

На github есть таблица совместимости где указаны какие версии используются для той или иной версии TestIT - GitHub - testit-tms/adapters-python

К примеру для версии 5.4 необходимо установить версию адаптера 3.6.6.post540,

За более актуальными релизами адаптеров можно перейти в “Releases

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

Следуя из релизов самым актуальной версией адаптера для 5.4 является 3.7.2.post540

Немного о версиях адаптера, если мы не наблюдаем приписку post, то данная версия поддерживается для Cloud решения продукта, если у версии присутствует приписка postxxx, где “xxx” это версия Enterprise решения.

Для того чтобы добавить интеграцию с LDAPS, в настройках подключения укажите порт 636 вместо 389, также поставьте галочку в поле SSL. Также сертификаты нужно будет прокинуть.

При проблеме с ошибкой "504 Gateway Time-out"

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

1. Вы можете линковать требование к тест-кейсу. У нас есть такой тип ссылки внутри ТК:

2. Можете создать кастомный атрибут (есть разных типов), в который будете передавать нужное вам значение
Например, можно добавить атрибут с типом чек-бокс, где будет три варианта "покрыт требованием", "не покрыт", "не проанализирован"

Подробнее про атрибуты в Test IT: https://docs.testit.software/user-guide/admin-guide/set-up-attributes.html

Сам пример будет рассматриваться на примере вебхука в telegram с событием прохождения автотестов, изменение статуса тест-плана и изменение тест-плана

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

Название произвольное

Описание на свое усмотрение

Состояние:

Запушен – хотим получать отбивку
Остановлен – если хотим прекратить получать уведомления по данному событию

URL:

Для получения уведомлений в telegram необходимо зарегестрироваться в чат-боте Настройка уведомлений в Telegram с помощью вебхуков | Test IT

В поле url указываем https://webhooks.testit.software/telegram

тип запроса POST

Заголовки HTTP:
Указываем параметр Authorization, в значении указываем токен который получаем из бота

Тело запроса HTTP:

Тип контекста – отправлять пользовательский контекст

Заменить системные параметры ставим галочку

Пользовательский контекст:

Внутри указываем переменные на те или иные параметры

Изменение тест-плана:
{
"message": "$TEST_PLAN_NAME тут можно вставить то, что хотите увидеть в уведомлении от бота", "parseMode": "HTML",
"chatIds": [ ваш чат айди ]
}
$TEST_PLAN_NAME – название тест-плана

Изменение тест-плана:
{
"message": "Тест-план: $TEST_PLAN_NAME теперь в статусе $TEST_PLAN_STATUS. \n юзер изменивший тест-план:$USER_NAME",
"parseMode": "HTML",
"chatIds": [ ваш чат айди ]
}
$TEST_PLAN_NAME – название тест-плана
$TEST_PLAN_STATUS – статус тест-план
$USER_NAME – учетная запись

Прохождение всех автотестов:
{
"message": "Завершен прогон автотестов $TEST_RUN_NAME, тестран завершён $TEST_RUN_COMPLETED_DATE. Ссылка: $TEST_RUN_URL.",
"parseMode": "HTML",
"chatIds": [ ваш чат айди ]
}
$TEST_RUN_NAME – название прогона $TEST_RUN_COMPLETED_DATE - время завершения$TEST_RUN_URL – ссылка на прогон

- Тест-кейсы, чек-листы, общие шаги удаляются из архива через:

Это когда в библиотеке тестов (ручных) мы нажимаем архивировать на какой-нибудь WorkItem

Затем их можно вручную удалить из архива уже навсегда, но если этого не делать, то в архиве могут копиться WI, которые занимают место, однако уже не нужны пользователю. Здесь логика, как у корзины Windows. Иногда нужно восстановить что-нибудь, что удалили по ошибке, но в целом её необходимо периодически чистить.

- Вложения из результатов тестов удаляются через:

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

- Автоматическое очищение архивов через:

Это когда мы на странице проектов архивируем проект:

И он попадает в глобальный архив, который отображается в верхнем меню:

Также данный пункт удаляет архив конфигураций и архив тест-плана

- Автоматическое очищение автотестов через:

Здесь речь идёт про автотесты, добавленные в архив в библиотеке автотестов:

- Автоматическое очищение прогонов через:

Здесь речь идет про прогоны автотестов, добавленные в архив. Располагаются они на вкладке "Автотесты" - "Прогоны"

Архивация будет работать для очистки архива и прогонов с указанным временным интервалом в 180 дней,

Необходимо поднять значение max_pool_size для testitdb, например, до 300, после чего переподнять систему. В Docker это настривается в .env файле, в K8s - в values TESTIT_DB_CONNECTION_STRING: >

Host=; Port=";" Database=";" Username=";" Password=";" Command Timeout=";" Target Session Attributes="any;" Pooling="true;" Maximum Pool Size="300;

Если в консоли появляется 400 JiraClientException
То ошибка находится на стороне Jira, необходимо проверить все схемы и поля поочередно отключив их, что может вызывать ошибку отправки баг-репорта

Необходимо найти в бд прогоны которые еще в процессе но в UI не отображаются
SELECT
tr."Id" AS "TestRunId",
tr."Name" AS "TestRunName",
tr."StartedDate" AS "StartedDate",
tr."CompletedDate" AS "CompletedDate",
tr."StateName" AS "Status",
tr."IsDeleted" AS "IsDeleted"
FROM
"TestRuns" tr
JOIN
"TestBiathlons" tb ON tr."Id" = tb."TestRunId"
WHERE
tb."AutoTestId" = '01973fff-8f2c-7ab3-8669-86939e9a47bf'
ORDER BY
tr."StartedDate" DESC;
Далее через Api запрос остановить прогоны post /api/v2/testRuns/{id}/stop
После остановки прогонов АТ должен удалится

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

Ctrl + Z - отмена
Ctrl + Y - повторить

Ctrl + E - код
Ctrl + Alt + C - блок кода

Ctrl + V (на выделенный текст) - добавить ссылку
Ctrl + B - полужирный
Ctrl + I - курсив
Ctrl + U - подчёркивание
Ctrl + Shift + S - перечёркивание

Ctrl + , - нижний индекс
Ctrl + . - верхний индекс

Ctrl + Shift + L - выравнивание по левому краю
Ctrl + Shift + E - выравнивание по центру
Ctrl + Shift + R - выравнивание по правому краю

Ctrl + Shift + 7 - нумерованный список
Ctrl + Shift + 8 - маркированный список

Ctrl + Alt + 1 - заголовок 1
Ctrl + Alt + 2 - заголовок 2
Ctrl + Alt + 3 - заголовок 3
Ctrl + Alt + 0 - обычный текст