Управление тест-кейсами

Тест-кейс — это письменное описание того, что нужно проверить: название, шаги и
ожидаемый результат. TMS (система управления тестированием) — это место, где команда
хранит все свои тест-кейсы организованно, запускает их и отслеживает, что прошло, а что
упало. Подсистема Test Case Management (TCM) в Mockarty — это встроенная TMS: организуйте
кейсы в папки, версионируйте каждую правку, прикладывайте скриншоты, связывайте с внешними
трекерами, отправляйте на ревью и запускайте — результаты попадают в тот же объединённый
Allure-отчёт, что и остальные типы тестов. Ручное и автоматизированное тестирование живут
в одном месте, а не в отдельном инструменте.

Об URL в примерах: во всех примерах используется localhost:5770 как адрес Mockarty по умолчанию. Если ваш инстанс работает на удалённом сервере, замените localhost:5770 на его реальный адрес (например, https://mockarty.company.com). Подробнее — в разделе Полезные функции и советы.

Смежные страницы: Шаги тест-кейсов · Runtime-вид прогона · Тест-планы · Рабочий процесс ревью · Вложения тест-кейсов · Каналы уведомлений · Вебхуки и обратные вызовы · Интеграции с трекерами

Ключевые понятия

• Тест-кейс — переиспользуемый документ, описывающий что проверить. Содержит метаданные (имя, приоритет, теги, режим исполнения), rich-text-описание, упорядоченный список шагов, вложения и опциональные ссылки во внешние трекеры (Jira, GitHub, Linear, GitLab). Каждый кейс лежит в папке и имеет историю версий.
• Папка — вложенный контейнер (глубина ≤ 8). Перенос в UI через drag-and-drop переносит всё поддерево и пишет запись аудита tcm.folder.moved.
• Шаг — отдельное действие внутри кейса. У каждого — действие, ожидаемый результат, возможные вложения и настройка исполнителя. Шаг может зависеть от предыдущих через dependsOn: [stepUID] — запуски распараллеливают независимые ветви.
• Общий шаг (shared step) — переиспользуемый фрагмент. Вставляется по ссылке — тогда кейсы остаются синхронизированы; можно «прибить» к версии или следовать latest. Builder показывает счётчик использования у каждого общего шага.
• Версия — снапшот кейса. Каждое сохранение создаёт новую версию (хранится до 20 — дальше FIFO-ротация; откат создаёт новую версию, старые не удаляются). Любые две версии можно сравнить: unified text diff + RFC 6902 JSON patch.
• Запуск (run) — исполнение кейса. Бывает одиночным, пакетным (synthetic Test Plan) или встроенным в обычный Test Plan через item-тип test_case.

С чего начать

Откройте /ui/test-cases в админке. Страница разделена на три области:

• Слева — дерево папок. Перетаскивание для переупорядочивания, правый клик для контекстного меню (новая папка, переименовать, удалить, переместить). Ctrl+Click — множественный выбор для массовых операций.
• По центру — редактор выбранного кейса. Вкладки: Шаги, Данные, Вложения, Ревью, Запуск, Прогоны и История. На узком экране прокрутите строку вкладок вбок, чтобы открыть последние разделы.
• Справа — метаданные кейса: статус, приоритет, владелец и кастомные поля. На широком экране панель можно свернуть.

В боковой панели отображается понятный номер кейса, если он есть. Если для
вызова API нужен внутренний ID, нажмите там Скопировать ID кейса.
Связанные и похожие кейсы показываются по названиям, а не по внутренним ID.
Если у кейса, шага или связанного диалога бота нет названия, в ревью и
прогонах отображается понятная подпись; внутренний ID сохраняется в системе.
В панели Агенты ручного шага исполнитель с одним лишь внутренним ID
получает подпись с номером; кнопка снятия назначения называет исполнителя.
Подписи кнопок отвязки запроса и закрытия проверки assertions или извлечений
следуют выбранному языку интерфейса.
При сравнении версий шаг без названия тоже получает понятную подпись. Сравнение
прогонов показывает статусы шагов на выбранном языке интерфейса.
В выборе окружения, хранилища секретов и раннера у шага элементы без названия
тоже получают понятную подпись; привязка для выполнения сохраняется.
В старых комментариях авторы с внутренним ID отображаются по имени учётной записи.
Пока имя загружается, панель ревью показывает понятную подпись без внутреннего
ID в тексте и подсказке при наведении.
Если пользователь не найден или поиск недоступен, в комментариях, метаданных и
истории появляется понятная подпись вместо фрагмента внутреннего ID.
Открытое представление автоматически повторяет временно неудачный поиск с
паузой между попытками, чтобы после восстановления сервиса появилось имя.
Такие же подписи авторов отображаются в комментариях к отчётам о прогонах и
меняют язык вместе с интерфейсом.
Если список выбора предлагает моки, дерево показывает названия папок.
Название API-запроса включает название коллекции. Если список папок временно
недоступен, мок остаётся в группе с названием папки без внутреннего ID в подписи.
Элемент без названия в дереве выбора и в выбранной кнопке показан как
Элемент без названия; сохранённая привязка остаётся прежней.
Если хранилища секретов не загрузились, список показывает Повторить, а не
пустое состояние. Поиск окружений повторяет неудачную загрузку при фокусе.
На узком экране откройте метаданные значком с ползунками в заголовке кейса.
Закройте панель кнопкой с крестиком, клавишей Escape или нажатием вне панели.

У каждой кнопки, поля ввода и элемента списка есть data-ai-action-id / data-ai-info — встроенный AI-ассистент умеет навигировать и действовать от вашего имени.

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

Создание кейса

1. Выберите папку в дереве (или оставайтесь в корне).
2. Нажмите New test case. Откроется пустой builder.
3. Заполните Name, по желанию Priority (low / medium / high / critical), Tags, Execution mode (auto / manual / semi-automatic). Если позже привязать автотест к ручному кейсу (панель Автоматизация в сайдбаре кейса), кейс автоматически переклассифицируется в auto — кейс, за которым стоит CI-автотест, считается автоматизированным. Явный выбор semi-automatic никогда не меняется, а отвязка автотеста режим обратно не возвращает.
4. Напишите Description в rich-text-редакторе. Поддерживаемые форматы: markdown (по умолчанию), html, plain. Область preview показывает экранированный HTML — то, что реально сохранится на сервере.
5. Добавьте Steps один за другим. Перетаскиванием меняйте порядок. Внутри шага:
   • Action и Expected result — rich-text.
   • Depends on позволяет выбрать один или несколько stepUID, которые должны завершиться успехом до этого.
   • Прикрепляйте файлы drag-and-drop или вставкой из буфера (скриншоты из clipboard работают «из коробки»).
   • Insert shared step — вставка общего шага; выбирайте reference (автообновление) или copy (снапшот).
6. Опционально связывайте внешние задачи через picker интеграций (PROJ-123 подсказывает название и статус из настроенного трекера).
7. Сохраните. Создаётся новая версия; панель Review переходит из No review в Draft.

Поверхность API

Все эндпоинты namespace-scoped — /api/v1/namespaces/:namespace/.

Папки

Кейсы

Payload шага (POST /test-cases/:id/versions)

Эндпоинт версий принимает массив steps. Все ключи — camelCase.

{
  "notes": "Регресс логина",
  "steps": [
    {
      "stepUid": "open-login",
      "name": "Открыть страницу логина",
      "action": "Перейти на /login.",
      "description": "Браузер запускается с чистым профилем.",
      "expectedResult": "Видна форма с полями email и пароль.",
      "mode": "manual",
      "executorType": "request",
      "orderIndex": 0,
      "estimatedDurationMs": 5000,
      "dependsOn": []
    },
    {
      "stepUid": "submit-creds",
      "name": "Отправить валидные креды",
      "action": "Ввести тестовый email + пароль и нажать «Войти».",
      "expectedResult": "Редирект на /dashboard в течение 2 секунд.",
      "mode": "manual",
      "executorType": "request",
      "orderIndex": 1,
      "dependsOn": ["open-login"]
    }
  ]
}

Поля:

• stepUid — стабильный идентификатор шага внутри кейса; сохраняется между версиями. Если не указать — сервер сгенерирует.
• name (≤ 300 символов) — короткое отображаемое имя.
• action (≤ 4000 символов) — что делает тестировщик / раннер.
• description (≤ 2000 символов) — опциональный контекст / rich-text.
• expectedResult (≤ 4000 символов) — проверяемый результат.
• mode — manual / semi_automatic / agent_controlled.
• executorType — mock / fuzz / load / collection / request / ui_test / bot / custom / manual. ui_test отправляет шаг браузерному раннеру; bot прогоняет диалог через движок разговорных сценариев (тот же, что в Тестировании ботов) — именно это делает кейс разговорного продукта исполнимым вообще, ведь адреса-ручки у такого продукта нет; manual — шаг без движка-исполнителя, его резолвит человек (или агент).
• executorConfig — настройки конкретного движка. Для шага ui_test полезны ui_test_id (сохранённая запись) или actions (действия прямо на шаге), а также storage_state_id (сохранённое состояние входа, см. Войти один раз), device_lease_id (тёплое, уже залогиненное устройство), snapshot_id (снятый снимок состояния устройства, восстанавливается перед прогоном) и storage_state_uri для состояния, собранного вручную. ID, который невозможно исполнить, проваливает шаг с именованной ошибкой, а не стартует молча разлогиненным или на холодном устройстве — опустите ключ, если нужно именно это. Для шага bot ключи: scenario (диалог, ровно та форма, которую принимает bot_dialog_run) или scenarioId (сохранённый сценарий из Тестирования ботов — тогда платформа берётся из него), а также sessionId (стенд, на который указывает api_url продукта) и необязательные platform (по умолчанию telegram-botapi) и successAny (реплика, означающая, что диалог достиг цели). Шаг bot для telegram-botapi или generic без sessionId проваливается по имени, а не поднимает стенд, который никто не опрашивает.
• orderIndex — неотрицательный int, порядок шагов внутри версии.
• estimatedDurationMs — подсказка для UI; раннер может сравнить с фактической длительностью.
• dependsOn — массив stepUid (≤ 32 элементов). Если любая зависимость завершилась failed / cancelled, раннер помечает текущий шаг skipped с причиной dependency failed: <uid>.

Связывание шагов: извлеки значение — переиспользуй дальше

Шаг может вытащить значение из своего ответа и передать его следующим шагам — так шаг логина захватывает токен, а каждый шаг после него этот токен отправляет. Этим управляют два поля шага:

• extract — массив директив, каждая { "kind": …, "from": …, "to": "plan.<name>" }:
  • kind — jsonpath (по умолчанию), regex, header или status.
  • from — JSONPath (например $.access_token), регэксп или имя заголовка. Для status не нужен.
  • to — имя связи, всегда с префиксом plan. (например plan.accessToken).
• assertions — проверки pass/fail по ответу, выполняются до извлечения (упавшая проверка проваливает шаг и пропускает извлечение).

Захваченное значение подставляется в любом следующем шаге (URL, заголовки, тело, ожидаемый результат) через {{plan.<name>}}. Колонки тест-данных подставляются так же — {{data.<column>}}.

{
  "stepUid": "login",
  "name": "Вход",
  "executorType": "request",
  "extract": [
    { "kind": "jsonpath", "from": "$.access_token", "to": "plan.accessToken" },
    { "kind": "header",   "from": "x-request-id",   "to": "plan.requestId" }
  ]
}

В конструкторе всё в один клик, без ручного редактирования:

• Run once — прогнать один шаг отдельно и увидеть живой ответ до того, как связывать остальную цепочку. Панель также прогоняет директивы извлечения шага по этому ответу и показывает по каждой точное значение, которое она захватила бы — или причину промаха (опечатка в JSONPath, отсутствующий заголовок), — так что экстрактор отлаживается без прогона всего кейса.
• Suggest extracts — проанализировать этот ответ и получить готовый список вероятных захватов (auth-токены, id, частые заголовки), каждый — рядом с примером значения, которое он вытащит, так что видно ровно то, что потечёт дальше. Отметьте нужные и добавьте.
• Автодополнение связей — начните печатать {{ в любом поле шага, и выпадающий список покажет все доступные {{plan.…}} / {{data.…}} из предыдущих шагов; выберите — вставится целиком. Редакторы текста шага (действие, ожидаемый результат, описание) дают тот же словарь через кнопку вставки токена в тулбаре — данные интерполируются и в ручные инструкции.

Запуски

Прогоны по тест-данным (Test Data)

У каждого кейса может быть таблица комбинаций параметров — она создаётся на
вкладке Тестовые данные редактора кейса:

1. Задайте параметры (имя + значения-кандидаты) и выберите технику
   генерации: pairwise (попарная), boundary_values (граничные значения),
   equivalence_classes (классы эквивалентности), decision_table (таблица
   решений), state_transition (переходы состояний) или custom (ручные
   строки). Можно загрузить CSV (первая строка — имена колонок, максимум 1 МБ).
   boundary_values и equivalence_classes варьируют один параметр за раз
   (по его границам / представителям класса), удерживая остальные на
   nominal-значении — поэтому каждая сгенерированная строка несёт значение
   для КАЖДОГО параметра и корректно интерполируется в шаг с несколькими
   токенами. Для equivalence_classes префиксуйте значения valid: /
   invalid: для классификации; в таблице появляется приглушённая колонка
   Класс с указанием, какой раздел проверяет строка.
2. Ссылайтесь на колонку в любом поле шага — URL, тело, заголовки, селекторы,
   проверки — токеном {{data.<колонка>}} (синоним: {{param.<колонка>}}).
   Клик по чипу токена на вкладке копирует его.
3. Запуск:
   • кнопка ▶ на строке таблицы запускает одну комбинацию, либо
     POST /test-cases/:id/run с {"iterationIndex": <строка>};
   • Запустить все запускает по одному прогону на каждую комбинацию одним
     запросом: POST /test-cases/:id/run с {"allIterations": true} — ответ
     {runs, total, started, iterationGroup, failures}; прогоны получают общий
     iterationGroup, каждый несёт бейдж своей итерации в истории запусков.
     До 200 комбинаций за запуск.

allIterations нельзя сочетать с iterationIndex или ciTriggerId
(CI-триггер диспатчит ровно один прогон) — API отклонит конфликт понятной
ошибкой до запуска чего-либо.

Тест-данные сохраняются вместе с кейсом: GET/PUT /test-cases/:id/data;
генерация комбинаций доступна и отдельно: POST /tcm/test-data/generate.

Вложения

Про пайплайн загрузки, квоты и MIME-whitelist — см. Вложения тест-кейсов.

Лимиты и квоты

• Глубина папок: 8 уровней. Проверяется на уровне сервиса и защищено DB CHECK constraint.
• История версий: 20 обычных авторских версий на кейс. FIFO-ротация при каждом сохранении; rollback всегда создаёт новую версию. Сохранённые снимки Test IT показаны по исходному номеру версии и не входят в этот лимит. Сравнение снимка остаётся внутри импортированной истории.
• Вложение: 25 MiB на файл по умолчанию. Администраторы задают квоты на общее хранилище и количество файлов per-namespace; оба лимита hard-enforced при hard_limit_enforce=true.
• Ревью: настраиваемая политика — по умолчанию требуется одно подтверждение, самоподтверждение запрещено. См. Рабочий процесс ревью.

Импорт кейсов из других инструментов

Кнопка Импорт на панели дерева кейсов выбирает обработчик по формату файла.
Правила сопоставления зависят от источника: Test IT сохраняет исходные ID,
если они переданы; табличные импорты кейсов используют имена. Перед повторной
миграцией проверьте сводку импорта.

• Бандл Mockarty (.json) — ранее экспортированный namespace.
• Excel (.xlsx) — первый лист, строка заголовков + одна строка на шаг.
• CSV (.csv) — экспорты из TestRail, Zephyr Scale / Squad,
  Xray или любого табличного инструмента.
• JSON для миграции Test IT — подготовленный бандл с project и workItems;
  поддерживаемые поля и сопоставление описаны в интеграции Test IT.
• Allure case JSON — экспорт кейсов из Allure TestOps.
• TestRail XML (.xml) — собственный экспорт кейсов TestRail (Test Cases →
  Export → XML). Сохраняет дерево разделов как папки, раздельные шаги,
  предусловие, приоритет, тип, ссылки и пользовательские поля, а также
  идентификатор кейса в TestRail (C123).

Для Excel и CSV заголовки колонок сопоставляются без учёта регистра с широкой
таблицей псевдонимов, поэтому «сырой» экспорт обычно импортируется без правок:

Строка с пустым именем продолжает список шагов предыдущего кейса (многострочные
шаги). Заголовок, начинающийся с cf: или custom:, становится кастом-полем
(например, cf:Component). Ответ содержит {created, updated, placed, failed, errors}.

Те же импортёры доступны по API:

curl -X POST "http://localhost:5770/api/v1/namespaces/<ns>/tcm/import/csv" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: text/csv" \
  --data-binary @testrail-export.csv

/tcm/import/xlsx и /tcm/import/allure-cases работают так же; полная миграция
из Test IT описана в интеграции с Test IT.

Экспорт кейсов Allure сохраняет свою идентичность при импорте: id кейса
(поле id экспорта или метка AS_ID, которую пишет аннотация @AllureId(123))
и fullName сохраняются на импортированном кейсе. Ваш CI продолжает отправлять
те же значения, поэтому выгруженные позже результаты попадают именно в
импортированный кейс, а не создают второй — даже после переименования теста.
Повторный импорт исправленного экспорта сопоставляется сначала по этой
идентичности и обновляет тот же кейс.

Загрузка результатов тестов

Результаты загружаются так же, как кейсы, — через Импорт, и каждый
записывается как прогон своего кейса:

• JUnit XML (.xml или .zip с отчётами, например заархивированный
  target/surefire-reports) — его пишут Maven, Gradle, pytest --junitxml, Jest,
  TestNG и большинство CI. Каждый <testcase> сопоставляется по
  classname.name; тест, встреченный впервые, становится новым автоматизированным
  кейсом в папке с именем его <testsuite>. failure записывается как провал,
  error — как сломанный тест, skipped — как пропущенный.
• Результаты Allure (.zip с allure-results) — см.
  Внешние прогоны.
• Результаты прогона TestRail — укажите адрес TestRail, email, API-ключ
  (TestRail → My Settings → API Keys) и номер прогона. Последний результат
  каждого теста ложится на кейс, импортированный из TestRail с тем же C-id.
  Passed → успех, Failed и Retest → провал, Blocked → пропуск; тесты Untested не
  записываются.
• Результаты прогона Test IT — укажите адрес Test IT, PrivateToken и ID
  тестового прогона. Результаты ложатся на кейсы, перенесённые из Test IT, — по
  внешнему идентификатору их автотеста.

Повторная загрузка того же отчёта ложится на те же кейсы. Ответ говорит, сколько
результатов сохранено из скольких было в файле, а если часть отклонена — почему.
Учётные данные TestRail и Test IT используются только для этой загрузки и не
сохраняются.

Из CI отчёт отправляется напрямую:

curl -X POST "http://localhost:5770/api/v1/namespaces/<ns>/tcm/junit-results" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/xml" \
  --data-binary @target/surefire-reports/TEST-com.shop.CartTest.xml

Статус ответа говорит конвейеру, что произошло: 200 — сохранено всё, 207 —
часть результатов отклонена, 422 — не сохранено ничего. В архиве результатов
Allure должны присутствовать все файлы вложений, на которые ссылается результат.
Если скриншота или другого вложения нет, результат отклоняется с причиной в
errors; повторно загрузите полный каталог allure-results.

Экспорт каталога кейсов

Экспорт на панели дерева кейсов предлагает три формата: устаревший JSON
метаданных кейсов,
TestRail XML (импортируйте его в TestRail через Test Cases → Import → XML —
папки становятся разделами, а кейс, пришедший из TestRail, сохраняет свой C-id,
и TestRail обновит его, а не добавит копию) и JSON для обмена кейсами.
Этот JSON сохраняет папки, шаги и приоритет в структуре, которую принимает
импорт Test IT в Mockarty. Интерфейс Test IT не импортирует такой JSON-файл;
для переноса в обратную сторону используйте форматы импорта Test IT.

Устаревший JSON метаданных ограничен 20 000 кейсов и содержит только базовые
метаданные. В нём нет шагов, статусов, кастомных полей, файлов, истории
версий, планов и запусков.
Не используйте его как резервную копию. При импорте появится предупреждение
перед восстановлением только метаданных. Если страница не загрузилась или
число кейсов изменилось во время выгрузки, файл не будет скачан. TestRail XML
и JSON для обмена кейсами также возвращают ошибку при превышении 20 000 кейсов;
отдельную папку с вложенными папками можно выгрузить через API с параметром
folderId. Если дерево папок не удаётся прочитать или число выгруженных кейсов
отличается от полного каталога, API вернёт ошибку вместо частичного файла;
повторите выгрузку после стабилизации каталога. Эти обменные форматы не
содержат кастомные поля, статусы/воркфлоу,
файлы, историю ревью и версий, планы и запуски и не являются полной
архивной копией.

Создание кейсов с помощью ИИ

Кнопка Draft with AI на дереве кейсов открывает ИИ-автора. Опишите, что
хотите проверить, обычным языком, затем:

• Generate draft создаёт ОДИН глубоко проработанный кейс (название, шаги,
  приоритет, предложенную папку) — проверьте превью и нажмите Save draft as
  case.
• Generate suite создаёт целый набор (размер сьюта — от 1 до 50) — кейсы
  приходят редактируемым превью, а Save all cases сохраняет их через тот же
  путь, что и файловый импорт (идемпотентно по имени, папки создаются
  автоматически).

Обоим нужен включённый LLM-профиль (см. ИИ-функции);
шестерёнка рядом с ИИ-кнопкой выбирает профиль, модель и кастомный промпт.

Вехи

Группируйте работу вокруг релиза. Веха — самостоятельная сущность с
человекочитаемым ключом (например, REL-1.4), дедлайном и статусом (open /
completed / archived); к нему привязываются задачи трекера, прогоны
тест-планов, кейсы и требования, а сводка прогресса отвечает на вопрос
«насколько готов релиз».

Вехи живут внутри трекера: откройте Задачи в сайдбаре и переключитесь
на вид Вехи (/ui/tasks?view=milestones):

• Создайте веху с ключом (уникален в namespace), названием и датой
  дедлайна. Просроченные даты подсвечиваются; каждая карточка несёт живой
  прогресс-бар.
• Кликните по карточке, чтобы открыть веху: готовность релиза,
  привязанные сущности (с названиями, ключами и статусами — каждая ведёт на
  саму сущность) и пикер привязки.
• Привязывайте сущности по названию: выберите тип (задача / прогон
  тест-плана / кейс / требование) и начните вводить — пикер подсказывает
  совпадения по мере ввода; клик привязывает сущность. Никаких id копировать
  не нужно. Требования — это страницы Wiki (помеченные как требования); их
  привязка учитывается в числе проверенных требований готовности релиза.
• Готовность релиза агрегирует привязанные прогоны тест-планов (всего /
  выполнено / упало / прошло элементов, число завершённых прогонов, процент
  выполнения и долю прошедших) плюс количество привязанных задач и сколько из
  них закрыто.
• Перевод статуса в completed автоматически проставляет время завершения.

API зеркалирует вид:

ИИ-агенты работают с той же поверхностью через MCP-инструменты
tcm_milestones_list, tcm_milestone_create, tcm_milestone_update,
tcm_milestone_entity_search, tcm_milestone_link, tcm_milestone_unlink и
tcm_milestone_progress.

Трассируемость требований

Отслеживайте, что реально покрывают ваши кейсы. Требование — это страница
Wiki, помеченная как требование (user story, пункт спецификации,
комплаенс-требование), к которой вы привязываете тест-кейсы; её панель
трассируемости отвечает на вопрос «какие кейсы это проверяют и проходят ли они».

Требования живут в Wiki, поэтому требование хранит и полную спецификацию (rich
text, таблицы, диаграммы), и своё покрытие в одном месте:

• Сделайте требование в Wiki: откройте страницу → Преобразовать в
  требование (или перетащите страницу в зону «Требования» в дереве). Оно
  получит человекочитаемый ключ (например REQ-42), тип (функциональное /
  нефункциональное) и статус. Преобразование родительской страницы
  преобразует и её дочерние страницы.
• Привяжите кейсы из панели Трассируемость страницы требования: найдите
  кейс и привяжите в один клик. Кейсы в корзине автоматически перестают
  считаться покрытием (восстановление из корзины возвращает покрытие).
• Сводка проверки. Панель показывает каждый покрывающий кейс и вердикт
  проверено / падает / не запускалось по правилу худшего состояния: один
  покрывающий кейс с упавшим последним прогоном помечает всё требование как
  падающее, даже если остальные проходят — регрессия не спрячется за зелёной
  полосой. Непокрытое требование — видимый пробел.
• Привязка со стороны кейса. Откройте тест-кейс → секция Документация в
  панели деталей: найдите страницу требования и привяжите. Ссылки на требования
  помечены их ключом REQ-N, поэтому кейс сразу показывает, какие требования он
  проверяет; панель «Трассируемость» страницы требования — обратное
  представление.

Так как требование — это страница Wiki, его API и агент-тулы — это Wiki-тулы:

AI-агенты работают с той же поверхностью через MCP-тулы wiki_search,
wiki_page_convert, wiki_requirement_link_case, wiki_requirement_unlink_case
и wiki_requirement_traceability (покрывающие кейсы требования + вердикт).

Работа с тест-планами

Тест-кейс можно включить в обычный Test Plan:

{
  "name": "Ночная регрессия",
  "items": [
    { "type": "test_case", "refId": "<case-uuid>" },
    { "type": "functional", "refId": "<collection-uuid>" }
  ]
}

При запуске плана TCM-координатор исполняет кейс пошагово — точно так же, как если бы вы вызвали /test-cases/:id/run напрямую, — и результат попадает в общий Allure-отчёт плана.

Нестабильные кейсы

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

Настройки детектора — в Настройки → TMS: порог оценки, сколько последних
прогонов образуют окно, заглушать ли помеченный кейс автоматически и на какой
срок, отправлять ли уведомление о новой пометке. Кнопка Run flaky scan
пересчитывает каталог по требованию.

Кнопка 🗲 в шапке дерева тест-кейсов открывает обзор нестабильных — плоский
список помеченных кейсов с долей переключений и количеством переключений за окно.
Из строки можно:

• открыть кейс,
• Заглушить на 24 ч — чтобы он не поднимал новые пометки, пока вы его чините,
• Снять заглушение — вернуть кейс под детектор.

Alt+клик по 🗲 (или адрес /ui/test-cases?flaky=muted) сузит список ровно до
заглушённых сейчас — так вы найдёте кейс, который заглушила автоматика.

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

Интеграции и автоматизация

• Внешние трекеры — настройте один или несколько инстансов Jira / GitHub / GitLab / Linear в Настройки → Интеграции. Поле внешней ссылки в конструкторе автоматически дополняет PROJ-123 и показывает живые чипы с заголовком и статусом задачи. Подробнее: Внешние трекеры и инструменты.
• Вебхуки — подпишитесь на события кейсов, папок, запусков и ревью и доставляйте в HTTP / Kafka / RabbitMQ. Кнопка 🔔 на любом кейсе оформляет подписку в один клик.
• Каналы уведомлений — те же события в Slack / Telegram / Teams / Discord / e-mail / в приложении через Настройки → Каналы уведомлений.
• AI-ассистент — AI-агент может составить новые кейсы по описанию фичи и пройти живой запуск, автоматически резолвя ручные шаги. Требует настроенного LLM-профиля (см. ИИ-функции).

Аудит

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