AI-застосунки
Тестування AI-застосунків: що ламається і як це тестувати.
LLM-застосунок ламається так, як звичайний вебзастосунок не ламається. Модель щоразу повертає різне, тож відповідь перевіряти не можна — ви перевіряєте усе навколо неї: що відповідь приходить, стрімиться, обривається, помітно падає, дотримується ліміту й ніколи не повертає дані, які людині не можна бачити.
Востаннє оновлено 24 серпня 2026
Чим тестування AI-застосунку відрізняється?
Інтерфейс той самий. Контракт — ні. Традиційна автоматизація тестів тримається на перевірці, що виконується двічі: натисни це, побач те. Модель ламає це припущення з першого запуску, тому команди часто доходять висновку, що їхні AI-функції взагалі не можна тестувати на регресію, і випускають їх нетестованими.
Можна. Хитрість у тому, щоб перенести перевірку з тексту на детерміновані частини: відповідь прийшла в межах бюджету, вона розпарсилась у запитану схему, вона посилається на документ, який цьому користувачу дозволено читати, відмова відобразилась як відмова, повтор не списав гроші двічі. Усе це — звичайна автоматизація. Оцінювання того, чи відповідь хороша, — це задача evaluation, вона потребує вашої власної еталонної правди й належить до набору поруч із вашими промптами, а не до регресійного набору.
Що справді ламається в LLM-застосунку
Це поведінки, а не думки про якість виводу, і саме тому їх можна тестувати. Кожна з них доходить до користувачів як баг продукту, а не як погана відповідь.
| Збій | Як він доходить до користувача | Тест |
|---|---|---|
| Відповідь стрімиться, а потім обривається на півслові | Обрив з’єднання посеред стріму лишає на екрані недописану відповідь без помилки й повтору. Користувачі сприймають її як готову відповідь. | Обірвіть відповідь посеред стріму й перевірте, що UI показує стан помилки, а не обрізану відповідь. |
| Модель повільна, а в UI немає що на це відповісти | p95 тримається на сорока секундах, а інтерфейс не показує ні прогресу, ні скасування, ні тайм-ауту. Люди тиснуть знову, і тепер тарифікуються два запити. | Утримуйте відповідь довше за тайм-аут і перевірте, що є помітний стан, можливість скасувати і що повторне натискання не дублює запит. |
| Провайдер повертає 429 або 503 | Ліміти запитів і збої провайдера — звична річ, а не виняток. Застосунки, які вважають їх неможливими, показують сиру помилку або нескінченний спінер. | Повертайте від провайдера 429 і 503 та перевірте, що застосунок деградує до повідомлення, з яким користувач може щось зробити. |
| Порожні, відхилені й відфільтровані відповіді | Модель відмовляється або спрацьовує фільтр безпеки, а інтерфейс малює порожню бульбашку, бо обробляє лише щасливий сценарій. | Спровокуйте відмову та порожнє завершення; перевірте, що жодне не дає порожнього повідомлення чи зламаної верстки. |
| Розмова втрачає контекст | Історію обрізають, щоб вона влізла у вікно, і асистент мовчки забуває, що йому казали три повідомлення тому. Для користувача це виглядає як дурний продукт. | Доведіть розмову за межу контексту й перевірте, що застосунок каже, що відкинув, а не відкидає мовчки. |
| Виклики інструментів спрацьовують більше одного разу | Агент повторює крок, інструмент якого вже виконався. Що б він не робив — лист, списання, запис — це стається двічі. | Зробіть так, щоб виклик інструмента завершився тайм-аутом після успіху, і перевірте, що повтор не дублює побічний ефект. |
| Пошук повертає документ іншого клієнта | Векторне сховище фільтрується в промпті, а не в запиті, тож пошук, що проігнорував інструкцію, повертає дані, які користувачу не можна читати. | Запитайте від імені одного клієнта документ іншого й перевірте, що його немає серед знайденого, а не просто не згадано у відповіді. |
| Витрати зростають без стелі | Немає ліміту на користувача, тож один цикл або один скриптований акаунт перетворюється на рахунок, який ніхто не помічає до інвойсу. | Багаторазово викличте один і той самий ендпоінт і перевірте, що ліміт існує — на користувача, на ключ, на хвилину. |
Безпека
Тестування безпеки LLM: поверхня, яку варто перевіряти
AI-функція зазвичай приходить підключеною до двох речей, до яких звичайна функція не підключена: платного ендпоінта і компонента, що виконує інструкції, знайдені в усьому, що він читає. Обидва розширюють поверхню атаки так, як не розраховувався стандартний огляд безпеки застосунків.
Нижче впорядковано за тим, як часто це справді трапляється, — а це не той порядок, у якому про це пишуть.
- 01
Ключі провайдера в клієнтському бандлі
Ключ провайдера моделі в front-end JavaScript або доступний через проксі-маршрут без авторизації.
Будь-хто з інструментами розробника може витратити вашу квоту. Це найдешевша перевірка в списку і найдорожча, якщо її пропустити.
- 02
Ін’єкція промпта через вміст
Інструкції, сховані в тому, що читає модель — завантажений документ, зібрана сторінка, тікет підтримки, текст листа, — які модель потім виконує.
Зловмисник ніколи не торкається вашого поля вводу. Усе, що ваша система споживає, — це вхід, чи планували ви його як вхід, чи ні.
- 03
Ін’єкція, що дістається інструмента
Підкинуті інструкції, через які агент викликає інструмент: надсилає повідомлення, пише запис, робить запит на внутрішню адресу.
Тут ін’єкція перестає бути прикрістю і стає інцидентом. Радіус ураження — усе, що агенту дозволено робити.
- 04
Розкриття системного промпта й секретів
Змусити модель повторити власні інструкції, визначення інструментів або фрагменти конфігурації, які їй дали.
Системний промпт часто містить бізнес-правила, внутрішні ендпоінти, а інколи й облікові дані, яких там ніхто не планував залишати.
- 05
Пошук між клієнтами
Пошук, обмежений проханням до моделі, а не фільтром у запиті.
Промпт — не контроль доступу. Якщо фільтр живе в інструкціях, одна проігнорована інструкція — це витік даних.
- 06
Вивід, відрендерений як розмітка чи код
Вивід моделі, підставлений на сторінку як HTML або в оболонку, запит чи eval.
Класична ін’єкція з новим джерелом. Модель тепер недовірений вхід, і на нього може впливати зловмисник.
- 07
Необмежені витрати як відмова в обслуговуванні
Ендпоінт, що викликає платну модель без ліміту запитів, без ліміту на акаунт і без обмеження розміру вхідних даних.
Мета атаки — не покласти вас, а накрутити рахунок, поки ви не покладете себе самі.
- 08
Що зберігають логи
Промпти й відповіді, записані в логи та аналітику, включно з усім, що користувач у них вставив.
Люди вставляють у чат production-облікові дані й записи клієнтів. Ваше зберігання логів тепер — питання захисту даних.
Що QA Spider автоматизує, а що ні
Сказано достатньо вузько, щоб ви могли з нас спитати.
Ми автоматизуємо це
- Керує вашим продуктом у справжньому браузері, тож випадки зі стрімінгом, тайм-аутом, повтором, порожнім станом і станом помилки, наведені вище, — звичайні UI-тести: вони запускаються за розкладом і після кожного деплою.
- Перевіряє API під інтерфейсом, зокрема маршрути, до яких ваш фронтенд звертається, щоб дістатися моделі.
- Заводить те, що падає, як тікет у Jira, Azure DevOps, ClickUp, GitHub або Linear, з кроками відтворення і скриншотом.
- Виконує поверхневий огляд безпеки публічного сайту: транспорт і заголовки безпеки, прапорці cookie, змішаний вміст, відкритість форм, DNS і захист від підробки пошти.
Ми не робимо цього
- Зараз ми не постачаємо автоматичний набір для prompt-injection чи jailbreak. Якщо вам кажуть, що їхній краулер робить це з коробки, попросіть показати перевірки.
- Ми не оцінюємо, чи правильна відповідь. Це завдання для eval, воно потребує вашої еталонної правди й відрізняється від регресійного тестування.
Питання, які ставлять про тестування AI-застосунків
- Чим тестування AI-застосунку відрізняється від тестування звичайного вебзастосунку?
- Інтерфейс той самий, вивід — ні. Звичайний застосунок двічі повертає ту саму відповідь, тож її можна перевіряти. Модель щоразу повертає різне, тому перевірки переходять на форму й поведінку навколо відповіді: чи вона приходить, стрімиться, обривається, помітно падає і коштує стільки, скільки має.
- Як писати перевірку, якщо вивід щоразу змінюється?
- Перевіряйте контракт, а не текст. Що відповідь прийшла в межах бюджету, що вона розпарсилась у запитану схему, що вона посилається на документ, який користувачу дозволено бачити, що відмова відображається як відмова. Оцінювання формулювань — це eval, який запускається окремо від регресійного набору.
- Що таке prompt injection і як його тестувати?
- Інструкції, сховані у вмісті, який читає ваша система — документі, вебсторінці, тікеті, — і яким модель потім підкоряється. Тестують, підкладаючи інструкції в кожен канал, що веде до моделі, і перевіряючи, що наслідків немає: жоден інструмент не викликано, дані не повернуто, системний промпт не повторено.
- Яка найпоширеніша проблема безпеки в AI-продуктах?
- Непримітні. Ключ провайдера, доступний з браузера, ендпоінт моделі без ліміту запитів і пошук, обмежений інструкцією в промпті, а не фільтром у запиті. Усі три знайти дешевше, ніж хитрий jailbreak, і вони трапляються частіше.
- Чи може QA Spider протестувати мій AI-продукт?
- Поведінку навколо моделі — так: стрімінг, тайм-аути, повтори, відмови, стани помилок, ліміти запитів і API під інтерфейсом, у справжньому браузері після кожного деплою. Автоматичних наборів для prompt-injection ми сьогодні не постачаємо, і краще скажемо про це, ніж дамо вам дізнатися пізніше.
- Ви перевіряєте, чи дає модель правильні відповіді?
- Ні. Правильність потребує вашої еталонної правди й належить до evaluation-набору, яким ви володієте і який версіонуєте разом із промптами. Регресійне тестування відповідає на інше питання: чи те, що працювало вчора, працює після сьогоднішнього деплою.
Наведіть його на свій AI-продукт.
Поведінка навколо моделі — стрімінг, тайм-аути, повтори, відмови, ліміти запитів і API під інтерфейсом — тестується в справжньому браузері після кожного деплою.