Надаєте перевагу дашборду? Та сама можливість доступна в Simulations
(
/dashboard/simulations), зокрема генерація сценаріїв за допомогою ШІ — дивіться
Симуляція дзвінка. На цій сторінці описано
програмний спосіб.- Smoke-тестів перед розгортанням після кожного редагування промпту
- Регресійних наборів, підключених до CI (підключіть вебхук
test-call.completed→ завершуйте збірку з помилкою, якщо оцінка знизиться) - Стрес-тестування лімітів одночасних викликів
Одноразовий запуск: один прогін
Відповідь містить об’єкт запуску тестового дзвінка
зі
status="queued". Опитуйте статус, доки status не стане completed або
failed; щойно буде задано call_id, завантажте транскрипт через
GET /v1/calls/{call_id}/transcript.
Пакети: паралельні сценарії
Запускайте N сценаріїв одночасно — це корисно для регресійних наборів, які паралельно перевіряють кожен відомий крайній випадок:run_ids з ідентифікаторами дочірніх запусків. Отримайте
статус пакета:
run_count обмежено значенням 20; stagger_seconds розподіляє запуски в часі,
щоб не перевантажувати агента (0–60 с).
Інтегруйте в CI
Створіть набір контрольних перевірок релізу на сторінці Симуляції (/dashboard/simulations) — виберіть агента, додайте сценарії вручну або
натисніть Згенерувати сценарії за допомогою ШІ, щоб створити їхні чернетки на основі
промпту агента (з необов’язковою перевіркою граничних випадків), і згрупуйте їх у набір.
Набір фіксує свої сценарії та агента, а також мінімальний рівень успішності й
необов’язкове правило нульової кількості критичних збоїв. Успішні запуски стають
прийнятою базовою лінією; подальші переходи з успішного результату до невдалого
повертаються як регресії.
Використовуйте API-ключ організації у CI.
Цей скрипт запускає набір, опитує статус, доки не завершаться оцінювання та порівняння,
і завершується з ненульовим кодом, якщо вердикт не pass:
POST /v1/orgs/{org_id}/suites/{suite_id}/run повертає 202 з
ідентифікатором запуску. GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id} повертає
status, verdict, pass_rate, critical_failure_count і список базових
regressions. Обидві кінцеві точки прив’язують організацію в URL
до організації API-ключа.
Шаблони
Корпус регресій для кожного промпту
Ведіть JSON-файл із кортежами{name, scenario_prompt, expected_outcome}.
Після кожної зміни промпту запускайте повний набір як пакет; порівнюйте
транскрипти та оцінки з попереднім запуском.
Smoke-тест для кожного релізу
Один пакет із п’яти сценаріїв щасливого шляху, який ви запускаєте після кожного розгортання. Чутливий до затримки, тому зберігайтеstagger_seconds: 0.
Бенчмаркінг затримки
Запускайте ідентичні сценарії для різних рівнів продукту (spark,
bolt, storm-base). Порівнюйте оцінки call.graded і
duration_seconds з кожного отриманого журналу виклику.
Наступні кроки
Довідник тестових викликів
Усі параметри запитів, коди стану та структури пакетів.
Оцінювання ШІ
Автоматично оцінюйте кожен тестовий запуск, щоб відстежувати якість із часом.
Звіти про проблеми
Позначайте конкретні тести для перевірки людиною.
Вебхук test-call.completed
Передавайте результати у ваші CI / Slack / PagerDuty.