Slik tester du API-endepunkter

Et programmeringsgrensesnitt for applikasjoner (API) gjør det mulig for to systemer å kommunisere med hverandre. I hovedsak tilbyr et API avtalen og språket som styrer kommunikasjonen mellom to systemer. 

API-testing innebærer å evaluere disse grensesnittene for å sikre at de oppfyller standarder for funksjonalitet, pålitelighet, ytelse og sikkerhet, vanligvis ved å sende ulike forespørsler til API-et og vurdere svarene. API-testing har høyeste prioritet for nesten alle utviklere, og over 90 % av utviklerne oppgir at de tester eller planlegger å teste API-ene sine, ifølge Rapids verdensomspennende API-undersøkelse fra 2022. 

API-endepunkter er spesifikke stier eller URL-er som et API tilbyr, og som gir tilgang til ulike funksjoner i programvareapplikasjonen. Hvert endepunkt tilsvarer en bestemt funksjon, for eksempel å hente data, oppdatere en post eller utføre en beregning, og er utformet for å håndtere bestemte typer forespørsler og svar innenfor API-ets overordnede struktur.

Regelmessig testing av API-endepunkter gjennom hele utviklingsprosessen bidrar til tidlig oppdagelse av problemer, noe som sparer tid og ressurser på lang sikt.

Så, hvordan kan API-testing utføres effektivt gjennom hele livssyklusen for API-utvikling? La oss se nærmere på det!

Hva er API-endepunkter?

Et API er et sett med regler og protokoller for å bygge og samhandle med programvareapplikasjoner, slik at ulike programvaresystemer kan kommunisere. Dokumentasjonen og spesifikasjonene for hvert API angir hvordan data kan utveksles.

API-er kan bruke HTTP-forespørsler til å hente data fra en nettapplikasjon eller server, omtrent slik en nettside gjengis.  

Dette kan være nettjenester eller URL-er, akkurat som de du bruker for å besøke et nettsted. I et API er et endepunkt en bestemt plassering som mottar forespørsler og svarer på dem. Gjennom overføring og mottak av data og kommandoer via endepunktet legger det til rette for kommunikasjon mellom ulike applikasjoner og systemer.

Det gjør det mulig for utviklere å få rask tilgang til og ta i bruk data samt funksjoner fra andre systemer, slik at de slipper å bygge alt fra bunnen av i nye applikasjoner.

Eksempel på et API-endepunkt

La oss se hvordan et API-endepunkt ser ut. Jeg bruker Cat API og deres Postman-dokumentasjon som eksempel:

I dette tilfellet er endepunktene «images», «favorites», «breeds» og så videre. Hvert av dem tillater ulike handlinger, som utføres gjennom forskjellige HTTP-forespørselsmetoder. De mest brukte metodene er for eksempel de som utfører CRUD-handlinger: POST for oppretting, GET for lesing, PUT for oppdatering og DELETE for sletting.

API-dokumentasjonen bør inneholde informasjon om tilgjengelige endepunkter, hvilken forespørselsmetode som er tillatt for endepunktet, samt modeller for forespørselen og svaret. Med denne informasjonen bør vi kunne begynne å teste endepunktene. Vi skal snakke om dette i en av de neste delene.

Hvorfor teste API-endepunkter?

Alle API-er er bygget for å utføre bestemte funksjoner, og applikasjonens funksjonalitet avhenger av API-transaksjonene for å motta svaret. En grunnleggende transaksjon kan foreta mange interne API-kall. Hvis ett av disse API-kallene mislykkes, kan systemet som helhet svikte og slutte å fungere. I tillegg kan flere applikasjoner bruke det samme API-et, så når et API ikke fungerer som det skal, kan det skade et stort antall applikasjoner. Testing av API-endepunkter bidrar til å forhindre problemer før klienten oppdager dem.

Slik tester du API-endepunkter

API-testing kan utføres manuelt, så vel som automatisert. Begge testtypene kan utføres ved hjelp av verktøy for API-testing.

I motsetning til UI-tester er API-tester ikke avhengige av en nettleser. Det kan imidlertid brukes et API-testverktøy som fungerer som en klient.

Basert på dokumentasjonen kan vi hente ut endepunktet som HTTP-forespørselen skal sendes til, HTTP-metoden, spørringsparameterne, forespørselsinnholdet (hvis nødvendig), de mulige statuskodene for HTTP-svaret og innholdet i HTTP-svaret. Ved hjelp av denne informasjonen kan vi identifisere API-testtilfellene som må kjøres.

Avhengig av kravene kan vi avgjøre hvilke tester som må kjøres – fra funksjonell testing til ikke-funksjonell testing, for eksempel ytelsestesting, belastningstesting og sikkerhetstesting.

Den mest grunnleggende API-testen består i å sende forespørselen og validere svaret. Avhengig av forespørselstypen og selve endepunktet kan vi trenge ekstra informasjon for å sende forespørselen. Her er en liste over det vi trenger for å sende en forespørsel:

• Endepunkt/URL: dette er adressen som forespørselen sendes til
• Forespørselsinndata: for forespørselsmetoder som POST og PUT kreves det en inndata, som inneholder dataene som skal sendes til serveren
• Forespørselsparametere: ekstra søkeparametere kan brukes til å begrense resultatene som returneres i svaret 
• Headere: dette er metadata som kan sendes med forespørselen. I katteeksempelet fra tidligere kan en API-nøkkel brukes som en header, noe som gjør det mulig å hente mer informasjon enn uten en nøkkel:

Etter at forespørselen er sendt, bør testen kontrollere svaret. Dette er det du bør se etter i svaret:

• HTTP-statuskoden: hvert svar har en statuskode. Disse kan grupperes i 5 hovedklasser: koder som begynner med 1 (100–199), representerer et informasjonsrikt svar, koder som begynner med 2 (200–299), representerer en vellykket melding, koder mellom 300 og 399 er omdirigeringer, koder som begynner med 4 (400–499), er klientfeil, og koder i 500-gruppen er serverfeil. 
• HTTP-svaret: informasjonen som kommer tilbake fra serveren. Dokumentasjonen bør oppgi hvilken type informasjon svaret skal inneholde, for eksempel:

• Svarheadere: metadata som returneres av serverne
• Svartid: hvis vi også er interessert i API-ets ytelse.

Som et raskt eksempel bruker jeg Postman for å vise hvordan en GET-forespørsel ser ut ved bruk av Cat API. Jeg sender en GET-forespørsel til bildeendepunktet. For å gjøre dette er det nok å bruke endepunktadressen, GET-metoden og sende forespørselen:

Etter at forespørselen er sendt, kan vi se HTTP-svarkoden, inndataene og tiden det tok å motta et svar:

Innholdet i svaret er det et API returnerer med de oppgitte inndataene, mens svarstatuskoden angir forespørselens nåværende status.

Det finnes forskjeller i datatypene og størrelsene på et API-svar. Ren tekst, et XML-dokument, en JSON-datastruktur og andre formater er alle mulige svarformater. De kan bestå av en JSON-/XML-fil på hundre sider eller en enkel streng på noen få ord, eller til og med være tomme. Derfor er det avgjørende å velge en egnet verifiseringsteknikk for det aktuelle API-et.

Opprette testtilfeller for API-er

De funksjonelle testtilfellene kan utledes ved hjelp av metoder for svartboks-testing. Dokumentasjonen angir hvilke datatyper hver parameter godtar, slik at ekvivalensklasser og grenseverdier kan opprettes basert på disse dataene.

Deretter kan vi opprette mer komplekse scenarier ved å kombinere flere forespørsler i én test. En test som for eksempel oppretter en ressurs, oppdaterer den, leser den og deretter sletter den, sender 4 forskjellige forespørsler.

Både positive og negative tester er nødvendige ved API-testing for å bekrefte at API-et fungerer som påkrevd. Ettersom API-testing er en delmengde av svartboks-testing, er inndata og utdata drivkreftene bak begge testtypene. Her er noen ideer for å opprette testscenarier:

Positive scenarier:

• Kontroller at API-et godtar inndata og produserer ønsket resultat i henhold til kravene.
• Kontroller om svarstatuskoden – enten den returnerer en feilkode eller en 2xx-kode – returneres på den måten kravene angir.
• Angi det minste og største antallet felt som må fylles ut.

Negative scenarier:

• Kontroller at API-et gir et passende svar i tilfeller der det forventede resultatet mangler.
• Kjør en test av validering av inndata.
• Undersøk API-ets handlinger på ulike autorisasjonsnivåer.

Ikke-funksjonelle API-tester 

I tillegg til funksjonell testing kan vi utføre ulike ikke-funksjonelle tester av API-er. Her er noen av de viktigste:

Ytelsestesting

Ytelsestesting viser til måling av programvarens ytelse under ulike arbeidsbelastninger, scenarier og forhold. Det kan hjelpe deg med å finne ressursflaskehalser, garantere stabilitet og skalerbarhet og sikre at programvaren kan håndtere belastningen. Undertypene av ytelsestesting omfatter belastningstesting, stresstesting, utholdenhetstesting og spikertesting. Den mest populære formen for ytelsestesting, kjent som belastningstesting, gjenskaper gjennomsnittlig eller høy brukertrafikk på programvaren din. Det kan hjelpe deg med å vurdere programvarens gjennomstrømning, responstid og ressursbruk. Apache JMeter, et Java-verktøy med åpen kildekode som kan generere og sende ulike forespørsler til API-et ditt og måle resultatene, er et av de beste verktøyene for belastningstesting av API-et ditt.

Sikkerhetstesting

Prosessen med å bekrefte at programvaren din er beskyttet mot ondsinnede angrep, uautorisert tilgang og datainnbrudd, kalles sikkerhetstesting. Det kan hjelpe deg med å garantere personvernet, integriteten og tilgjengeligheten til programmets data. Sikkerhetstesting kan gjennomføres på ulike nivåer, blant annet på database-, applikasjons- og nettverksnivå. Kodegjennomganger, penetrasjonstester, sårbarhetsskanninger og etisk hacking er noen populære metoder for sikkerhetstesting. Postman er et populært plattformuavhengig verktøy som kan sende og motta forespørsler til API-et ditt og teste sikkerhetsfunksjoner som autentisering, autorisasjon, kryptering og feilhåndtering. Det er et av de beste verktøyene for sikkerhetstesting av API-et ditt.

Pålitelighetstesting

Pålitelighetstesting er prosessen med å fastslå hvor driftssikker og konsekvent programvaren din er over tid og i ulike situasjoner. Det kan hjelpe deg med å garantere programvarens gjenopprettbarhet, feiltoleranse og tilgjengelighet. Du kan utføre pålitelighetstesting ved bevisst å introdusere feil, mangler eller svikt i programvaren din og se hvordan den reagerer og kommer seg igjen. Gjennomsnittlig tid mellom feil (MTBF), gjennomsnittlig tid til feil (MTTF), gjennomsnittlig reparasjonstid (MTTR) og feilrate er noen av de vanligste måleverdiene for pålitelighetstesting. Chaos Monkey, et verktøy som avslutter instanser tilfeldig i skymiljøet ditt og tester hvordan programvaren håndterer forstyrrelsen, er et av de beste verktøyene for pålitelighetstesting av API-et ditt.

Avsluttende tanker

Testing av API-er er en stadig viktigere ferdighet for QA-fagfolk. Det er avgjørende å teste API-endepunkter grundig for å sikre at de fungerer som tiltenkt og oppfyller de nødvendige standardene. Testing av API-endepunkter bidrar til å identifisere og løse potensielle problemer eller feil, og validerer applikasjonens overordnede funksjonalitet.

For å teste API-endepunkter effektivt er det viktig å følge beste praksis, for eksempel å utforme omfattende testtilfeller, ta hensyn til ulike inndata og utdata og bruke automatiseringsverktøy for effektiv og pålitelig testing. I tillegg kan bruk av testmiljøer som i stor grad simulerer virkelige scenarier, ytterligere forbedre nøyaktigheten ved testing av API-endepunkter.

Omfattende og effektiv testing av API-endepunkter er avgjørende for å sikre påliteligheten, ytelsen og funksjonaliteten til moderne applikasjoner. Ved å forstå hva API-endepunkter er og hvordan de testes, kan utviklere sikre vellykket integrasjon av applikasjonene sine med andre systemer, samtidig som de leverer en enestående brukeropplevelse.

Abonner på nyhetsbrevet til QA Lead for å motta oppdateringer om nytt testinnhold.