Меню

Підручник з тестування API: повний посібник для початківців

  • Головна
  • Інший
  • Підручник з тестування API: повний посібник для початківців

api testing tutorial

Спробуйте Наш Інструмент Для Усунення Проблем

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

Отримайте глибоке розуміння тестування API разом із концепцією тестування вліво та веб-сервісів із цього вступного посібника.

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

=>ПРОКРУТИ ВНИЗпереглянути повний перелік 5 посібників із глибокого тестування API для початківців

Тестування API

Що ви дізнаєтесь:

Перелік підручників з тестування API

Підручник No1: Підручник з тестування API: повний посібник для початківців
Підручник No2: Підручник з веб-служб: Компоненти, архітектура, типи та приклади
Підручник No3: Найкращі 35 запитань щодо інтерв’ю ASP.Net та Web API із відповідями
Підручник No4: Підручник з POSTMAN: Тестування API за допомогою POSTMAN
Підручник No5: Тестування веб-служб за допомогою клієнта Apache HTTP

Огляд підручників у цій серії тестування API

Підручник №Що ви дізнаєтесь
LoadFocus Залежно від кількості користувачів та типів плану* Може використовуватися для тестування навантаження API - дозволяє запустити кілька тестів, щоб з’ясувати кількість користувачів, які може підтримувати API.
* Простий у використанні - дозволяє запускати тести в браузері.
Підручник_1: Підручник з тестування API: повний посібник для початківців
Цей поглиблений посібник з тестування API детально пояснить все про тестування API та веб-служби, а також навчить вас, як запровадити тестування API у вашій організації.
Підручник_2: Підручник з веб-служб: Компоненти, архітектура, типи та приклади
Цей посібник з веб-служб пояснює архітектуру, типи та компоненти веб-служб, а також важливі термінології та різницю між SOAP та REST.
Підручник_3: Найкращі 35 запитань щодо інтерв’ю ASP.Net та Web API із відповідями
У цьому посібнику ви можете ознайомитись із списком найпопулярніших запитань щодо інтерв’ю щодо ASP.Net та Web API, а також відповіді та приклади для початківців та досвідчених професіоналів.
Підручник_4: Підручник з POSTMAN: Тестування API за допомогою POSTMAN
Цей покроковий посібник пояснить тестування API за допомогою POSTMAN, а також основи роботи POSTMAN, його компоненти та вибіркові запити та відповіді простими словами для Вашого легкого розуміння.
Підручник_5: Тестування веб-служб за допомогою клієнта Apache HTTP
Цей підручник з API стосується виконання різних CRUD-операцій у веб-службах та тестування веб-служб за допомогою клієнта Apache HTTP

Підручник з тестування API

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

API (Application Programming Interface) - це набір усіх процедур та функцій, які дозволяють нам створювати додаток, отримуючи доступ до даних або функцій операційної системи або платформ. Тестування таких процедур відоме як API-тестування.

Переміщення вліво Тестування

Одним з важливих видів тестування, про яке сьогодні задають інтерв’ю для тестування API, є тестування Shift Left. Цей тип тестування практикується майже у всіх проектах, які дотримуються гнучкої методології.

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

Крім цього, зусилля, докладені (коли дефекти були зареєстровані на останньому етапі перед виробництвом), були величезними, оскільки розробникам довелося пройти спочатку фазу проектування та кодування.

Життєвий цикл розробки програмного забезпечення (SDLC) перед тестуванням на зміну вліво

Традиційний потік SDLC був: Вимога -> Дизайн -> Кодування -> Тестування.

Недоліки традиційного тестування

  • Тестування відбувається вкрай праворуч. Багато витрат виникають, коли помилка виявляється в останню хвилину.
  • Час, витрачений на усунення помилки та повторне тестування, перш ніж просувати його до виробництва, величезний.

Таким чином, з’явилася нова ідея для зсуву фази тестування вліво, що призвело до тестування Shift Left.

Пропоноване читання => Тестування Shift Left: Секретна мантра для успіху програмного забезпечення

Фази тестування на ліву зміну

Етапи тестування на ліву зміну

Тестування на ліву зміну призвело до успішного переходу від виявлення дефектів до запобігання дефектам. Це також допомогло програмному забезпеченню швидко вийти з ладу і усунути всі збої як можна раніше.

Веб-API

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

Як працює API?

Візьмемо дуже поширений сценарій бронювання рейсу на веб-сайті www.makemytrip.com, який є онлайн-послугою для подорожей, яка збирає інформацію від кількох авіакомпаній. Коли ви йдете на бронювання авіарейсу, ви вводите таку інформацію, як дата подорожі / дата повернення, клас тощо, і натискаєте на пошук.

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

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

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

Веб-сервіси

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

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

Веб-API проти веб-служб

Веб-API проти WEB-служб

Веб-служби проти веб-API

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

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

Запитання та відповіді на інтерв’ю для oracle sql

Відмінності між веб-службами та веб-API наведено нижче для ознайомлення.

Веб-сервіс

  • Як правило, веб-служби використовують XML (Розширювана мова розмітки), що означає, що вони більш безпечні.
  • Веб-служби є більш безпечними, оскільки як веб-служби, так і API забезпечують SSL (захищений рівень сокетів) під час передачі даних, але вони також забезпечують WSS (захист веб-служб).
  • Веб-служба - це підмножина веб-API. Наприклад, Веб-служби базуються лише на трьох стилях використання, тобто SOAP, REST та XML-RPC.
  • Веб-службам завжди потрібна мережа для роботи.
  • Веб-служби підтримують “One Code різні додатки”. Це означає, що більш загальний код пишеться в різних додатках.

Веб-API

  • Веб-API зазвичай використовує JSON (JavaScript Object Notation), що означає, що веб-API є швидшим.
  • Веб-API швидший, оскільки JSON є легким, на відміну від XML.
  • Веб-API - це надмножина веб-служб. Наприклад, Всі три стилі веб-служб також присутні у веб-API, але крім цього, він використовує інші стилі, такі як JSON - RPC.
  • Веб-API не обов'язково вимагає роботи мережі.
  • Веб-API може підтримувати або не підтримувати взаємодію залежно від природи системи або програми.

Представляємо тестування API у вашій організації

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

Наприклад, Давайте зважатимемо, що ви переглядаєте продукти на Amazon.com і бачите товар / угоду, який вам дуже подобається, і ви хочете поділитися ним із вашою мережею Facebook.

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

Переміщення фокусу на тестування API

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

Є кілька причин, з яких організації переходять на продукти та додатки на основі API. І декілька з них подані нижче для ознайомлення.

# 1) Програми на основі API є більш масштабованими в порівнянні з традиційними програмами / програмним забезпеченням. Швидкість розробки коду швидша, і той самий API може обслуговувати більше запитів без будь-яких серйозних змін коду або інфраструктури.

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

Наприклад, Якщо ви розробник, який працює на веб-сайті електронної комерції, і хочете додати Amazon як платіжний процесор, тоді вам не потрібно писати код з нуля.

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

# 3) API дозволяють легко інтегрувати з іншими системами як для підтримуваних автономних програм, так і з програмними продуктами на основі API.

Наприклад , Давайте розглянемо, що ви хочете відправити відправлення з Торонто до Нью-Йорка. Ви заходите в Інтернет, переходите на добре відомий веб-сайт з питань вантажів або логістики та вводите необхідну інформацію.

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

Повний спектр тестування API

Тестування API не обмежується лише надсиланням запиту до API та аналізом відповіді на предмет правильності. Потрібно протестувати API на ефективність при різних навантаженнях на наявність уразливостей.

Давайте обговоримо це детально.

(i) Функціональне тестування

Функціональне тестування може бути складним завданням через відсутність графічного інтерфейсу.

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

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

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

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

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

Наприклад, Якщо для програми потрібен формат дати DD / MM / YYYY, тоді ми можемо застосувати цю перевірку на формі, що збирає інформацію, щоб переконатися, що програма отримує та обробляє дійсну дату.

Однак це не однаково для додатків API. Нам потрібно переконатися, що API добре написаний і здатний забезпечити виконання всіх цих перевірок, розрізнити дійсні та недійсні дані та повернути код стану та повідомлення про помилку перевірки кінцевому користувачеві через відповідь.

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

Крім того, якщо саме повідомлення про помилку є неправильним, це може ввести в оману кінцевого споживача, який намагається інтегрувати цей API.

На скріншоті нижче користувач ввів недійсну вагу, що перевищує допустимі 2267 кг. API відповідає кодом стану помилки та повідомленням про помилку. Однак повідомлення про помилку неправильно називає одиниці ваги як фунти замість KG. Це дефект, який може заплутати кінцевого споживача.

Тестування API - неправильне повідомлення про помилку

(ii) Випробування навантаження та продуктивності

API призначені для масштабування за дизайном.

Це, в свою чергу, робить Load і Тестування продуктивності важливо, особливо якщо передбачається, що система, що проектується, обслуговуватиме тисячі запитів на хвилину або годину, залежно від вимог. Постійне проведення тестів навантаження та продуктивності на API може допомогти визначити продуктивність, пікові навантаження та точку розриву.

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

Наприклад скажімо, виходячи з наданих вимог, ми знаємо, що розроблений API повинен обслуговувати щонайменше 500 запитів на годину та підтримувати середній час відгуку менше, ніж 0,01 секунди.

На основі наших тестів навантаження та продуктивності ми з’ясували, що до тих пір, поки API отримує менше 500 запитів на годину, він може підтримувати рівень SLA середній час відгуку. Однак, якщо він отримує ще 200 запитів, тоді середній час відгуку збільшується, і точка розриву досягається, коли вхідний запит перевищує 1200 на годину.

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

(iii) Тестування безпеки

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

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

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

Також читайте = >> Що таке тестування контрактних контрактів

Як запровадити тестування API у вашій організації

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

У таблиці нижче наведено основні кроки разом із очікуваним результатом кожного кроку.

ФазаКрокОчікуваний результат
Вибір інструментуЗберіть вимоги та визначте обмеження
Зрозумійте вимоги до дослідження ринку відповідного інструменту тестування API.
Наприклад
Який тип API тестується - SOAP чи REST?
Чи потрібно наймати тестера для цієї ролі чи навчати вже існуючого тестера?
Які випробування будуть виконуватися - функціональні, випробувальні та ін.
Який бюджет для реалізації?
Оцініть наявні інструментиПорівняйте наявні інструменти та 1 або 2 інструменти, що найкраще відповідають вимогам.
Доказ концепціїЗдійснюйте підмножину тестів за допомогою інструменту, що входить до списку.
Представити висновки зацікавленим сторонам.
Доопрацюйте інструмент, який потрібно впровадити.
ВпровадженняПочинаємоЗалежно від вашого вибору інструменту, вам доведеться встановити необхідний інструмент на ПК, віртуальній машині або сервері.
Якщо вибраним інструментом є підписка, створіть необхідні облікові записи команди.
Навчіть команду, якщо потрібно.
РухатисяСтворіть тести
Виконайте тести
Повідомте про дефекти

Загальні виклики та способи їх пом'якшення

Давайте обговоримо деякі загальні виклики, з якими стикаються команди з контролю якості при спробі впровадити структуру тестування API в організації.

# 1) Вибір правильного інструменту

Вибір правильного інструменту для роботи є найпоширенішою проблемою. На ринку доступно декілька засобів тестування API.

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

Отже, завжди вибирайте інструмент, який відповідає вимогам, які потрібно мати, виходячи з ваших організаційних потреб.

Ось зразок матриці оцінки інструментів для доступних інструментів API

ІнструментЦіноутворенняПримітки
Інтерфейс мила Безкоштовна версія доступна для відкритого коду SoapUI (функціональне тестування)* REST, SOAP та інші популярні протоколи API та IoT.

* Входить у безкоштовну версію
Спеціальне тестування SOAP та REST
Ствердження повідомлення
Створення тесту перетягування
Журнали випробувань
Конфігурація тесту
Тест із записів
Підрозділ звітів.

* Повний перелік функцій можна знайти на їх веб-сайті.
Листоноша Доступний безкоштовний додаток Листоноша* Найчастіше використовується для REST.
* Функції можна знайти на їх веб-сайті.
Parasoft Це платний інструмент, він вимагає придбання ліцензії, а потім вимагає встановлення, перш ніж інструмент можна буде використовувати.* Комплексне тестування API: функціональність, навантаження, тестування безпеки, управління тестовими даними
vREST Залежно від кількості користувачів* Автоматизоване тестування REST API.
* Запис і відтворення.
* Видаляє залежність від інтерфейсу та серверного сервера за допомогою макетних API.
* Потужна перевірка відповіді.
* Працює для тестових додатків, розгорнутих на localhost / intranet / Internet.
* Інтеграція JIRA, Інтеграція Дженкінса Імпорт від Swagger, Postman.
HttpMaster Express Edition: Безкоштовно завантажити
Професійна версія: Залежно від кількості користувачів
* Допомагає у тестуванні веб-сайтів, а також тестуванні API.
* Інші функції включають можливість визначати загальні параметри, надає користувачеві можливість створювати перевірки для перевірки відповіді даних за допомогою великого набору типів перевірки, які він підтримує.
Рунскоп Залежно від кількості користувачів та типів планів
* Для моніторингу та тестування API.
* Може використовуватися для перевірки даних, щоб забезпечити повернення правильних даних.
* Містить функцію відстеження та сповіщення у випадку будь-якої помилки транзакції API (якщо ваша програма вимагає перевірки платежу, то цей інструмент може виявитись хорошим вибором).
PingAPI Безкоштовно для 1 проекту (1000 запитів)* Вигідно для автоматизованого тестування та моніторингу API.

# 2) Відсутні специфікації тесту

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

Наприклад , враховуйте вимоги, наведені нижче:

'Заявка повинна приймати лише дійсну дату доставки, а всі недійсні вимоги слід відхиляти'

У цих вимогах відсутні ключові деталі і дуже неоднозначні - як ми визначаємо дійсну дату? А як щодо формату? Ми повертаємо будь-яке повідомлення про відмову кінцевому користувачу тощо?

Приклад чітких вимог:

1) Заявка повинна приймати лише дійсну дату доставки.

Дата доставки вважається дійсною, якщо вона є

  • Не в минулому
  • Більше або дорівнює сьогоднішній даті
  • Є у прийнятному форматі: ДД / ММ / РРРР

два)

Код статусу відповіді = 200
Повідомлення: добре

3) Дата доставки, яка не відповідає вищезазначеним критеріям, слід вважати недійсною. Якщо клієнт надсилає недійсну дату доставки, він повинен відповісти таким повідомленням (повідомленнями) про помилку:

3.1

Код стану відповіді НЕ 200
Помилка: вказана дата доставки недійсна; будь ласка, переконайтесь, що дата вказана у форматі ДД / ММ / РРРР

3.2

Код стану відповіді НЕ 200
Помилка: вказана дата доставки минула

# 3) Крива навчання

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

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

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

# 4) Існуючий набір навичок

Це безпосередньо пов’язано з попереднім пунктом щодо кривої навчання.

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

Приклад

Завдання

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

Виклики

  • Жоден з інших програмних продуктів не мав архітектури, заснованої на API, отже, щоб провести тестування навколо цього завдання, команда повинна встановити процес тестування API з нуля. Це означає, що інструменти мали бути оцінені, внесені в шорт-лист, доопрацьовані, а команда повинна бути підготовлена ​​до тестів.
  • Для придбання та впровадження інструменту не було виділено додаткового бюджету. Це означає, що команда мала вибрати безкоштовний засіб тестування API з відкритим кодом, а когось із існуючої команди потрібно було навчити приймати це завдання.
  • Не було вимог до полів API та перевірки даних. Вимоги були “повинен працювати так само, як і відповідний графічний інтерфейс”.

Підхід, який дотримується команда для зменшення ризиків та вирішення проблем

  • Команда QA працювала з командою проекту, щоб визначити наступні вимоги:
    • Тип API (REST / SOAP): Відпочинок
    • Необхідні тести (функціональні, навантажувальні, безпечні): Тільки функціональне тестування
    • Потрібні автоматизовані тести (так / ні): Наразі необов’язково
    • Звіти про випробування (так / ні): вимагається
  • Команда QA провела оцінку інструментів щодо наявних Засоби тестування API виходячи з обов’язкових вимог. Посібник API Tool був доопрацьований як інструмент за їх вибором, оскільки він був безкоштовним, а також простим у використанні, таким чином мінімізуючи криву навчання, маючи потенціал для автоматизації тестів, і мав хороші вбудовані звіти.
  • Той самий тестер, який тестував додаток, пройшов навчання для використання Postman для створення початкових тестів, усуваючи тим самим будь-які прогалини в знаннях про продукт.
  • Для вирішення відсутніх вимог команда проекту створила документацію високого рівня на місцях, використовуючи Swagger. Однак це залишило певні прогалини з точки зору прийнятних форматів даних, і це було узгоджено з командою проекту, а також передбачено узгодження та документування передбачуваних форматів.

Висновок

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

У цьому посібнику з тестування API докладно описано все про тестування API, тестування зсуву вліво, веб-служби та веб-API. Ми також дослідили відмінності між веб-службами та веб-API на прикладах.

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

Перегляньте наш майбутній підручник, щоб дізнатись більше про веб-служби разом із прикладами !!

НАСТУПНИЙ підручник

Рекомендована література

^