• Листа на упатства за тестирање API
• Преглед на упатства во оваа серија за тестирање API
  • • (ii) Тестирање на оптоварување и перформанси
  • Како да воведете API тестирање во вашата организација
  • Вообичаени предизвици и начини за нивно ублажување
    • #1) Избор на вистинската алатка
    • #2) Недостасуваат спецификации за тестот
    • #3) Крива на учење
    • #4) Постоечки сет на вештини
  • Студија на случај
• Заклучок
• Упатство за тестирање на API
  • Shift Left Testing
  • Животен циклус на развој на софтвер (SDLC) Пред Shift Left Testing
  • Фази на тестирање на лево поместување
  • Web API
  • Како функционира API?
  • Веб-услуги
  • Web Services vs Web API
• Воведување на тестирање API во вашата организација
  • Фокусирајте го „Преместување“ на тестирање на API
  • Целосен спектар на тестирање на API
    • (i) Функционално тестирање

Овој длабински упатство за тестирање на API објаснува сè за тестирањето на API, веб-услугите и како да се воведе тестирање API во вашата организација:

Стекнете длабок увид во тестирањето API заедно со концептот за тестирање и веб-услуги од поместување на лево од овој воведен туторијал.

Концептите како Web API, како функционира API (со пример од реалниот свет) и како се разликува од веб-услугите се добро објаснети со примери во ова упатство.

Листа на упатства за тестирање API

Упатство #1: Упатство за тестирање API: Целосен водич за почетници

Упатство #2: Упатство за веб-услуги: компоненти, архитектура, типови и засилувач; Примери

Упатство #3: Топ 35 прашања за интервју на ASP.Net и веб API со одговори

Упатство #4: Упатство за POSTMAN: Тестирање на API Користење на POSTMAN

Упатство #5: Тестирање на веб-услуги со користење на клиентот на Apache HTTP

Преглед на упатства во оваа серија за тестирање API

Упатство #	Што ќе научите
Упатство_#1:	Упатство за тестирање на API : Целосен водич за почетници Овој туторијал за длабинско тестирање на API детално ќе објасни сè за тестирањето на API и веб-услугите, а исто така ќе ве едуцира како да воведете тестирање API во вашата организација.
Упатство_#2:	Упатство за веб-услуги: компоненти, архитектура, типови и засилувач; Примери Овој вебточноста на одговорите од API за валиден и невалиден одговор е навистина клучна. Ако статусната шифра од 200 (што значи сè е во ред) се прими како одговор од тест API, но ако текстот на одговорот вели дека е наидена грешка, тогаш ова е дефект. Дополнително, ако пораката за грешка самото по себе е неточно, тогаш тоа може да биде многу погрешно за крајниот клиент кој се обидува да се интегрира со овој API. На сликата од екранот подолу, корисникот внел неважечка тежина, што е повеќе од прифатливите 2267 кг. API одговара со код за статус на грешка и порака за грешка. Сепак, пораката за грешка погрешно ги споменува единиците за тежина како lbs наместо KG. Ова е дефект што може да го збуни крајниот клиент. (ii) Тестирање на оптоварување и перформанси API-ите треба да бидат скалабилни според дизајнот. Ова, пак, го прави тестирањето за оптоварување и перформанси од суштинско значење, особено ако се очекува системот што се дизајнира да опслужува илјадници барања во минута или час, во зависност од барањето. Рутинското извршување на тестовите за оптоварување и перформанси на API може да помогне да се одредат перформансите, максималните оптоварувања и точката на прекин. Овие податоци се корисни додека се планира зголемување на апликацијата. Имањето на овие информации на располагање ќе помогне да се поддржат одлуките и планирањето, особено ако организацијата планира да додаде повеќе клиенти, што би значело повеќе дојдовнибарања. Како да воведете API тестирање во вашата организација Процесот за воведување на тестирање API во која било организација е сличен на процесот што се користи за имплементација или воведување на која било друга алатка и рамка за тестирање. Табелата подолу ги сумира главните чекори заедно со очекуваниот исход од секој чекор. Фаза Чекор Очекуван исход Избор на алатка Соберете ги барањата и идентификувајте ги ограничувањата Разберете ги барањата за истражување пазар за соодветна алатка за тестирање API. На пр. Каков вид на API се тестира - САПУН или ОСТАНОК? Дали треба да ангажираме тестер за оваа улога или да тренираме постоечки тестер? Какви тестови ќе се вршат - функционални, тестови за изведба итн. Колкав е буџетот за реализација? Оценете ги достапните алатки Споредете ги достапните алатки и листајте 1 или 2 алатки кои најдобро ги задоволуваат барањата. Доказ за концепт Имплементирајте подгрупа тестови со алатката од потесен избор. Претставете ги наодите на засегнатите страни. Финализирајте ја алатката што треба да се имплементира. Имплементација Започнување Во зависност од изборот на алатката, ќе венее потребата да ја инсталирате потребната алатка на компјутер, виртуелна машина или сервер. Ако алатката која ја избирате е базирана на претплата , создадете потребен тимсметки. Обучете го тимот доколку е потребно. Започнете Креирајте тестови Извршете тестови Пријавете дефекти Вообичаени предизвици и начини за нивно ублажување Да разговараме за некои од вообичаените предизвици на тимовите за ОК се соочуваат додека се обидувате да имплементирате рамка за тестирање на API во организација. #1) Избор на вистинската алатка Изборот на вистинската алатка за работата е најчестиот предизвик. Постојат неколку алатки за тестирање API кои се достапни на пазарот. Можеби изгледа многу привлечно да се имплементира најновата, најскапата алатка достапна на пазарот - но ако не ги донесе посакуваните резултати, тогаш таа алатка не е од корист. Оттука, секогаш избирајте ја алатката што одговара на барањата „задолжителни“ врз основа на вашите организациски потреби. Еве примерок од матрица за евалуација на алатката за достапни алатки за API Алатка Цени Забелешки Сапун UI Достапна е бесплатна верзија за SoapUI со отворен код (функционално тестирање) * REST, SOAP и други популарни API и IoT протоколи. * Вклучено во бесплатната верзија Ад-хок тестирање на САПУН и ПОДОЧИ Потврда за порака Повлечете и засилувајте; Отфрлете го создавањето на тестот Дневници за тестирање Конфигурација на тестот Тест од снимки Известување единица. * Целосната листа на функции може да биде пронајдени во нивнитевеб-локација. Поштар Достапна е бесплатна апликација Поштар * Најкористена за ОДМОР. * Функциите може да се најдат на нивната веб-локација. Parasoft Тоа е платена алатка, бара купување лиценца, а потоа бара инсталација пред да може да се користи алатката. * Сеопфатно тестирање на API: функционално, оптоварување, безбедносно тестирање, управување со податоци од тестот vREST Врз основа на бројот на корисници * Автоматско тестирање REST API. * Снимајте и репродуцирајте. * Ја отстранува зависноста од предниот дел и задниот дел користејќи лажни API. * Моќна валидација на одговорот. * Работи за тест-апликации распоредени на локален хост/интранет/интернет. * Интеграција JIRA, Увоз на интеграција Џенкинс од Swagger, Postman. HttpMaster Express Edition: бесплатно за преземање Професионална верзија: Врз основа на бројот на корисници * Помага при тестирање на веб-локација, како и тестирање на API. * Другите карактеристики вклучуваат можност за дефинирање на глобалните параметри, му овозможува на корисникот можност да креира проверки за валидација на одговорот на податоците со користење на голем сет на типови на валидација што поддржува. Runscope Врз основа на бројот на корисници и типови планови * За следење и тестирање на API. * Може да се користи за валидација на податоците за да се осигура дека се враќаат точните податоци. * Содржи карактеристика наследење и известување во случај на неуспех на трансакцијата на API (ако вашата апликација бара валидација на плаќање, тогаш оваа алатка може да се покаже како добар избор). LoadFocus Врз основа на бројот на корисници и типовите планови * Може да се користи за тестирање на оптоварување на API - овозможува извршување на неколку тестови за да се открие бројот на корисници што може да ги поддржи API. * Едноставен за употреба - овозможува извршување на тестови во прелистувачот. PingAPI Бесплатно за 1 проект (1.000 барања ) * Корисно за автоматско тестирање и следење на API. #2) Недостасуваат спецификации за тестот Како тестери, треба да знаеме очекуваните резултати за ефикасно тестирање на апликацијата. Ова е често предизвик, бидејќи за да ги знаеме очекуваните резултати, треба да имаме јасни прецизни барања – што не е случај. На пример , разгледајте ги барањата дадени подолу: „Апликацијата треба да прифати само важечки датум за испорака и сите неважечки барања треба да се отфрлат“ На овие барања недостасуваат клучни детали и се многу двосмислени - како дефинираме важечки датум? Што е со форматот? Дали враќаме порака за одбивање на крајниот корисник итн.? Пример за јасни барања: 1) Апликацијата треба само прифатете важечки датум за испорака. Датумот на испорака се смета за валиден доколку ее Не е во минатото Поголема или еднаква на денешниот датум Е во прифатлив формат: ДД/ММ/ГГГГГ 2) Шифра на статус на одговор = 200 Порака: OK 3) Датумот на испорака што не ги исполнува горенаведените критериуми треба да се смета за неважечки. Ако клиентот испрати неважечки датум за испорака, тогаш мора да одговори со следнава порака(и) за грешка: 3.1 Шифра за статус на одговор НЕ 200 Грешка: дадениот датум на испорака е неважечки; ве молиме проверете дали датумот е во формат ДД/ММ/ГГГГ 3.2 Шифра за статус на одговор НЕ 200 Грешка: под услов датумот на испорака е во минатото #3) Крива на учење Како што беше споменато претходно, пристапот за тестирање на API е различен во споредба со пристапот што се применува при тестирањето на апликации базирани на GUI. Ако вработуваат специјалисти или домашни или консултанти за API тестирање, тогаш кривата на учење на пристапот за тестирање API или алатката за тестирање API може да биде минимална. Секоја крива на учење, во овој случај, би била поврзана со стекнување знаење за производот или апликацијата. Ако постоечки член на тимот е назначен да научи тестирање API, тогаш во зависност од алатката на избор, кривата на учење може да биде средно до високо, заедно со промена на пристапот за тестирање. Кривата на учење за самиот производ или апликација може да биде ниско-средна во зависност од тоа дали овој тестер тестиралтаа апликација претходно или не. #4) Постоечки сет на вештини Ова директно се поврзува со претходната точка за кривата на учење. Ако тестерот преминувал од Тестирање базирано на GUI, тогаш тестерот ќе треба да го промени пристапот на тестирање и да ја научи новата алатка или рамка по потреба. На пр. Ако API ги прифати барањата во JSON формат, тогаш тестерот ќе треба да дознае што е JSON, за да започне со создавање на тестовите. Студија на случај Задача Со цел да се зголеми постоечката апликација, една компанија сакаше да понуди производ во API, како и стандардна GUI апликација. Од тимот за QA беше побарано да обезбеди план за покривање на тестот за да се осигура дека тие се подготвени да примат API тестирање надвор од редовните тестови базирани на GUI. Предизвици Никој од другите софтверски производи имаа архитектура базирана на API, па оттука за да се приспособат тестирањата околу оваа задача, тимот треба да го воспостави процесот на тестирање API од нула. Ова значи дека алатките требаше да се евалуираат, да се стават во потесен избор, да се финализираат и тимот да се обучи за тестовите. Немаше дополнителен буџет за набавка и имплементација на алатката. Ова значи дека тимот мораше да избере бесплатна или со отворен код алатка за тестирање API и некој од постоечкиот тим мораше да биде обучен да ја преземе оваа задача. Немаше барања за полиња и податоци за APIвалидација. Барањата беа „да работи исто како и соодветната GUI апликација“. Пристапот што го следи тимот за да се ублажат ризиците и да се работи околу предизвиците Тимот за QA работеше со проектниот тим за да ги идентификува следните барања: Тип на API (REST/SOAP): REST Потребни тестови (Функционално, Оптоварување, безбедност): Само функционално тестирање Потребни се автоматизирани тестови (Да/Не): Факултативно засега Извештаи за тестирање (Да/Не ): Потребно Тимот за QA направи евалуација на алатките на достапните алатки за тестирање на API врз основа на задолжителните барања. Postman API Tool беше финализиран како алатка по нивен избор бидејќи беше бесплатна и лесна за користење, со што се минимизираше кривата на учење и имаше потенцијал да ги автоматизира тестовите и дојде со добри вградени извештаи. Истиот тестер кој ја тестираше апликацијата беше обучен да користи Postman за да создаде првични тестови, со што ќе ги елиминира празнините во знаењето за производот. За да се справи со барањата што недостасуваат, проектниот тим ја изгради документацијата на теренско ниво на високо ниво користејќи Swagger . Сепак, ова остави некои празнини во однос на прифатливите формати на податоци и ова беше преземено со проектниот тим и очекуваните формати беа договорени и документирани. Заклучок Апликациите базирани на API имаат стекна популарност во последно време. Овие апликации се повеќескалабилни во споредба со традиционалните апликации/софтвер и овозможуваат полесна интеграција со другите API или апликации. Овој туторијал за тестирање на API детално објасни сè за тестирање на API, тестирање Shift лево, веб-услуги и веб API. Исто така, ги истраживме разликите помеѓу Web Services и Web API со примери. Во вториот дел од упатството, разговаравме за целиот спектар на тестирање API, како да воведете API тестирање во вашата организација и некои вообичаени предизвици во овој процес заедно со решенија за нив. Погледнете го нашиот претстоен туторијал за да дознаете повеќе за веб-услугите заедно со примери!! СЛЕДНО Упатство Упатството за услуги објаснува Архитектура, типови и засилувач; Компоненти на веб-услуги заедно со важни терминологии и разлики помеѓу SOAP и REST.
Упатство_#3:	Топ 35 прашања за интервју за ASP.Net и Web API со одговори Можете да ја истражите листата на најпопуларните најчесто поставувани прашања за интервју за ASP.Net и Web API со одговори & примери за почетници и искусни професионалци во ова упатство.
Упатство_#4:	Упатство за поштари: API тестирање со користење POSTMAN Овој туторијал чекор по чекор ќе го објасни тестирањето на API со користење на POSTMAN заедно со основите на POSTMAN, неговите компоненти и барањето за примероци & засилувач; Одговорете со едноставни зборови за ваше лесно разбирање.
Упатство_#5:	Тестирање на веб-услуги со користење на клиентот Apache HTTP Овој упатство за API се однесува на извршување на различни операции CRUD на веб-услуги и тестирање на веб-услуги со користење на Apache HTTP Client

Упатство за тестирање на API

Овој дел ќе ви помогне да добиете основно разбирање за веб-услугите и веб API-то, што, пак, ќе биде корисно за разбирање на главните концепти во претстојните упатства во оваа серија за тестирање на API.

API ( Програмски интерфејс за апликации) е збир од сите процедури и функции кои ни овозможуваат да создадеме апликација со пристап до податоците или карактеристиките наоперативен систем или платформи. Тестирањето на таквите постапки е познато како API тестирање.

Shift Left Testing

Еден од важните типови на тестирање што се поставува во денешно време во интервјуата за тестирање на API е Тестирањето со Shift Left. Овој тип на тестирање се практикува во скоро сите проекти кои следат Агилна методологија.

Пред да се воведе Shift Left Testing, тестирањето на софтверот се појави само откако кодирањето беше завршено и кодот беше доставен до тестерите. Оваа практика доведе до гужва во последен момент за запазување на рокот и во голема мера го попречи квалитетот на производот.

Покрај тоа, направените напори (кога беа пријавени дефекти во последната фаза пред производството) беа огромен бидејќи програмерите мораа повторно да поминат низ фазата на дизајнирање и кодирање.

Животен циклус на развој на софтвер (SDLC) Пред Shift Left Testing

Традиционалниот тек на SDLC беше: Потребно - > Дизајн –> Кодирање –> Тестирање.

Недостатоци на традиционалното тестирање

• Тестирањето е екстремно десно. Многу трошоци се прават кога ќе се идентификува грешка во последен момент.
• Потрошеното време за решавање на бубачката и повторно тестирање пред да се промовира во производство е огромно.

Оттука, се појави нова идеја за да се префрли фазата на тестирање налево, што на тој начин доведе до тестирање Shift Left.

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

Фази на тестирање на лево поместување

Тестирањето на лево поместување доведе до успешна миграција од откривање дефекти во спречување дефекти. Исто така, му помогна на софтверот да пропадне брзо и најрано да ги поправи сите неуспеси.

Web API

Во општа смисла, Web API може да се дефинира како нешто што го зема барањето од клиентот систем на веб-сервер и го испраќа одговорот од веб-серверот до машината со клиентот.

Како функционира API?

Да земеме многу вообичаено сценарио за резервирање лет на www.makemytrip.com, што е онлајн патувачка услуга која собира информации од повеќе авиокомпании. Кога одите на резервација на летот, внесувате информации како датум на патување/датум на враќање, класа, итн. и кликнете на пребарување.

Ова ќе ви ја покаже цената на повеќе авиокомпании и нивната достапност. Во овој случај, апликацијата е во интеракција со API на повеќе авиокомпании и на тој начин дава пристап до податоците на авиокомпанијата.

Друг пример е www.trivago.com кој ги споредува и наведува цените, достапноста итн. на различни хотели од одреден град. Оваа веб-локација комуницира со API на повеќе хотели за пристап до базата на податоци и ги наведува цените и достапноста од нивната веб-локација.

Така, Web API може да се дефинира како „интерфејс што ја олеснува комуникацијата помеѓу клиентската машина и навеб-сервер“.

Веб-услуги

Веб-услугите се (како Web API) услугите што служат од една машина до друга. Но, главната разлика што се појавува помеѓу API и веб-услугите е тоа што веб-услугите користат мрежа.

Можеме безбедно да се каже дека сите веб-услуги се веб-API-и, но сите веб-API-а не се веб-услуги (објаснето во последниот дел од статијата). Така, веб-услугите се подмножество на Web API. Погледнете го дијаграмот подолу за да дознаете повеќе за Web API и Web Services.

Web API vs Web Services

Web Services vs Web API

И Web API и Web Services се користат за да се олесни комуникацијата помеѓу клиентот и серверот. Главната разлика доаѓа само во начинот на кој тие комуницираат.

Секој од нив бара тело за барање кое е прифатливо на одреден јазик, нивните разлики во обезбедувањето безбедна врска, нивната брзина на комуникација со серверот и одговорот назад на клиентот, итн.

Разлики помеѓу веб-услугите и веб-аПИ-то е наведено подолу за вашата референца.

Веб-услуга

• Веб-услугите обично користат XML (Extensible Markup Language), што значи дека се побезбедни.
• Веб-услугите се побезбедни бидејќи и веб-услугите и API-те обезбедуваат SSL (Secure Socket Layer) за време на преносот на податоци , но обезбедува и WSS (Безбедност на веб-услугите).
• Веб-услугата е подмножество на Web API. На пример, Веб-услугите се засноваат само на три стила на употреба, т.е. SOAP, REST и XML-RPC.
• Веб-услугите секогаш имаат потреба од мрежа за да работат.
• Веб-услугите поддржуваат „Еден код различни апликации“. Ова значи дека погенерички код е напишан на различни апликации.

Web API

• Web API обично користи JSON (JavaScript Object Notation), што значи дека Web API е побрз.
• Web API е побрз бидејќи JSON е лесен, за разлика од XML.
• Web API се супермножество на веб-услугите. На пример, Сите три стила на веб-услуги се присутни и во Web API, но освен тоа, тој користи други стилови како JSON – RPC.
• Web API не мора да бара мрежа за работа.
• Web API може или не поддржува интероперабилност во зависност од природата на системот или апликацијата.

Воведување на тестирање API во вашата организација

Во нашиот секојдневен живот, сите ние сме толку навикнати да комуницираме со апликациите со API, а сепак не ни размислуваме за задни процеси што ја водат основната функционалност.

На пример , Дозволете ни да сметаме дека ги прелистувате производите на Amazon.com и гледате производ/договор што навистина ви се допаѓа и сакате да го споделите со вашата мрежа на Facebook.

Во моментот кога ќе кликнете на иконата на Facebook во делот за споделување на страницата и внесете ја вашатаИнгеренциите на сметката на Facebook што треба да ги споделите, комуницирате со API што беспрекорно ја поврзува веб-локацијата на Amazon со Facebook.

Фокусирајте го „Преместување“ на тестирање на API

Пред да разговарате повеќе за тестирањето API, ајде да разговараме за причините за кои апликациите базирани на API се здобија со популарност во последно време.

Постојат неколку причини поради кои организациите преминуваат кон производи и апликации базирани на API. А неколку од нив се наведени подолу за ваша референца.

#1) Апликациите базирани на API се поскалабилни во споредба со традиционалните апликации/софтвер. Стапката на развој на кодот е побрза и истото API може да опслужува повеќе барања без некои поголеми кодови или инфраструктурни промени.

#2) Развојните тимови не треба да започнуваат со кодирање од нула секој време кога ќе почнат да работат на развој на функција или апликација. API-ите најчесто ги користат постојните, повторливи функции, библиотеки, складирани процедури итн. и оттука овој процес може да ги направи попродуктивни во целина.

На пример, Ако сте програмер кој работи на веб-локација за е-трговија и сакате да го додадете Амазон како процесор за плаќање - тогаш не мора да го пишувате кодот од нула.

Сè што треба да направите е да поставите интеграција помеѓу вашата веб-локација и АПИ на Amazon користејќи Клучеви за интеграција и повикајте го Amazon API за обработка на плаќањата за време на наплатата.

#3) API-ите дозволуваатлесна интеграција со другите системи и за поддржани самостојни апликации како и со софтверски производи базирани на API.

На пример , Дозволете ни да размислиме дека сакате да испратите пратка од Торонто до Њујорк . Одите онлајн, одите до добро позната веб-локација за товари или логистика и ги внесувате потребните информации.

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

Целосен спектар на тестирање на API

Тестирањето на API не е ограничено на испраќање барање на API и анализа на одговорот само за точност. АПИ треба да се тестираат за нивните перформанси под различни оптоварувања за пропусти.

Да разговараме за ова детално.

(i) Функционално тестирање

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

Ајде да видиме како пристапот за функционално тестирање за API се разликува од апликацијата базирана на GUI и ќе разговараме и за некои примери околу него.

а) Најочигледната разлика е во тоа што нема GUI за интеракција. Тестерите кои вообичаено прават функционално тестирање базирано на GUI, им е малку потешко да преминат во тестирање на апликации без GUI во споредба сонекој кој веќе е запознаен со него.

Првично, дури и пред да започнете со тестирање на API, ќе треба да го тестирате и потврдите самиот процес на автентикација. Методот за автентикација ќе варира од едно API до друго API и ќе вклучува некој вид клуч или токен за автентикација.

Ако не можете успешно да се поврзете со API, тогаш понатамошното тестирање не може да продолжи. Овој процес може да се смета за споредлив со автентикацијата на корисникот во стандардните апликации каде што ви требаат валидни ингеренции за да се најавите и да ја користите апликацијата.

b) Потврдувањата на полињата за тестирање или валидацијата на влезните податоци се многу важни за време на тестирање на API. Ако е достапен вистински интерфејс базиран на форма (GUI), тогаш валидациите на полето може да се имплементираат во предниот или задниот дел, со што ќе се осигури дека на корисникот не му е дозволено да внесува неважечки вредности на полињата.

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

Ова, сепак, не е исто за API апликациите. Треба да се погрижиме API-то да е добро напишано и да може да ги спроведе сите овие валидации, да прави разлика помеѓу валидни и неважечки податоци и да ја врати статусната шифра и пораката за грешка за валидација на крајниот корисник преку одговор.

в) Тестирање на