Sådan tester du API-slutpunkter

En programmeringsgrænseflade (API) gør det muligt for to systemer at kommunikere med hinanden. Grundlæggende tilbyder en API den kontrakt og det sprog, der styrer kommunikationen mellem to systemer. 

API-test involverer evaluering af disse grænseflader for at sikre, at de opfylder standarder for funktionalitet, pålidelighed, ydeevne og sikkerhed, typisk ved at sende forskellige forespørgsler til API'en og vurdere svarene. API-test er en topprioritet for næsten alle udviklere, hvor over 90 % af udviklerne ifølge Rapids globale API-undersøgelse fra 2022 rapporterer, at de tester eller planlægger at teste deres API'er. 

API-slutpunkter er specifikke stier eller URL'er, som en API stiller til rådighed, og som giver adgang til forskellige funktioner i softwareapplikationen. Hvert slutpunkt svarer til en specifik funktion, f.eks. at hente data, opdatere en post eller udføre en beregning, og er designet til at håndtere bestemte typer forespørgsler og svar inden for API'ens overordnede struktur.

Regelmæssig test af API-slutpunkter gennem hele udviklingsprocessen hjælper med at opdage problemer tidligt, hvilket sparer tid og ressourcer på lang sigt.

Så, hvordan kan API-test udføres effektivt gennem hele API-udviklingslivscyklussen? Lad os dykke ned i det!

Hvad er API-slutpunkter?

En API er et sæt regler og protokoller til opbygning af og interaktion med softwareapplikationer, som gør det muligt for forskellige softwaresystemer at kommunikere. Dokumentationen og specifikationerne for hver API angiver, hvordan data kan udveksles.

API'er kan bruge HTTP-forespørgsler til at hente data fra en webapplikation eller server, ligesom en webside bliver gengivet.  

API-slutpunkter kan være tjenester eller URL'er, ligesom dem du bruger til at besøge et websted. I en API er et slutpunkt en bestemt placering, der modtager forespørgsler og svarer på dem. Gennem overførsel og modtagelse af data og kommandoer via slutpunktet letter det kommunikationen mellem forskellige applikationer og systemer.

Det giver udviklere hurtig adgang til og mulighed for at bruge data samt funktioner fra andre systemer, så de slipper for at bygge alt fra bunden i nye applikationer.

Eksempel på et API-slutpunkt

Lad os se, hvordan et API-slutpunkt ser ud. Jeg bruger Cat API og deres Postman-dokumentation som eksempel:

I dette tilfælde er slutpunkterne “images”, “favorites”, “breeds” osv. Hvert slutpunkt tillader forskellige handlinger, som udføres gennem forskellige HTTP-forespørgselsmetoder. De mest almindeligt anvendte metoder er f.eks. dem, der udfører CRUD-handlinger: POST til oprettelse, GET til læsning, PUT til opdatering og DELETE til sletning.

API-dokumentationen bør indeholde oplysninger om de tilgængelige slutpunkter, den forespørgselsmetode, der er tilladt for slutpunktet, samt modeller for forespørgslen og svaret. Med disse oplysninger bør vi kunne begynde at teste slutpunkter. Det taler vi om i et af de næste afsnit.

Hvorfor teste API-slutpunkter?

Alle API'er er bygget til at udføre specifikke funktioner, og applikationens funktionalitet afhænger af API-transaktionerne for at modtage svaret. Den grundlæggende transaktion kan foretage mange interne API-kald; hvis et af disse API-kald mislykkes, kan systemet som helhed svigte og ophøre med at fungere. Derudover kan flere applikationer bruge den samme API, så når en API ikke fungerer korrekt, kan det skade et stort antal applikationer. Test af API-slutpunkter hjælper med at forhindre problemer, før klienten opdager dem.

Sådan tester du API-slutpunkter

API-test kan udføres manuelt såvel som automatisk. Begge typer test kan udføres ved hjælp af værktøjer til API-test.

I modsætning til UI-tests afhænger API-tests ikke af en browser. Der kan dog bruges et API-testværktøj, der fungerer som klient.

På baggrund af dokumentationen kan vi udtrække det slutpunkt, som HTTP-forespørgslen skal sendes til, HTTP-metoden, forespørgselsparametrene, forespørgslens brødtekst (hvis det er nødvendigt), de mulige HTTP-svarstatuskoder og HTTP-svarets brødtekst. Ved hjælp af disse oplysninger kan vi identificere de API-testcases, der skal udføres.

Afhængigt af kravene kan vi beslutte, hvilke tests der skal udføres – fra funktionel test til ikke-funktionelle tests såsom ydeevnetest, belastningstest og sikkerhedstest.

Den mest grundlæggende API-test består i at sende forespørgslen og validere svaret. Afhængigt af forespørgselstypen og selve slutpunktet kan vi have brug for ekstra oplysninger for at sende forespørgslen. Her er en liste over det, vi skal sende med en forespørgsel:

• Slutpunkt/URL: dette er den adresse, som anmodningen sendes til
• Anmodningens brødtekst: for anmodningsmetoder som POST og PUT kræves en brødtekst, der indeholder de data, som skal sendes til serveren
• Forespørgselsparametre: yderligere søgeparametre kan bruges til at begrænse de resultater, der returneres i svaret 
• Headere: dette er metadata, der kan sendes sammen med anmodningen. I katteeksemplet fra før kan en API-nøgle bruges som en header, hvilket gør det muligt at hente flere oplysninger end uden en nøgle:

Når anmodningen er sendt korrekt, bør testen kontrollere svaret. Det, man skal se efter i svaret, er:

• HTTP-statuskoden: hvert svar har en statuskode. Disse kan grupperes i 5 hovedklasser: koder, der begynder med 1 (100-199), repræsenterer et informationssvar, koder, der begynder med 2 (200-299), repræsenterer en vellykket meddelelse, koder mellem 300 og 399 er omdirigeringer, koder, der begynder med 4 (400-499), er klientfejl, og koder i 500-gruppen er serverfejl. 
• HTTP-svarets brødtekst: de oplysninger, der kommer tilbage fra serveren. Dokumentationen bør angive, hvilken type oplysninger svaret skal indeholde, for eksempel:

• Svarheadere: metadata, der returneres af serverne
• Svartid: hvis vi også er interesserede i API'ets ydeevne.

Som et hurtigt eksempel vil jeg bruge Postman til at vise, hvordan en GET-anmodning ser ud ved hjælp af Cat API. Jeg sender en GET-anmodning til billedernes slutpunkt. For at gøre det er det nok at bruge slutpunktadressen, GET-metoden og sende anmodningen:

Efter at have sendt anmodningen kan vi se HTTP-svarkoden, brødteksten og den tid, det tog at modtage et svar:

Indholdet i svarbrødteksten er det, som en API returnerer med de angivne input, mens svarstatuskoden angiver anmodningens aktuelle status.

Der er forskelle på datatyperne og størrelserne af et API-svar. Ren tekst, et XML-dokument, en JSON-datastruktur og andre formater er alle mulige for svarene. De kan bestå af en JSON/XML-fil på hundrede sider eller en simpel streng på nogle få ord, eller de kan endda være tomme. Derfor er det afgørende at vælge en passende verifikationsteknik til et bestemt API.

Oprettelse af testtilfælde til API'er

De funktionelle testtilfælde kan udledes ved hjælp af sortboks-testteknikker. Dokumentationen angiver, hvilke datatyper hver parameter accepterer, så der kan oprettes partitioner og grænser baseret på disse data.

Derefter kan vi oprette mere komplekse scenarier ved at kombinere flere anmodninger i én test. En test, der opretter en ressource, opdaterer den, læser den og derefter sletter den, sender for eksempel 4 forskellige anmodninger.

Både positive og negative tests er nødvendige ved API-testning for at kontrollere, at API'et fungerer som krævet. Da API-testning er en delmængde af sortboks-testning, er input- og outputdata de drivende kræfter bag begge testtyper. Nogle idéer til oprettelse af testscenarier er som følger:

Positive scenarier:

• Kontrollér, at API'et accepterer input og producerer det ønskede resultat i henhold til kravet.
• Kontrollér, om svarstatuskoden – uanset om den returnerer en fejlkode eller en 2xx-kode – returneres på den måde, som kravet angiver.
• Angiv det minimale og maksimale antal felter, der skal udfyldes.

Negative scenarier:

• Sørg for, at API'et giver et passende svar i tilfælde, hvor det forventede output mangler.
• Kør en test af inputvalideringen.
• Undersøg API'ets handlinger på forskellige autorisationsniveauer.

Ikke-funktionelle API-tests 

Ud over funktionel testning kan vi udføre forskellige ikke-funktionelle tests af API'er. Her er nogle af de vigtigste:

Ydeevnetest

Ydeevnetest henviser til måling af softwarens ydeevne under forskellige arbejdsbelastninger, scenarier og forhold. Det kan hjælpe dig med at finde ressourceflaskehalse, garantere stabilitet og skalerbarhed samt sikre skalerbarhed. Undertyper af ydeevnetest omfatter belastningstest, stresstest, udholdenhedstest og spidstest. Den mest populære form for ydeevnetest, kendt som belastningstest, simulerer gennemsnitlig eller høj brugertrafik på din software. Det kan hjælpe dig med at vurdere softwarens gennemløb, svartid og ressourceforbrug. Apache JMeter, et open source-Java-værktøj, der kan generere og sende forskellige forespørgsler til din API og måle resultaterne, er et af de bedste værktøjer til belastningstest af din API.

Sikkerhedstest

Processen med at bekræfte, at din software er beskyttet mod ondsindede angreb, uautoriseret adgang og databrud, kaldes sikkerhedstest. Det kan hjælpe dig med at garantere fortroligheden, nøjagtigheden og tilgængeligheden af dit programs data. Sikkerhedstest kan udføres på forskellige niveauer, herunder database-, applikations- og netværksniveau. Kodegennemgange, penetrationstest, sårbarhedsscanninger og etisk hacking er nogle af de populære metoder til sikkerhedstest. Postman er et populært værktøj på tværs af platforme, der kan sende og modtage forespørgsler til din API og teste sikkerhedsfunktioner som godkendelse, autorisation, kryptering og fejlhåndtering. Det er et af de bedste værktøjer til sikkerhedstest af din API.

Pålidelighedstest

Pålidelighedstest er processen med at fastslå, hvor driftssikker og konsekvent din software er over tid og under forskellige forhold. Det kan hjælpe dig med at garantere softwarens genoprettelighed, fejltolerance og tilgængelighed. Du kan udføre pålidelighedstest ved med vilje at introducere fejl, fejlsituationer eller nedbrud i din software og se, hvordan den reagerer og kommer sig. Gennemsnitlig tid mellem fejl (MTBF), gennemsnitlig tid til fejl (MTTF), gennemsnitlig reparationstid (MTTR) og fejlrate er nogle af de hyppigst anvendte målinger til pålidelighedstest. Chaos Monkey, et værktøj, der tilfældigt afslutter instanser i dit cloudmiljø og tester, hvordan din software håndterer forstyrrelsen, er et af de bedste værktøjer til pålidelighedstest af din API.

Afsluttende tanker

API-test er en stadig vigtigere færdighed for QA-fagfolk. Det er afgørende at teste API-endepunkter grundigt for at sikre, at de fungerer efter hensigten og opfylder de krævede standarder. Test af API-endepunkter hjælper med at identificere og løse potentielle problemer eller fejl og validerer applikationens overordnede funktionalitet.

For effektivt at teste API-endepunkter er det vigtigt at følge bedste praksis, såsom at udforme omfattende testcases, tage højde for forskellige input og output samt anvende automatiseringsværktøjer til effektiv og pålidelig test. Derudover kan anvendelse af testmiljøer, der nøje simulerer scenarier fra den virkelige verden, yderligere forbedre nøjagtigheden af testen af API-endepunkter.

Omfattende og effektiv test af API-endepunkter er afgørende for at sikre moderne applikationers pålidelighed, ydeevne og funktionalitet. Ved at forstå, hvad API-endepunkter er, og hvordan de testes, kan udviklere sikre en vellykket integration af deres applikationer med andre systemer, samtidig med at de leverer en fremragende brugeroplevelse.

Tilmeld dig QA Lead-nyhedsbrevet for at modtage opdateringer om nyt testindhold.