Тестування API у 2026 році: що перевіряти, як почати й які інструменти обрати

Більшість сучасних застосунків — це інтерфейс поверх API. Кнопка «Оплатити» в мобільному застосунку, фільтр в інтернет-магазині, вхід через Google — за кожною дією стоїть запит до сервера. Тому тестування API давно перестало бути задачею лише для автоматизаторів: мануальні тестувальники перевіряють запити в Postman, дивляться мережу в DevTools і знаходять баги ще до того, як готовий інтерфейс.

У статті розповідаємо, що саме перевіряти в API, як побудувати чек-лист, з яких інструментів почати і як перейти від ручних запитів до автотестів, контрактних тестів, моків і перевірки навантаження.

Короткий вибір

Що таке API і які вони бувають

API (Application Programming Interface) — це «домовленість», як одна програма звертається до іншої: яку адресу викликати, що передати й що отримати у відповідь. Тестувальнику найчастіше трапляються:

• REST — найпоширеніший стиль: ресурси мають адреси (/users/42), дії задаються HTTP-методами (GET, POST, PUT, PATCH, DELETE), дані передаються в JSON. Опис такого API зазвичай зберігають у специфікації OpenAPI, яку показує Swagger UI.
• GraphQL — одна адреса, а клієнт сам описує в запиті, які поля йому потрібні. Тут важливо перевіряти не лише дані, а й помилки в полі errors: сервер часто повертає код 200 навіть тоді, коли запит не вдався.
• gRPC — швидкий двійковий протокол для зв’язку мікросервісів, контракт описується в .proto-файлах.
• SOAP — старіший формат на XML, досі живе в банках, страхуванні й держсистемах. Для нього є класичний SoapUI.
• Вебхуки — коли сервер сам надсилає запит на вашу адресу (наприклад, про успішну оплату). Перехопити й подивитися такий запит допоможе Webhook.site.

Що перевіряти в API

Кожен запит складається з методу, адреси, заголовків, параметрів і тіла, а відповідь — з коду статусу, заголовків і тіла. Перевіряйте всі частини:

1. Код статусу. 200/201 для успіху, 400 для некоректних даних, 401 без авторизації, 403 без прав, 404 для неіснуючого ресурсу, 409 для конфлікту, 422 для помилок валідації. Код 500 — це майже завжди баг: сервер не обробив ситуацію.

2. Тіло відповіді. Чи є всі поля, чи правильні типи (число, а не рядок "42"), формат дат, порожні масиви замість null, відповідність схемі.

3. Бізнес-логіку. Після POST ресурс справді створився, після DELETE — зник, сума замовлення порахована правильно, зміни видно в інтерфейсі й базі.

4. Валідацію вхідних даних. Порожні й надто довгі значення, від’ємні числа, спецсимволи, емодзі, зайві й відсутні поля, неправильний тип даних.

5. Авторизацію й права. Запит без токена, з простроченим чи чужим токеном; чи можна, змінивши id в адресі, отримати чужі дані.

6. Заголовки. Content-Type, кешування, CORS, відсутність службової інформації (версії сервера) у відповідях.

7. Пагінацію, сортування й фільтри. Перша й остання сторінка, сторінка за межами, великий limit, комбінації фільтрів.

8. Ідемпотентність і повтори. Що буде, якщо двічі надіслати той самий запит на оплату чи створення замовлення.

9. Повідомлення про помилки. Зрозумілі для клієнта, однакові за форматом і без стектрейсів.

10. Швидкість. Час відповіді для основних запитів і поведінку під навантаженням.

Для граничних значень і незвичних символів зручно мати під рукою генератори даних: Mockaroo створить набір реалістичних тестових записів, а Faker.js — дані прямо в коді тестів.

Мануальне тестування API: з чого почати

Почніть з двох речей: вкладки Network у DevTools браузера та API-клієнта.

DevTools показує, які запити надсилає вебінтерфейс: відкрийте вкладку Network, виконайте дію на сайті й подивіться запит і відповідь. Будь-який запит можна скопіювати «як cURL» і вставити в API-клієнт або в баг-репорт: так розробник відтворить проблему однією командою.

API-клієнти:

• Postman — найпопулярніший: колекції, змінні середовища, скрипти перед запитом і тести після нього, документація й моки. Більшість курсів і вакансій орієнтуються саме на нього.
• Bruno зберігає колекції у файлах поруч із кодом і працює офлайн — зручно, коли команда хоче тримати тести в Git.
• Insomnia і Hoppscotch (працює просто в браузері) — легші альтернативи з підтримкою REST, GraphQL і WebSocket.
• Apidog поєднує проєктування API, запити, моки, тестові сценарії й документацію в одному застосунку.
• Thunder Client — клієнт прямо у VS Code, якщо ви вже працюєте в редакторі.

Термінал теж знадобиться: curl є майже на кожному комп’ютері й сервері, HTTPie має простіший синтаксис і гарно форматує JSON.

Відповідь API легко перевірити на синтаксис у JSONLint, а httpbin покаже, що саме ваш клієнт надіслав на сервер.

Перехоплення трафіку: API мобільних застосунків і десктопу

Мобільний застосунок не має DevTools, тому трафік перехоплюють через проксі: телефон надсилає запити через комп’ютер, а ви бачите кожен запит і відповідь.

• Charles Proxy і Fiddler — класика для вебу й мобільних, з підміною відповідей і імітацією повільної мережі.
• Proxyman — сучасний проксі з зручним налаштуванням для iOS і Android.
• HTTP Toolkit підключається до браузера чи Android в один клік, а mitmproxy — відкритий консольний проксі зі скриптами на Python.
• Requestly у браузері підмінює відповіді й заголовки, щоб перевірити, як інтерфейс поводиться при помилці 500 чи порожньому списку.

Чек-лист для одного ендпоінта

Візьмемо POST /api/orders — створення замовлення:

• коректне замовлення → 201, у відповіді id та всі поля, замовлення видно в GET /api/orders/{id};
• без токена → 401, з токеном іншого користувача на чуже замовлення → 403 або 404;
• без обов’язкового поля, з порожнім рядком, з від’ємною кількістю, з неіснуючим товаром → 400/422 зі зрозумілим повідомленням;
• рядок замість числа, дуже довгий коментар, спецсимволи й емодзі → коректна валідація без 500;
• той самий запит двічі поспіль → не створено два замовлення (якщо так задумано);
• заголовок Content-Type: text/plain замість JSON → 415 або 400;
• час відповіді в межах вимог.

Такий чек-лист зручно вести в системі тест-менеджменту, наприклад, у Qase чи TestRail, а знайдені баги — оформлювати в Jira з командою curl і відповіддю сервера.

Автоматизація API-тестів

API-тести — найвигідніша автоматизація: вони швидкі, стабільні й не ламаються від змін верстки. Варіанти залежать від мови команди:

• Колекції Postman у CI: Newman запускає колекцію з командного рядка й формує звіт — найпростіший перехід від ручних перевірок до автотестів.
• Java: REST Assured у стилі given/when/then разом із JUnit або TestNG.
• Python: pytest з бібліотекою requests або httpx.
• JavaScript/TypeScript: Supertest з Jest чи Vitest, або API-тести в Playwright, якщо UI-тести вже написані на ньому.
• Без програмування: Karate описує запити й перевірки в синтаксисі, схожому на Gherkin, а Hurl — у простих текстових файлах.
• Low-code платформи: Katalon і SoapUI мають графічний інтерфейс для API-тестів.

Щоб тести запускалися на кожну зміну коду, підключіть їх до GitHub Actions чи Jenkins, а результати збирайте в Allure Report.

Тести, які пише специфікація

Якщо в API є опис OpenAPI, частину роботи можна віддати інструментам:

• Schemathesis сам генерує тисячі запитів зі специфікації, шукає 500-ті помилки й невідповідності схемі та дає команду curl для відтворення кожної знахідки;
• Spectral перевіряє саму специфікацію: помилки, найменування полів, наявність описів і прикладів — ще до того, як написано код.

Моки, заглушки й тестові середовища

Часто потрібний сервіс ще не готовий, платний або нестабільний (платіжна система, служба доставки). Тоді його замінюють заглушкою:

• WireMock — стандарт для моків у автотестах: задані відповіді, затримки, помилки, запис реального трафіку.
• Mockoon — настільний застосунок, де мок-API створюється за хвилини без коду.
• Prism за файлом OpenAPI одразу піднімає мок-сервер, а в режимі проксі перевіряє реальний API на відповідність специфікації.
• Beeceptor — моки в браузері, зокрема для REST, SOAP і GraphQL.
• Testcontainers піднімає на час тесту справжню базу даних чи брокер повідомлень у Docker.
• Листи й SMS, які надсилає API (підтвердження реєстрації, скидання пароля), перевіряють через Mailpit, Mailtrap або Mailosaur.

Контрактне тестування

У системі з десятками мікросервісів наскрізні тести стають повільними й крихкими. Контрактні тести перевіряють інше: що клієнт і сервіс однаково розуміють API. Pact записує очікування клієнта (які запити він надсилає й які відповіді чекає) і перевіряє, що сервіс їм відповідає, — без розгортання всієї системи. Так зміна в одному сервісі не зламає непомітно інший.

GraphQL і gRPC

• GraphQL: Altair GraphQL Client показує документацію схеми й дозволяє додавати поля в запит прямо з неї; запити GraphQL також уміють Postman, Insomnia і Hoppscotch. Перевіряйте глибоко вкладені запити, права доступу на рівні окремих полів і поле errors у відповідях.
• gRPC: Kreya імпортує protobuf-файли чи server reflection і працює зі стримінгом, а grpcurl викликає методи прямо з терміналу.

Навантаження й продуктивність

API, що швидко відповідає одному тестувальнику, може «лягти» під тисячею користувачів. Для перевірки:

• Grafana k6 — сценарії на JavaScript і пороги, які зручно перевіряти в CI;
• Apache JMeter — графічний редактор і найширша підтримка протоколів;
• Gatling, Locust (Python) і Artillery (YAML) — сценарії як код.

Почніть із простого: як змінюється час відповіді й частка помилок, коли кількість одночасних користувачів зростає з 10 до 100. Докладніше — у статті «Навантажувальне тестування».

Безпека API

Типові вразливості API зібрані в списку OWASP API Security Top 10: доступ до чужих об’єктів через зміну id, слабка автентифікація, надто «балакучі» відповіді, відсутність обмеження частоти запитів. Мануальний тестувальник може перевірити базові речі сам: запити без токена, з чужим токеном, із зайвими полями (наприклад, "role": "admin" у запиті на зміну профілю).

Для глибших перевірок є ZAP (безкоштовний сканер із відкритим кодом) і Burp Suite. Перевіряйте безпеку лише тих систем, на тестування яких у вас є дозвіл. Докладніше — у статті «Тестування безпеки».

Де потренуватися

Безкоштовні тестові API, на які можна спокійно надсилати запити:

• ReqRes і JSONPlaceholder — найпростіший старт без реєстрації;
• Restful-Booker — API бронювань з авторизацією й навмисними багами;
• Swagger Petstore — класичне демо OpenAPI з документацією;
• GoRest — токени, пагінація й специфікація OpenAPI;
• DummyJSON і Fake Store API — дані інтернет-магазину, пошук, авторизація;
• Practice Software Testing, QA Practice (зокрема GraphQL), Contact List App і Expand Testing Practice — застосунки, де можна порівняти поведінку інтерфейсу й API.

Більше тренажерів — у статті «Тренажери для тестувальників» і підкатегорії Тренажери для тестувальників.

План на два тижні

Результат — колекція Postman і репозиторій з автотестами, які можна показати в портфоліо.

АІ в тестуванні API

АІ-асистенти добре справляються з рутиною: за специфікацією OpenAPI пропонують перелік перевірок і негативних сценаріїв, генерують тестові дані й каркас автотестів. У Postman є вбудовані АІ-функції, а GitHub Copilot, Cursor чи Claude Code напишуть тести на REST Assured чи pytest за описом. Але кожен згенерований тест варто перечитати: АІ легко пише перевірку, яка проходить завжди, навіть коли API зламаний.

Про інструменти для інших видів тестування читайте в статтях «Інструменти для мануального тестування» та «Інструменти для автоматизації тестування». Усі інструменти з цієї статті є в підкатегоріях Тестування й API.

Часті запитання

Чи потрібно вміти програмувати, щоб тестувати API?

Ні, для початку достатньо Postman і розуміння HTTP. Програмування знадобиться, коли захочете автоматизувати перевірки, але навіть тоді можна почати з тестів у Postman і Newman.

Postman чи Bruno?

Postman — стандарт ринку з найбільшою кількістю навчальних матеріалів. Bruno зручніший, коли команда хоче зберігати колекції в Git поруч із кодом і працювати без хмарного акаунта.

Чим API-тести відрізняються від UI-тестів?

API-тести перевіряють логіку й дані напряму, без інтерфейсу, тому вони швидші й стабільніші. UI-тести перевіряють, що користувач бачить і може зробити. У добрій стратегії API-тестів більше, ніж UI-тестів.

Чи безпечно надсилати запити до тестових API?

Так, для цього вони й створені. Але не вводьте туди справжні персональні дані й паролі: інші користувачі можуть їх побачити.

Не знаєте, з чого почати?

Запитайте Елю: вона підбере інструменти для тестування API під ваш проєкт і мову програмування.

Дата перевірки фактів: 4 листопада 2026 року. Умови сервісів можуть змінюватися, тож перевіряйте їх на офіційних сайтах.