---
read_when:
    - Розширення qa-lab або qa-channel
    - Додавання сценаріїв QA з підтримкою репозиторію
    - Побудова більш реалістичної автоматизації QA навколо панелі керування Gateway
summary: Приватна форма автоматизації QA для qa-lab, qa-channel, сценаріїв із початковими даними та звітів протоколу
title: Автоматизація QA E2E
x-i18n:
    generated_at: "2026-04-20T02:15:03Z"
    model: gpt-5.4
    provider: openai
    source_hash: 34245ce871356caeab0d9e0eeeaa9fb4e408920a4a97ad27567fa365d8db17c7
    source_path: concepts/qa-e2e-automation.md
    workflow: 15
---

# Автоматизація QA E2E

Приватний стек QA призначений для перевірки OpenClaw у більш реалістичний,
каналоподібний спосіб, ніж це може зробити один модульний тест.

Поточні складові:

- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями для DM, каналу, треду,
  реакції, редагування та видалення.
- `extensions/qa-lab`: UI для налагодження та шина QA для спостереження за транскриптом,
  інʼєкції вхідних повідомлень і експорту Markdown-звіту.
- `qa/`: ресурси з початковими даними з підтримкою репозиторію для стартового завдання та базових сценаріїв QA.

Поточний робочий процес оператора QA — це сайт QA з двома панелями:

- Ліворуч: панель керування Gateway (Control UI) з агентом.
- Праворуч: QA Lab, де показано транскрипт у стилі Slack та план сценарію.

Запустіть його так:

```bash
pnpm qa:lab:up
```

Це збирає сайт QA, запускає лінію Gateway на базі Docker і відкриває
сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-місію,
спостерігати реальну поведінку каналу та записувати, що спрацювало, що не спрацювало або
що залишилося заблокованим.

Для швидшої ітерації UI QA Lab без повторного збирання Docker-образу щоразу
запустіть стек із bind-mounted збіркою QA Lab:

```bash
pnpm openclaw qa docker-build-image
pnpm qa:lab:build
pnpm qa:lab:up:fast
pnpm qa:lab:watch
```

`qa:lab:up:fast` залишає Docker-сервіси на попередньо зібраному образі та bind-mount-ить
`extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
перезбирає цю збірку при змінах, а браузер автоматично перезавантажується, коли змінюється хеш ресурсів QA Lab.

Для транспортно-реалістичної лінії smoke для Matrix виконайте:

```bash
pnpm openclaw qa matrix
```

Ця лінія розгортає одноразовий homeserver Tuwunel у Docker, реєструє
тимчасових користувачів driver, SUT та observer, створює одну приватну кімнату, а потім запускає
реальний Plugin Matrix усередині дочірнього процесу QA gateway. Лінія живого транспорту залишає
конфігурацію дочірнього процесу обмеженою транспортом, що тестується, тож Matrix працює без
`qa-channel` у конфігурації дочірнього процесу. Вона записує структуровані артефакти звіту та
обʼєднаний журнал stdout/stderr у вибраний каталог виводу Matrix QA. Щоб
також захопити зовнішній вивід збірки/запуску `scripts/run-node.mjs`, установіть
`OPENCLAW_RUN_NODE_OUTPUT_LOG=<path>` на файл журналу всередині репозиторію.

Для транспортно-реалістичної лінії smoke для Telegram виконайте:

```bash
pnpm openclaw qa telegram
```

Ця лінія націлюється на одну реальну приватну групу Telegram замість розгортання
одноразового сервера. Вона вимагає `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і
`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, а також двох різних ботів в одній
приватній групі. Бот SUT повинен мати імʼя користувача Telegram, а спостереження бот-до-бота
працює найкраще, коли в обох ботів увімкнено Bot-to-Bot Communication Mode
у `@BotFather`.
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується помилкою. Використовуйте `--allow-failures`, якщо
вам потрібні артефакти без коду завершення з помилкою.

Тепер лінії живого транспорту мають один спільний менший контракт замість того, щоб кожна
вигадувала власну форму списку сценаріїв:

`qa-channel` залишається широким синтетичним набором перевірок поведінки продукту і не входить
до матриці покриття живого транспорту.

| Лінія    | Canary | Гейтінг згадок | Блокування allowlist | Відповідь верхнього рівня | Відновлення після перезапуску | Подальша дія в треді | Ізоляція треду | Спостереження за реакціями | Команда help |
| -------- | ------ | -------------- | -------------------- | ------------------------- | ----------------------------- | -------------------- | -------------- | -------------------------- | ------------ |
| Matrix   | x      | x              | x                    | x                         | x                             | x                    | x              | x                          |              |
| Telegram | x      |                |                      |                           |                               |                      |                |                            | x            |

Це зберігає `qa-channel` як широкий набір перевірок поведінки продукту, тоді як Matrix,
Telegram та майбутні живі транспорти мають один явний контрольний список транспортного контракту.

Для одноразової лінії Linux VM без залучення Docker до шляху QA виконайте:

```bash
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
```

Це завантажує нову гостьову систему Multipass, встановлює залежності, збирає OpenClaw
усередині гостя, запускає `qa suite`, а потім копіює звичайний звіт QA та
підсумок назад у `.artifacts/qa-e2e/...` на хості.
Вона повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
Запуски suite на хості й у Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно
з ізольованими воркерами gateway. `qa-channel` за замовчуванням має concurrency 4,
обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати
кількість воркерів, або `--concurrency 1` для послідовного виконання.
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується помилкою. Використовуйте `--allow-failures`, якщо
вам потрібні артефакти без коду завершення з помилкою.
Живі запуски пересилають підтримувані вхідні дані автентифікації QA, які практично
використовувати в гостьовій системі: ключі провайдера через env, шлях до конфігурації живого провайдера QA і
`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гість
міг записувати дані назад через змонтований workspace.

## Початкові дані з підтримкою репозиторію

Ресурси з початковими даними зберігаються в `qa/`:

- `qa/scenarios/index.md`
- `qa/scenarios/<theme>/*.md`

Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
агенту.

`qa-lab` має залишатися загальним виконавцем markdown. Кожен markdown-файл сценарію є
джерелом істини для одного тестового запуску та має визначати:

- метадані сценарію
- необовʼязкові метадані категорії, можливості, лінії та ризику
- посилання на docs і код
- необовʼязкові вимоги до Plugin
- необовʼязковий patch конфігурації gateway
- виконуваний `qa-flow`

Багаторазова поверхня виконання, яка лежить в основі `qa-flow`, може залишатися загальною
і кросфункціональною. Наприклад, markdown-сценарії можуть поєднувати допоміжні засоби
з боку транспорту з допоміжними засобами з боку браузера, які керують вбудованим Control UI через
поверхню Gateway `browser.request`, не додаючи спеціалізованого виконавця.

Файли сценаріїв слід групувати за можливостями продукту, а не за папкою дерева
вихідного коду. Зберігайте ідентифікатори сценаріїв стабільними, коли файли переміщуються; використовуйте `docsRefs` і `codeRefs`
для трасування реалізації.

Базовий список має залишатися достатньо широким, щоб охоплювати:

- чат у DM і каналі
- поведінку тредів
- життєвий цикл дій із повідомленнями
- зворотні виклики Cron
- виклик памʼяті
- перемикання моделей
- передавання підзадачі субагенту
- читання репозиторію та docs
- одне невелике завдання зі збирання, наприклад Lobster Invaders

## Лінії mock провайдерів

`qa suite` має дві локальні лінії mock провайдерів:

- `mock-openai` — це сценарійно-орієнтований mock OpenClaw. Він залишається типовою
  детермінованою лінією mock для QA з підтримкою репозиторію та перевірок паритету.
- `aimock` запускає сервер провайдера на базі AIMock для експериментального покриття протоколу,
  фікстур, record/replay та chaos. Це доповнення, а не заміна диспетчера сценаріїв `mock-openai`.

Реалізація ліній провайдерів розміщена в `extensions/qa-lab/src/providers/`.
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделей gateway,
потребами підготовки профілів автентифікації та прапорцями можливостей live/mock. Спільний код suite і
gateway має маршрутизувати через реєстр провайдерів замість розгалуження за назвами провайдерів.

## Адаптери транспорту

`qa-lab` володіє загальною транспортною поверхнею для markdown-сценаріїв QA.
`qa-channel` — перший адаптер на цій поверхні, але ціль дизайну ширша:
майбутні реальні або синтетичні канали мають підключатися до того самого виконавця suite
замість додавання виконавця QA, специфічного для транспорту.

На рівні архітектури розподіл такий:

- `qa-lab` володіє загальним виконанням сценаріїв, паралельністю воркерів, записом артефактів і звітністю.
- адаптер транспорту володіє конфігурацією gateway, готовністю, спостереженням за вхідними та вихідними подіями, транспортними діями та нормалізованим станом транспорту.
- markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазову поверхню виконання, яка його виконує.

Орієнтовані на мейнтейнерів вказівки з упровадження нових адаптерів каналів розміщені в
[Testing](/uk/help/testing#adding-a-channel-to-qa).

## Звітність

`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини.
Звіт має відповідати на запитання:

- Що спрацювало
- Що не спрацювало
- Що залишилося заблокованим
- Які подальші сценарії варто додати

Для перевірок характеру й стилю запустіть той самий сценарій для кількох живих ref моделей
і запишіть оцінений Markdown-звіт:

```bash
pnpm openclaw qa character-eval \
  --model openai/gpt-5.4,thinking=xhigh \
  --model openai/gpt-5.2,thinking=xhigh \
  --model openai/gpt-5,thinking=xhigh \
  --model anthropic/claude-opus-4-6,thinking=high \
  --model anthropic/claude-sonnet-4-6,thinking=high \
  --model zai/glm-5.1,thinking=high \
  --model moonshot/kimi-k2.5,thinking=high \
  --model google/gemini-3.1-pro-preview,thinking=high \
  --judge-model openai/gpt-5.4,thinking=xhigh,fast \
  --judge-model anthropic/claude-opus-4-6,thinking=high \
  --blind-judge-models \
  --concurrency 16 \
  --judge-concurrency 16
```

Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії оцінювання характеру
мають задавати persona через `SOUL.md`, а потім виконувати звичайні користувацькі ходи,
такі як чат, допомога з workspace та невеликі файлові завдання. Моделі-кандидату
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
транскрипт, записує базову статистику запуску, а потім просить моделі-суддів у швидкому режимі з
міркуванням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
Використовуйте `--blind-judge-models` при порівнянні провайдерів: підказка для суддів усе одно отримує
кожен транскрипт і статус запуску, але ref кандидатів замінюються на нейтральні
мітки, такі як `candidate-01`; після парсингу звіт зіставляє рейтинги назад із реальними ref.
Запуски кандидатів за замовчуванням використовують рівень мислення `high`, а для моделей OpenAI, які це підтримують, — `xhigh`.
Щоб перевизначити конкретного кандидата, використовуйте inline-форму
`--model provider/model,thinking=<level>`. `--thinking <level>` і надалі задає
глобальне резервне значення, а старіша форма `--model-thinking <provider/model=level>` зберігається
для сумісності.
ref кандидатів OpenAI за замовчуванням працюють у швидкому режимі, щоб використовувати пріоритетну обробку там,
де це підтримується провайдером. Додайте `,fast`, `,no-fast` або `,fast=false` inline, коли
одному кандидату або судді потрібно перевизначення. Передавайте `--fast`, лише якщо хочете
примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
записується у звіт для аналізу продуктивності, але підказки для суддів прямо кажуть
не ранжувати за швидкістю.
Запуски моделей-кандидатів і моделей-суддів за замовчуванням обидва використовують concurrency 16. Зменшуйте
`--concurrency` або `--judge-concurrency`, коли ліміти провайдера чи навантаження на локальний gateway
роблять запуск надто шумним.
Коли не передано жодного кандидата `--model`, character eval за замовчуванням використовує
`openai/gpt-5.4`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`,
`anthropic/claude-sonnet-4-6`, `zai/glm-5.1`,
`moonshot/kimi-k2.5` і
`google/gemini-3.1-pro-preview`, якщо не передано `--model`.
Коли не передано `--judge-model`, за замовчуванням як судді використовуються
`openai/gpt-5.4,thinking=xhigh,fast` і
`anthropic/claude-opus-4-6,thinking=high`.

## Повʼязані docs

- [Testing](/uk/help/testing)
- [QA Channel](/uk/channels/qa-channel)
- [Dashboard](/web/dashboard)
