Просмотр прогона тест-плана

Run View — это живая картинка выполнения тест-плана. Он открывается,
когда вы запускаете план со страницы плана, открываете запись из истории
прогонов или переходите по ссылке, которую отправил коллега. Это один и
тот же вид, независимо от того, прогон закончился секунду назад или две
недели назад — разница только в том, обновляется ли он перед вами в
реальном времени.

Run View показывает все типы элементов плана — TCM-кейсы, функциональные
коллекции, нагрузочные прогоны, фаззинг-кампании, хаос-эксперименты,
контрактные проверки и вложенные планы — с их родными runtime-видами,
рекурсивно, инлайн на одной странице. Чтобы увидеть, что произошло
глубоко внутри дочернего плана или фаззинг-аномалии, уходить со страницы
не нужно.

Об URL в примерах: все примеры используют localhost:5770 как
адрес Mockarty по умолчанию. Если экземпляр работает на удалённом
сервере, замените localhost:5770 на его реальный адрес.

Связанные страницы: Тест-планы ·
Переопределения ·
Отчёт о прогоне плана ·
Runtime-вид прогона (тест-кейс) ·
Шаги тест-кейсов

Что вы видите

Вертикальное дерево карточек — по одной на элемент плана — с шапкой
прогона наверху и панелью контекста справа.

  План: nightly-smoke                       RUNNING  · started 14:22:08

  ├── 1  TCM         Login regression               PASS     4m 12s   ▸ развернуть
  ├── 2  LOAD        Stress checkout                PASS     5m 00s   ▸ развернуть
  ├── 3  FUZZ        Auth endpoint                  PASS     2m 37s   ▸ развернуть
  ├── 4  PLAN        Smoke after deploy             RUNNING  …        ▸ развернуть
  ├── 5  CONTRACT    OpenAPI diff                   PASS     0.9s     ▸ развернуть
  └── 6  TCM         Logout regression              MANUAL   ждёт вас

Кликните карточку — она раскроется. В теле появится родной runtime-вид
для этого типа элемента: графики для нагрузочного прогона, аномалии для
фаззинга, пошаговое дерево для TCM-кейса, такое же дерево уровнем ниже
для вложенного плана.

[Run View — полный прогон плана — screenshot pending]

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

Чипы статусов

Цвет и текст на каждой карточке элемента — это live-статус:

Иконки типов элементов

Каждая карточка несёт маленькую иконку типа элемента, чтобы длинный
список оставался читаемым:

Тело карточки — что показывает каждый тип

Когда карточка развёрнута, тело показывает родной runtime-вид для
этого типа элемента, не обобщённую панель «детали»:

• TCM-кейс — полное дерево шагов. Клик по шагу — запрос, ответ,
  снимок окружения, извлечённые значения, drawer ручного вердикта.
  Контролы пошагового debug-режима (Continue / Stop) появляются, если
  кейс запускался в debug-режиме. Полный гид по чтению — в
  Runtime-виде прогона.
• Functional — сводная карточка: всего запросов / passed / failed /
  длительность. Ниже — список запросов, у каждого метод, путь, код
  ответа, длительность. Клик по строке → drawer с полным HAR.
• Load — три live-графика плюс KPI-чипы. Графики прекращают
  анимацию по завершении прогона и фиксируются на финальной форме.
• Fuzz — список аномалий по severity (critical / high / medium /
  low). У каждой карточки аномалии — payload, спровоцировавший запрос,
  трасса. В шапке счётчики: всего аномалий, уникальных, coverage %,
  всего запусков.
• Chaos — таймлайн fault-событий: когда внедрён, что внедрено,
  когда снят, наблюдаемая дельта метрики в окне вокруг каждого
  события.
• Contract — дерево diff: добавленные пути зелёным, удалённые —
  красным, изменённые — янтарным. Клик по изменённому пути → monaco
  side-by-side с старой и новой схемой.
• Nested plan — Run View дочернего плана, рекурсивно. Все адаптеры
  активны на более глубоком уровне. Защита от циклов: если дочерний
  ссылается на предка, карточка показывает чип CYCLE и placeholder
  «cycle skipped» вместо бесконечной рекурсии. Каждый дочерний прогон
  помнит, какой прогон его запустил, поэтому скрипт или агент может сразу
  получить вложенные прогоны: GET /api/v1/test-plans/runs/{runId}/children
  (MCP: list_test_plan_child_runs) возвращает id, план, статус и счётчики
  элементов каждого дочернего прогона.

Sticky-баннер ручных действий

Если один или несколько TCM-элементов ждут ручной вердикт, наверху
страницы появляется жёлтая полоса:

2 элемента ждут вашего действия — Step 2 of TC-25 · Step 3 of TC-31

Клик по строке — страница прокручивается к нужному элементу,
раскрывает его и открывает resolve-drawer поверх шага. Тот же drawer,
что и на отдельной странице кейса; никакого перехода.

Live-обновления — что означает каждое событие

Run View подписывается на live-поток с сервера. События приходят
естественно; вручную обновлять страницу не нужно.

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

Пошаговый debug TCM-кейсов внутри плана

Если TCM-элемент стартовал в режиме step-debug, во встроенном дереве
TCM показывается sticky-bar внизу после каждого шага — те же контролы,
что на отдельной странице кейса:

• Continue — снять паузу и запустить следующий шаг.
• Continue & edit — открыть редактор, чтобы перед возобновлением
  поправить извлечённые значения plan-context, переопределения для
  следующего шага или его тело запроса.
• Stop — отменить прогон.

Полная справка по debug-режиму, включая как case-level
plan_context_snap перетекает в следующий шаг, — в гиде
Runtime-вид прогона.

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

В шапке есть кнопка Override context. Клик открывает drawer, в
котором можно записать пары ключ/значение {{plan.X}} в живой прогон.

Пары попадают в plan-context bag прогона и распространяются вниз во
все TCM-кейсы, которые стартуют ПОСЛЕ merge — ровно тот же механизм,
что и harvested extract шага, только источник — вы, а не ответ шага.

Когда тянуться к этому:

• Mid-run выясняется, что downstream-элемент ждёт токен, который вы
  можете вставить из другой системы (admin-консоль, wallet-экспорт).
• Флаки upstream-шаг не harvested значение, и вы хотите разблокировать
  прогон без перезапуска.
• Вы ведёте длинный ручной тест и хотите, чтобы все следующие шаги
  видели base URL, который вы выбрали на лету.

Правила приоритета {{plan.X}} — на странице
Переопределения; case-step контекст — в
Шагах тест-кейсов §3.

Item-level переопределение параметров

У pending-элемента — ещё не стартовавшего — можно поправить
parameters до старта. Используется, когда нужно:

• Изменить число виртуальных пользователей нагрузочного элемента
  только для этого прогона.
• Дать фаззинг-элементу другой seed corpus.
• Принудить TCM-кейс запуститься в manual execution mode только для
  этого триггера.

Кликните Edit parameters на карточке pending-элемента. Drawer
покажет текущие параметры; правите, сохраняете — оркестратор подхватит
новые значения, когда будет диспатчить элемент.

Override сбрасывается на rerun элемента (так что вторая попытка с
новыми параметрами — всегда осознанное действие). Шаблон плана не
изменяется; будущие прогоны того же плана стартуют с сохранённых
параметров.

Принятие результата элемента прогона

Если зафиксированная ошибка элемента допустима, выберите на нём
Принять как пройденный и укажите причину. Решение сохраняется для
этого прогона и видно другим операторам; оно не запускает элемент заново
и не меняет исходную запись выполнения. Элемент также можно пометить
пропущенным. Изменять можно только элементы существующего живого прогона.
Удалённый прогон не принимает новые решения. Удаление плана закрывает
сохранённые решения, восстановление плана возвращает их, а окончательное
удаление плана удаляет их вместе с ним.

Item rerun vs plan rerun

У каждой terminal-карточки есть действие Rerun item; в шапке
плана — меню Rerun plan. Это не одно и то же:

Для TCM-элементов Rerun item каскадно вызывает rerun встроенного
case-run. Вложенные планы каскадят так же: сброс родителя триггерит
сброс дочернего рекурсивно, с защитой от циклов, если граф
ссылается на себя.

Чтение комплексного отчёта

Каждый terminal-прогон даёт один вложенный отчёт, который можно
читать прямо на странице прогона или скачать как Allure JSON, Allure ZIP,
JUnit XML, Markdown, HTML или Mockarty JSON. Кнопка Export в шапке
открывает меню форматов. Детали по форматам — что внутри каждого и
когда его выбирать — на странице
Отчёт о прогоне плана.

Шеринг прогона

У каждого прогона постоянный URL:

https://mockarty.example.com/ui/<namespace>/test-plans/runs/<run-id>

Отправьте URL любому, у кого есть read-доступ на namespace, и он
увидит ровно тот же вид, реконструированный с сервера. Если поделиться
ещё бегущим прогоном, получатель сразу с момента открытия видит live-
обновления.

Частые ошибки

• Cycle detected на вложенном плане — родительское дерево потока
  показывает чип CYCLE на карточке вложенного плана вместо
  рекурсии. Оркестратор отказался спускаться, потому что дочерний
  ссылается на предка (прямо или транзитивно). Откройте исходные
  планы и разорвите петлю; прогон завершит остальные элементы
  нормально.
• Item override не сохраняется — override применим только к
  pending-элементу. После старта параметры менять нельзя; чтобы
  сбросить элемент в pending, сделайте rerun.
• Drawer контекста отверг ключ — ключи должны соответствовать
  [A-Za-z_][A-Za-z0-9_.]{0,127}, размер значения ограничен. Drawer
  покажет, какое правило не прошло.
• Drawer пишет «rate limited» — пер-юзерный бюджет на override
  общий с /run-extract из standalone case-вида. Подождите минуту;
  если это agent loop — батчируйте обновления в одно сохранение
  drawer вместо по-ключу.
• Rerun элемента nested-plan пишет «would form a cycle» — defence
  in depth: rerun-путь отказывается ходить по уже посещённой
  родословной. Та же причина, что и CYCLE выше; правьте ссылки
  плана.
• «Plan run is terminal» при попытке overriden’a контекста или
  rerun элемента — прогон уже завершился (passed / failed /
  cancelled). Запустите Rerun plan для нового прогона; mid-run
  overrides действуют только пока прогон ещё в полёте.

Права и namespace-изоляция

• Чтение Run View (снимок + live-обновления) требует test_plan:read
  на namespace, которому принадлежит план.
• Override контекста, правка параметров элемента, rerun элемента и
  разрешение ручного шага — все требуют test_plan:write.
• Кросс-namespace доступ запрещён — пользователь с правом читать
  namespace acme не увидит прогоны из globex, даже если у него
  есть постоянный URL.
• Секреты в request’ах шагов показываются как *** и никогда не
  пишутся в историю прогона, экспорт или audit-trail. В audit
  попадает только имя алиаса и хранилище, откуда секрет читался.

Дальше: страница Переопределения —
сфокусированный справочник по plan / item / step переопределениям и
их приоритету. Страница Отчёт о прогоне плана
покрывает экспорты.