Урок за API тестване: Пълно ръководство за начинаещи

api testing tutorial

Този урок за задълбочено API тестване обяснява всичко за API тестване, уеб услуги и как да въведете API тестване във вашата организация:

Получете задълбочена представа за API тестване заедно с концепцията за тестване вляво и уеб услуги от този уводен урок.

Понятия като уеб API, как работи API (с реалния пример) и как се различава от уеб услугите са добре обяснени с примери в този урок.

=>ПРЕВЪРТИ НАДОЛУза да видите целия списък с 5 Уроци за тестване на API за дълбочина за начинаещи

Какво ще научите:

• Списък с уроци за тестване на API
• Преглед на уроци в тази серия за тестване на API
• Урок за API тестване
  • Тестване на смяна наляво
  • Жизнен цикъл на разработка на софтуер (SDLC) преди тестване на ляво превключване
  • Фази на тестване на лява смяна
  • Уеб API
  • Как работи API?
  • Уеб услуги
  • Уеб услуги срещу уеб API
• Представяне на API тестване във вашата организация
  • Преместване на фокуса към API тестване
  • Пълен спектър на API тестване
    • (i) Функционално тестване
    • (ii) Тестване на натоварване и производителност
    • (iii) Тестване на сигурността
  • Как да въведем API тестване във вашата организация
  • Общи предизвикателства и начини за тяхното смекчаване
    • # 1) Избор на правилния инструмент
    • # 2) Липсващи спецификации на теста
    • # 3) Крива на обучение
    • # 4) Съществуващ набор от умения
  • Казус
• Заключение
  • Препоръчително четене

Списък с уроци за тестване на API

Урок # 1: Урок за API тестване: Пълно ръководство за начинаещи
Урок # 2: Урок за уеб услуги: Компоненти, архитектура, типове и примери
Урок № 3: Топ 35 въпроси за интервю за ASP.Net и Web API с отговори
Урок № 4: Урок за POSTMAN: Тестване на API с помощта на POSTMAN
Урок № 5: Тестване на уеб услуги с помощта на Apache HTTP клиент

Преглед на уроци в тази серия за тестване на API

Урок за API тестване

Този раздел ще ви помогне да получите основно разбиране за уеб услугите и уеб API, което от своя страна ще бъде полезно за разбирането на основните концепции в предстоящите уроци в тази поредица за тестване на API.

за да генерирате произволно число, можете да използвате функцията rand на заглавния файл

API (Application Programming Interface) е набор от всички процедури и функции, които ни позволяват да създадем приложение чрез достъп до данните или функциите на операционната система или платформи. Тестването на такива процедури е известно като API тестване.

Тестване на смяна наляво

Един от важните видове тестване, който се задава в наши дни в интервютата за тестване на API, е Shift Left Testing. Този тип тестване се практикува в почти всички проекти, които следват гъвкава методология.

Преди да бъде въведено Shift Left Testing, тестването на софтуера се появи само след като кодирането завърши и кодът беше доставен на тестерите. Тази практика доведе до шума в последния момент, за да се спази крайният срок, а също така до голяма степен затрудни качеството на продукта.

Отделно от това, усилията, положени (когато дефектите бяха докладвани в последната фаза преди производството) бяха огромни, тъй като разработчиците трябваше да преминат през фазата на проектиране и кодиране отново.

Жизнен цикъл на разработка на софтуер (SDLC) преди тестване на ляво превключване

Традиционният SDLC поток беше: Изискване -> Дизайн -> Кодиране -> Тестване.

Недостатъци на традиционното тестване

• Тестването е в крайно дясно. Много разходи се правят, когато бъг бъде идентифициран в последния момент.
• Отнема много време за отстраняване на грешката и повторно тестване, преди да се популяризира в производство, е огромно.

Следователно се появи нова идея за изместване на фазата на тестване вляво, което по този начин доведе до Shift Left Testing.

Предложено четене => Shift Left Testing: Тайната мантра за успех на софтуера

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

Тестването на лява смяна доведе до успешна миграция от откриване на дефекти към предотвратяване на дефекти. Той също така помогна на софтуера да се провали бързо и да отстрани всички грешки най-рано.

Уеб API

Най-общо казано, уеб API може да бъде дефиниран като нещо, което приема заявката от клиентска система към уеб сървър и изпраща обратно отговора от уеб сървър на клиентска машина.

Как работи API?

Нека вземем много често срещан сценарий за резервиране на полет на www.makemytrip.com, който е онлайн услуга за пътуване, която обединява информация от множество авиокомпании. Когато отидете за резервация на полет, въвеждате информация като дата на пътуване / дата на връщане, клас и т.н. и кликнете върху търсене.

Това ще ви покаже цената на няколко авиокомпании и тяхната наличност. В този случай приложението взаимодейства с API на множество авиокомпании и по този начин дава достъп до данните на авиокомпанията.

Друг пример е www.trivago.com, който сравнява и изброява цената, наличността и т.н. на различни хотели от определен град. Този уебсайт комуникира с приложни програмни интерфейси (API) на множество хотели за достъп до базата данни и изброява цените и наличността от техния уебсайт.

По този начин уеб API може да бъде дефиниран като „интерфейс, който улеснява комуникацията между клиентска машина и уеб сървър“.

Уеб услуги

Уеб услугите са (като Web API) услугите, които обслужват от една машина на друга. Но основната разлика, която възниква между API и Web Services, е, че Web Services използва мрежа.

Безопасно е да се каже, че всички уеб услуги са уеб API, но всички уеб API не са уеб услуги (обяснено в последната част на статията). По този начин уеб услугите са подмножество на уеб API. Вижте диаграмата по-долу, за да научите повече за уеб API и уеб услугите.

Web API срещу Web Services

Уеб услуги срещу уеб API

Уеб API и Web Services се използват за улесняване на комуникацията между клиента и сървъра. Основната разлика идва само в начина, по който общуват.

Всеки от тях изисква орган за заявка, който е приемлив на конкретен език, разликите им в осигуряването на сигурна връзка, скоростта на комуникация със сървъра и отговор на клиента и т.н.

Разликите между уеб услугите и уеб API са изброени по-долу за справка.

Уеб сервиз

• Уеб услугите обикновено използват XML (Extensible Markup Language), което означава, че са по-сигурни.
• Уеб услугите са по-сигурни, тъй като както уеб услугите, така и приложните програмни интерфейси осигуряват SSL (Secure Socket Layer) по време на предаване на данни, но също така осигурява и WSS (защита на уеб услуги).
• Web Service е подмножество на Web API. Например, Уеб услугите се основават само на три стила на употреба, т.е. САПУН, ПОЧИВКА и XML-RPC.
• Уеб услугите винаги се нуждаят от мрежа, за да работят.
• Уеб услугите поддържат „Един код различни приложения“. Това означава, че в различни приложения се пише по-общ код.

Уеб API

• Web API обикновено използва JSON (JavaScript Object Notation), което означава, че Web API е по-бърз.
• Уеб API е по-бърз, тъй като JSON е леко претеглен, за разлика от XML.
• Уеб API са надмножието на уеб услугите. Например, И трите стила на уеб услуги присъстват и в уеб API, но освен това той използва и други стилове като JSON - RPC.
• Уеб API не изисква непременно мрежа за работа.
• Web 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) Функционално тестване

Функционалното тестване може да бъде предизвикателна задача поради липсата на GUI интерфейс.

Нека да видим как подход за функционално тестване for APIs се различава от приложението, базирано на GUI и ще обсъдим и някои примери около него.

да се) Най-очевидната разлика е, че няма графичен интерфейс за взаимодействие. Тестерите, които обикновено правят функционално тестване, базирано на GUI, смятат, че е малко по-трудно да преминат към не-GUI тестване на приложения, в сравнение с някой, който вече е запознат с него.

Първоначално, дори преди да започнете да тествате API, ще трябва да тествате и проверите самия процес на удостоверяване. Методът за удостоверяване ще варира от един API на друг API и ще включва някакъв ключ или маркер за удостоверяване.

Ако не можете да се свържете успешно с API, по-нататъшното тестване не може да продължи. Този процес може да се счита за сравним с удостоверяване на потребителя в стандартните приложения, където се нуждаете от валидни идентификационни данни, за да влезете и да използвате приложението.

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

Например, Ако дадено приложение се нуждае от формата на датата да бъде ДД / ММ / ГГГГ, тогава можем да приложим тази проверка във формуляра за събиране на информация, за да гарантираме, че приложението получава и обработва валидна дата.

Това обаче не е същото за приложенията на API. Трябва да гарантираме, че API е добре написан и е в състояние да приложи всички тези проверки, да прави разлика между валидни и невалидни данни и да върне кода на състоянието и съобщението за грешка при проверка на крайния потребител чрез отговор.

° С) Тестването на коректността на отговорите от API за валиден и невалиден отговор е наистина важно. Ако код на състоянието от 200 (което означава всичко е наред) се получи като отговор от тестовия API, но ако текстът на отговора казва, че е възникнала грешка, това е дефект.

Освен това, ако самото съобщение за грешка е неправилно, това може да бъде много подвеждащо за крайния клиент, който се опитва да се интегрира с този API.

На екранната снимка по-долу потребителят е въвел невалидно тегло, което е повече от приемливите 2267 кг. API отговаря с код за състояние на грешка и съобщение за грешка. Съобщението за грешка обаче неправилно посочва тегловните единици като lbs вместо KG. Това е дефект, който може да обърка крайния клиент.

(ii) Тестване на натоварване и производителност

API трябва да бъдат мащабируеми по дизайн.

Това от своя страна прави Load и Тестване на производителността от съществено значение, особено ако се очаква проектираната система да обслужва хиляди заявки в минута или час, в зависимост от изискването. Рутинното извършване на тестове за натоварване и производителност на API може да помогне за сравнение на производителността, пиковите натоварвания и точката на счупване.

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

Например , да кажем, че въз основа на предоставените изисквания знаем, че API, който е проектиран, трябва да обслужва поне 500 заявки на час и да поддържа средното време за реакция по-малко от .01 секунди.

Въз основа на нашите тестове за натоварване и производителност открихме, че докато API получава по-малко от 500 заявки на час, той е в състояние да поддържа SLA за средно време за реакция. Ако обаче получи още 200 заявки, тогава средното време за реакция се увеличава и точката на прекъсване се достига, когато входящата заявка надвиши 1200 на час.

Обикновено се вижда, че по време на началните фази на проектиране, често се набляга на функционалните аспекти на API. С течение на времето продуктът започва да поддържа множество клиенти на живо, тогава тестването за изпълнение на API и тестването на натоварване се появява по-рутинно.

(iii) Тестване на сигурността

Интерфейсите за приложно програмиране или API са уязвими и са най-лесната точка за достъп за злонамерени хакери, които искат достъп до данни или да получат контрол върху приложението.

Това може да доведе всяка компания до правни проблеми, при които поради нарушение на сигурността неволните хора и / или организации имат достъп до данните на клиента чрез почтен API.

Тестване на сигурността е специализиран клон на тестване и с него трябва да се занимават специалисти. Ресурсите за тестване на сигурността могат да бъдат от организацията или от независими консултанти.

Прочетете също = >> Какво е тестване на договорни договори

Как да въведем API тестване във вашата организация

Процесът за въвеждане на API тестване във всяка организация е подобен на процеса, използван за внедряване или въвеждане на друг инструмент и рамка за тестване.

Таблицата по-долу обобщава основните стъпки заедно с очаквания резултат от всяка стъпка.

Общи предизвикателства и начини за тяхното смекчаване

Нека обсъдим някои от често срещаните предизвикателства, пред които са изправени екипите за QA, докато се опитват да внедрят рамка за тестване на API в организация.

# 1) Избор на правилния инструмент

Изборът на правилния инструмент за работата е най-често срещаното предизвикателство. На пазара се предлагат няколко инструмента за тестване на API.

Може да изглежда много привлекателно да се приложи най-новият, най-скъпият инструмент, който се предлага на пазара, но ако не донесе желаните резултати, тогава този инструмент няма полза.

Следователно, винаги избирайте инструмента, който отговаря на изискванията за „задължително“ въз основа на вашите организационни нужди.

Ето примерна матрица за оценка на инструмента за наличните API инструменти

# 2) Липсващи спецификации на теста

Като тестери, ние трябва да знаем очакваните резултати, за да тестваме ефективно приложение. Това често е предизвикателство, тъй като за да знаем очакваните резултати, трябва да имаме ясни точни изисквания - което не е така.

Например , вземете предвид изискванията, предоставени по-долу:

„Заявлението трябва да приема само валидна дата на доставка и всички невалидни изисквания трябва да бъдат отхвърлени“

въпроси за интервю за сапун и почивка

В тези изисквания липсват ключови подробности и са много неясни - как определяме валидна дата? Какво ще кажете за формата? Връщаме ли някакво съобщение за отказ на крайния потребител и т.н.?

Пример за ясни изисквания:

1) Приложението трябва да приема само валидна дата на доставка.

Датата на доставка се счита за валидна, ако е

• Не и в миналото
• По-голямо или равно на днешната дата
• Е в приемлив формат: ДД / ММ / ГГГГ

две)

Код на състоянието на отговора = 200
Съобщение: ОК

3) Датата на доставка, която не отговаря на горните критерии, трябва да се счита за невалидна. Ако клиент изпрати невалидна дата за доставка, той трябва да отговори със следното съобщение (я) за грешка:

3.1

Код на състоянието на отговора НЕ 200
Грешка: Предоставената дата за доставка е невалидна; моля, уверете се, че датата е във формат ДД / ММ / ГГГГ

3.2

Код на състоянието на отговора НЕ 200
Грешка: Предоставената дата за доставка е в миналото

# 3) Крива на обучение

Както бе споменато по-рано, подходът за тестване на API е различен в сравнение с подхода, следван при тестване на приложения, базирани на GUI.

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

Ако на съществуващ член на екипа е възложено да учи API тестване, тогава в зависимост от избрания инструмент кривата на обучение може да бъде средна до висока, заедно с промяна на тестовия подход. Кривата на обучение за самия продукт или приложение може да бъде ниско-средна в зависимост от това дали този тестер е тествал това приложение преди или не.

# 4) Съществуващ набор от умения

Това се свързва директно с предишната точка за кривата на обучение.

Ако тестер преминава от тестване, базирано на GUI, тогава тестерът ще трябва да промени подхода на тестване и да научи новия инструмент или рамка, както е необходимо. E.g. Ако API приема заявките във формат JSON, тогава тестерът ще трябва да научи какво е JSON, за да започне да създава тестовете.

Казус

Задача

За да разшири съществуващото приложение, една компания искаше да предложи продукт в API, както и стандартно GUI приложение. Екипът на QA беше помолен да предостави план за покритие на теста, за да се гарантира, че те са готови да приемат API тестовете извън редовните тестове, базирани на GUI.

Предизвикателства

• Нито един от останалите софтуерни продукти няма архитектура, базирана на API, следователно, за да се приспособи тестването около тази задача, екипът трябва да установи процеса на тестване на API от нулата. Това означава, че инструментите трябва да бъдат оценени, включени в списъка, финализирани и екипът трябва да бъде обучен за тестовете.
• Не е отделен допълнителен бюджет за придобиване и прилагане на инструмента. Това означава, че екипът е трябвало да избере безплатен инструмент за тестване на API с отворен код и някой от съществуващия екип трябва да бъде обучен да поеме тази задача.
• Нямаше изисквания за API полета и проверка на данните. Изискванията бяха „трябва да работи по същия начин като съответното приложение на GUI“.

Подходът, следван от екипа за намаляване на рисковете и заобикаляне на предизвикателствата

• Екипът за QA работи с екипа по проекта, за да идентифицира следните изисквания:
  • Тип на API (REST / SOAP): ПОЧИВКА
  • Необходими тестове (функционални, натоварване, сигурност): Само функционално тестване
  • Необходими автоматизирани тестове (Да / Не): Задължително за сега
  • Доклади от теста (Да / Не): Задължително
• Екипът за QA направи оценка на инструмента на наличните Инструменти за тестване на API въз основа на задължителните изисквания. Пощальонният API инструмент е финализиран като инструмент по техен избор, тъй като е безплатен и лесен за използване, като по този начин минимизира кривата на обучение и има потенциал за автоматизиране на тестовете и идва с добри вградени отчети.
• Същият тестер, който е тествал приложението, е бил обучен да използва Postman за създаване на първоначални тестове, като по този начин елиминира всякакви пропуски в познанията за продукта.
• За да се справи с липсващите изисквания, екипът на проекта създаде документация на високо ниво на полето, използвайки Swagger. Това обаче остави известни пропуски по отношение на приемливите формати на данни и това беше взето от екипа на проекта и очакваните формати бяха съгласувани и документирани.

Заключение

Приложенията, базирани на API, придобиха популярност в последно време. Тези приложения са по-мащабируеми в сравнение с традиционните приложения / софтуер и позволяват по-лесна интеграция с другите API или приложения.

Този урок за API тестване обяснява подробно всичко за API тестване, Shift Left Testing, Web Services и Web API. Също така изследвахме разликите между Web Services и Web API с примери.

Във втората част на урока обсъдихме пълния спектър на API тестване, как да въведете API тестване във вашата организация и някои често срещани предизвикателства в този процес заедно с решения за тях.

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

СЛЕДВАЩ урок

Препоръчително четене

• Алфа тестване и бета тестване (Пълно ръководство)
• Функционално тестване срещу нефункционално тестване
• Урок за тестване на използваемост: Пълно ръководство за начало
• Пълно ръководство за тестване за проверка на компилация (BVT тестване)
• Урок за тестване на DevOps: Как DevOps ще повлияе на QA тестването?
• Урок за тестване на достъпността (Пълно ръководство стъпка по стъпка)
• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Какво е тестване на софтуер? 100+ безплатни ръководства за ръчно тестване