API Testing Tutorial: popoln vodnik za začetnike

Seznam učnih gradiv za testiranje API
Pregled učnih gradiv v tej seriji testiranja API
API Testiranje Tutorial
Uvedba testiranja API v vaši organizaciji
Zaključek

Ta poglobljena vadnica za testiranje API pojasnjuje vse o testiranju API, spletnih storitvah in kako uvesti testiranje API v vaši organizaciji:

V tem uvodnem učbeniku boste dobili poglobljen vpogled v testiranje API, koncept testiranja s premikom v levo in spletne storitve.

Pojmi, kot so spletni API, kako API deluje (s primerom iz resničnega sveta) in kako se razlikuje od spletnih storitev, so dobro razloženi s primeri v tem učbeniku.

Seznam učnih gradiv za testiranje API

Učni pripomoček št. 1: API Testing Tutorial: popoln vodnik za začetnike

Učni pripomoček št. 2: Spletne storitve: komponente, arhitektura, vrste in primeri

Vadnica #3: Top 35 vprašanj za intervjuje za ASP.Net in Web API z odgovori

Vadnica #4: POSTMAN Tutorial: Testiranje API z uporabo POSTMAN

Vadnica #5: Testiranje spletnih storitev z uporabo odjemalca Apache HTTP

Pregled učnih gradiv v tej seriji testiranja API

Vadnica #	Kaj se boste naučili
Tutorial_#1:	API Testing Tutorial: popoln vodnik za začetnike V tem poglobljenem učbeniku za testiranje API boste podrobno razložili vse o testiranju API in spletnih storitvah ter se naučili, kako uvesti testiranje API v svojo organizacijo.
Tutorial_#2:	Spletne storitve: komponente, arhitektura, vrste in primeri V tem učbeniku o spletnih storitvah so razloženi arhitektura, vrste in komponente spletnih storitev, pomembna terminologija in razlike med SOAP in REST.
Tutorial_#3:	Top 35 vprašanj za intervjuje za ASP.Net in Web API z odgovori V tem priročniku lahko raziščete seznam najbolj priljubljenih najpogosteje zastavljenih vprašanj ASP.Net in Web API Interview Questions z odgovori in primeri za začetnike in izkušene strokovnjake.
Tutorial_#4:	POSTMAN Tutorial: Testiranje API z uporabo POSTMAN Ta korak za korakom bo razložil testiranje API z uporabo POSTMAN-a skupaj z osnovami POSTMAN-a, njegovimi sestavnimi deli in vzorčnimi zahtevami in odgovori v preprostih izrazih za lažje razumevanje.
Tutorial_#5:	Testiranje spletnih storitev z uporabo odjemalca Apache HTTP Ta API Tutorial govori o izvajanju različnih operacij CRUD na spletnih storitvah in testiranju spletnih storitev z uporabo odjemalca Apache HTTP.

API Testiranje Tutorial

To poglavje vam bo pomagalo pri osnovnem razumevanju spletnih storitev in spletnega vmesnika API, kar vam bo v pomoč pri razumevanju glavnih konceptov v naslednjih učnih gradivih v tej seriji Testiranje API.

API (vmesnik za programiranje aplikacij) je skupek vseh postopkov in funkcij, ki nam omogočajo ustvarjanje aplikacije z dostopom do podatkov ali funkcij operacijskega sistema ali platform. Testiranje takšnih postopkov je znano kot testiranje API.

Preizkušanje premik v levo

Ena od pomembnih vrst testiranja, ki se danes zahteva na razgovorih za testiranje API, je testiranje s premikom v levo. Ta vrsta testiranja se izvaja v skoraj vseh projektih, ki sledijo agilni metodologiji.

Pred uvedbo testiranja s premikom v levo je bilo testiranje programske opreme uvedeno šele po končanem kodiranju in dostavi kode preizkuševalcem. Ta praksa je povzročila hitenje v zadnjem trenutku, da bi se izpolnil rok, in v veliki meri ovirala kakovost izdelka.

Poleg tega so bili vloženi veliki napori (ko so bile napake prijavljene v zadnji fazi pred produkcijo), saj so morali razvijalci znova opraviti tako fazo načrtovanja kot fazo kodiranja.

Življenjski cikel razvoja programske opreme (SDLC) pred premikom v levo Testiranje

Tradicionalni potek SDLC je bil: zahtevanje -> oblikovanje -> kodiranje -> testiranje.

Slabosti tradicionalnega testiranja

Testiranje je na skrajni desni. Veliko stroškov nastane, če se napaka odkrije v zadnjem trenutku.
Čas, porabljen za odpravo napake in ponovno testiranje pred prenosom v produkcijo, je ogromen.

Zato se je pojavila nova zamisel o premiku faze testiranja na levo, kar je privedlo do testiranja Shift Left Testing.

Predlagano branje => Preizkušanje s premikom v levo: skrivna mantra za uspeh programske opreme

Faze testiranja levega premika

Testiranje z levim premikom je omogočilo uspešen prehod z odkrivanja napak na preprečevanje napak. Prav tako je pomagalo programski opremi, da je hitro odpravljala napake in vse napake odpravila čim prej.

Spletni API

Na splošno lahko spletni vmesnik API opredelimo kot nekaj, kar sprejme zahtevo od odjemalčevega sistema do spletnega strežnika in pošlje odziv od spletnega strežnika nazaj v odjemalčev računalnik.

Kako deluje API?

Vzemimo zelo pogost scenarij rezervacije leta na spletni strani www.makemytrip.com, ki je spletna potovalna storitev, ki združuje informacije več letalskih družb. Ko želite rezervirati let, vnesete podatke, kot so datum potovanja/povratka, razred itd., in kliknete iskanje.

To vam bo prikazalo cene več letalskih prevoznikov in njihovo razpoložljivost. V tem primeru aplikacija sodeluje z vmesniki API več letalskih prevoznikov in tako omogoča dostop do podatkov letalskega prevoznika.

Drug primer je www.trivago.com, ki primerja in navaja cene, razpoložljivost itd. različnih hotelov v določenem mestu. To spletno mesto komunicira z vmesniki API več hotelov za dostop do zbirke podatkov ter navaja cene in razpoložljivost z njihovih spletnih strani.

Tako je spletni vmesnik API mogoče opredeliti kot "vmesnik, ki olajša komunikacijo med odjemalskim računalnikom in spletnim strežnikom".

Spletne storitve

Spletne storitve so (tako kot spletni vmesnik API) storitve, ki služijo od enega računalnika do drugega. Vendar je glavna razlika med vmesnikom API in spletnimi storitvami ta, da spletne storitve uporabljajo omrežje.

Lahko rečemo, da so vse spletne storitve spletni vmesniki API, vendar vsi spletni vmesniki API niso spletne storitve (pojasnjeno v drugem delu članka). Tako so spletne storitve podmnožica spletnih vmesnikov API. Za več informacij o spletnih vmesnikih API in spletnih storitvah si oglejte spodnji diagram.

Spletni vmesnik API proti spletnim storitvam

Spletne storitve v primerjavi s spletnim vmesnikom API

Tako spletni vmesnik API kot spletne storitve se uporabljata za olajšanje komunikacije med odjemalcem in strežnikom. Glavna razlika je le v načinu komunikacije.

Vsak od njih zahteva telo zahteve, ki je sprejemljivo v določenem jeziku, razlikujejo se pri zagotavljanju varne povezave, hitrosti komunikacije s strežnikom in odgovora odjemalcu itd.

Razlike med spletnimi storitvami in spletnim vmesnikom API so navedene v nadaljevanju.

Spletna storitev

Spletne storitve običajno uporabljajo XML (Extensible Markup Language), kar pomeni, da so varnejše.
Spletne storitve so varnejše, saj tako spletne storitve kot vmesniki API med prenosom podatkov zagotavljajo SSL (Secure Socket Layer), poleg tega pa zagotavljajo tudi WSS (Web Services Security).
Spletna storitev je podmnožica spletnega vmesnika API. Na primer, Spletne storitve temeljijo le na treh načinih uporabe, tj. SOAP, REST in XML-RPC.
Spletne storitve za svoje delovanje vedno potrebujejo omrežje.
Spletne storitve podpirajo "eno kodo za različne aplikacije". To pomeni, da je za različne aplikacije napisana bolj splošna koda.

Spletni API

Spletni API običajno uporablja JSON (JavaScript Object Notation), kar pomeni, da je spletni API hitrejši.
Spletni vmesnik API je hitrejši, saj je JSON za razliko od XML lahkoten.
Spletni vmesniki API so nadskupina spletnih storitev. Na primer, Vsi trije slogi spletnih storitev so prisotni tudi v spletnem vmesniku API, vendar poleg tega uporablja tudi druge sloge, kot so JSON - RPC.
Za delovanje spletnega vmesnika API ni nujno potrebno omrežje.
Spletni vmesnik API lahko podpira interoperabilnost ali ne, odvisno od narave sistema ali aplikacije.

Uvedba testiranja API v vaši organizaciji

V vsakdanjem življenju smo vsi navajeni, da z aplikacijami komuniciramo prek vmesnikov API, vendar ne razmišljamo o zalednih procesih, ki poganjajo osnovne funkcije.

Na primer, Recimo, da brskate po izdelkih na spletnem mestu Amazon.com in opazite izdelek/ponudbo, ki vam je zelo všeč, ter jo želite deliti s svojim omrežjem Facebook.

V trenutku, ko kliknete ikono Facebook v razdelku za skupno rabo na strani in vnesete poverilnice računa Facebook za skupno rabo, ste v stiku z vmesnikom API, ki nemoteno povezuje Amazonovo spletno mesto s storitvijo Facebook.

Preusmeritev pozornosti na testiranje API

Preden se podrobneje posvetimo testiranju API, si poglejmo razloge, zaradi katerih so aplikacije, ki temeljijo na API, v zadnjem času postale priljubljene.

Obstaja več razlogov, zaradi katerih organizacije prehajajo na izdelke in aplikacije, ki temeljijo na API. Nekaj jih je navedenih v nadaljevanju.

#1) Aplikacije, ki temeljijo na API, so v primerjavi s tradicionalnimi aplikacijami/programsko opremo bolj razširljive. Hitrost razvoja kode je hitrejša in isti API lahko brez večjih sprememb kode ali infrastrukture obravnava več zahtevkov.

#2) Razvojnim ekipam ni treba začeti kodirati od začetka vsakič, ko začnejo razvijati funkcijo ali aplikacijo. API-ji najpogosteje ponovno uporabljajo obstoječe, ponovljive funkcije, knjižnice, shranjene postopke itd., zato je ta postopek lahko na splošno bolj produktiven.

Na primer, Če ste razvijalec spletnega mesta za e-trgovino in želite dodati Amazon kot plačilni procesor, vam kode ni treba pisati od začetka.

Vse, kar morate storiti, je nastaviti integracijo med svojim spletnim mestom in Amazon API z uporabo integracijskih ključev in poklicati Amazon API za obdelavo plačil med blagajno.

#3) API-ji omogočajo enostavno integracijo z drugimi sistemi tako za podprte samostojne aplikacije kot tudi za programske izdelke, ki temeljijo na API-jih.

Na primer , Recimo, da želite poslati pošiljko iz Toronta v New York. Odpravite se na splet, obiščete dobro znano spletno mesto za tovorni promet ali logistiko in vnesete zahtevane podatke.

Ko po posredovanju obveznih podatkov kliknete gumb Get Rates (Pridobi tarife), se lahko logistično spletno mesto poveže z več API-ji in aplikacijami prevoznikov in ponudnikov storitev ter tako pridobi dinamične tarife za kombinacijo lokacij od izvora do cilja.

Celoten spekter testiranja API

Preizkušanje API ni omejeno le na pošiljanje zahtevka API in analizo odgovora glede pravilnosti. API je treba preizkusiti glede na njihovo delovanje pri različnih obremenitvah in ranljivosti.

Podrobno se o tem pogovorimo.

(i) Funkcionalno preskušanje

Funkcionalno testiranje je lahko zaradi pomanjkanja grafičnega vmesnika zahtevna naloga.

Oglejmo si, kako se pristop k funkcionalnemu testiranju API-jev razlikuje od aplikacij, ki temeljijo na grafičnem vmesniku, in si oglejmo nekaj primerov v zvezi s tem.

a) Najbolj očitna razlika je, da ni grafičnega vmesnika, s katerim bi bilo treba sodelovati. Testerji, ki običajno izvajajo funkcionalno testiranje na podlagi grafičnega vmesnika, imajo nekoliko težji prehod na testiranje aplikacij brez grafičnega vmesnika v primerjavi s tistimi, ki so z njim že seznanjeni.

Na začetku, še preden začnete testirati API, boste morali preizkusiti in preveriti sam postopek avtentikacije. Metoda avtentikacije se razlikuje od API do API in vključuje neke vrste ključ ali žeton za avtentikacijo.

Če se ne morete uspešno povezati z vmesnikom API, se nadaljnje testiranje ne more nadaljevati. Ta postopek je primerljiv z avtentikacijo uporabnika v standardnih aplikacijah, kjer za prijavo in uporabo aplikacije potrebujete veljavne poverilnice.

b) Preizkušanje potrditev polj ali potrditev vhodnih podatkov je zelo pomembno pri preizkušanju vmesnikov API. Če bi bil na voljo dejanski vmesnik na podlagi obrazca (grafični vmesnik), bi lahko potrditve polj izvajali v sprednjem ali zadnjem delu, s čimer bi zagotovili, da uporabnik ne more vnesti neveljavnih vrednosti polj.

Na primer, Če aplikacija potrebuje format datuma DD/MM/YYYYY, lahko to potrditev uporabimo na obrazcu za zbiranje informacij, da zagotovimo, da aplikacija prejme in obdela veljaven datum.

To pa ne velja za aplikacije API. Zagotoviti moramo, da je API dobro napisan in da lahko izvaja vse te validacije, razlikuje med veljavnimi in neveljavnimi podatki ter končnemu uporabniku v odzivu vrne kodo stanja in sporočilo o napaki validacije.

c) Preizkus pravilnosti odgovorov API za veljavne in neveljavne odgovore je ključnega pomena. Če je kot odgovor testnega API prejeta koda stanja 200 (kar pomeni, da je vse v redu), v besedilu odgovora pa piše, da je prišlo do napake, je to napaka.

Poleg tega je lahko sporočilo o napaki napačno in zavajajoče za končno stranko, ki se poskuša povezati s tem vmesnikom API.

Na spodnji sliki zaslona je uporabnik vnesel neveljavno težo, ki je večja od sprejemljivih 2267 kg. API se odzove s kodo stanja napake in sporočilom o napaki. Vendar so v sporočilu o napaki enote teže napačno navedene kot funti namesto kot kilogrami. To je napaka, ki lahko zmoti končno stranko.

(ii) Testiranje obremenitve in zmogljivosti

API-ji so zasnovani tako, da jih je mogoče skalirati.

Zaradi tega je nujno testiranje obremenitve in zmogljivosti, zlasti če se pričakuje, da bo načrtovani sistem obravnaval na tisoče zahtevkov na minuto ali uro, odvisno od zahteve. Redno izvajanje testov obremenitve in zmogljivosti API lahko pomaga primerjati zmogljivost, največje obremenitve in točko preloma.

Ti podatki so uporabni pri načrtovanju razširitve aplikacije. Če so te informacije na voljo, bodo pomagale pri odločitvah in načrtovanju, zlasti če organizacija namerava dodati več strank, kar bi pomenilo več prejetih zahtevkov.

Kako uvesti testiranje API v svojo organizacijo

Postopek uvajanja testiranja API v organizaciji je podoben postopku uvajanja ali uvajanja katerega koli drugega orodja in okvira za testiranje.

V spodnji preglednici so povzeti glavni koraki in pričakovani rezultati vsakega koraka.

Faza	Korak	Pričakovani rezultati
Izbira orodja	Zbiranje zahtev in ugotavljanje omejitev	Razumevanje zahtev za raziskovanje trga za ustrezno orodje za testiranje API. Npr. Kakšno vrsto API testirate - SOAP ali REST? Ali moramo za to vlogo zaposliti testerja ali usposobiti obstoječega testerja? Kakšne vrste testov bodo izvedeni - funkcionalni testi, testi zmogljivosti itd. Kakšen je proračun za izvajanje?
	Ocenite razpoložljiva orodja	Primerjajte razpoložljiva orodja in naredite ožji izbor 1 ali 2 orodij, ki najbolje ustrezajo zahtevam.
	Dokazovanje koncepta	Izvedite podsklop testov z orodjem, ki je v ožjem izboru. Predstavitev ugotovitev zainteresiranim stranem. Dokončanje orodja, ki ga je treba izvesti.
Izvajanje	Začetek	Odvisno od izbranega orodja boste morali zahtevano orodje namestiti v računalnik, virtualni stroj ali strežnik. Če izbrano orodje temelji na naročnini, ustvarite zahtevane račune skupine. po potrebi usposobite ekipo.
	Odpravite se	Ustvarjanje testov Izvedba testov Prijava napak

Najpogostejši izzivi in načini za njihovo ublažitev

Obravnavajmo nekatere pogoste izzive, s katerimi se srečujejo ekipe za zagotavljanje kakovosti, ko poskušajo v organizaciji uvesti okvir za testiranje API.

#1) Izbira pravega orodja

Najpogostejši izziv je izbira ustreznega orodja za delo. Na trgu je na voljo več orodij za testiranje API.

Morda se zdi zelo privlačno uporabiti najnovejše in najdražje orodje, ki je na voljo na trgu, vendar če ne prinaša želenih rezultatov, je to orodje neuporabno.

Zato vedno izberite orodje, ki izpolnjuje "nujne" zahteve glede na vaše organizacijske potrebe.

Tukaj je vzorec matrike za ocenjevanje orodij za razpoložljiva orodja API.

Orodje	Oblikovanje cen	Opombe
Uporabniški vmesnik za milo	Brezplačna različica je na voljo za odprto kodo SoapUI (funkcionalno testiranje)	* REST, SOAP in drugi priljubljeni protokoli API in IoT. * Vključeno v brezplačno različico Ad-hoc testiranje SOAP in REST Potrditev sporočila Drag & amp; Drop Test Creation Testni dnevniki Testna konfiguracija Test iz posnetkov Enota za poročanje. * Celoten seznam funkcij je na voljo na njihovem spletnem mestu.
Poštar	Na voljo je brezplačna aplikacija Postman	* Najbolj uporaben za REST. * Funkcije so na voljo na njihovi spletni strani.
Parasoft	Gre za plačljivo orodje, za katerega je treba kupiti licenco, nato pa ga je treba pred uporabo namestiti.	* Celovito testiranje API: funkcionalno testiranje, testiranje obremenitve, varnostno testiranje, upravljanje testnih podatkov
vREST	Na podlagi števila uporabnikov	* Avtomatizirano testiranje API REST. * Snemanje in predvajanje. * Odpravi odvisnost od frontenda in backenda z uporabo posnemovalnih API-jev. * Zmogljivo potrjevanje odzivov. * Deluje za testne aplikacije, nameščene na lokalnem gostitelju/intranetu/internetu. * Integracija JIRA, Integracija Jenkins Uvozi iz Swagger, Postman.
HttpMaster	Express Edition: Brezplačen prenos Profesionalna različica: na podlagi števila uporabnikov	* Pomaga pri testiranju spletne strani in API. * Druge funkcije vključujejo možnost določanja globalnih parametrov, ki uporabniku omogoča ustvarjanje preverjanj za preverjanje odzivov podatkov z uporabo velikega nabora vrst preverjanja, ki jih podpira.
Runscope	Glede na število uporabnikov in vrste načrtov	* Za spremljanje in testiranje API-jev. * Uporablja se lahko za preverjanje podatkov, da se zagotovi vračanje pravilnih podatkov. * vsebuje funkcijo sledenja in obveščanja v primeru neuspešne transakcije API (če vaša aplikacija zahteva potrditev plačila, se lahko to orodje izkaže za dobro izbiro).
LoadFocus	Glede na število uporabnikov in vrste načrtov	* Uporablja se lahko za testiranje obremenitve API - omogoča izvedbo nekaj testov za ugotavljanje števila uporabnikov, ki jih API lahko podpira. * Enostavna uporaba - omogoča izvajanje testov v brskalniku.
PingAPI	Brezplačno za 1 projekt (1.000 zahtevkov)	* Koristno za avtomatizirano testiranje in spremljanje API.

#2) Manjkajoče testne specifikacije

Kot preizkuševalci moramo za učinkovito preizkušanje aplikacije poznati pričakovane rezultate. To je pogosto izziv, saj moramo za poznavanje pričakovanih rezultatov imeti jasne in natančne zahteve, kar pa ni tako.

Na primer , upoštevajte spodaj navedene zahteve:

"Aplikacija mora sprejeti samo veljaven datum odpreme, vse neveljavne zahteve pa je treba zavrniti."

V teh zahtevah manjkajo ključne podrobnosti in so zelo dvoumne - kako opredeljujemo veljavni datum? Kaj pa format? Ali končnemu uporabniku vrnemo sporočilo o zavrnitvi itd.?

Primer jasnih zahtev:

1) Aplikacija mora sprejeti samo veljaven datum odpreme.

Datum odpreme se šteje za veljavnega, če je

Ne v preteklosti
Večje ali enako današnjemu datumu
Je v sprejemljivi obliki: DD/MM/YYYY

Koda stanja odziva = 200

Sporočilo: OK

3) Datum odpreme, ki ne izpolnjuje zgornjih meril, je treba šteti za neveljaven. Če stranka pošlje neveljaven datum odpreme, se mora odzvati z naslednjim(-i) sporočilom(-i) o napaki:

3.1

Koda stanja odziva NI 200

Napaka: Navedeni datum odpreme je neveljaven; preverite, ali je datum v obliki DD/MM/YYYY

3.2

Koda stanja odziva NI 200

Napaka: Zagotovljeni datum odpreme je v preteklosti

#3) Krivulja učenja

Kot smo že omenili, je pristop k testiranju API drugačen v primerjavi s pristopom k testiranju aplikacij, ki temeljijo na grafičnem vmesniku.

Če za testiranje API najemate strokovnjake v podjetju ali svetovalce, je lahko krivulja učenja pristopa za testiranje API ali orodja za testiranje API minimalna. V tem primeru je krivulja učenja povezana s pridobivanjem znanja o izdelku ali aplikaciji.

Če je za učenje testiranja API zadolžen obstoječi član ekipe, je lahko krivulja učenja, odvisno od izbranega orodja, srednja do visoka, skupaj s spremembo pristopa k testiranju. Krivulja učenja samega izdelka ali aplikacije je lahko nizka do srednja, odvisno od tega, ali je ta tester to aplikacijo že prej testiral ali ne.

#4) Obstoječi nabor znanj in spretnosti

To je neposredno povezano s prejšnjo točko o krivulji učenja.

Če bi tester prešel s testiranja na podlagi grafičnega vmesnika, bi moral spremeniti pristop k testiranju in se po potrebi naučiti novega orodja ali ogrodja. Npr. Če API sprejema zahteve v obliki JSON, se mora preizkuševalec naučiti, kaj je JSON, da lahko začne ustvarjati teste.

Študija primera

Naloga

Podjetje je za razširitev obstoječe aplikacije želelo ponuditi izdelek v vmesniku API in standardni aplikaciji z grafičnim vmesnikom. Ekipa za zagotavljanje kakovosti je bila zaprošena, da zagotovi načrt pokritosti testov, da bi zagotovila pripravljenost na testiranje vmesnika API poleg običajnih testov, ki temeljijo na grafičnem vmesniku.

Izzivi

Noben od drugih programskih izdelkov ni imel arhitekture, ki bi temeljila na API, zato mora ekipa za testiranje te naloge vzpostaviti postopek testiranja API od začetka. To pomeni, da je bilo treba oceniti orodja, jih izbrati, dokončno oblikovati in usposobiti ekipo za testiranje.
Za nakup in uvedbo orodja ni bilo dodeljenih dodatnih proračunskih sredstev. To pomeni, da je morala ekipa izbrati brezplačno ali odprtokodno orodje za testiranje API in za to nalogo usposobiti nekoga iz obstoječe ekipe.
Za polja API in preverjanje podatkov ni bilo zahtev. Zahteve so bile "delovati mora enako kot ustrezna aplikacija grafičnega vmesnika".

Pristop, ki ga je ekipa uporabila za zmanjševanje tveganj in odpravljanje izzivov

Ekipa za zagotavljanje kakovosti je sodelovala s projektno skupino, da bi opredelila naslednje zahteve:
- Vrsta API (REST/SOAP ): REST
- Zahtevani testi (funkcionalni, obremenitveni, varnostni): Samo funkcionalno testiranje
- Zahtevani avtomatizirani testi (Da/Ne): Za zdaj neobvezno
- Poročila o preskusih (da/ne): Zahtevano
Ekipa QA je na podlagi obveznih zahtev ocenila razpoložljiva orodja za testiranje API. Orodje Postman API Tool je bilo izbrano kot orodje, saj je bilo brezplačno in enostavno za uporabo, kar je zmanjšalo krivuljo učenja, omogočalo je avtomatizacijo testov in imelo dobra vgrajena poročila.
Isti preizkuševalec, ki je testiral aplikacijo, je bil usposobljen za uporabo programa Postman za ustvarjanje začetnih testov, s čimer so bile odpravljene vrzeli v znanju o izdelku.
Za odpravo manjkajočih zahtev je projektna skupina pripravila dokumentacijo na visoki ravni za polja z uporabo programa Swagger. Vendar je to pustilo nekaj vrzeli glede sprejemljivih oblik podatkov, kar je bilo obravnavano s projektno skupino in dogovorjeni ter dokumentirani so bili pričakovani formati.

Zaključek

Aplikacije, ki temeljijo na API, so v zadnjem času vse bolj priljubljene. Te aplikacije so v primerjavi s tradicionalnimi aplikacijami/programsko opremo bolj razširljive in omogočajo lažjo integracijo z drugimi API ali aplikacijami.

V tem učbeniku za testiranje API je podrobno razloženo vse o testiranju API, testiranju Shift Left, spletnih storitvah in spletnem API. Raziskali smo tudi razlike med spletnimi storitvami in spletnim API s primeri.

V drugem delu vadnice smo obravnavali celoten spekter testiranja API, kako uvesti testiranje API v svojo organizacijo in nekatere pogoste izzive v tem procesu ter rešitve zanje.

Oglejte si naše prihajajoče vodstvo, v katerem boste izvedeli več o spletnih storitvah skupaj s primeri!!

NASLEDNJI Učni pripomoček