chore(i18n): refresh uk translations
This commit is contained in:
parent
11a7a09498
commit
19b599bba8
@ -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
Loading…
Reference in New Issue
Block a user