Ting du bør se etter når du tester APIer

Hva er en API?

Et API (Applications Programming Interface) er et databehandlingsgrensesnitt som lar programvareformidlere kommunisere med hverandre og dele informasjon. 

API-er brukes til å definere typen anrop og forespørsler, hvordan de gjøres, og konvensjonene og dataformatene som brukes når de foretar anrop og forespørsler. Hver gang du bruker applikasjoner som Google Maps eller Uber på telefonen, bruker du et API.

Hva er API-testing?

API-testing er en programvaretestingsprosess som involverer direkte validering av APIer for å sikre at de oppfyller noen fastsatte forventninger. Disse forventningene dreier seg om å teste funksjonene til API, sjekke påliteligheten og ytelsen og sørge for at den er sikker. Testingen gjøres på meldingslaget fordi APIer ikke har et grafisk brukergrensesnitt.

API-testing er en svært viktig del av API-livssyklusen . De fleste testere gjør feil når de bygger og vedlikeholder API-testene sine. Det er viktig å sørge for at du forstår alt som trengs når det gjelder å utføre API-tester . API-tester bruker ikke standard brukerinndata og -utganger som tastaturer, de bruker programvare som sender anrop til API og deretter sjekker og validerer API-ens svar.

Det er en rekke ting som testere må se etter når de tester APIer. De inkluderer;

Forstå kravene til API

Testere må først forstå formålet med API-en før de kan begynne å teste den. Dette bidrar til å skape et godt grunnlag som er avgjørende for å forberede input og output testdata, samt definere tilnærmingen som skal brukes under verifiseringsprosessen. 

 Å forstå kravene til API-en vil også hjelpe testerne til å forstå hvor API-en ligger i arbeidsflytprosessen til applikasjonen som implementerer den. APIer manipulerer ressursene til applikasjonene som implementerer dem. Å vite hvor API-en ligger og ressursene de bruker vil også hjelpe deg med å forberede testdataene dine.

API-utdatastatuskoder

Svarstatuskoden er en av de viktigste API-utdataene som testere må bekrefte. De fleste testere, spesielt nybegynnere, antar at det er nok å bruke svarkoden 200 for å fastslå suksess eller fiasko. Selv om dette ikke er feil, bør det ikke brukes til å bestemme alle API-testtilfeller fullt ut.

API-testere må forstå de forskjellige kategoriene av API-statuskoder . Det er fem kategorier, med det første sifferet i svarkoden som brukes til å bestemme klassen som svaret tilhører. De forskjellige kategoriene inkluderer 1xx, 2xx, 3xx, 4xx og 5xx . Men før testingen starter, bør testerne søke å vite om kodene i API-en følger de angitte globale standardene eller de er spesifisert av API-utviklerne.

Organisering av API-endepunkter

Når du starter et testprosjekt, for eksempel for en applikasjon, kan applikasjonen bruke mange APIer, noe som betyr at det kan være et stort antall APIer for testing. For å sikre at testerne er i stand til å administrere testene sine effektivt, bør de gruppere API-ene i forskjellige kategorier. 

For eksempel vil du finne at APIer som er gruppert sammen deler mye informasjon som ressursbane og type. Dette er viktig for å sikre høy integrasjon og dekning når man lager testscenarier.

Testing av små funksjonelle APIer

I en applikasjon som implementerer mange APIer, vil du finne at det er små funksjonelle APIer som utfører få oppgaver som å registrere seg, logge inn blant annet. Selv om disse API-ene kan virke små, og noen testere kanskje ikke legger særlig vekt på dem, er de (API-ene) inngangsportene til mye større og mer funksjonelle API-er. Testing av disse små funksjonelle API-ene sikrer at API-miljøet, autentiseringen og serverne fungerer bra.

Konklusjon

Til slutt bør testere alltid sørge for at de tester en enkelt API i hvert testtilfelle. Dette er fordi i tilfelle en feil oppstår, vil de bli tvunget til å sjekke dataene generert av API-en, noe som blir smertefullt hvis de testet mange API-er i ett testtilfelle. 

Selv når man står overfor situasjoner som krever at man kaller en rekke API-er for testing, bør man sørge for at de har testet de involverte API-ene individuelt før man kaller alle de andre API-ene. Hvis testerne observerer disse tiltakene, kan de være sikre på å ha en jevn testprosess som gir de forventede resultatene.