Vadnica za testiranje API-jev: Popoln vodnik za začetnike

api testing tutorial

Ta poglobljena vadnica za testiranje API pojasnjuje vse o testiranju API-jev, spletnih storitvah in kako predstaviti testiranje API-jev v svoji organizaciji:

Pridobite globok vpogled v testiranje API skupaj s konceptom preskusa v levo in spletnih storitev iz te uvodne vadnice.

Koncepti, kot je spletni API, kako deluje API (z resničnim primerom) in kako se razlikuje od spletnih storitev, so dobro pojasnjeni s primeri v tej vadnici.

=>POMAKNITE NAVZDOLda si ogledate celoten seznam 5 vadnic za globinsko testiranje API-jev za začetnike

Kaj se boste naučili:

• Seznam vaj za testiranje API
• Pregled vadnic v tej seriji testiranja API
• Vadnica za testiranje API
  • Preizkus leve prestave
  • Življenjski cikel razvoja programske opreme (SDLC) pred preskusom leve prestave
  • Faze preskusov levega premika
  • Spletni API
  • Kako deluje API?
  • Spletne storitve
  • Spletne storitve v primerjavi s spletnim API-jem
• Predstavljamo testiranje API-jev v vaši organizaciji
  • Osredotočite se na preskušanje API
  • Celoten spekter testiranja API
    • (i) Funkcionalno preskušanje
    • (ii) Preskušanje obremenitve in zmogljivosti
    • (iii) Preskušanje varnosti
  • Kako predstaviti testiranje API v vaši organizaciji
  • Skupni izzivi in ​​načini za njihovo ublažitev
    • # 1) Izbira pravega orodja
    • # 2) Manjkajoče specifikacije testa
    • # 3) Krivulja učenja
    • # 4) Obstoječi sklop spretnosti
  • Študija primera
• Zaključek
  • Priporočeno branje

Seznam vaj za testiranje API

Vadnica št. 1: Vadnica za testiranje API-ja: popoln vodnik za začetnike
Vadnica # 2: Vadnica za spletne storitve: Komponente, arhitektura, tipi in primeri
Vadnica št. 3: Najpogostejših 35 vprašanj z odgovori na vprašanja ASP.Net in Web API
Vadnica # 4: Vadnica za POSTMAN: Testiranje API-jev z uporabo POSTMAN-a
Vadnica št. 5: Testiranje spletnih storitev z uporabo odjemalca Apache HTTP

Pregled vadnic v tej seriji testiranja API

Vadnica za testiranje API

Ta razdelek vam bo pomagal pridobiti osnovno razumevanje spletnih storitev in spletnega API-ja, kar pa vam bo pomagalo pri razumevanju glavnih konceptov v prihajajočih vadnicah v tej seriji testiranja API-jev.

API (Application Programming Interface) je sklop 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 API Testiranje.

Preizkus leve prestave

Ena izmed pomembnih vrst preskušanja, ki jo danes zahtevamo pri intervjujih za testiranje API, je Shift Left Testiranje. Ta vrsta testiranja se izvaja v skoraj vseh projektih, ki sledijo agilni metodologiji.

Pred uvedbo Shift Left Testiranja se je testiranje programske opreme pojavilo šele po končanem kodiranju in dostavi kode preskuševalcem. Ta praksa je privedla do vrveža v zadnjem trenutku, rok pa je tudi močno oviral kakovost izdelkov.

Poleg tega so bila prizadevanja (ko so bile napake prijavljene v zadnji fazi pred proizvodnjo) ogromna, saj so morali razvijalci znova iti skozi fazo načrtovanja in kodiranja.

Življenjski cikel razvoja programske opreme (SDLC) pred preskusom leve prestave

Tradicionalni tok SDLC je bil: Zahteva -> Oblikovanje -> Kodiranje -> Testiranje.

Slabosti tradicionalnega testiranja

• Testiranje je skrajno desno. Ko v zadnjem trenutku odkrijemo napako, nastane veliko stroškov.
• Čas, ki ga porabimo za odpravo napake in njeno ponovno preizkušanje pred promocijo v proizvodnjo, je ogromen.

Zato se je pojavila nova ideja za premik faze testiranja v levo, kar je privedlo do preskusa leve prestave.

Predlagano branje => Testiranje v levo smer: Skrivna mantra za uspeh programske opreme

Faze preskusov levega premika

Testiranje levega premika je privedlo do uspešne migracije z odkrivanja napak na preprečevanje napak. Prav tako je programski opremi pomagal hitro odpovedati in odpraviti vse napake že prej.

Spletni API

Na splošno lahko spletni API definiramo kot nekaj, kar prevzame zahtevo iz odjemalskega sistema na spletni strežnik in pošlje nazaj odgovor s spletnega strežnika na odjemalski stroj.

Kako deluje API?

Vzemimo zelo pogost scenarij rezervacije leta na www.makemytrip.com, ki je spletna potovalna storitev, ki zbira informacije več letalskih družb. Ko se odločite za rezervacijo leta, vnesete podatke, kot so datum potovanja / datum povratka, razred itd., In kliknite na iskanje.

To vam bo pokazalo ceno več letalskih prevoznikov in njihovo razpoložljivost. V tem primeru aplikacija deluje z API-ji več letalskih družb in s tem omogoča dostop do podatkov letalske družbe.

Drug primer je www.trivago.com, ki primerja in navaja ceno, razpoložljivost itd. Različnih hotelov v določenem mestu. To spletno mesto komunicira z API-ji več hotelov za dostop do baze podatkov in na njihovem spletnem mestu določa cene in razpoložljivost.

Tako lahko spletni API definiramo kot 'vmesnik, ki olajša komunikacijo med odjemalskim računalnikom in spletnim strežnikom'.

Spletne storitve

Spletne storitve so (na primer spletni API) storitve, ki služijo od enega računalnika do drugega. Toda glavna razlika med API in spletnimi storitvami je v tem, da spletne storitve uporabljajo omrežje.

Varno lahko rečemo, da so vse spletne storitve spletne API-je, vendar vsi spletni API-ji niso spletne storitve (razloženo v zadnjem delu članka). Tako so spletne storitve podmnožica spletnega API-ja. Oglejte si spodnji diagram, če želite izvedeti več o spletnem API-ju in spletnih storitvah.

Vprašanja in odgovori mrežnega inženirja v podjetju cisco

Spletni API v primerjavi s spletnimi storitvami

Spletne storitve v primerjavi s spletnim API-jem

Spletni API in spletne storitve se uporabljajo za lažjo komunikacijo med odjemalcem in strežnikom. Glavna razlika je le v načinu njihove komunikacije.

Vsak od njih zahteva telo zahteve, ki je sprejemljivo v določenem jeziku, njihove razlike pri zagotavljanju varne povezave, hitrost komunikacije s strežnikom in odziv stranki itd.

Razlike med spletnimi storitvami in spletnim API-jem so navedene spodaj za referenco.

Spletna storitev

• Spletne storitve običajno uporabljajo XML (Extensible Markup Language), kar pomeni, da so bolj varne.
• Spletne storitve so bolj varne, saj tako spletne storitve kot API-ji med prenosom podatkov zagotavljajo SSL (Secure Socket Layer), zagotavljajo pa tudi WSS (Web Services Security).
• Spletna storitev je podmnožica spletnega API-ja. Na primer, Spletne storitve temeljijo le na treh slogih uporabe, tj. MILO, POČITEK in XML-RPC.
• Spletne storitve za delovanje vedno potrebujejo omrežje.
• Spletne storitve podpirajo »One Code različne aplikacije«. To pomeni, da je v različnih aplikacijah 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 API je hitrejši, saj je JSON lahka, za razliko od XML.
• Spletni API-ji so nadmnožica spletnih storitev. Na primer, Vsi trije slogi spletnih storitev so prisotni tudi v spletnem API-ju, vendar poleg tega uporablja še druge sloge, kot je JSON - RPC.
• Za delovanje spletnega API-ja ni nujno, da deluje omrežje.
• Spletni API lahko podpira ali ne podpira interoperabilnosti, odvisno od narave sistema ali aplikacije.

Predstavljamo testiranje API-jev v vaši organizaciji

V našem vsakdanjem življenju smo vsi tako navajeni komunicirati z aplikacijami z API-ji, vendar sploh ne razmišljamo o zalednih procesih, ki poganjajo osnovno funkcionalnost.

Na primer, Upoštevajte, da brskate po izdelkih na Amazon.com in vidite izdelek / ponudbo, ki vam je res všeč, in jo želite deliti s svojim omrežjem Facebook.

Ko kliknete ikono Facebook v razdelku za skupno rabo na strani in vnesete poverilnice za svoj Facebook račun, ki jih želite deliti, komunicirate z API-jem, ki Amazonovo spletno stran brez težav poveže s Facebookom.

Osredotočite se na preskušanje API

Preden se pogovarjamo več o testiranju API-jev, se pogovorimo o razlogih, zaradi katerih so aplikacije, ki temeljijo na API-ju, v zadnjem času postale priljubljene.

Obstaja več razlogov, zaradi katerih organizacije prehajajo na izdelke in aplikacije, ki temeljijo na API-ju. Le malo jih je spodaj navedenih za vašo referenco.

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

#two) Razvojnim skupinam ni treba začeti kodirati iz nič vsakič, ko začnejo delati na razvoju funkcije ali aplikacije. API-ji najpogosteje ponovno uporabljajo obstoječe, ponovljive funkcije, knjižnice, shranjene postopke itd., Zato jih lahko ta postopek na splošno postane bolj produktiven.

Na primer, Če ste razvijalec, ki dela na spletnem mestu za e-poslovanje in želite dodati Amazon kot plačilni procesor, vam ni treba kode pisati iz nič.

Vse, kar morate storiti, je, da z integracijskimi ključi nastavite integracijo med svojim spletnim mestom in Amazon API-jem ter med obdelavo plačil pokličete Amazon API za obdelavo plačil.

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

Na primer , Upoštevajte, da želite poslati pošiljko iz Toronta v New York. Pojdite v splet, obiščite dobro znano spletno mesto za tovor ali logistiko in vnesite zahtevane podatke.

Ko vnesete obvezne podatke, ko kliknete gumb Pridobi cene - na zadnji strani se lahko to logistično spletno mesto poveže z več API-ji in aplikacijami operaterjev in ponudnikov storitev, da dobi dinamične cene za kombinacijo lokacij od začetka do cilja.

Celoten spekter testiranja API

Testiranje API-jev ni omejeno na pošiljanje zahteve API-ju in samo analizo odziva glede pravilnosti. API-je je treba preizkusiti glede njihove zmogljivosti pod različnimi obremenitvami zaradi ranljivosti.

Pogovorimo se o tem podrobno.

(i) Funkcionalno preskušanje

Funkcionalno testiranje je lahko izziv zaradi pomanjkanja vmesnika GUI.

Poglejmo, kako pristop funkcionalnega testiranja for API-ji se razlikuje od aplikacije, ki temelji na GUI, o njej pa bomo razpravljali tudi o nekaterih primerih.

do) Najbolj očitna razlika je v tem, da ni GUI za interakcijo. Preizkuševalci, ki običajno izvajajo funkcionalno testiranje na osnovi uporabniškega vmesnika, nekoliko težje preidejo na preizkušanje aplikacij, ki niso vmesniki GUI, v primerjavi z nekom, ki ga že pozna.

Sprva, še preden začnete preizkušati API, boste morali preizkusiti in preveriti sam postopek preverjanja pristnosti. Način preverjanja pristnosti se razlikuje od API-ja do API-ja in vključuje nekakšen ključ ali žeton za preverjanje pristnosti.

Če se z API-jem ne morete uspešno povezati, nadaljnje preskušanje ne more nadaljevati. Ta postopek lahko štejemo za primerljivega z overjanjem uporabnika v standardnih aplikacijah, kjer potrebujete veljavne poverilnice za prijavo in uporabo aplikacije.

b) Med testiranjem API-jev je zelo pomembno preverjanje veljavnosti polja ali preverjanje vhodnih podatkov. Če bi bil na voljo dejanski vmesnik na osnovi obrazcev (GUI), bi lahko na sprednjem ali zadnjem delu izvedli preverjanje polj, s čimer bi zagotovili, da uporabnik ne sme vnašati neveljavnih vrednosti polj.

Na primer, Če aplikacija potrebuje obliko datuma DD / MM / LLLL, lahko to potrditev uporabimo na obrazcu, ki zbira informacije, da zagotovimo, da aplikacija prejme in obdela veljaven datum.

To pa ni enako za aplikacije API. Zagotoviti moramo, da je API dobro napisan in da lahko uveljavi vse te validacije, razlikuje med veljavnimi in neveljavnimi podatki ter s pomočjo končnega uporabnika z odgovorom vrne kodo stanja in sporočilo o napaki preverjanja.

c) Preskušanje pravilnosti odzivov API za veljaven in neveljaven odgovor je resnično ključnega pomena. Če je kot odgovor testnega API-ja prejeta koda stanja 200 (kar pomeni, da je vse v redu), če pa v besedilu odgovora piše, da je prišlo do napake, je to napaka.

Če je sporočilo o napaki samo napačno, je to lahko zelo zavajajoče za končnega kupca, ki se poskuša povezati s tem API-jem.

Na spodnjem posnetku 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 pa sporočilo o napaki nepravilno omenja enote teže kot kg namesto KG. To je napaka, ki lahko končnega kupca zmede.

(ii) Preskušanje obremenitve in zmogljivosti

API-ji naj bi bili po oblikovanju prilagodljivi.

To pa naredi Load in Testiranje učinkovitosti bistvenega pomena, še posebej, če naj bi sistem, ki ga načrtujemo, servisiral na tisoče zahtev na minuto ali uro, odvisno od zahteve. Redno izvajanje testov obremenitve in zmogljivosti na API-ju lahko pomaga določiti uspešnost, največje obremenitve in prelomne točke.

Ti podatki so uporabni pri načrtovanju razširitve aplikacije. Če imate na voljo te informacije, boste lažje podprli odločitve in načrtovanje, zlasti če namerava organizacija dodati več strank, kar bi pomenilo več dohodnih prošenj.

Na primer recimo, da na podlagi zagotovljenih zahtev vemo, da mora API, ki je zasnovan, servisirati najmanj 500 zahtev na uro in ohraniti povprečni odzivni čas manj kot .01 sekunde.

Na podlagi testov obremenitve in učinkovitosti smo ugotovili, da lahko API, dokler prejme manj kot 500 zahtev na uro, vzdržuje SLA za povprečni odzivni čas. Če pa prejme še 200 zahtev, se povprečni odzivni čas poveča in prelomna točka doseže, ko dohodna zahteva preseže 1200 na uro.

Običajno je videti, da je v začetnih fazah načrtovanja pogosto poudarek na funkcionalnih vidikih API. Sčasoma izdelek začne podpirati več odjemalcev v živo, takrat nastopijo preizkusi zmogljivosti API-ja in testiranja obremenitve na bolj rutinski način.

(iii) Preskušanje varnosti

Programski vmesniki ali API-ji so ranljivi in ​​so najlažja dostopna točka za zlonamerne hekerje, ki želijo dostop do podatkov ali pridobijo nadzor nad aplikacijo.

To lahko vsako podjetje zavede v pravne težave, kjer lahko zaradi kršitve varnosti nenamerni ljudje in / ali organizacije dostopajo do podatkov stranke prek častitljivega API-ja.

Testiranje varnosti je specializirana veja testiranja in z njo bi se morali ukvarjati strokovnjaki. Viri za preskušanje varnosti so lahko v organizaciji ali neodvisnih svetovalcih.

Preberite tudi = >> Kaj je preizkušanje pogodbenih pogodb

Kako predstaviti testiranje API v vaši organizaciji

Postopek za uvedbo testiranja API v kateri koli organizaciji je podoben postopku, ki se uporablja za izvajanje ali uvajanje katerega koli drugega orodja in ogrodja za testiranje.

Spodnja tabela povzema glavne korake skupaj s pričakovanim izidom vsakega koraka.

Skupni izzivi in ​​načini za njihovo ublažitev

Pogovorimo se o nekaterih pogostih izzivih, s katerimi se soočajo skupine za preverjanje kakovosti, ko poskušajo v organizacijo vpeljati okvir za testiranje API-jev.

# 1) Izbira pravega orodja

Izbira ustreznega orodja za delo je najpogostejši izziv. Na trgu je na voljo več testnih orodij API.

Morda se zdi zelo privlačno uvesti najnovejše, najdražje orodje, ki je na voljo na trgu, toda če to ne prinese želenih rezultatov, potem to orodje ne koristi.

Zato vedno izberite orodje, ki upošteva zahteve, ki jih morate imeti, glede na vaše organizacijske potrebe.

Tu je vzorčna matrika ocenjevanja orodij za razpoložljiva orodja API

# 2) Manjkajoče specifikacije testa

Kot preizkuševalci moramo vedeti pričakovane rezultate, da lahko učinkovito preizkusimo aplikacijo. To je pogosto izziv, saj moramo, da bi vedeli pričakovane rezultate, imeti jasne natančne zahteve - kar pa ne drži.

Na primer , upoštevajte spodnje zahteve:

'Prijava mora sprejeti samo veljaven datum pošiljanja in zavrniti vse neveljavne zahteve.'

V teh zahtevah manjkajo ključne podrobnosti in so zelo dvoumne - kako določimo veljaven datum? Kaj pa format? Ali končnemu uporabniku vračamo kakšno zavrnilno sporočilo itd.?

Primer jasnih zahtev:

1) Vloga mora sprejeti samo veljaven datum pošiljanja.

Datum pošiljanja velja za veljavnega, če je

• Ne v preteklosti
• Večji ali enak današnjemu datumu
• Je v sprejemljivi obliki: DD / MM / LLLL

dva)

Koda stanja odziva = 200
Sporočilo: V redu

3) Datum pošiljanja, ki ne izpolnjuje zgornjih meril, je treba šteti za neveljavnega. Če kupec pošlje neveljaven datum pošiljanja, mora odgovoriti z naslednjim sporočilom o napaki:

3.1

Koda stanja odziva NE 200
Napaka: Navedeni datum pošiljanja ni veljaven; prosimo, poskrbite, da bo datum v obliki DD / MM / LLLL

3.2

Koda stanja odziva NE 200
Napaka: Navedeni datum pošiljanja je v preteklosti

# 3) Krivulja učenja

Kot smo že omenili, je pristop za testiranje API-ja drugačen v primerjavi s pristopom, ki smo ga uporabili med testiranjem aplikacij, ki temeljijo na GUI.

Če za testiranje API najamete lastne strokovnjake ali svetovalce, potem je krivulja učenja preskusnega pristopa API ali orodja za preskušanje API morda minimalna. Vsaka učna krivulja bi bila v tem primeru povezana s pridobivanjem znanja o izdelku ali aplikaciji.

Če je obstoječemu članu ekipe dodeljen, da se uči testiranja API-ja, je učna krivulja, odvisno od izbranega orodja, lahko srednja do visoka, skupaj s spremembo testnega pristopa. Krivulja učenja za sam izdelek ali aplikacijo je lahko nizko-srednja, odvisno od tega, ali je ta preizkuševal to aplikacijo že prej ali ne.

# 4) Obstoječi sklop spretnosti

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

Če bi preizkuševalec prehajal s testiranja na osnovi GUI, bi moral tester spremeniti pristop testiranja in se po potrebi naučiti novega orodja ali ogrodja. Npr. Če API sprejme zahteve v obliki JSON, se mora preizkuševalec naučiti, kaj je JSON, da začne ustvarjati teste.

Študija primera

Naloga

Za razširitev obstoječe aplikacije je podjetje želelo ponuditi izdelek v API-ju in standardno aplikacijo GUI. Skupina QA je bila pozvana, naj predloži načrt zajema preskusov, s katerim bo zagotovila, da bo pripravljena na preskušanje API-jev, ki presegajo običajne teste, ki temeljijo na grafičnem uporabniškem vmesniku.

Izzivi

• Nobeden od drugih programskih izdelkov ni imel arhitekture, ki temelji na API-ju, zato mora ekipa za testiranje te naloge vzpostaviti postopek testiranja API-ja od začetka. To pomeni, da je bilo treba orodja oceniti, uvrstiti v ožji izbor, dokončati in ekipo usposobiti za teste.
• Za nakup in izvajanje orodja ni bil dodeljen noben dodaten proračun. To pomeni, da je morala ekipa izbrati brezplačno ali odprtokodno orodje za testiranje API-ja, nekdo iz obstoječe ekipe pa mora biti usposobljen za to nalogo.
• Za polja API in preverjanje veljavnosti podatkov ni bilo nobenih zahtev. Zahteve so bile 'mora delovati enako kot ustrezna aplikacija GUI'.

Pristop, ki ga je sledila ekipa za ublažitev tveganj in reševanje izzivov

• Skupina QA je s projektno skupino ugotovila naslednje zahteve:
  • Tip API (REST / SOAP): POČITEK
  • Zahtevani testi (funkcionalni, obremenitveni, varnostni): Samo funkcionalno preskušanje
  • Zahtevani avtomatizirani testi (da / ne): Zaenkrat neobvezno
  • Poročila o preskusih (da / ne): Obvezno
• Skupina za preverjanje kakovosti je opravila oceno orodij glede razpoložljivih Orodja za testiranje API na podlagi obveznih zahtev. Postman API Tool je bil dokončan kot orodje po njihovi izbiri, saj je bil brezplačen in enostaven za uporabo, s čimer je minimiziral učno krivuljo, imel je možnost avtomatizirati teste in je dobil dobra vgrajena poročila.
• Isti preizkuševalec, ki je preizkusil aplikacijo, je bil usposobljen za uporabo Postman za ustvarjanje začetnih testov, s čimer je odpravil vrzeli v znanju o izdelku.
• Za spopad z manjkajočimi zahtevami je projektna skupina z uporabo Swaggerja izdelala dokumentacijo na visoki ravni na terenu. Vendar je to povzročilo nekaj vrzeli glede sprejemljivih formatov podatkov, to pa je prevzela projektna skupina, dogovorjeni in dokumentirani pričakovani formati.

Zaključek

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

Ta vadnica API testiranja je podrobno razložila vse o testiranju API-jev, preskusu Shift Left, spletnih storitvah in spletnem API-ju. Razlike med spletnimi storitvami in spletnim API-jem smo raziskali tudi s primeri.

V drugem delu vadnice smo razpravljali o celotnem spektru testiranja API-jev, o tem, kako v svojo organizacijo uvesti testiranje API-jev, in o nekaterih skupnih izzivih v tem procesu, skupaj z rešitvami zanje.

Oglejte si našo prihajajočo vadnico, če želite izvedeti več o spletnih storitvah skupaj s primeri !!

NASLEDNJA Vadnica

Priporočeno branje

• Alfa testiranje in beta testiranje (popoln vodnik)
• Funkcionalno testiranje vs nefunkcionalno testiranje
• Vadnica za preizkušanje uporabnosti: popoln vodnik za začetek
• Popoln vodnik za preizkus preverjanja gradnje (testiranje BVT)
• Vadnica za testiranje DevOps: Kako bodo DevOps vplivali na testiranje kakovosti?
• Vadnica za preizkušanje dostopnosti (popoln vodnik po korakih)
• Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
• Kaj je testiranje programske opreme? 100+ brezplačnih vaj za ročno testiranje