chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
d0873c8689
commit
23ebc4db2a
@ -1,49 +1,49 @@
|
||||
---
|
||||
read_when:
|
||||
- Розширення qa-lab або qa-channel
|
||||
- Додавання QA-сценаріїв із підтримкою репозиторію
|
||||
- Побудова реалістичнішої автоматизації QA навколо панелі керування Gateway
|
||||
summary: Приватна форма автоматизації QA для qa-lab, qa-channel, початково заповнених сценаріїв і звітів протоколу
|
||||
- Додавання QA-сценаріїв, що спираються на репозиторій
|
||||
- Створення реалістичнішої автоматизації QA навколо панелі керування Gateway
|
||||
summary: Приватна форма автоматизації QA для qa-lab, qa-channel, сценаріїв із початковими даними та звітів протоколу
|
||||
title: Автоматизація QA E2E
|
||||
x-i18n:
|
||||
generated_at: "2026-04-26T23:47:39Z"
|
||||
generated_at: "2026-04-26T23:53:03Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 654d8333149d98a85373652ce483ab29f3e524df298493d2d3101564f3e01799
|
||||
source_hash: 107c0af2635ffa272c6d559ac77cc4b3846a664c92cb1054d37fa73ded119559
|
||||
source_path: concepts/qa-e2e-automation.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Приватний стек QA призначений для перевірки OpenClaw у більш реалістичний,
|
||||
Приватний стек QA призначений для тестування OpenClaw у більш реалістичний,
|
||||
каналоподібний спосіб, ніж це може один модульний тест.
|
||||
|
||||
Поточні складові:
|
||||
|
||||
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями для DM, каналів, гілок,
|
||||
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, треду,
|
||||
реакцій, редагування та видалення.
|
||||
- `extensions/qa-lab`: UI налагодження та шина QA для спостереження за транскриптом,
|
||||
інʼєкції вхідних повідомлень і експорту звіту у форматі Markdown.
|
||||
- `qa/`: assets початкового заповнення з підтримкою репозиторію для стартового завдання та базових QA-
|
||||
сценаріїв.
|
||||
- `extensions/qa-lab`: інтерфейс налагодження та шина QA для спостереження за транскриптом,
|
||||
введення вхідних повідомлень і експорту звіту в Markdown.
|
||||
- `qa/`: seed-ресурси на основі репозиторію для стартового завдання та базових
|
||||
QA-сценаріїв.
|
||||
|
||||
Поточний потік роботи оператора QA — це двопанельний сайт QA:
|
||||
Поточний робочий процес оператора QA — це двопанельний сайт QA:
|
||||
|
||||
- Ліворуч: панель керування Gateway (Control UI) з агентом.
|
||||
- Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію.
|
||||
- Праворуч: QA Lab, де показано транскрипт у стилі Slack і план сценарію.
|
||||
|
||||
Запустіть це так:
|
||||
Запустіть це за допомогою:
|
||||
|
||||
```bash
|
||||
pnpm qa:lab:up
|
||||
```
|
||||
|
||||
Це збирає сайт QA, запускає лінію Gateway на базі Docker і відкриває
|
||||
сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-
|
||||
місію, спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що
|
||||
не спрацювало або що залишилося заблокованим.
|
||||
Це збирає сайт QA, запускає доріжку gateway на базі Docker і відкриває
|
||||
сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-місію,
|
||||
спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що не
|
||||
спрацювало або що залишилося заблокованим.
|
||||
|
||||
Для швидшої ітерації UI QA Lab без повторного збирання образу Docker щоразу,
|
||||
запустіть стек із QA Lab bundle, змонтованим через bind mount:
|
||||
Щоб швидше ітерувати UI QA Lab без перебудови Docker-образу щоразу,
|
||||
запускайте стек зі змонтованим через bind bundle QA Lab:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa docker-build-image
|
||||
@ -52,136 +52,144 @@ pnpm qa:lab:up:fast
|
||||
pnpm qa:lab:watch
|
||||
```
|
||||
|
||||
`qa:lab:up:fast` утримує сервіси Docker на попередньо зібраному образі та монтує
|
||||
`extensions/qa-lab/web/dist` у контейнер `qa-lab` через bind mount. `qa:lab:watch`
|
||||
перезбирає цей bundle при змінах, а браузер автоматично перезавантажується, коли
|
||||
змінюється хеш asset QA Lab.
|
||||
`qa:lab:up:fast` залишає сервіси Docker на попередньо зібраному образі та
|
||||
монтує `extensions/qa-lab/web/dist` у контейнер `qa-lab` через bind-mount. `qa:lab:watch`
|
||||
перезбирає цей bundle при змінах, а браузер автоматично перезавантажується,
|
||||
коли змінюється хеш ресурсів QA Lab.
|
||||
|
||||
Для локального smoke-тесту трасування OpenTelemetry виконайте:
|
||||
Для локальної smoke-перевірки трасування OpenTelemetry виконайте:
|
||||
|
||||
```bash
|
||||
pnpm qa:otel:smoke
|
||||
```
|
||||
|
||||
Цей скрипт запускає локальний приймач трас OTLP/HTTP, виконує
|
||||
QA-сценарій `otel-trace-smoke` з увімкненим Plugin `diagnostics-otel`, потім
|
||||
декодує експортовані protobuf spans і перевіряє критично важливу для релізу форму:
|
||||
QA-сценарій `otel-trace-smoke` з увімкненим Plugin `diagnostics-otel`, а потім
|
||||
декодує експортовані protobuf span-и та перевіряє критично важливу для релізу форму:
|
||||
мають бути присутні `openclaw.run`, `openclaw.harness.run`, `openclaw.model.call`,
|
||||
`openclaw.context.assembled` і `openclaw.message.delivery`;
|
||||
виклики моделі не повинні експортувати `StreamAbandoned` у разі успішних ходів; сирі ID діагностики та
|
||||
атрибути `openclaw.content.*` не повинні потрапляти в трасу. Він записує
|
||||
`otel-smoke-summary.json` поруч з artifacts QA suite.
|
||||
виклики моделі не повинні експортувати `StreamAbandoned` у разі успішних ходів; сирі діагностичні ID і
|
||||
атрибути `openclaw.content.*` не повинні потрапляти до траси. Він записує
|
||||
`otel-smoke-summary.json` поруч з артефактами набору QA.
|
||||
|
||||
Звичайний агрегат Docker також виконує лінію спостережуваності. Він збирає або
|
||||
повторно використовує Docker-образ спостережуваності на основі вихідного коду, запускає smoke-тест трасування OTEL
|
||||
всередині контейнера, а потім виконує QA-сценарій `docker-prometheus-smoke` з
|
||||
увімкненим Plugin `diagnostics-prometheus`. Установіть
|
||||
Звичайний агрегований Docker-запуск і базовий chunk для релізного шляху також
|
||||
виконують доріжку спостережуваності. Вона повторно використовує спільний
|
||||
функціональний Docker-образ, встановлений як пакет, монтує файли harness QA лише для читання,
|
||||
виконує smoke-перевірку трасування OTEL усередині контейнера, а потім запускає
|
||||
QA-сценарій `docker-prometheus-smoke` з увімкненим Plugin `diagnostics-prometheus`. Установіть
|
||||
`OPENCLAW_DOCKER_OBSERVABILITY_LOOPS=<count>`, щоб повторити обидві перевірки в межах одного
|
||||
запуску Docker зі збереженням artifacts кожного циклу в
|
||||
Docker-запуску, зберігаючи артефакти кожного циклу в
|
||||
`.artifacts/docker-observability/...`.
|
||||
|
||||
Для smoke-лінії Matrix з реальним транспортом виконайте:
|
||||
Для транспортно-реальної smoke-доріжки Matrix виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa matrix
|
||||
```
|
||||
|
||||
Ця лінія розгортає в Docker тимчасовий homeserver Tuwunel, реєструє
|
||||
тимчасових користувачів driver, SUT і observer, створює одну приватну кімнату, а потім запускає
|
||||
справжній Plugin Matrix у дочірньому Gateway QA. Лінія живого транспорту тримає
|
||||
конфігурацію дочірнього процесу обмеженою транспортом, що тестується, тож Matrix запускається без
|
||||
`qa-channel` у дочірній конфігурації. Вона записує структуровані artifacts звіту та
|
||||
обʼєднаний журнал stdout/stderr у вибраний вихідний каталог Matrix QA. Щоб
|
||||
також захопити зовнішній вивід збирання/запуску `scripts/run-node.mjs`, установіть
|
||||
`OPENCLAW_RUN_NODE_OUTPUT_LOG=<path>` на локальний щодо репозиторію файл журналу.
|
||||
Поступ Matrix за замовчуванням виводиться в консоль. `OPENCLAW_QA_MATRIX_TIMEOUT_MS` обмежує
|
||||
повний запуск, а `OPENCLAW_QA_MATRIX_CLEANUP_TIMEOUT_MS` обмежує очищення, щоб
|
||||
зависле завершення Docker повідомляло точну команду відновлення замість зависання.
|
||||
Ця доріжка розгортає одноразовий 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>` на
|
||||
локальний для репозиторію файл журналу.
|
||||
Хід Matrix виводиться за замовчуванням. `OPENCLAW_QA_MATRIX_TIMEOUT_MS`
|
||||
обмежує весь запуск, а `OPENCLAW_QA_MATRIX_CLEANUP_TIMEOUT_MS` обмежує очищення, щоб
|
||||
зависле завершення Docker повідомляло точну команду відновлення замість
|
||||
зависання.
|
||||
|
||||
Для smoke-лінії Telegram з реальним транспортом виконайте:
|
||||
Для транспортно-реальної smoke-доріжки Telegram виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa telegram
|
||||
```
|
||||
|
||||
Ця лінія націлюється на одну реальну приватну групу Telegram замість розгортання
|
||||
тимчасового сервера. Вона потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
|
||||
Ця доріжка націлена на одну реальну приватну групу 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`, коли
|
||||
потрібні artifacts без коду завершення з помилкою.
|
||||
Звіт і підсумок Telegram включають RTT для кожної відповіді — від запиту на
|
||||
приватній групі. Бот SUT повинен мати ім’я користувача Telegram, а спостереження
|
||||
бота за ботом працює найкраще, коли для обох ботів увімкнено режим
|
||||
Bot-to-Bot Communication Mode у `@BotFather`.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується
|
||||
невдачею. Використовуйте `--allow-failures`, якщо вам потрібні артефакти без
|
||||
коду завершення з помилкою.
|
||||
Звіт і підсумок Telegram містять RTT для кожної відповіді від запиту на
|
||||
надсилання повідомлення driver до спостережуваної відповіді SUT, починаючи з canary.
|
||||
|
||||
Перш ніж використовувати спільні живі облікові дані, виконайте:
|
||||
Перш ніж використовувати об’єднані живі облікові дані, виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa credentials doctor
|
||||
```
|
||||
|
||||
Doctor перевіряє env брокера Convex, валідовує налаштування endpoint і перевіряє
|
||||
досяжність admin/list, коли присутній секрет супровідника. Він повідомляє лише
|
||||
статус set/missing для секретів.
|
||||
Doctor перевіряє env брокера Convex, валідує налаштування endpoint і перевіряє
|
||||
досяжність admin/list, коли присутній секрет супроводжувача. Він повідомляє лише
|
||||
про статус set/missing для секретів.
|
||||
|
||||
Для smoke-лінії Discord з реальним транспортом виконайте:
|
||||
Для транспортно-реальної smoke-доріжки Discord виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa discord
|
||||
```
|
||||
|
||||
Ця лінія націлюється на один реальний приватний канал guild у Discord із двома ботами:
|
||||
Ця доріжка націлена на один реальний приватний канал guild у Discord із двома ботами:
|
||||
ботом driver, яким керує harness, і ботом SUT, запущеним дочірнім
|
||||
Gateway OpenClaw через вбудований Plugin Discord. Вона потребує
|
||||
OpenClaw gateway через вбудований Plugin Discord. Вона вимагає
|
||||
`OPENCLAW_QA_DISCORD_GUILD_ID`, `OPENCLAW_QA_DISCORD_CHANNEL_ID`,
|
||||
`OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN`, `OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN`
|
||||
і `OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID` під час використання облікових даних через env.
|
||||
Лінія перевіряє обробку згадок каналу та перевіряє, що бот SUT
|
||||
і `OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID` під час використання облікових даних з env.
|
||||
Доріжка перевіряє обробку згадок у каналі та перевіряє, що бот SUT
|
||||
зареєстрував нативну команду `/help` у Discord.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується невдачею. Використовуйте `--allow-failures`, коли
|
||||
потрібні artifacts без коду завершення з помилкою.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується
|
||||
невдачею. Використовуйте `--allow-failures`, якщо вам потрібні артефакти без
|
||||
коду завершення з помилкою.
|
||||
|
||||
Тепер лінії живого транспорту спільно використовують один менший контракт замість того, щоб
|
||||
кожна вигадувала власну форму списку сценаріїв:
|
||||
Доріжки живого транспорту тепер спільно використовують один менший контракт,
|
||||
замість того щоб кожна вигадувала власну форму списку сценаріїв:
|
||||
|
||||
`qa-channel` залишається широким синтетичним набором поведінки продукту й не входить
|
||||
до матриці покриття живого транспорту.
|
||||
`qa-channel` залишається широким синтетичним набором перевірок поведінки продукту й не є частиною
|
||||
матриці покриття живого транспорту.
|
||||
|
||||
| Лінія | Canary | Контроль згадок | Блокування списком дозволених | Відповідь верхнього рівня | Відновлення після перезапуску | Подальша дія в гілці | Ізоляція гілки | Спостереження реакцій | Команда help | Реєстрація нативної команді |
|
||||
| -------- | ------ | --------------- | ----------------------------- | ------------------------- | ----------------------------- | -------------------- | -------------- | --------------------- | ------------ | --------------------------- |
|
||||
| Matrix | x | x | x | x | x | x | x | x | | |
|
||||
| Telegram | x | x | | | | | | | x | |
|
||||
| Discord | x | x | | | | | | | | x |
|
||||
| Доріжка | Canary | Блокування за згадками | Блокування allowlist | Відповідь верхнього рівня | Відновлення після перезапуску | Подальше повідомлення в треді | Ізоляція треду | Спостереження за реакціями | Команда help | Реєстрація нативної команд |
|
||||
| -------- | ------ | ---------------------- | -------------------- | ------------------------- | ----------------------------- | ----------------------------- | -------------- | -------------------------- | ------------- | -------------------------- |
|
||||
| Matrix | x | x | x | x | x | x | x | x | | |
|
||||
| Telegram | x | x | | | | | | | x | |
|
||||
| Discord | x | x | | | | | | | | x |
|
||||
|
||||
Це зберігає `qa-channel` як широкий набір поведінки продукту, тоді як Matrix,
|
||||
Telegram і майбутні живі транспорти спільно використовують один явний контрольний список транспортного контракту.
|
||||
Це зберігає `qa-channel` як широкий набір перевірок поведінки продукту, тоді як Matrix,
|
||||
Telegram і майбутні живі транспорти спільно використовують один явний чекліст
|
||||
транспортного контракту.
|
||||
|
||||
Для лінії з тимчасовою Linux VM без залучення Docker у шлях QA виконайте:
|
||||
Для доріжки з одноразовою Linux VM без включення Docker у шлях QA виконайте:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
|
||||
```
|
||||
|
||||
Це завантажує свіжу гостьову систему Multipass, встановлює залежності, збирає OpenClaw
|
||||
всередині гостьової системи, запускає `qa suite`, а потім копіює звичайний звіт і
|
||||
Це завантажує нову гостьову VM Multipass, установлює залежності, збирає OpenClaw
|
||||
усередині гостя, запускає `qa suite`, а потім копіює звичайний звіт і
|
||||
підсумок QA назад у `.artifacts/qa-e2e/...` на хості.
|
||||
Вона повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
|
||||
Запуски suite на хості та в Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно
|
||||
з ізольованими Gateway workers. `qa-channel` за замовчуванням використовує concurrency 4,
|
||||
обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати
|
||||
кількість workers, або `--concurrency 1` для послідовного виконання.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується невдачею. Використовуйте `--allow-failures`, коли
|
||||
потрібні artifacts без коду завершення з помилкою.
|
||||
Живі запуски передають підтримувані вхідні дані автентифікації QA, які практичні для
|
||||
гостьової системи: ключі провайдерів через env, шлях до конфігурації живого провайдера QA та
|
||||
`CODEX_HOME`, якщо присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гостьова система
|
||||
могла записувати назад через змонтований workspace.
|
||||
Воно повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
|
||||
Запуски набору на хості та в Multipass за замовчуванням виконують кілька вибраних
|
||||
сценаріїв паралельно з ізольованими worker-ами gateway. `qa-channel` за замовчуванням
|
||||
використовує concurrency 4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати
|
||||
кількість worker-ів, або `--concurrency 1` для послідовного виконання.
|
||||
Команда завершується з ненульовим кодом, якщо будь-який сценарій завершується
|
||||
невдачею. Використовуйте `--allow-failures`, якщо вам потрібні артефакти без
|
||||
коду завершення з помилкою.
|
||||
Живі запуски пересилають підтримувані вхідні дані автентифікації QA, які
|
||||
практичні для гостя: ключі провайдера на основі env, шлях до конфігурації
|
||||
живого провайдера QA і `CODEX_HOME`, якщо він присутній. Тримайте `--output-dir`
|
||||
у межах кореня репозиторію, щоб гість міг записувати назад через змонтований
|
||||
робочий простір.
|
||||
|
||||
## Початкове заповнення з підтримкою репозиторію
|
||||
## Seed-ресурси на основі репозиторію
|
||||
|
||||
Assets початкового заповнення розміщені в `qa/`:
|
||||
Seed-ресурси розміщені в `qa/`:
|
||||
|
||||
- `qa/scenarios/index.md`
|
||||
- `qa/scenarios/<theme>/*.md`
|
||||
@ -189,81 +197,83 @@ Assets початкового заповнення розміщені в `qa/`:
|
||||
Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
|
||||
агенту.
|
||||
|
||||
`qa-lab` має залишатися загальним виконавцем markdown. Кожен файл сценарію markdown є
|
||||
джерелом істини для одного тестового запуску та має визначати:
|
||||
`qa-lab` має залишатися універсальним runner-ом Markdown. Кожен файл сценарію в Markdown —
|
||||
це джерело істини для одного тестового запуску й повинен визначати:
|
||||
|
||||
- метадані сценарію
|
||||
- необовʼязкові метадані категорії, можливостей, лінії та ризику
|
||||
- посилання на docs і код
|
||||
- необовʼязкові вимоги до Plugin
|
||||
- необовʼязковий patch конфігурації Gateway
|
||||
- необов’язкові метадані категорії, можливостей, доріжки та ризику
|
||||
- посилання на документацію та код
|
||||
- необов’язкові вимоги до Plugin
|
||||
- необов’язковий patch конфігурації gateway
|
||||
- виконуваний `qa-flow`
|
||||
|
||||
Багаторазова runtime-поверхня, що підтримує `qa-flow`, може залишатися загальною
|
||||
і наскрізною. Наприклад, markdown-сценарії можуть поєднувати helper-и на боці транспорту
|
||||
з helper-ами на боці браузера, які керують вбудованим Control UI через
|
||||
seam `browser.request` Gateway, без додавання спеціального виконавця.
|
||||
Багаторазово використовувана поверхня runtime, що стоїть за `qa-flow`, може
|
||||
залишатися універсальною та наскрізною. Наприклад, Markdown-сценарії можуть
|
||||
поєднувати допоміжні засоби на боці транспорту з допоміжними засобами на боці браузера, які керують
|
||||
вбудованим Control UI через seam `browser.request` у Gateway, не додаючи runner
|
||||
зі спеціальною обробкою.
|
||||
|
||||
Файли сценаріїв слід групувати за можливостями продукту, а не за папками дерева
|
||||
вихідного коду. Зберігайте стабільність ID сценаріїв, коли файли переміщуються; використовуйте `docsRefs` і `codeRefs`
|
||||
для простежуваності реалізації.
|
||||
Файли сценаріїв слід групувати за можливостями продукту, а не за папкою
|
||||
дерева вихідного коду. Зберігайте стабільність ID сценаріїв під час переміщення файлів; використовуйте `docsRefs` і `codeRefs`
|
||||
для відстежуваності реалізації.
|
||||
|
||||
Базовий список має залишатися достатньо широким, щоб охоплювати:
|
||||
|
||||
- чати в DM і каналах
|
||||
- поведінку гілок
|
||||
- чат у DM і каналі
|
||||
- поведінку тредів
|
||||
- життєвий цикл дій із повідомленнями
|
||||
- Cron callbacks
|
||||
- відновлення з памʼяті
|
||||
- зворотні виклики cron
|
||||
- відтворення пам’яті
|
||||
- перемикання моделей
|
||||
- передачу підлеглому агенту
|
||||
- читання репозиторію та docs
|
||||
- одне невелике завдання зі збирання, наприклад Lobster Invaders
|
||||
- передачу підзадач субагенту
|
||||
- читання репозиторію та документації
|
||||
- одне невелике завдання збірки, наприклад Lobster Invaders
|
||||
|
||||
## Лінії mock провайдерів
|
||||
## Доріжки mock-провайдерів
|
||||
|
||||
`qa suite` має дві локальні лінії mock провайдерів:
|
||||
`qa suite` має дві локальні доріжки mock-провайдерів:
|
||||
|
||||
- `mock-openai` — це сценарійно-орієнтований mock OpenClaw. Він залишається
|
||||
типовою детермінованою mock-лінією для QA з підтримкою репозиторію та parity gates.
|
||||
- `aimock` запускає сервер провайдера на базі AIMock для експериментального покриття протоколів,
|
||||
fixtures, запису/відтворення та chaos. Він є додатковим і не замінює
|
||||
диспетчер сценаріїв `mock-openai`.
|
||||
- `mock-openai` — це сценарно-орієнтований mock OpenClaw. Він залишається
|
||||
типовою детермінованою mock-доріжкою для QA на основі репозиторію та перевірок паритету.
|
||||
- `aimock` запускає сервер провайдера на базі AIMock для експериментального
|
||||
покриття протоколів, фікстур, record/replay і chaos. Він є додатковим і не
|
||||
замінює dispatcher сценаріїв `mock-openai`.
|
||||
|
||||
Реалізація лінії провайдера розташована в `extensions/qa-lab/src/providers/`.
|
||||
Кожен провайдер володіє своїми значеннями за замовчуванням, запуском локального сервера,
|
||||
конфігурацією моделі Gateway, потребами staging auth-profile та прапорцями можливостей
|
||||
live/mock. Спільний код suite і Gateway має маршрутизуватися через реєстр провайдерів,
|
||||
а не розгалужуватися за назвами провайдерів.
|
||||
Реалізація доріжок провайдерів розміщена в `extensions/qa-lab/src/providers/`.
|
||||
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера,
|
||||
конфігурацією моделі gateway, потребами staging для auth-profile і прапорцями
|
||||
можливостей live/mock. Спільний код suite і gateway має маршрутизуватися через
|
||||
реєстр провайдерів, а не розгалужуватися за назвами провайдерів.
|
||||
|
||||
## Адаптери транспорту
|
||||
|
||||
`qa-lab` володіє загальним seam транспорту для markdown QA-сценаріїв.
|
||||
`qa-channel` — перший адаптер на цьому seam, але цільовий дизайн ширший:
|
||||
майбутні реальні або синтетичні канали мають підключатися до того самого виконавця suite
|
||||
замість додавання специфічного для транспорту виконавця QA.
|
||||
`qa-lab` володіє універсальним seam транспорту для Markdown-сценаріїв QA.
|
||||
`qa-channel` — перший адаптер на цьому seam, але ціль дизайну ширша:
|
||||
майбутні реальні або синтетичні канали мають підключатися до того самого runner-а suite
|
||||
замість додавання спеціального runner-а QA для конкретного транспорту.
|
||||
|
||||
На рівні архітектури поділ такий:
|
||||
|
||||
- `qa-lab` володіє загальним виконанням сценаріїв, concurrency workers, записом artifacts і звітністю.
|
||||
- адаптер транспорту володіє конфігурацією Gateway, готовністю, спостереженням за вхідними й вихідними подіями, транспортними діями та нормалізованим станом транспорту.
|
||||
- markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазову runtime-поверхню, яка їх виконує.
|
||||
- `qa-lab` володіє універсальним виконанням сценаріїв, concurrency worker-ів, записом артефактів і звітністю.
|
||||
- адаптер транспорту володіє конфігурацією gateway, готовністю, спостереженням за вхідним і вихідним трафіком, діями транспорту та нормалізованим станом транспорту.
|
||||
- файли сценаріїв Markdown у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазово використовувану поверхню runtime, що їх виконує.
|
||||
|
||||
Керівництво з упровадження для супровідників нових адаптерів каналів розміщене в
|
||||
[Тестування](/uk/help/testing#adding-a-channel-to-qa).
|
||||
Рекомендації для супроводжувачів щодо впровадження нових адаптерів каналів
|
||||
розміщені в
|
||||
[Testing](/uk/help/testing#adding-a-channel-to-qa).
|
||||
|
||||
## Звітність
|
||||
|
||||
`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини.
|
||||
Звіт має відповідати на такі запитання:
|
||||
`qa-lab` експортує звіт протоколу в Markdown зі спостережуваної часової шкали шини.
|
||||
Звіт має відповідати на такі питання:
|
||||
|
||||
- Що спрацювало
|
||||
- Що не спрацювало
|
||||
- Що залишилося заблокованим
|
||||
- Які подальші сценарії варто додати
|
||||
|
||||
Для перевірок характеру та стилю виконайте той самий сценарій на кількох refs живих моделей
|
||||
і запишіть оцінений Markdown-звіт:
|
||||
Для перевірок характеру та стилю запустіть той самий сценарій на кількох live model
|
||||
refs і запишіть оцінений звіт у Markdown:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa character-eval \
|
||||
@ -282,41 +292,42 @@ pnpm openclaw qa character-eval \
|
||||
--judge-concurrency 16
|
||||
```
|
||||
|
||||
Команда запускає локальні дочірні процеси Gateway QA, а не Docker. Сценарії character eval
|
||||
Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії character eval
|
||||
мають задавати persona через `SOUL.md`, а потім виконувати звичайні ходи користувача,
|
||||
такі як чат, допомога з workspace і невеликі файлові завдання. Кандидатній моделі
|
||||
такі як чат, допомога з робочим простором і невеликі файлові завдання. Моделі-кандидату
|
||||
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
|
||||
транскрипт, записує базову статистику запуску, а потім просить моделі-судді в швидкому режимі з
|
||||
міркуванням `xhigh`, де це підтримується, ранжувати запуски за природністю, вайбом і гумором.
|
||||
Використовуйте `--blind-judge-models` під час порівняння провайдерів: prompt судді все одно отримує
|
||||
кожен транскрипт і статус запуску, але refs кандидатів замінюються нейтральними
|
||||
мітками, такими як `candidate-01`; після парсингу звіт зіставляє ранжування з реальними refs.
|
||||
Використовуйте `--blind-judge-models` під час порівняння провайдерів: промпт судді все одно отримує
|
||||
кожен транскрипт і статус запуску, але посилання на кандидатів замінюються нейтральними
|
||||
мітками, такими як `candidate-01`; звіт зіставляє ранжування з реальними посиланнями після
|
||||
розбору.
|
||||
|
||||
Для запусків кандидатів за замовчуванням використовується thinking `high`, `medium` для GPT-5.5 і `xhigh`
|
||||
для старіших eval refs OpenAI, які це підтримують. Перевизначайте конкретного кандидата безпосередньо через
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше задає
|
||||
глобальне резервне значення, а старіша форма `--model-thinking <provider/model=level>` збережена
|
||||
Для запусків кандидатів за замовчуванням використовується мислення `high`, для GPT-5.5 — `medium`, а `xhigh`
|
||||
— для старіших eval-посилань OpenAI, які це підтримують. Перевизначте конкретного кандидата прямо в рядку через
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше встановлює
|
||||
глобальне резервне значення, а старіша форма `--model-thinking <provider/model=level>` зберігається
|
||||
для сумісності.
|
||||
Refs кандидатів OpenAI за замовчуванням використовують швидкий режим, щоб застосовувалась пріоритетна обробка там,
|
||||
де провайдер це підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` безпосередньо, коли
|
||||
для одного кандидата або судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли
|
||||
хочете примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
|
||||
записується у звіт для аналізу benchmark, але prompts суддів явно вказують
|
||||
Для посилань кандидатів OpenAI за замовчуванням увімкнено швидкий режим, щоб використовувалася
|
||||
пріоритетна обробка там, де це підтримується провайдером. Додайте `,fast`, `,no-fast` або `,fast=false` прямо в рядку, коли
|
||||
окремому кандидату або судді потрібно перевизначення. Передавайте `--fast`, лише якщо хочете
|
||||
примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
|
||||
записується у звіт для аналізу бенчмарків, але в промптах суддів прямо сказано
|
||||
не ранжувати за швидкістю.
|
||||
І запуски моделей-кандидатів, і запуски моделей-суддів за замовчуванням мають concurrency 16. Зменшуйте
|
||||
`--concurrency` або `--judge-concurrency`, коли обмеження провайдера або локальне навантаження на Gateway
|
||||
І для запусків моделей-кандидатів, і для запусків моделей-суддів за замовчуванням використовується concurrency 16. Зменшуйте
|
||||
`--concurrency` або `--judge-concurrency`, коли ліміти провайдера або навантаження на локальний gateway
|
||||
роблять запуск надто шумним.
|
||||
Коли не передано жодного кандидата `--model`, character eval за замовчуванням використовує
|
||||
Якщо не передано жодного `--model` кандидата, для character eval за замовчуванням використовуються
|
||||
`openai/gpt-5.5`, `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`, за замовчуванням використовуються судді
|
||||
Якщо не передано `--judge-model`, за замовчуванням використовуються судді
|
||||
`openai/gpt-5.5,thinking=xhigh,fast` і
|
||||
`anthropic/claude-opus-4-6,thinking=high`.
|
||||
|
||||
## Пов’язана документація
|
||||
## Пов’язані документи
|
||||
|
||||
- [Тестування](/uk/help/testing)
|
||||
- [Testing](/uk/help/testing)
|
||||
- [QA Channel](/uk/channels/qa-channel)
|
||||
- [Панель керування](/uk/web/dashboard)
|
||||
- [Dashboard](/uk/web/dashboard)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user