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

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

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

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

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

Поточний потік роботи оператора QA — це двопанельний сайт QA:

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

Запустіть це так:

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

Це збирає сайт QA, запускає lane 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.

Для Matrix smoke lane з реальним транспортом виконайте:

```bash
pnpm openclaw qa matrix
```

Цей lane розгортає одноразовий homeserver Tuwunel у Docker, реєструє
тимчасових користувачів driver, SUT та observer, створює одну приватну кімнату, а потім запускає
реальний Matrix Plugin усередині дочірнього QA gateway. Lane живого транспорту зберігає
конфігурацію дочірнього процесу обмеженою транспортом, що тестується, тому Matrix працює без
`qa-channel` у конфігурації дочірнього процесу.

Для Telegram smoke lane з реальним транспортом виконайте:

```bash
pnpm openclaw qa telegram
```

Цей lane націлюється на одну реальну приватну групу 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`.

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

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

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

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

Для lane з одноразовою 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, до 64 workers або кількості вибраних
сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати кількість workers, або
`--concurrency 1` для послідовного виконання.
Живі запуски передають підтримувані вхідні дані автентифікації QA, які практичні для
гостя: ключі провайдера через env, шлях до конфігурації QA live provider і
`CODEX_HOME`, якщо він наявний. Тримайте `--output-dir` у межах кореня репозиторію, щоб гість
міг записувати назад через змонтований workspace.

## Сиди, що підтримуються репозиторієм

Ресурси сидування розміщені в `qa/`:

- `qa/scenarios/index.md`
- `qa/scenarios/*.md`

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

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

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

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

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

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

## Транспортні адаптери

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

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

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

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

## Звітність

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

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

Для перевірок характеру й стилю запускайте той самий сценарій на кількох live model
refs і записуйте оцінений 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 і невеликі завдання з файлами. Кандидатній моделі
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
транскрипт, записує базову статистику запуску, а потім просить моделі-оцінювачі в fast mode з
мисленням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
Використовуйте `--blind-judge-models` під час порівняння провайдерів: запит до оцінювача все одно отримує
кожен транскрипт і статус запуску, але candidate refs замінюються нейтральними
мітками на кшталт `candidate-01`; звіт зіставляє ранжування назад із реальними refs після
розбору.
Для запусків кандидатів за замовчуванням використовується мислення `high`, а для моделей OpenAI, які це
підтримують, — `xhigh`. Перевизначте конкретного кандидата прямо в рядку за допомогою
`--model provider/model,thinking=<level>`. `--thinking <level>` і далі задає
глобальне запасне значення, а старіша форма `--model-thinking <provider/model=level>` збережена
для сумісності.
Для candidate refs OpenAI за замовчуванням використовується fast mode, щоб застосовувалася пріоритетна обробка там,
де провайдер це підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` прямо в рядку, коли
одному кандидату або оцінювачу потрібне перевизначення. Передавайте `--fast`, лише якщо хочете
примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалість виконання кандидатів і оцінювачів
записується у звіт для аналізу бенчмарків, але в запитах до оцінювачів прямо сказано
не ранжувати за швидкістю.
Для запусків моделей-кандидатів і моделей-оцінювачів за замовчуванням використовується 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`.

## Повʼязані документи

- [Тестування](/uk/help/testing)
- [QA Channel](/uk/channels/qa-channel)
- [Панель керування](/web/dashboard)
