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

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

Що таке API?

API розшифровується як інтерфейс прикладного програмування. Це набір правил, які дозволяють одному програмному забезпеченню взаємодіяти з іншим. Коли ваш метеорологічний додаток отримує прогноз погоди на сьогодні, або коли ви входите на сайт за допомогою свого облікового запису Google, API виконує цю роботу.

Найпоширеніший тип, з яким ви зіткнетеся як тестувальник, - це REST API - він взаємодіє через HTTP і використовує стандартні методи для взаємодії з даними. GET отримує дані, POST створює їх, PUT і PATCH оновлюють їх, а DELETE видаляє. Кожен виклик націлений на певну кінцеву точку (URL, наприклад, https://api.example.com/users/42) і повертає відповідь з кодом статусу і, як правило, у вигляді JSON-тексту.

Коди статусу - це ваш перший сигнал про те, що сталося. Найчастіше ви бачите такі коди: 200 означає успіх, 201 - створено новий ресурс, 400 - щось не так з вашим запитом, 401 - потрібна автентифікація, 403 - у вас немає дозволу, 404 - ресурсу не існує, а 500 - щось сталося на стороні сервера.

Навіщо тестувати API?

Більшість тестувальників спочатку вивчають UI тестування. Тож навіщо йти глибше?

Швидкість. Тести API повністю оминають браузер і виконуються безпосередньо на рівні бізнес-логіки. Набір, який займає 20 хвилин у фреймворку користувацького інтерфейсу, може виконуватися за лічені секунди на рівні API.

Більш раннє виявлення помилок. Пошкоджений API призведе до збоїв у всіх функціях, які від нього залежать. Виявлення помилки у джерелі - до того, як вона з’явиться в інтерфейсі користувача - значно економить час і зусилля.

Стабільність. Тести інтерфейсу перериваються, коли змінюється напис на кнопці або змінюється макет. API пов’язані контрактом на передачу даних, який, як правило, набагато стабільніший, що робить тести API набагато дешевшими у підтримці.

Ось чому досвідчені команди QA будують свою роботу за принципом піраміди тестування: широка база швидких, надійних тестів API та інтеграції, з меншим шаром тестів користувацького інтерфейсу на вершині.

Що тестувати в API

Коли ви підходите до нового API, є п’ять областей, які варто послідовно розглянути.

Перше - це функціональна коректність - чи робить кожна кінцева точка те, що вона повинна робити? POST до /users має створювати користувача. GET до /users/999 для неіснуючого запису повинен повертати 404, а не аварійне завершення.

Другий - це валідація даних. Що станеться з відсутніми обов’язковими полями, неправильними типами даних або дуже довгими значеннями? Добре спроектований API повертає корисну помилку 400-го рівня. Погано спроектований - повертає 500 або поводиться непередбачувано.

По-третє, перевірте структуру відповіді. Чи всі очікувані поля присутні і в правильному форматі? Якщо в договорі API вказано, що вік - це число, це завжди має бути число, а не рядок.

По-четверте, не забувайте про автентифікацію та авторизацію. Чи можуть неавторизовані користувачі отримати доступ до захищених кінцевих точок? Чи може звичайний користувач отримати доступ до ресурсів лише для адміністраторів? Ці питання легко пропустити, коли ви зосереджені на щасливому шляху, але вони є критично важливими для безпеки.

Нарешті, перевірте обробку помилок. Коли щось йде не так, API дає збій безболісно - чи розкриває внутрішні траси стека і деталі сервера?

Інструменти для початку роботи

Для початку вам не потрібно багато. Postman - найкращий вибір для початківців: він дозволяє створювати запити, перевіряти відповіді, писати тестові скрипти і організовувати все в колекції, до яких можна надавати спільний доступ. Insomnia - легша альтернатива, якщо ви віддаєте перевагу більш простому інтерфейсу. Для команд, які хочуть інтегрувати тести в код, REST Assured (Java) і pytest-requests (Python) є хорошими варіантами. А curl, інструмент командного рядка, попередньо встановлений на більшості систем, є незамінним, якщо ви працюєте в середовищах CI/CD.

У цьому уроці ми будемо використовувати Postman.

Ваші перші тести API: Практична інструкція

Ми потренуємося на JSONPlaceholder - безкоштовному, публічному фейковому REST API, призначеному для тестування.

Крок 1: Надішліть GET-запит

Відкрийте Postman, створіть новий запит, встановіть метод GET і введіть:

Натисніть “Відправити”. Ви повинні отримати відповідь 200 OK з тілом JSON, що містить дані користувача. Тепер перейдіть на вкладку Тести і додайте:

pm.test(“Статус - 200”, function () {

pm.response to have status(200);

});

pm.test(“Response has name field”, function () {

const body = pm.response.json();

pm.expect(body).to.have.property(“name”);

});

pm.test(“ID відповідає запиту”, function () {

const body = pm.response.json();

pm.expect(body.id).to equal(1);

});

Запустіть запит - всі три тести повинні пройти.

Крок 2: Тестування POST-запиту

Змініть метод на POST, оновіть URL-адресу на https://jsonplaceholder.typicode.com/posts, а на вкладці Body виберіть raw → JSON і вставте:

{

“заголовок”: “Мій перший пост”,

“body”: “Тестування кінцевої точки POST.”,

“userId”: 1

}

Ви повинні отримати відповідь 201 Створено. Перевірте його:

pm.test(“Статус - 201”, function () {

pm.response to have status(201);

});

pm.test(“Назва збігається з тим, що ми надіслали”, функція () {

const body = pm.response.json();

pm.expect(body.title).to.equal(“My First Post”);

});

Крок 3: Перевірте негативний випадок

Поверніться до GET і запитайте користувача, якого не існує:

Ви повинні отримати помилку 404. Пиши тест:

pm.test(“Неіснуючий ресурс повертає 404”, function () {

pm.response to have status(404);

});

Це одна з найцінніших звичок, яку потрібно формувати на ранніх етапах: завжди перевіряти, що відбувається, коли щось йде не так, а не тільки тоді, коли все йде добре.

Організація та автоматизація ваших тестів

Якщо у вас більше кількох запитів, використовуйте колекції Postman’а, щоб згрупувати пов’язані запити за функціями, і змінні оточення (наприклад, {{base_url}}), щоб уникнути жорсткого кодування URL-адрес - таким чином, перемикання між розробкою, стадією і продакшеном відбувається в один клік.

Коли ви будете готові до автоматизації, Newman (CLI для Postman) дозволить вам запустити всю колекцію з командного рядка:

newman виконати my-collection.json -e my-environment.json

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

Типові помилки, яких слід уникати

Найпоширеніша пастка - це тестування лише щасливого шляху. Завжди запитуйте: що тут може піти не так? Пропущені поля, невірні типи, дублікати записів - граничні випадки, де ховаються помилки. Так само не варто жорстко кодувати тестові дані, які покладаються на конкретні записи, що вже існують в базі даних; використовуйте динамічні дані і очищайте їх після тестів, щоб вони надійно проходили в будь-якому середовищі.

Дві інші речі, які тестувальники зазвичай не беруть до уваги: заголовки відповідей (які містять важливі метадані, такі як тип контенту і статус обмеження швидкості) і тести на автентифікацію. Перевірка того, що несанкціоновані запити належним чином відхиляються, має фундаментальне значення для безпеки API - і зазвичай не є пріоритетним завданням.

Куди рухатися далі

Після того, як ви освоїте основи, природним наступним кроком буде тестування контрактів за допомогою таких інструментів, як Pact - воно гарантує, що поведінка API відповідає узгодженим між сервісами специфікаціям. Після цього тестування продуктивності за допомогою k6 або Apache JMeter допоможе вам перевірити, як ваш API працює в умовах реального трафіку, а тестування безпеки за допомогою OWASP ZAP йде глибше, ніж коди статусів, щоб знайти реальні вразливості.

Потрібна експертна підтримка тестування API?

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

Якщо вам потрібна спеціальна команда QA, разовий аудит або постійна підтримка автоматизованого тестування, ми готові допомогти. Зв ‘яжіться з нами або запросіть безкоштовну пропозицію, щоб дізнатися, як ми можемо покращити ваш процес контролю якості.