Skip to main content
Надаєте перевагу дашборду? Та сама можливість доступна в Simulations (/dashboard/simulations), зокрема генерація сценаріїв за допомогою ШІ — дивіться Симуляція дзвінка. На цій сторінці описано програмний спосіб.
Ітерації над ШІ-агентом означають ітерації над його промптом, інструментами та способом обробки крайніх випадків. API test-calls виконує реальні дзвінки (бот-до-бота або SIP loopback) до агента за наданим вами промптом сценарію — кожен запуск створює реальний журнал дзвінка з транскриптом, оцінюванням і тарифікацією, тож ви точно бачите, як поводиться агент і скільки це коштує. Використовуйте його для:
  • 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.