chore(i18n): refresh uk translations
This commit is contained in:
parent
e4cd4565f1
commit
80432ba439
@ -1,51 +1,51 @@
|
||||
---
|
||||
read_when:
|
||||
- Розширення qa-lab або qa-channel
|
||||
- Додавання QA-сценаріїв із підтримкою репозиторію
|
||||
- Побудова реалістичнішої QA-автоматизації навколо панелі Gateway
|
||||
summary: Форма приватної QA-автоматизації для qa-lab, qa-channel, сценаріїв із початковими даними та звітів про протокол
|
||||
title: QA E2E автоматизація
|
||||
- Додавання QA-сценаріїв на основі репозиторію
|
||||
- Побудова реалістичнішої QA-автоматизації навколо панелі керування Gateway
|
||||
summary: Форма приватної QA-автоматизації для qa-lab, qa-channel, початково заповнених сценаріїв і звітів протоколу
|
||||
title: QA E2E-автоматизація
|
||||
x-i18n:
|
||||
generated_at: "2026-04-09T00:27:53Z"
|
||||
generated_at: "2026-04-09T22:54:33Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: c922607d67e0f3a2489ac82bc9f510f7294ced039c1014c15b676d826441d833
|
||||
source_hash: 357d6698304ff7a8c4aa8a7be97f684d50f72b524740050aa761ac0ee68266de
|
||||
source_path: concepts/qa-e2e-automation.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# QA E2E автоматизація
|
||||
# QA E2E-автоматизація
|
||||
|
||||
Приватний стек QA призначений для перевірки OpenClaw у реалістичніший,
|
||||
орієнтований на канали спосіб, ніж це може зробити один модульний тест.
|
||||
Приватний QA-стек призначений для тестування OpenClaw у реалістичніший,
|
||||
схожий на канал спосіб, ніж це може зробити один модульний тест.
|
||||
|
||||
Поточні складові:
|
||||
|
||||
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями для DM, каналу, гілки,
|
||||
реакцій, редагування та видалення.
|
||||
- `extensions/qa-lab`: UI налагодження та шина QA для спостереження за транскриптом,
|
||||
інʼєкції вхідних повідомлень і експорту звіту в Markdown.
|
||||
- `qa/`: ресурси початкових даних із підтримкою репозиторію для стартового завдання та базових QA
|
||||
- `extensions/qa-lab`: UI налагодження та QA-шина для спостереження за транскриптом,
|
||||
інʼєкції вхідних повідомлень і експорту Markdown-звіту.
|
||||
- `qa/`: ресурси початкового заповнення на основі репозиторію для стартового завдання та базових QA-
|
||||
сценаріїв.
|
||||
|
||||
Поточний робочий процес оператора QA — це двопанельний сайт QA:
|
||||
Поточний робочий процес QA-оператора — це двопанельний QA-сайт:
|
||||
|
||||
- Ліворуч: панель Gateway (Control UI) з агентом.
|
||||
- Ліворуч: панель керування Gateway (Control UI) з агентом.
|
||||
- Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію.
|
||||
|
||||
Запустіть це командою:
|
||||
Запустіть його командою:
|
||||
|
||||
```bash
|
||||
pnpm qa:lab:up
|
||||
```
|
||||
|
||||
Це збирає сайт QA, запускає лінію Gateway на основі Docker і відкриває
|
||||
Це збирає QA-сайт, запускає lane Gateway на основі Docker і відкриває
|
||||
сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-
|
||||
завдання, спостерігати реальну поведінку каналу та записувати, що спрацювало,
|
||||
що не спрацювало або що залишилося заблокованим.
|
||||
завдання, спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що
|
||||
не спрацювало або що залишилося заблокованим.
|
||||
|
||||
Для швидшої ітерації UI QA Lab без повторного збирання Docker-образу щоразу
|
||||
запустіть стек із bind-mounted бандлом QA Lab:
|
||||
запустіть стек із bind-mount пакета QA Lab:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa docker-build-image
|
||||
@ -54,14 +54,29 @@ 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:up:fast` залишає сервіси Docker на попередньо зібраному образі та монтує
|
||||
`extensions/qa-lab/web/dist` у контейнер `qa-lab` через bind-mount. `qa:lab:watch`
|
||||
перебудовує цей пакет при змінах, а браузер автоматично перезавантажується, коли
|
||||
змінюється хеш ресурсів QA Lab.
|
||||
|
||||
## Початкові дані з підтримкою репозиторію
|
||||
Для одноразової lane Linux VM без додавання Docker до QA-шляху виконайте:
|
||||
|
||||
Ресурси початкових даних розміщені в `qa/`:
|
||||
```bash
|
||||
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
|
||||
```
|
||||
|
||||
Це завантажує нову гостьову систему Multipass, встановлює залежності, збирає OpenClaw
|
||||
усередині гостьової системи, запускає `qa suite`, а потім копіює звичайний QA-звіт і
|
||||
підсумок назад у `.artifacts/qa-e2e/...` на хості.
|
||||
Використовується така сама поведінка вибору сценаріїв, як і для `qa suite` на хості.
|
||||
Під час live-запусків пересилаються підтримувані вхідні дані автентифікації QA, які є практичними для
|
||||
гостьової системи: ключі провайдера на основі env, шлях до конфігурації QA live provider і
|
||||
`CODEX_HOME`, якщо він присутній. Зберігайте `--output-dir` у межах кореня репозиторію, щоб гостьова система
|
||||
могла записувати назад через змонтований workspace.
|
||||
|
||||
## Початково заповнені ресурси на основі репозиторію
|
||||
|
||||
Ресурси початкового заповнення містяться в `qa/`:
|
||||
|
||||
- `qa/scenarios/index.md`
|
||||
- `qa/scenarios/*.md`
|
||||
@ -69,28 +84,28 @@ pnpm qa:lab:watch
|
||||
Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
|
||||
агенту. Базовий список має залишатися достатньо широким, щоб охоплювати:
|
||||
|
||||
- чати в DM і каналах
|
||||
- поведінку гілок
|
||||
- чат у DM і каналі
|
||||
- поведінку в гілках
|
||||
- життєвий цикл дій із повідомленнями
|
||||
- cron-зворотні виклики
|
||||
- виклик спогадів із памʼяті
|
||||
- згадування памʼяті
|
||||
- перемикання моделей
|
||||
- передавання підзадач субагенту
|
||||
- читання репозиторію та документації
|
||||
- передавання до субагента
|
||||
- читання репозиторію та читання документації
|
||||
- одне невелике завдання зі збирання, наприклад Lobster Invaders
|
||||
|
||||
## Звітування
|
||||
|
||||
`qa-lab` експортує звіт про протокол у Markdown зі спостережуваної часової шкали шини.
|
||||
`qa-lab` експортує Markdown-звіт протоколу на основі спостережуваної часової шкали шини.
|
||||
Звіт має відповідати на такі запитання:
|
||||
|
||||
- Що спрацювало
|
||||
- Що не спрацювало
|
||||
- Що залишилося заблокованим
|
||||
- Які додаткові сценарії варто додати
|
||||
- Які сценарії для подальшої роботи варто додати
|
||||
|
||||
Для перевірок характеру та стилю запускайте той самий сценарій для кількох live model
|
||||
refs і створюйте оцінений звіт у Markdown:
|
||||
Для перевірок характеру та стилю запустіть той самий сценарій для кількох live model
|
||||
ref і запишіть Markdown-звіт з оцінюванням:
|
||||
|
||||
```bash
|
||||
pnpm openclaw qa character-eval \
|
||||
@ -109,40 +124,40 @@ pnpm openclaw qa character-eval \
|
||||
--judge-concurrency 16
|
||||
```
|
||||
|
||||
Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії
|
||||
оцінювання характеру мають задавати персону через `SOUL.md`, а потім виконувати звичайні
|
||||
ходи користувача, такі як чат, допомога з робочим простором і невеликі файлові завдання. Моделі-
|
||||
кандидату не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
|
||||
транскрипт, записує базову статистику запуску, а потім просить моделі-судді в режимі fast з
|
||||
Команда запускає дочірні процеси локального QA gateway, а не Docker. Сценарії character eval
|
||||
мають задавати персонажа через `SOUL.md`, а потім виконувати звичайні користувацькі ходи,
|
||||
такі як чат, допомога з workspace і невеликі файлові завдання. Моделі-кандидату
|
||||
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
|
||||
транскрипт, записує базову статистику запуску, а потім просить моделі-оцінювачі в режимі fast з
|
||||
міркуванням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
|
||||
Використовуйте `--blind-judge-models` під час порівняння провайдерів: запит судді все одно отримує
|
||||
кожен транскрипт і статус запуску, але посилання кандидатів замінюються нейтральними
|
||||
мітками, такими як `candidate-01`; після розбору звіт зіставляє рейтинги з реальними refs.
|
||||
Для запусків кандидатів за замовчуванням використовується рівень thinking `high`, а для моделей OpenAI, що
|
||||
його підтримують, — `xhigh`. Перевизначте конкретного кандидата безпосередньо через
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` і надалі задає
|
||||
глобальний запасний варіант, а старіша форма `--model-thinking <provider/model=level>` зберігається
|
||||
Використовуйте `--blind-judge-models` під час порівняння провайдерів: запит оцінювача все одно отримує
|
||||
кожен транскрипт і статус запуску, але ref кандидатів замінюються нейтральними
|
||||
мітками на кшталт `candidate-01`; після розбору звіт зіставляє ранжування назад із реальними ref.
|
||||
Для запусків кандидатів за замовчуванням використовується рівень thinking `high`, а для моделей OpenAI,
|
||||
які це підтримують, — `xhigh`. Перевизначте конкретного кандидата inline за допомогою
|
||||
`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше задає
|
||||
глобальний резервний варіант, а стара форма `--model-thinking <provider/model=level>` збережена
|
||||
для сумісності.
|
||||
Для кандидатських refs OpenAI за замовчуванням використовується режим fast, щоб задіяти пріоритетну
|
||||
обробку там, де провайдер це підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` безпосередньо, коли
|
||||
потрібно перевизначити це для одного кандидата або судді. Передавайте `--fast` лише тоді, коли хочете
|
||||
примусово ввімкнути режим fast для кожної моделі-кандидата. Тривалість кандидатів і суддів
|
||||
записується у звіт для порівняльного аналізу, але в запитах до суддів прямо зазначено,
|
||||
Для ref кандидатів OpenAI за замовчуванням використовується режим fast, щоб там, де провайдер це підтримує,
|
||||
застосовувалася пріоритетна обробка. Додайте `,fast`, `,no-fast` або `,fast=false` inline, якщо
|
||||
для одного кандидата або оцінювача потрібно перевизначення. Передавайте `--fast` лише тоді, коли хочете
|
||||
примусово ввімкнути режим fast для кожної моделі-кандидата. Тривалість роботи кандидатів і оцінювачів
|
||||
записується у звіт для аналізу бенчмарків, але в запитах до оцінювачів прямо зазначено,
|
||||
що не слід ранжувати за швидкістю.
|
||||
Для запусків моделей-кандидатів і моделей-суддів за замовчуванням встановлено concurrency 16. Зменшуйте
|
||||
`--concurrency` або `--judge-concurrency`, коли обмеження провайдера або навантаження на локальний gateway
|
||||
І для запусків моделей-кандидатів, і для запусків моделей-оцінювачів за замовчуванням використовується паралелізм 16. Зменште
|
||||
`--concurrency` або `--judge-concurrency`, якщо обмеження провайдера чи навантаження на локальний gateway
|
||||
роблять запуск надто шумним.
|
||||
Якщо не передано жодного кандидатського `--model`, для оцінювання характеру за замовчуванням використовуються
|
||||
Якщо не передано жодного кандидата `--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)
|
||||
- [QA Channel](/uk/channels/qa-channel)
|
||||
- [Панель](/web/dashboard)
|
||||
- [Панель керування](/web/dashboard)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user