Тестування API (API - Application Programming Interface)

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

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

Ще більш простий приклад: прийміть офіціанта як ресторан API. У ресторані ви даєте замовлення на основі страв, визначених у меню. Офіціант приймає ваше замовлення і на цьому ваша участь закінчується і вам не цікаво, що там станеться далі. Від офіціанта ви очікуєте тільки результат - вам приносять замовлену страву.

Можете спробувати взаємодію з API самі: відправляєте GET запит на і отримуєте у відповідь список користувачів. Це дуже зручно, коли ви хочете надати інтерфейс взаємодії зі своїм сервісом стороннім особам. Наприклад, у google, instagram, vk і, загалом, у всіх популярних продуктів є відкрита частина API. Тобто у вас є документ із переліком того, що і як можна спитати і що вам на це прийде у відповідь. Взаємодіяти з API можна і з веб-сторінки, і за допомогою спеціальних інструментів і з коду. Окрім іншого, API буває не тільки в контексті мереж, наприклад, в тій же системі Android є внутрішнє системне API.

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

Типи тестування API:

Unit testing: Для перевірки функціональності окремої операції;
Functional testing: Щоб перевірити функціональність ширших сценаріїв за допомогою блоку результатів unit-тестування, протестованих разом;
Load testing: Щоб перевірити функціональність та продуктивність під навантаженням;
Runtime/Error Detection: Моніторинг програми для виявлення проблем, таких як виключення та витоку ресурсів;
Security testing: Щоб гарантувати, що реалізація API захищена від зовнішніх загроз;
UI testing: Це виконується як частина end-to-end integration тестів, щоб переконатися, що кожен аспект інтерфейсу користувача функціонує належним чином;
Interoperability and WS Compliance testing: Сумісність та WS Compliance testing – це тип тестування, який застосовується до SOAP API. Функціональна сумісність між API-інтерфейсами SOAP перевіряється за допомогою відповідності профілям функціональної сумісності веб-служб. Відповідність WS-* перевірено, щоб гарантувати, що стандарти, такі як WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security та WS-Trust, належним чином реалізовані та використовуються;
Penetration testing: Щоб знайти вразливість під час атак зловмисників;
Fuzz testing: Для перевірки API шляхом примусового введення в систему некоректних даних для спроб примусового збою;
Usability testing: перевіряє, чи API є функціональним і зручним для користувача і чи добре інтегрується з іншою платформою;
Documentation testing: команда тестування має переконатися, що документація відповідає вимогам та надає достатньо інформації для взаємодії з API. Документація має бути частиною остаточного результату;

Приклади проблем, які виявляє тестування API:

Некоректне опрацювання умов помилки;
Прапори, що не використовуються;
Відсутні чи повторювані функції;
питання надійності;
Складність підключення та отримання відповіді від API;
Проблеми із безпекою;
Проблеми із багатопоточністю;
Проблеми із продуктивністю. Час відгуку API дуже великий;
Неправильні помилки / попередження абоненту, що викликає;
неправильне оброблення допустимих значень аргументів;
Дані відповіді неправильно структуровані (JSON чи XML);

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

У загальному випадку контрактне тестування або Consumer Driven Contract (CDC) є сполучною ланкою між модульним та інтеграційним тестуванням.

Кожен інтерфейс має постачальника (supplier) та споживача (consumer). Само собою, сервіси постачальника та споживача розподілені між різними командами, ми опиняємось у ситуації, коли чітко прописаний інтерфейс між ними (або контракт) просто необхідний. Зазвичай багато хто підходить до цієї проблеми таким чином:

Пишуть докладний опис специфікації інтерфейсу – контракт;
Реалізують сервіс постачальника відповідно до специфікації;
Передають специфікацію інтерфейсу споживачеві;
Чекають на реалізацію з іншого боку;
Запускають ручні системні тести, щоб перевірити все;
Тримають кулачки, що обидві сторони вічно дотримуватимуться описаний інтерфейс;

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

Розберемося у взаємодії з прикладу REST архітектури: постачальник створює API з деяким endpoint, а споживач відправляє запит до API, наприклад, із єдиною метою отримання даних чи виконання змін у іншому додатку. Це договір, який описується з допомогою DSL (domain-specific language). Він включає опис API у формі сценаріїв взаємодії між споживачем і постачальником. За допомогою CDC виконується тестування клієнта та API із використанням заглушок, які збираються на основі контракту. Основним завданням CDC є зближення сприйняття між командами розробників API та розробників клієнта. Таким чином, учасники команди споживачів пишуть CDC тести (для всіх даних проекту розробки), щоб команда постачальника змогла запустити тести та перевірити API. У результаті команда постачальника легко розробить свій API, використовуючи тести CDC. Результатом прогону контрактних тестів є розуміння, що постачальник упевнений у справній роботі API у споживача. Слід звернути увагу, що команда споживача повинна регулярно здійснювати підтримку CDC-тестів під час кожної зміни, і вчасно передавати всю інформацію команді постачальника. Якщо регулярно фіксуємо невдало виконані CDC-тести, слід піти (у буквальному значенні слова, до постраждалої стороні тесту і дізнатися, в рамках якого завдання були зміни (що призвело до падіння тесту).

З того, що було описано вище, можна виділити такі тези для виконання контрактного тестування:

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

Мінуси CDC:

CDC тести не замінюють тести E2E. За фактом я схильний віднести CDC до заглушок, які є моделями реальних компонентів, але є ними, тобто. це ще одна абстракція, яку потрібно підтримувати та застосовувати у потрібних місцях (складно реалізувати складні сценарії);
CDC тести не замінюють функціональні тести API. Особисто дотримуюсь золотого правила - якщо прибрати контракт і це не викликає помилки чи неправильної роботи клієнта, то він не потрібен. Приклад: Немає необхідності перевіряти всі коди помилок через контракт, якщо клієнт обробляє їх (помилки) однаково. Таким чином, контракт те, що важливо для клієнта сервісу, а не навпаки;
CDC тести дорожче у підтримці, ніж функціональні тести;
Для реалізації CDC-тестів потрібно використовувати окремі інструменти тестування - Spring Cloud Contract, PACT;

Відмінність API від SDK :

SDK (software development kit) – це набір функціоналу (бібліотек) та утиліт для розробки. Власне SDK і надає реалізацію деякого API, це оболонка API, яка спрощує роботу для розробників.

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

Тестування API без документації/чорною скринькою :

Якщо Вам з якоїсь причини доведеться зробити цю невдячну роботу, визначтеся, наскільки все погано і яка у Вас інформація про об'єкт тестування. Чи відомі які порти для Вас відкриті? Чи знаєте Ви потрібні endpoints? Якщо справа зовсім погано – проскануйте порти, наприклад, за допомогою netcat. Збережіть файл у відкритих портах. Ця операція займе чимало часу. Можете почитати поради щодо роботи з Nmap і Netcat. Якщо Вам відомий потрібний порт та відповідний endpoint – переберіть усі можливі HTTP методи. Почніть із найбільш очевидних POST, PUT, GET. Для прискорення процесу напишіть скрипт, наприклад, на Python. У гіршому випадку, коли ні порт ні endpoints невідомі Вам, швидше за все, доведеться перебирати всі відкриті порти і генерувати endpoints, які підходять за змістом. Розробники зазвичай особливо не морочаться і закладають мінімально-необхідну інформацію. Так що увімкніть уяву і спробуйте придумати endpoints спираючись на бізнес логіку та прийняті у Вашій компанії стандарти. Якщо ні endpoints ні бізнес логіка Вам невідомі, то маю підозру, що Ви тестуєте API з не найкращими намірами.

Джерела:

Дод. матеріал:

PreviousТестування графічного інтерфейсу/візуальне тестування (GUI - Graphical User Interface testing NextA/B тестування (A/B Testing)

Last updated 2 years ago