api testing tutorial
Tento podrobný návod na testovanie API vysvetľuje všetko o testovaní API, webových službách a o tom, ako zaviesť testovanie API vo vašej organizácii:
Z tohto úvodného tutoriálu získate hlboký prehľad o testovaní API spolu s konceptom testovania ľavou a ľavou stranou a webovými službami.
Koncepty ako Web API, ako funguje API (s príkladom z reálneho sveta) a v čom sa líši od webových služieb, sú dobre vysvetlené na príkladoch v tomto výučbe.
=>POSUNÚŤ NADOLzobraziť celý zoznam 5 podrobných návodov na testovanie rozhrania API pre začiatočníkov
Čo sa dozviete:
- Zoznam výukových programov na testovanie API
- Prehľad tutoriálov v tejto sérii testovania API
- Výukový program pre testovanie API
- Predstavujeme testovanie API vo vašej organizácii
- Záver
Zoznam výukových programov na testovanie API
Výukový program č. 1: Výukový program pre testovanie API: Kompletný sprievodca pre začiatočníkov
Výukový program č. 2: Výukový program pre webové služby: Komponenty, architektúra, typy a príklady
Výukový program č. 3: Najvyšších 35 otázok týkajúcich sa rozhovorov s ASP.Net a webovým API s odpoveďami
Výukový program č. 4: Výukový program POSTMAN: Testovanie API pomocou programu POSTMAN
Výukový program č. 5: Testovanie webových služieb pomocou klienta HTTP Apache
Prehľad tutoriálov v tejto sérii testovania API
Návod | Čo sa naučíte | |
---|---|---|
LoadFocus | Na základe počtu používateľov a typov plánov | * Môže sa použiť na testovanie zaťaženia API - umožňuje spustenie niekoľkých testov na zistenie počtu používateľov, ktoré môže API podporovať. * Jednoduché použitie - umožňuje vykonávanie testov v prehliadači. |
Tutorial_ # 1: | Výukový program pre testovanie API: Kompletný sprievodca pre začiatočníkov Tento podrobný návod na testovanie API vysvetlí všetko o testovaní API a webových službách podrobne a tiež vás naučí, ako zaviesť testovanie API vo vašej organizácii. | |
Tutorial_ # 2: | Výukový program pre webové služby: Komponenty, architektúra, typy a príklady Tento tutoriál o webových službách vysvetľuje architektúru, typy a súčasti webových služieb spolu s dôležitými terminológiami a rozdielmi medzi SOAP a REST. | |
Tutorial_ # 3: | Najvyšších 35 otázok týkajúcich sa rozhovorov s ASP.Net a webovým API s odpoveďami V tomto výučbe môžete preskúmať zoznam najpopulárnejších často kladených otázok o rozhovoroch s rozhraním ASP.Net a Web API s odpoveďami a príkladmi pre začiatočníkov a skúsených odborníkov. | |
Výukový program č. 4: | Výukový program POSTMAN: Testovanie API pomocou programu POSTMAN Tento podrobný návod vysvetlí testovanie API pomocou POSTMANU spolu so základmi POSTMANU, jeho komponentov a vzorových požiadaviek a odpovedí jednoduchým spôsobom pre vaše ľahké pochopenie. | |
Výukový program č. 5: | Testovanie webových služieb pomocou klienta HTTP Apache Tento výukový program API sa týka vykonávania rôznych operácií CRUD na webových službách a testovania webových služieb pomocou klienta HTTP Apache |
Výukový program pre testovanie API
Táto časť vám pomôže získať základné znalosti o webových službách a webovom rozhraní API, ktoré vám zase pomôžu porozumieť hlavným konceptom v nadchádzajúcich tutoriáloch v tejto sérii testov API.
API (Application Programming Interface) je sada všetkých postupov a funkcií, ktoré nám umožňujú vytvoriť aplikáciu pomocou prístupu k údajom alebo vlastnostiam operačného systému alebo platforiem. Testovanie takýchto postupov je známe ako API Testing.
Testovanie posunu doľava
Jedným z dôležitých typov testovania, ktoré sa v súčasnosti vyžaduje v rozhovoroch na testovanie API, je Shift Left Testing. Tento typ testovania sa praktizuje takmer vo všetkých projektoch, ktoré sa riadia agilnou metodikou.
Pred zavedením testovania Shift Left Testovanie softvéru sa dostalo do povedomia až po dokončení kódovania a doručení kódu testerom. Tento postup viedol k tomu, že sa dodržal termín na poslednú chvíľu, a do značnej miery tiež obmedzil kvalitu produktu.
Okrem toho bolo vynaložené úsilie (keď boli chyby nahlásené v poslednej fáze pred výrobou) obrovské, pretože vývojári museli znova prejsť fázou návrhu aj kódovania.
Životný cyklus vývoja softvéru (SDLC) pred testovaním posunu doľava
Tradičný tok SDLC bol: Požiadavka -> Dizajn -> Kódovanie -> Testovanie.
Nevýhody tradičného testovania
- Testovanie je v extrémnej pravici. Pri identifikácii chyby na poslednú chvíľu vznikajú veľké náklady.
- Čas strávený na vyriešenie chyby a jej opätovné vyskúšanie pred jej povýšením na produkciu je obrovský.
Preto sa objavila nová myšlienka posunúť fázu testovania doľava, čo viedlo k testovaniu posunu doľava.
Navrhované čítanie => Testovanie Shift Left: Tajná mantra úspechu softvéru
ako vytvoriť testovací plán pre testovanie softvéru
Fázy testovania ľavého posuvu
Testovanie ľavého posuvu viedlo k úspešnej migrácii z detekcie defektov na prevenciu defektov. Pomohlo to aj rýchlemu zlyhaniu softvéru a odstráneniu všetkých zlyhaní najskôr.
Web API
Všeobecne možno webové rozhranie API definovať ako niečo, čo prevezme požiadavku z klientskeho systému na webový server a odošle späť odpoveď z webového servera na klientsky počítač.
Ako funguje API?
Zoberme si veľmi častý scenár rezervácie letu na www.makemytrip.com, čo je online cestovná služba, ktorá zhromažďuje informácie od viacerých leteckých spoločností. Pri rezervácii letu zadáte informácie ako dátum cesty / dátum návratu, trieda atď. A kliknete na tlačidlo Hľadať.
Zobrazí sa cena viacerých leteckých spoločností a ich dostupnosť. V takom prípade aplikácia interaguje s API viacerých leteckých spoločností a umožňuje tak prístup k údajom leteckej spoločnosti.
Ďalším príkladom je www.trivago.com, ktorý porovnáva a uvádza ceny, dostupnosť atď. Rôznych hotelov z konkrétneho mesta. Táto webová stránka komunikuje s API viacerých hotelov, aby získala prístup do databázy, a uvádza zoznam cien a dostupnosti z ich webových stránok.
Webové API možno teda definovať ako „rozhranie, ktoré uľahčuje komunikáciu medzi klientskym strojom a webovým serverom“.
Webové služby
Webové služby sú (podobne ako webové rozhranie API) služby poskytované z jedného počítača na druhý. Ale hlavným rozdielom, ktorý vzniká medzi API a webovými službami, je to, že webové služby používajú sieť.
Dá sa dosť dobre povedať, že všetky webové služby sú webové rozhrania API, ale všetky webové rozhrania API nie sú webové služby (vysvetlené v druhej časti článku). Webové služby sú teda podmnožinou webového rozhrania API. V nasledujúcom diagrame nájdete ďalšie informácie o webovom rozhraní API a webových službách.
Webové rozhranie API a webové služby
Webové služby vs. webové API
Na uľahčenie komunikácie medzi klientom a serverom sa používajú webové rozhranie API aj webové služby. Zásadný rozdiel nastáva iba v spôsobe ich komunikácie.
Každý z nich vyžaduje orgán žiadosti, ktorý je prijateľný v konkrétnom jazyku, ich odlišnosti v zabezpečení zabezpečeného pripojenia, rýchlosť komunikácie so serverom a spätná reakcia s klientom atď.
Rozdiely medzi webovými službami a webovým rozhraním API sú uvedené nižšie pre vašu informáciu.
Webová služba
- Webové služby všeobecne používajú XML (Extensible Markup Language), čo znamená, že sú bezpečnejšie.
- Webové služby sú bezpečnejšie, pretože webové služby aj rozhrania API poskytujú počas prenosu údajov protokol SSL (Secure Socket Layer), poskytuje však aj WSS (zabezpečenie webových služieb).
- Webová služba je podmnožinou webového rozhrania API. Napríklad, Webové služby sú založené iba na troch štýloch použitia, t. SOAP, REST a XML-RPC.
- Webové služby na svoje fungovanie vždy potrebujú sieť.
- Webové služby podporujú „One Code different applications“. To znamená, že pre rôzne aplikácie je napísaný všeobecnejší kód.
Web API
- Webové rozhranie API zvyčajne používa JSON (JavaScript Object Notation), čo znamená, že webové rozhranie API je rýchlejšie.
- Webové rozhranie API je rýchlejšie, pretože formát JSON je ľahký, na rozdiel od XML.
- Webové rozhrania API sú nadmnožinou webových služieb. Napríklad, Všetky tri štýly webových služieb sú prítomné aj vo webovom rozhraní API, ale okrem toho používajú iné štýly, napríklad JSON - RPC.
- Web API nevyhnutne nevyžaduje na fungovanie sieť.
- Webové rozhranie API môže alebo nemusí podporovať interoperabilitu v závislosti od povahy systému alebo aplikácie.
Predstavujeme testovanie API vo vašej organizácii
V každodennom živote sme všetci tak zvyknutí na interakciu s aplikáciami pomocou rozhraní API, a napriek tomu ani len nepomýšľame na back-end procesy, ktoré riadia základné funkcie.
Napríklad, Zoberme si, že prechádzate produktmi na Amazon.com a vidíte produkt / ponuku, ktorá sa vám naozaj páči a chcete ju zdieľať so svojou sieťou Facebook.
V okamihu, keď kliknete na ikonu Facebook v sekcii zdieľania na stránke a zadáte svoje poverenia účtu Facebook, ktoré chcete zdieľať, interagujete s API, ktoré bezproblémovo prepája web Amazon s Facebookom.
Posun zamerania na testovanie API
Predtým, ako sa dozvieme viac o testovaní API, poďme sa rozprávať o dôvodoch, pre ktoré si aplikácie založené na API v poslednej dobe získali popularitu.
Existuje niekoľko dôvodov, pre ktoré organizácie prechádzajú na produkty a aplikácie založené na API. A niekoľko z nich je uvedených nižšie pre vašu informáciu.
# 1) Aplikácie založené na API sú škálovateľnejšie v porovnaní s tradičnými aplikáciami / softvérom. Rýchlosť vývoja kódu je rýchlejšia a to isté API dokáže obslúžiť viac požiadaviek bez akýchkoľvek zásadných zmien kódu alebo infraštruktúry.
#dva) Vývojové tímy nemusia začať programovať od nuly vždy, keď začnú pracovať na vývoji funkcie alebo aplikácie. API najčastejšie používajú existujúce opakovateľné funkcie, knižnice, uložené procedúry atď., A preto ich tento proces môže celkovo zvýšiť produktivitu.
Napríklad, Ak ste vývojár pracujúci na webe elektronického obchodu a chcete pridať Amazon ako platobný procesor - nemusíte kód písať úplne od začiatku.
Všetko, čo musíte urobiť, je nastaviť integráciu medzi vašim webom a Amazon API pomocou integračných kľúčov a zavolať Amazon API na spracovanie platieb počas platby.
# 3) API umožňujú ľahkú integráciu s ostatnými systémami ako pre podporované samostatné aplikácie, tak aj so softvérovými produktmi založenými na API.
Napríklad „Uvažujme, že chcete poslať zásielku z Toronta do New Yorku. Prejdete do režimu online, navigujete na dobre známu webovú stránku pre nákladnú dopravu alebo logistiku a zadáte požadované informácie.
Po zadaní povinných informácií, keď kliknete na tlačidlo Získať sadzby - na konci servera, sa táto logistická webová stránka môže spájať s niekoľkými API a aplikáciami dopravcu a poskytovateľa služieb, aby získala dynamické sadzby za kombináciu miest od miesta určenia.
Úplné spektrum testovania API
Testovanie API sa neobmedzuje iba na odoslanie požiadavky API a samotnú analýzu odpovede. Je potrebné testovať výkonnosť API pri rôznych zaťaženiach kvôli zraniteľnostiam.
Poďme o tom diskutovať podrobne.
i) Funkčné testovanie
Testovanie funkcií môže byť náročná úloha z dôvodu nedostatku grafického rozhrania.
Pozrime sa, ako prístup funkčného testovania pre API sa líši od aplikácie založenej na GUI a tiež si rozoberieme niekoľko príkladov okolo neho.
do) Najviditeľnejším rozdielom je, že neexistuje žiadne grafické rozhranie, s ktorým by bolo možné pracovať. Testéri, ktorí zvyčajne vykonávajú funkčné testovanie založené na grafickom používateľskom rozhraní, majú o niečo ťažší prechod na testovanie aplikácií bez grafického používateľského rozhrania v porovnaní s niekým, kto ich už pozná.
Spočiatku, ešte predtým, ako začnete testovať API, budete musieť otestovať a overiť samotný proces autentifikácie. Metóda autentifikácie sa bude líšiť od jedného API k druhému API a bude zahŕňať nejaký druh kľúča alebo tokenu na autentifikáciu.
Ak sa nemôžete úspešne pripojiť k API, ďalšie testovanie nemôže pokračovať. Tento proces možno považovať za porovnateľný s autentifikáciou používateľa v štandardných aplikáciách, kde na prihlásenie a používanie aplikácie potrebujete platné poverenia.
b) Testovanie overenia poľa alebo overenie vstupných údajov je počas testovania API veľmi dôležité. Ak bolo k dispozícii skutočné rozhranie založené na formulári (GUI), potom by bolo možné implementovať overenia polí v klientskom rozhraní alebo v zadnom rozhraní, čím sa zabezpečí, že používateľ nebude môcť zadávať neplatné hodnoty polí.
Napríklad, Ak aplikácia vyžaduje, aby formát dátumu bol DD / MM / RRRR, potom môžeme toto overenie použiť na formulári zhromažďujúcom informácie, aby sme sa uistili, že aplikácia prijíma a spracováva platný dátum.
To však nie je rovnaké pre aplikácie API. Musíme sa ubezpečiť, že API je dobre napísané a je schopné vynútiť všetky tieto validácie, rozlišovať medzi platnými a neplatnými údajmi a vrátiť koncovému používateľovi prostredníctvom odpovede stavový kód a chybové hlásenie o overení.
c) Testovanie správnosti odpovedí z API na platnú a neplatnú odpoveď je skutočne kľúčové. Ak sa ako odpoveď z testovacieho rozhrania API prijme stavový kód 200 (to znamená v poriadku), ale ak text odpovede hovorí, že došlo k chybe, jedná sa o chybu.
Ak je navyše samotné chybové hlásenie nesprávne, môže to byť pre koncového zákazníka, ktorý sa pokúša integrovať s týmto rozhraním API, veľmi zavádzajúce.
Na snímke obrazovky nižšie používateľ zadal neplatnú hmotnosť, ktorá je viac ako prijateľných 2 677 kg. Rozhranie API reaguje kódom chybového stavu a chybovým hlásením. Chybové hlásenie však nesprávne uvádza jednotky hmotnosti ako libry namiesto KG. Jedná sa o vadu, ktorá môže koncového zákazníka zmiasť.
ii) Testovanie zaťaženia a výkonu
Rozhrania API majú byť dizajnovo škálovateľné.
To zase robí záťaž a Testovanie výkonu nevyhnutné, najmä ak sa očakáva, že navrhovaný systém obslúži tisíce požiadaviek za minútu alebo hodinu, v závislosti od požiadavky. Rutinné vykonávanie testov zaťaženia a výkonu na API môže pomôcť pri porovnávaní výkonu, špičkových zaťažení a bodu zlomu.
Tieto údaje sú užitočné pri plánovaní rozšírenia aplikácie. Získanie týchto informácií pomôže podporiť rozhodnutia a plánovanie, najmä ak organizácia plánuje pridať ďalších zákazníkov, čo by znamenalo viac prichádzajúcich požiadaviek.
Napríklad , povedzme, že na základe poskytnutých požiadaviek vieme, že navrhnuté API musí obsluhovať najmenej 500 požiadaviek za hodinu a udržiavať priemerný čas odozvy menej ako 0,01 sekundy.
Na základe našich testov zaťaženia a výkonu sme zistili, že pokiaľ API prijme menej ako 500 požiadaviek za hodinu, je schopné udržiavať SLA na priemernú dobu odozvy. Ak však prijme ďalších 200 požiadaviek, priemerný čas odozvy sa zvýši a bod zlomu sa dosiahne, keď prichádzajúca požiadavka prekročí 1 200 za hodinu.
Spravidla sa ukazuje, že počas počiatočných fáz návrhu sa často kladie dôraz na funkčné aspekty API. Postupom času začne produkt podporovať viac živých klientov, to je testovanie výkonu API a testovanie záťaže bežnejším spôsobom.
(iii) Testovanie bezpečnosti
Aplikačné programové rozhrania alebo rozhrania API sú zraniteľné a sú najjednoduchším prístupovým bodom pre škodlivých hackerov, ktorí chcú prístup k údajom alebo kontrolu nad aplikáciou.
To môže viesť každú spoločnosť k právnym problémom, kde z dôvodu narušenia bezpečnosti môžu mať nechcené osoby alebo organizácie prístup k údajom klienta prostredníctvom ctihodného rozhrania API.
Testovanie bezpečnosti je špecializovaná oblasť testovania a mali by s ňou zaobchádzať špecialisti. Zdroje na testovanie bezpečnosti môžu byť od organizácie alebo od nezávislých konzultantov.
Prečítajte si tiež = >> Čo je to Paktové testovanie zmlúv
Ako zaviesť testovanie API vo vašej organizácii
Proces zavedenia testovania API v akejkoľvek organizácii je podobný procesu použitému na implementáciu alebo zavedenie ľubovoľného iného testovacieho nástroja a rámca.
V nasledujúcej tabuľke sú zhrnuté hlavné kroky spolu s očakávaným výsledkom každého kroku.
Fáza | Krok | Očakávaný výsledok |
---|---|---|
Výber nástroja | Zhromaždite požiadavky a identifikujte obmedzenia | Pochopte požiadavky na prieskum trhu pre vhodný testovací nástroj API. Napr. Aký druh API sa testuje - SOAP alebo REST? Potrebujeme na túto úlohu najať testera alebo vyškoliť existujúceho testera? Aký druh testov sa bude vykonávať - funkčné, výkonnostné testy atď. Aký je rozpočet na implementáciu? |
Vyhodnoťte dostupné nástroje | Porovnajte dostupné nástroje a užší zoznam 1 alebo 2 nástrojov, ktoré najlepšie vyhovujú požiadavkám. | |
Dôkaz o koncepcii | Implementujte podmnožinu testov pomocou nástroja z užšieho výberu. Prezentujte zistenia zainteresovaným stranám. Dokončiť nástroj, ktorý sa má implementovať. | |
Implementácia | Začíname | V závislosti od vášho výberu nástroja by ste museli inštalovať požadovaný nástroj na počítač, virtuálny počítač alebo server. Ak je vybraným nástrojom predplatné, vytvorte požadované tímové účty. Ak je to potrebné, trénujte tím. |
Choď | Vytvorte testy Vykonajte testy Nahlásiť chyby |
Bežné výzvy a spôsoby, ako ich zmierniť
Poďme diskutovať o niekoľkých bežných výzvach, ktorým tímy QA čelia pri pokuse o implementáciu testovacieho rámca API v organizácii.
# 1) Výber správneho nástroja
Výber správneho nástroja pre danú prácu je najbežnejšou výzvou. Na trhu je k dispozícii niekoľko testovacích nástrojov API.
Zavádzanie najnovšieho a najdrahšieho nástroja dostupného na trhu sa môže javiť ako veľmi lákavé. Ak však neprinesie požadované výsledky, potom je tento nástroj nepoužiteľný.
Preto si vždy vyberte nástroj, ktorý reaguje na požiadavky, ktoré musíte mať, na základe vašich organizačných potrieb.
Tu je ukážka hodnotiacej matice nástrojov pre dostupné nástroje API
Nástroj | Ceny | Poznámky |
---|---|---|
Mydlové rozhranie | K dispozícii je bezplatná verzia pre SoapUI Open Source (funkčné testovanie) | * REST, SOAP a ďalšie populárne protokoly API a IoT. * Zahrnuté vo verzii zadarmo Ad hoc testovanie SOAP a REST Zadanie správy Vytvorenie testu drag & drop Testovacie denníky Vyskúšajte konfiguráciu Test z nahrávok Vykazovanie jednotiek. * Kompletný zoznam funkcií nájdete na ich webových stránkach. |
Poštár | K dispozícii je bezplatná aplikácia Postman | * Najčastejšie používané pre REST. * Funkcie nájdete na ich webových stránkach. |
Parasoft | Je to platený nástroj, ktorý vyžaduje zakúpenie licencie a potom vyžaduje inštaláciu, aby bolo možné nástroj použiť. | * Komplexné testovanie API: funkčné, záťažové, bezpečnostné testovanie, správa testovacích dát |
vREST | Na základe počtu používateľov | * Automatické testovanie REST API. * Nahrávajte a prehrávajte. * Odstraňuje závislosť z frontendu a backendu pomocou falošných rozhraní API. * Účinná validácia odpovede. * Funguje na testovacie aplikácie nasadené na serveri localhost / intranet / internet. * JIRA Integration, Jenkins Integration Imports from Swagger, Postman. |
HttpMaster | Express Edition: Stiahnutie zadarmo Profesionálna verzia: Podľa počtu používateľov | * Pomáha pri testovaní webových stránok aj pri testovaní API. * Medzi ďalšie funkcie patrí schopnosť definovať globálne parametre, poskytuje používateľovi možnosť vytvárať kontroly na overenie odozvy údajov pomocou veľkej množiny typov overenia, ktoré podporuje. |
Runscope | Na základe počtu používateľov a typov plánov | * Na monitorovanie a testovanie rozhraní API. * Môže sa použiť na overenie údajov, aby sa zabezpečilo vrátenie správnych údajov. * Obsahuje funkciu sledovania a upozorňovania v prípade zlyhania akejkoľvek transakcie API (ak vaša aplikácia vyžaduje overenie platby, potom sa tento nástroj môže ukázať ako dobrá voľba). |
PingAPI | Zadarmo pre 1 projekt (1 000 požiadaviek) | * Prospešné pre automatické testovanie a monitorovanie API. |
# 2) Chýbajúce špecifikácie testu
Ako testeri potrebujeme poznať očakávané výsledky, aby sme mohli aplikáciu efektívne otestovať. Toto je často výzva, pretože na to, aby sme poznali očakávané výsledky, musíme mať jasné presné požiadavky, čo však nie je tento prípad.
Napríklad , zvážte nasledujúce požiadavky:
„Aplikácia by mala akceptovať iba platný dátum dodania a všetky neplatné požiadavky by mali byť odmietnuté.“
V týchto požiadavkách chýbajú kľúčové podrobnosti a sú veľmi nejednoznačné - ako definujeme platný dátum? A čo formát? Vraciame nejaké správy o odmietnutí koncovému používateľovi atď.?
Príklad jasných požiadaviek:
1) Aplikácia by mala akceptovať iba platný dátum dodania.
Dátum dodania sa považuje za platný, ak je
- Nie v minulosti
- Väčšie alebo rovnaké ako dnešný dátum
- Je v prijateľnom formáte: DD / MM / RRRR
dva)
Kód stavu odpovede = 200
Správa: OK
3) Dátum dodania, ktorý nespĺňa vyššie uvedené kritériá, by sa mal považovať za neplatný. Ak zákazník pošle neplatný dátum dodania, musí odpovedať nasledujúcimi chybovými správami:
3.1
jednoduchý binárny strom c ++
Kód stavu odpovede NIE je 200
Chyba: Zadaný dátum dodania je neplatný; uistite sa, že je dátum vo formáte DD / MM / RRRR
3.2
Kód stavu odpovede NIE je 200
Chyba: Zadaný dátum dodania je minulosťou
# 3) Krivka učenia
Ako už bolo spomenuté, prístup k testovaniu API je odlišný v porovnaní s prístupom použitým pri testovaní aplikácií založených na GUI.
Ak hľadáte interných alebo konzultantov na testovanie API, potom môže byť krivka učenia testovacieho prístupu API alebo testovacieho nástroja API minimálna. Akákoľvek krivka učenia, v tomto prípade, by bola spojená so získaním znalostí o produkte alebo aplikácii.
Ak je existujúcemu členovi tímu pridelený naučiť sa testovať API, potom môže byť krivka učenia v závislosti od zvoleného nástroja stredná až vysoká spolu so zmenou prístupu k testovaniu. Krivka učenia pre samotný produkt alebo aplikáciu môže byť nízka až stredná v závislosti od toho, či tento tester danú aplikáciu predtým testoval alebo nie.
# 4) Existujúca sada zručností
Toto priamo súvisí s predchádzajúcim bodom o krivke učenia.
Ak tester prechádzal z testovania založeného na GUI, potom by tester musel zmeniť prístup k testovaniu a podľa potreby sa naučiť nový nástroj alebo rámec. Napr. Ak API prijme požiadavky vo formáte JSON, potom bude musieť tester zistiť, čo je JSON, aby mohol začať vytvárať testy.
Prípadová štúdia
Úloha
S cieľom rozšíriť existujúcu aplikáciu chcela spoločnosť ponúknuť produkt v API, ako aj štandardnú aplikáciu GUI. Tím QA bol požiadaný, aby predložil plán pokrytia testov, aby sa zabezpečilo, že sú pripravení vyhovieť testovaniu API nad rámec bežných testov založených na grafickom používateľskom rozhraní.
Výzvy
- Žiadny z ďalších softvérových produktov nemal architektúru založenú na API, a preto musí tím pre testovanie okolo tejto úlohy vytvoriť testovací proces API od nuly. To znamená, že nástroje mali byť vyhodnotené, vybrané do užšieho výberu, finalizované a tím musel byť vyškolený pre testy.
- Na obstaranie a implementáciu nástroja nebol pridelený žiadny ďalší rozpočet. To znamená, že tím si musel zvoliť bezplatný alebo otvorený nástroj na testovanie API a niekto z existujúceho tímu musel byť na túto úlohu vyškolený.
- Neexistovali žiadne požiadavky na polia API a overenie údajov. Požiadavky boli „mali by fungovať rovnako ako zodpovedajúca aplikácia GUI“.
Prístup, ktorý tím sleduje, pri zmierňovaní rizík a obchádzaní výziev
- Tím QA pracoval s projektovým tímom na identifikácii nasledujúcich požiadaviek:
- Typ API (REST / SOAP): ODDYCH
- Požadované testy (funkčné, zaťaženie, bezpečnosť): Iba funkčné testovanie
- Vyžadujú sa automatické testy (áno / nie): Zatiaľ voliteľné
- Protokoly o teste (áno / nie): Požadovaný
- Tím QA vykonal hodnotenie nástrojov na základe dostupných informácií Nástroje na testovanie API na základe nevyhnutných požiadaviek. Postman API Tool bol finalizovaný ako nástroj podľa ich výberu, pretože bol bezplatný a ľahko použiteľný tiež, čím sa minimalizovala krivka učenia a mal potenciál automatizovať testy. Prišiel s dobrými vstavanými správami.
- Rovnaký tester, ktorý testoval aplikáciu, bol vyškolený na používanie aplikácie Postman na vytváranie počiatočných testov, čím sa eliminujú medzery v znalostiach o produkte.
- Aby sa vyrovnal s chýbajúcimi požiadavkami, projektový tím vytvoril dokumentáciu na vysokej úrovni pomocou programu Swagger. To však zanechalo určité medzery, pokiaľ ide o prijateľné dátové formáty, a tento problém bol vyriešený projektovým tímom a boli dohodnuté a zdokumentované očakávané formáty.
Záver
Aplikácie založené na API si v poslednej dobe získali popularitu. Tieto aplikácie sú škálovateľnejšie v porovnaní s tradičnými aplikáciami / softvérom a umožňujú ľahšiu integráciu s ostatnými API alebo aplikáciami.
Tento návod na testovanie API podrobne vysvetlil všetko o testovaní API, testovaní posunu vľavo, webových službách a webovom API. Na príkladoch sme tiež preskúmali rozdiely medzi webovými službami a webovým rozhraním API.
V druhej časti tutoriálu sme diskutovali o celom spektre testovania API, o tom, ako predstaviť testovanie API vo vašej organizácii a o niektorých bežných výzvach v tomto procese spolu s ich riešeniami.
V našom pripravovanom výučbe sa dozviete viac o webových službách spolu s príkladmi !!
Odporúčané čítanie
- Alfa testovanie a beta testovanie (kompletný sprievodca)
- Funkčné testovanie vs. Nefunkčné testovanie
- Výukový program pre testovanie použiteľnosti: Kompletná príručka Začíname
- Kompletný sprievodca zostavením Verification Testing (BVT Testing)
- Výukový program pre testovanie DevOps: Ako DevOps ovplyvní testovanie kvality?
- Výukový program pre testovanie prístupnosti (Kompletný sprievodca krok za krokom)
- Najlepšie nástroje na testovanie softvéru 2021 [QA Test Automation Tools]
- Čo je to testovanie softvéru? 100+ návodov na ručné testovanie zadarmo