Skip to main content

Ett programmeringsgränssnitt (API) gör det möjligt för två system att kommunicera med varandra. I grunden erbjuder ett API det kontrakt och det språk som styr kommunikationen mellan två system. 

API-testning innebär att dessa gränssnitt utvärderas för att säkerställa att de uppfyller standarder för funktionalitet, tillförlitlighet, prestanda och säkerhet, vanligtvis genom att skicka olika förfrågningar till API:et och bedöma svaren. API-testning är en högsta prioritet för nästan alla utvecklare, där över 90 % av utvecklarna uppger att de testar eller planerar att testa sina API:er, enligt Rapids globala API-undersökning från 2022. 

API-slutpunkter är specifika sökvägar eller URL:er som ett API tillhandahåller och som ger åtkomst till olika funktioner i programvaruapplikationen. Varje slutpunkt motsvarar en specifik funktion, till exempel att hämta data, uppdatera en post eller utföra en beräkning, och är utformad för att hantera specifika typer av förfrågningar och svar inom API:ets övergripande struktur.

Continue Reading for Free

Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.

Genom att konsekvent testa API-slutpunkter under hela utvecklingsprocessen blir det lättare att upptäcka problem tidigt, vilket sparar tid och resurser på lång sikt.

SP, hur kan API-testning genomföras effektivt under hela API-utvecklingens livscykel? Låt oss gå igenom det!

Vad är API-slutpunkter?

Ett API är en uppsättning regler och protokoll för att bygga och interagera med programvaruapplikationer, vilket gör det möjligt för olika programvarusystem att kommunicera. Dokumentationen och specifikationerna för varje API anger hur data kan utbytas.

API:er kan använda HTTP-förfrågningar för att hämta data från en webbapplikation eller server, ungefär på samma sätt som en webbsida återges.  

tjänster, URL:er, precis som de du använder för att besöka en webbplats. I ett API är en slutpunkt en specifik plats som tar emot förfrågningar och svarar på dem. Genom överföring och mottagning av data och kommandon via slutpunkten underlättas kommunikationen mellan olika applikationer och system.

Det gör det möjligt för utvecklare att snabbt komma åt och använda data samt funktioner från andra system, vilket besparar dem arbetet med att bygga allt från grunden i nya applikationer.

Exempel på en API-slutpunkt

Vi ska se hur en API-slutpunkt ser ut. Jag använder Cat API och dess Postman-dokumentation som exempel:

skärmbildsexempel på en API-slutpunkt

I det här fallet är slutpunkterna ”images”, ”favorites”, ”breeds” osv. Var och en möjliggör olika åtgärder, som utförs med olika HTTP-förfrågningsmetoder. De vanligaste metoderna är till exempel de som utför CRUD-åtgärder: POST för att skapa, GET för att läsa, PUT för att uppdatera och DELETE för att ta bort.

API-dokumentationen bör innehålla information om tillgängliga slutpunkter, den förfrågningsmetod som tillåts för slutpunkten samt modeller för förfrågan och svaret. Med denna information bör vi kunna börja testa slutpunkterna. Vi kommer att prata om detta i ett av de kommande avsnitten.

Get regular tech leadership wisdom for delivering better software and systems.

Varför testa API-slutpunkter?

Varje API är byggt för att utföra specifika funktioner, och applikationens funktionalitet är beroende av API-transaktionerna för att ta emot svaret. En grundläggande transaktion kan göra många interna API-anrop; om ett av dessa API-anrop misslyckas kan hela systemet sluta fungera. Dessutom kan flera applikationer använda samma API, så när ett API inte fungerar kan det skada ett stort antal applikationer. Genom att testa API-slutpunkter kan man förhindra problem innan klienten upptäcker dem.

Så testar du API-slutpunkter

API-testning kan utföras genom manuell testning såväl som automatiserad testning. Båda typerna av testning kan genomföras med hjälp av verktyg för API-testning.

Till skillnad från användargränssnittstester är API-tester inte beroende av en webbläsare. Däremot kan ett API-testverktyg som fungerar som en klient användas.

Utifrån dokumentationen kan vi ta fram slutpunkten dit HTTP-förfrågan ska skickas, HTTP-metoden, frågeparametrarna, förfrågningskroppen (om den krävs), möjliga HTTP-svarsstatuskoder och HTTP-svarskroppen. Med hjälp av denna information kan vi identifiera de API-testfall som behöver köras.

Beroende på kraven kan vi besluta vilka tester som behöver köras – från funktionell testning till icke-funktionell testning, såsom prestandatestning, belastningstestning och säkerhetstestning.

Det mest grundläggande API-testet består av att skicka förfrågan och validera svaret. Beroende på typen av förfrågan och själva slutpunkten kan vi behöva ytterligare information för att skicka förfrågan. Här är en lista över vad vi behöver för att skicka en förfrågan:

  • Slutpunkt/URL: detta är adressen som begäran skickas till
  • Begärans innehåll: för begärandemetoder som POST och PUT krävs ett innehåll som innehåller de data som ska skickas till servern
  • Frågeparametrar: ytterligare sökparametrar kan användas för att begränsa resultaten som returneras i svaret 
  • Huvuden: detta är metadata som kan skickas med begäran. I exemplet med katter från tidigare kan en API-nyckel användas som huvud, vilket gör det möjligt att hämta mer information än utan en nyckel:
skärmbild av guide

När begäran har skickats utan problem bör testet kontrollera svaret. Det här ska du leta efter i svaret:

  • HTTP-statuskoden: varje svar har en statuskod. Dessa kan delas in i 5 huvudklasser: koder som börjar med 1 (100–199) representerar ett informationssvar, koder som börjar med 2 (200–299) representerar ett lyckat meddelande, koder mellan 300 och 399 är omdirigeringar, koder som börjar med 4 (400–499) är klientfel och koder i 500-gruppen är serverfel. 
  • HTTP-svarets innehåll: informationen som kommer tillbaka från servern. Dokumentationen bör ange vilken typ av information svaret ska innehålla, till exempel:
skärmbild av exempelsvar
  • Svarshuvuden: metadata som returneras av servrarna
  • Svarstid: om vi även är intresserade av API:ets prestanda.

Som ett snabbt exempel använder jag Postman för att visa hur en GET-begäran ser ut med Cat API. Jag skickar en GET-begäran till bildslutpunkten. För att göra det räcker det att använda slutpunktsadressen och GET-metoden samt skicka begäran:

skärmbildsexempel

När begäran har skickats kan vi se HTTP-svarskoden, innehållet och tiden det tog att ta emot ett svar:

skärmbildsexempel

Svarets innehåll är det som ett API returnerar med de angivna indata, medan svarsstatuskoden anger begärans aktuella status.

Det finns skillnader i datatyperna och storlekarna på ett API-svar. Ren text, ett XML-dokument, en JSON-datastruktur och andra format är alla möjliga för svaren. De kan bestå av en JSON-/XML-fil på hundra sidor eller en enkel sträng på några få ord, eller till och med vara tomma. Därför är det avgörande att välja en lämplig verifieringsteknik för ett visst API.

Skapa testfall för API:er

De funktionella testfallen kan tas fram med hjälp av svartlådetestningstekniker. Dokumentationen anger vilka typer av data varje parameter accepterar, så partitioner och gränser kan skapas utifrån dessa data.

Därefter kan vi skapa mer komplexa scenarier genom att kombinera flera begäranden i ett test. Ett test som till exempel skapar en resurs, uppdaterar den, läser den och sedan tar bort den skickar 4 olika begäranden.

Både positiva och negativa tester behövs vid API-testning för att verifiera att API:et fungerar enligt kraven. Eftersom API-testning är en delmängd av svartlådetestning är indata och utdata de drivande faktorerna bakom båda typerna av testning. Några idéer för att skapa testscenarier är följande:

Positiva scenarier:

  • Kontrollera att API:et accepterar indata och producerar det önskade resultatet enligt kravet.
  • Kontrollera att svarsstatuskoden – oavsett om den returnerar en felkod eller en 2xx-kod – returneras på det sätt som anges i kravet.
  • Ange det minsta och största antalet fält som måste fyllas i.

Negativa scenarier:

  • Se till att API:et ger ett lämpligt svar i fall där det förväntade resultatet saknas.
  • Genomför ett test av indatavalideringen.
  • Undersök API:ets åtgärder på olika auktoriseringsnivåer.

Icke-funktionella API-tester 

Utöver funktionell testning kan vi utföra olika icke-funktionella tester av API:er. Här är några av de viktigaste:

Prestandatestning

Prestandatestning innebär att programvarans prestanda mäts under olika arbetsbelastningar, scenarier och förhållanden. Det kan hjälpa dig att hitta resursflaskhalsar, garantera stabilitet och skalbarhet samt säkerställa skalbarhet. Underkategorier av prestandatestning omfattar belastningstestning, stresstestning, uthållighetstestning och toppbelastningstestning. Den mest populära formen av prestandatestning, som kallas belastningstestning, simulerar genomsnittlig eller hög användartrafik i din programvara. Det kan hjälpa dig att bedöma programvarans genomströmning, svarstid och resursanvändning. Apache JMeter, ett Java-verktyg med öppen källkod som kan generera och skicka olika förfrågningar till ditt API och mäta resultaten, är ett av de bästa verktygen för belastningstestning av ditt API.

Säkerhetstestning

Processen att bekräfta att din programvara är skyddad mot skadliga angrepp, obehörig åtkomst och dataintrång kallas säkerhetstestning. Det kan hjälpa dig att garantera sekretessen, korrektheten och tillgängligheten för programmets data. Säkerhetstestning kan utföras på olika nivåer, bland annat på databas-, applikations- och nätverksnivå. Kodgranskningar, penetrationstester, sårbarhetsskanningar och etisk hackning är några populära metoder för säkerhetstestning. Postman är ett populärt plattformsoberoende verktyg som kan skicka och ta emot förfrågningar till ditt API och testa säkerhetsfunktioner som autentisering, auktorisering, kryptering och felhantering. Det är ett av de bästa verktygen för säkerhetstestning av ditt API.

Tillförlitlighetstestning

Tillförlitlighetstestning är processen för att fastställa hur pålitlig och konsekvent din programvara är över tid och i olika situationer. Det kan hjälpa dig att garantera programvarans återställningsförmåga, feltolerans och tillgänglighet. Du kan utföra tillförlitlighetstestning genom att avsiktligt införa buggar, fel eller störningar i programvaran och se hur den reagerar och återhämtar sig. Medeltid mellan fel (MTBF), medeltid till fel (MTTF), medeltid för reparation (MTTR) och felfrekvens är några av de vanligaste mätvärdena för tillförlitlighetstestning. Chaos Monkey, ett verktyg som slumpmässigt avslutar instanser i din molnmiljö och testar hur programvaran hanterar störningen, är ett av de bästa verktygen för tillförlitlighetstestning av ditt API.

Avslutande tankar

API-testning är en allt viktigare färdighet för QA-specialister. Det är viktigt att testa API-slutpunkter noggrant för att säkerställa att de fungerar som avsett och uppfyller de krav som ställs. Testning av API-slutpunkter hjälper till att identifiera och lösa potentiella problem eller buggar samt validerar applikationens övergripande funktionalitet.

För att testa API-slutpunkter effektivt är det viktigt att följa bästa praxis, till exempel att utforma omfattande testfall, ta hänsyn till olika indata och utdata samt använda automatiseringsverktyg för effektiv och tillförlitlig testning. Dessutom kan användning av testmiljöer som nära simulerar verkliga scenarier ytterligare förbättra precisionen i testningen av API-slutpunkter.

Omfattande och effektiv testning av API-slutpunkter är avgörande för att säkerställa moderna applikationers tillförlitlighet, prestanda och funktionalitet. Genom att förstå vad API-slutpunkter är och hur de ska testas kan utvecklare säkerställa att deras applikationer integreras framgångsrikt med andra system, samtidigt som de levererar en enastående användarupplevelse.

Prenumerera på QA Leads nyhetsbrev för att få uppdateringar om nytt innehåll om testning.