chore(i18n): refresh uk translations

This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-10 23:39:42 +00:00
parent 11a7a09498
commit 19b599bba8
2 changed files with 482 additions and 425 deletions

View File

@ -1,36 +1,37 @@
---
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-10T12:52:46Z"
generated_at: "2026-04-10T23:36:40Z"
model: gpt-5.4
provider: openai
source_hash: e416ffd285a05339a88eb749e37c4ed9448f232ca67dc0c85eba772029b5b306
source_hash: 5427b505e26bfd542e984e3920c3f7cb825473959195ba9737eff5da944c60d0
source_path: concepts/qa-e2e-automation.md
workflow: 15
---
# Автоматизація QA E2E
Приватний стек QA призначений для перевірки OpenClaw у більш реалістичний,
Приватний стек QA призначений для того, щоб перевіряти OpenClaw у більш реалістичний,
орієнтований на канали спосіб, ніж це може зробити один модульний тест.
Поточні складові:
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, треду,
реакцій, редагування та видалення.
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, гілки,
реакції, редагування та видалення.
- `extensions/qa-lab`: UI налагодження та шина QA для спостереження за транскриптом,
інʼєкції вхідних повідомлень і експорту звіту у форматі Markdown.
- `qa/`: ресурси початкових даних, що підтримуються репозиторієм, для стартового завдання та базових сценаріїв QA.
інʼєкції вхідних повідомлень і експорту Markdown-звіту.
- `qa/`: ресурси початкового заповнення з підтримкою репозиторію для стартового завдання та базових QA
сценаріїв.
Поточний потік роботи оператора QA — це сайт QA із двома панелями:
Поточний робочий процес оператора QA — це сайт QA з двома панелями:
- Ліворуч: панель керування Gateway (Control UI) з агентом.
- Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію.
- Праворуч: QA Lab, де показано транскрипт у стилі Slack і план сценарію.
Запустіть його так:
@ -38,12 +39,11 @@ x-i18n:
pnpm qa:lab:up
```
Це збирає сайт QA, запускає lane Gateway на основі Docker і відкриває
сторінку QA Lab, де оператор або цикл автоматизації може дати агенту
QA-місію, спостерігати реальну поведінку каналу й записувати, що спрацювало,
що не спрацювало або що залишилося заблокованим.
Це збирає сайт QA, запускає лінію gateway на базі Docker і відкриває
сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA
місію, спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що не спрацювало або що залишилося заблокованим.
Для швидшої ітерації UI QA Lab без повторного збирання образу Docker щоразу,
Щоб швидше ітерувати UI QA Lab без повторного збирання Docker-образу щоразу,
запустіть стек із bind-mounted збіркою QA Lab:
```bash
@ -53,60 +53,100 @@ pnpm qa:lab:up:fast
pnpm qa:lab:watch
```
`qa:lab:up:fast` утримує сервіси Docker на попередньо зібраному образі та bind-mount
`qa:lab:up:fast` зберігає сервіси Docker на попередньо зібраному образі та bind-mount-ить
`extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
перезбирає цей пакет при змінах, а браузер автоматично перезавантажується, коли змінюється хеш ресурсів QA Lab.
перезбирає цей bundle під час змін, а браузер автоматично перезавантажується, коли змінюється хеш ресурсів QA Lab.
Для тимчасового lane на Linux VM без залучення Docker до шляху QA виконайте:
Для лінії smoke-тестування Matrix із реальним транспортом запустіть:
```bash
pnpm openclaw qa matrix
```
Ця лінія розгортає одноразовий homeserver Tuwunel у Docker, реєструє
тимчасових користувачів driver, SUT і observer, створює одну приватну кімнату, а потім запускає
реальний плагін Matrix усередині дочірнього процесу QA gateway. Лінія з живим транспортом зберігає конфігурацію дочірнього процесу в межах транспорту, що тестується, тому Matrix працює без
`qa-channel` у конфігурації дочірнього процесу.
Для лінії 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`.
Лінії з живим транспортом тепер використовують один менший спільний контракт замість того, щоб кожна вигадувала
власну форму списку сценаріїв:
`qa-channel` залишається широким набором синтетичних тестів поведінки продукту і не входить
до матриці покриття живого транспорту.
| Лінія | Канарка | Гейтінг згадок | Блокування 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 і
Це завантажує свіжу гостьову машину Multipass, встановлює залежності, збирає OpenClaw
усередині гостьової машини, запускає `qa suite`, а потім копіює звичайний звіт QA та
підсумок назад у `.artifacts/qa-e2e/...` на хості.
Використовується та сама поведінка вибору сценаріїв, що й у `qa suite` на хості.
Воно повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
Запуски suite на хості та в Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно
з ізольованими працівниками gateway, до 64 працівників або до кількості вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати кількість працівників, або
з ізольованими воркерами gateway, до 64 воркерів або до кількості вибраних
сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати кількість воркерів, або
`--concurrency 1` для послідовного виконання.
Live-запуски пересилають підтримувані вхідні дані автентифікації QA, які практичні для
гостя: ключі провайдера на основі env, шлях до конфігурації live-провайдера QA і
`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гість
міг записувати результати назад через змонтований робочий простір.
Живі запуски передають підтримувані вхідні дані автентифікації QA, які практично використовувати для
гостьової машини: ключі провайдера на основі env, шлях до конфігурації live-провайдера QA та
`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гостьова машина
могла записувати назад через змонтований workspace.
## Початкові дані, що підтримуються репозиторієм
## Початкові дані з підтримкою репозиторію
Ресурси початкових даних розташовані в `qa/`:
Ресурси початкового заповнення знаходяться в `qa/`:
- `qa/scenarios/index.md`
- `qa/scenarios/*.md`
Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
агенту. Базовий список має залишатися достатньо широким, щоб охоплювати:
Вони навмисно зберігаються в git, щоб план QA був видимим як для людей, так і для
агента. Базовий список має залишатися достатньо широким, щоб охоплювати:
- DM і чат у каналі
- поведінку тредів
- чат у DM і каналі
- поведінку гілок
- життєвий цикл дій із повідомленнями
- cron-зворотні виклики
- відтворення памʼяті
- cron callbacks
- відновлення памʼяті
- перемикання моделей
- передачу субагенту
- передачу підагенту
- читання репозиторію та документації
- одне невелике завдання зі збирання, наприклад Lobster Invaders
## Звітність
`qa-lab` експортує звіт протоколу у форматі Markdown зі спостережуваної часової шкали шини.
Звіт має відповідати на запитання:
`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини.
Звіт має відповідати на такі питання:
- Що спрацювало
- Що не спрацювало
- Що залишилося заблокованим
- Які сценарії продовження варто додати
- Які подальші сценарії варто додати
Для перевірок характеру та стилю запустіть той самий сценарій для кількох live-моделей
і запишіть оцінений звіт у форматі Markdown:
Для перевірки характеру та стилю запустіть той самий сценарій для кількох live-моделей
і створіть оцінений Markdown-звіт:
```bash
pnpm openclaw qa character-eval \
@ -125,39 +165,38 @@ pnpm openclaw qa character-eval \
--judge-concurrency 16
```
Ця команда запускає локальні дочірні процеси gateway QA, а не Docker. Сценарії оцінювання характеру
мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи користувача,
такі як чат, допомога з робочим простором і невеликі файлові завдання. Моделі-кандидату
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний транскрипт,
записує базову статистику запуску, а потім просить моделі-судді у fast mode з
міркуванням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
Використовуйте `--blind-judge-models` при порівнянні провайдерів: підказка для судді все одно отримує
кожен транскрипт і статус запуску, але посилання кандидатів замінюються на нейтральні
мітки, такі як `candidate-01`; після розбору звіт зіставляє ранжування з реальними посиланнями.
Запуски кандидатів за замовчуванням використовують `high` thinking, а для моделей OpenAI — `xhigh`,
якщо вони це підтримують. Перевизначте конкретного кандидата inline через
`--model provider/model,thinking=<level>`. `--thinking <level>` усе ще задає
Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії оцінювання характеру
мають задавати persona через `SOUL.md`, а потім запускати звичайні користувацькі ходи,
такі як чат, допомога з workspace і невеликі файлові завдання. Моделі-кандидату
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
транскрипт, записує базову статистику запуску, а потім просить моделі-судді в режимі fast з
міркуванням `xhigh` ранжувати запуски за природністю, атмосферою та гумором.
Використовуйте `--blind-judge-models` під час порівняння провайдерів: підказка для судді все одно отримує
кожен транскрипт і статус запуску, але посилання кандидатів замінюються нейтральними
мітками, такими як `candidate-01`; після розбору звіту ранжування зіставляється назад із реальними посиланнями.
Для запусків кандидатів за замовчуванням використовується рівень thinking `high`, а для моделей OpenAI, що це підтримують, — `xhigh`. Перевизначте конкретного кандидата вбудовано через
`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше задає
глобальний резервний варіант, а старіша форма `--model-thinking <provider/model=level>` зберігається для сумісності.
Посилання кандидатів OpenAI за замовчуванням використовують fast mode, щоб за можливості провайдера
застосовувалася обробка з пріоритетом. Додайте inline `,fast`, `,no-fast` або `,fast=false`, якщо
окремому кандидату чи судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
записується у звіті для аналізу бенчмарків, але підказки для суддів явно вказують
Посилання кандидатів OpenAI за замовчуванням використовують режим fast, щоб застосовувалася пріоритетна обробка там,
де провайдер це підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` вбудовано, коли для
окремого кандидата чи судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
примусово ввімкнути режим fast для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
записується у звіт для аналізу бенчмарків, але в підказках для суддів явно сказано
не ранжувати за швидкістю.
І запуски моделей-кандидатів, і запуски моделей-суддів за замовчуванням мають concurrency 16. Зменшуйте
`--concurrency` або `--judge-concurrency`, якщо обмеження провайдера або навантаження на локальний gateway
І для запусків моделей-кандидатів, і для моделей-суддів за замовчуванням використовується concurrency 16. Зменшіть
`--concurrency` або `--judge-concurrency`, коли обмеження провайдера або навантаження на локальний gateway
роблять запуск надто шумним.
Якщо не передано жодного кандидатського `--model`, оцінювання характеру за замовчуванням використовує
Якщо не передано жодного candidate `--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`, суддями за замовчуванням є
Якщо не передано `--judge-model`, за замовчуванням як судді використовуються
`openai/gpt-5.4,thinking=xhigh,fast` і
`anthropic/claude-opus-4-6,thinking=high`.
## Повʼязана документація
- [Тестування](/uk/help/testing)
- [Testing](/uk/help/testing)
- [QA Channel](/uk/channels/qa-channel)
- [Панель керування](/web/dashboard)
- [Dashboard](/web/dashboard)

File diff suppressed because it is too large Load Diff