Meny

API Testing Tutorial: En komplett guide för nybörjare

  • Huvud
  • Övrig
  • API Testing Tutorial: En komplett guide för nybörjare

api testing tutorial

Prova Vårt Instrument För Att Eliminera Problem

Den här djupgående API-testhandledningen förklarar allt om API-testning, webbtjänster och hur man introducerar API-testning i din organisation:

Få en djup insikt i API-testning tillsammans med begreppet skift-vänster-testning och webbtjänster från denna introduktionshandledning.

Begrepp som Web API, hur API fungerar (med exempel från verkliga världen) och hur skiljer det sig från webbtjänster förklaras väl med exempel i denna handledning.

=>SCROLLA NERför att se hela listan med 5 djupgående API-testhandledning för nybörjare

API-testning

Vad du kommer att lära dig:

Lista över API-testhandledning

Handledning nr 1: API Testing Tutorial: En komplett guide för nybörjare
Handledning nr 2: Webbtjänsthandledning: komponenter, arkitektur, typer och exempel
Självstudie 3: Topp 35 intervjuer med ASP.Net och webb-API med svar
Självstudie 4: POSTMAN-handledning: API-testning med POSTMAN
Handledning nr 5: Webbtjänsttestning med Apache HTTP-klient

Översikt över handledningar i denna API-testserie

Handledning #Vad du kommer att lära dig
LoadFocus Baserat på antalet användare och plantyperna* Kan användas för API-belastningstestning - gör det möjligt att köra några tester för att ta reda på antalet användare som ett API kan stödja.
* Enkel att använda - tillåter körning av tester i webbläsaren.
Handledning_ # 1: API Testing Tutorial: En komplett guide för nybörjare
Den här djupgående API-testhandledningen kommer att förklara allt om API-testning och webbtjänster i detalj och utbilda dig också om hur du introducerar API-testning i din organisation.
Handledning_ # 2: Webbtjänsthandledning: komponenter, arkitektur, typer och exempel
Denna webbtjänsthandledning förklarar arkitektur, typer och komponenter för webbtjänster tillsammans med viktiga terminologier och skillnaderna mellan SOAP och REST.
Handledning_ # 3: Topp 35 intervjuer med ASP.Net och webb-API med svar
Du kan utforska listan över de mest populära ASP.Net- och Web API-intervjufrågorna med svar och exempel för nybörjare och erfarna proffs i denna handledning.
Handledning_ # 4: POSTMAN-handledning: API-testning med POSTMAN
Denna steg för steg-handledning kommer att förklara API-testning med POSTMAN tillsammans med grunderna för POSTMAN, dess komponenter och provförfrågan och svar i enkla termer för din enkla förståelse.
Handledning_ # 5: Webbtjänsttestning med Apache HTTP-klient
Denna API-handledning handlar om att utföra olika CRUD-operationer på webbtjänster och testa webbtjänster med hjälp av Apache HTTP-klient

API Testing Tutorial

Det här avsnittet hjälper dig att få en grundläggande förståelse för webbtjänster och webb-API, vilket i sin tur kommer att vara till hjälp för att förstå de viktigaste begreppen i de kommande handledningarna i denna API-testserie.

API (Application Programming Interface) är en uppsättning av alla procedurer och funktioner som tillåter oss att skapa en applikation genom att komma åt data eller funktioner i operativsystemet eller plattformarna. Testning av sådana procedurer kallas API-testning.

Skift vänster testning

En av de viktiga typerna av tester som frågas idag i API-testintervjuer är Shift Left Testing. Denna typ av testning praktiseras i nästan alla projekt som följer en Agile Methodology.

Innan Shift Left Testing introducerades kom programvarutestning in i bilden först efter att kodningen var klar och koden levererades till testarna. Denna praxis ledde till sista minuten stress för att uppfylla deadline och det hindrade också produktkvaliteten i stor utsträckning.

Bortsett från det var de ansträngningar som gjordes (när fel rapporterades i sista fasen före produktion) enorma eftersom utvecklare var tvungna att gå igenom både design- och kodningsfasen igen.

Programvaruutveckling livscykel (SDLC) före skift vänster testning

Traditionellt SDLC-flöde var: Krav -> Design -> Kodning -> Testning.

Nackdelar med traditionell testning

  • Testning är ytterst till höger. Många kostnader uppstår när ett fel identifieras i sista minuten.
  • Den tid det tar att lösa felet och testa det igen innan det marknadsförs till produktion är enormt.

Därför dök upp en ny idé för att flytta testfasen till vänster vilket ledde till Shift Left Testing.

Föreslagen läsning => Shift Left Testing: Ett hemligt mantra för mjukvaruframgång

Faser av vänster skift testning

Faser av vänster skifttestning

Vänster skifttestning ledde till en framgångsrik migrering från defektdetektering till förebyggande av defekter. Det hjälpte också programvaran att misslyckas snabbt och åtgärda alla fel tidigast.

Webb-API

I allmänna termer kan ett webb-API definieras som något som tar begäran från ett klientsystem till en webbserver och skickar tillbaka svaret från en webbserver till en klientmaskin.

Hur fungerar ett API?

Låt oss ta ett mycket vanligt scenario med att boka en flygning på www.makemytrip.com, som är en onlinetjänst som samlar information från flera flygbolag. När du går till en flygbokning anger du information som resdatum / returdatum, klass etc. och klickar på sök.

Detta visar priset på flera flygbolag och deras tillgänglighet. I det här fallet interagerar applikationen med API: er från flera flygbolag och ger därmed åtkomst till flygbolagets data.

Ett annat exempel är www.trivago.com som jämför och listar pris, tillgänglighet etc. för olika hotell från en viss stad. Denna webbplats kommunicerar med flera hotells API för att komma åt databasen och listar priser och tillgänglighet från deras webbplats.

Således kan ett webb-API definieras som 'ett gränssnitt som underlättar kommunikationen mellan en klientmaskin och webbservern'.

Webbservice

Web Services är (som Web API) de tjänster som fungerar från en maskin till en annan. Men den största skillnaden som uppstår mellan API och webbtjänster är att webbtjänsterna använder ett nätverk.

bästa programmet för att konvertera youtube till mp3

Det är säkert att säga att alla webbtjänster är webb-API: er men alla webb-API: er inte webbtjänster (förklaras i den senare delen av artikeln). Webbtjänster är alltså en delmängd av webb-API. Se nedanstående diagram för att lära dig mer om Web API och Web Services.

Web API vs webbtjänster

Web API vs WEB-tjänster

Web Services vs Web API

Både Web API och Web Services används för att underlätta kommunikationen mellan klienten och servern. Den största skillnaden kommer bara i hur de kommunicerar.

Var och en av dem kräver ett begärande organ som är acceptabelt på ett visst språk, deras skillnader i att tillhandahålla en säker anslutning, deras hastighet att kommunicera till servern och svara tillbaka till klienten, etc.

Skillnader mellan webbtjänster och webb-API listas nedan för din referens.

Webb-service

  • Webbtjänster använder vanligtvis XML (Extensible Markup Language), vilket innebär att de är säkrare.
  • Webbtjänster är säkrare eftersom både webbtjänster och API: er tillhandahåller SSL (Secure Socket Layer) under dataöverföring, men det ger också WSS (Web Services Security).
  • Web Service är en delmängd av Web API. Till exempel, Webbtjänster baseras endast på tre användningsformer, dvs. SOAP, REST och XML-RPC.
  • Webbtjänster behöver alltid ett nätverk för att fungera.
  • Webbtjänster stöder 'One Code different applications'. Det betyder att en mer generisk kod skrivs över olika applikationer.

Webb-API

  • Ett webb-API använder vanligtvis JSON (JavaScript Object Notation), vilket innebär att Web-API är snabbare.
  • Web-API är snabbare eftersom JSON är lättvikts, till skillnad från XML.
  • Webb-API: er är överuppsättningen av webbtjänster. Till exempel, Alla tre stilar av webbtjänster finns också i webb-API, men bortsett från det använder den andra stilar som JSON - RPC.
  • Web API kräver inte nödvändigtvis ett nätverk för att fungera.
  • Web API stöder eventuellt inte interoperabilitet beroende på vilken typ av system eller applikation som är.

Vi presenterar API-testning i din organisation

I vårt dagliga liv är vi alla så vana att interagera med apparna med API: er och ändå tänker vi inte ens på de backend-processer som driver den underliggande funktionaliteten.

Till exempel, Låt oss överväga att du bläddrar igenom produkterna på Amazon.com och du ser en produkt / affär som du verkligen gillar och vill dela den med ditt Facebook-nätverk.

I det ögonblick du klickar på Facebook-ikonen på delningsavsnittet på sidan och anger dina Facebook-kontouppgifter för att dela, interagerar du med ett API som sömlöst ansluter Amazon-webbplatsen till Facebook.

Focus Shift to API Testing

Innan vi diskuterar mer om API-testning, ska vi diskutera orsakerna till vilka API-baserade applikationer har vunnit popularitet på senare tid.

Det finns flera anledningar till att organisationer övergår till API-baserade produkter och applikationer. Och få av dem är listade nedan för din referens.

# 1) API-baserade applikationer är mer skalbara jämfört med traditionella applikationer / programvara. Koden för kodutveckling är snabbare och samma API kan betjäna fler förfrågningar utan några större kod- eller infrastrukturförändringar.

#två) Utvecklingsteam behöver inte börja koda från grunden varje gång de börjar arbeta med att utveckla en funktion eller en applikation. API: n återanvänder oftast befintliga, repeterbara funktioner, bibliotek, lagrade procedurer etc. och därför kan denna process göra dem mer produktiva övergripande.

Till exempel, Om du är en utvecklare som arbetar på en e-handelswebbplats och vill lägga till Amazon som betalningsprocessor - behöver du inte skriva koden från grunden.

Allt du behöver göra är att ställa in integration mellan din webbplats och Amazon API med hjälp av integrationsnycklar och ringa Amazon API för bearbetning av betalningar under kassan.

# 3) API: er möjliggör enkel integration med de andra systemen både för fristående applikationer som stöds och med API-baserade programvaruprodukter.

Till exempel Låt oss överväga att du vill skicka en leverans från Toronto till New York. Du går online, navigerar till en välkänd frakt- eller logistikwebbplats och anger önskad information.

Efter att ha tillhandahållit den obligatoriska informationen, när du klickar på knappen Hämta priser - i baksidan kan denna logistikwebbplats ansluta till flera operatörs- och tjänsteleverantörs-API: er och applikationer för att få de dynamiska priserna för kombinationen av ursprung till destination av platser.

Fullt spektrum av API-testning

Testning av API: er är inte begränsat till att skicka en begäran till API och analysera svaret för att vara korrekt. API: erna måste testas för deras prestanda under olika belastningar för sårbarheter.

Låt oss diskutera detta i detalj.

(i) Funktionstestning

Funktionstestning kan vara en utmanande uppgift på grund av bristen på ett GUI-gränssnitt.

Låt oss se hur funktionell testmetod för API skiljer sig från GUI-baserad applikation och vi kommer också att diskutera några exempel kring det.

till) Den mest uppenbara skillnaden är att det inte finns något GUI att interagera med. Testare som vanligtvis gör GUI-baserade funktionstester tycker att det är lite svårare att övergå till icke-GUI-applikationstest jämfört med någon som redan känner till det.

Inledningsvis, även innan du börjar testa API: et, måste du testa och verifiera själva autentiseringsprocessen. Autentiseringsmetoden kommer att variera från ett API till ett annat API och skulle innebära någon form av nyckel eller token för autentisering.

Om du inte kan ansluta till API: et framgångsrikt kan ytterligare testning inte fortsätta. Denna process kan anses vara jämförbar med användarautentisering i standardapplikationerna där du behöver giltiga referenser för att logga in och använda applikationen.

b) Att testa fältvalideringar eller validering av indata är mycket viktigt vid testning av API: er. Om ett faktiskt formulärbaserat (GUI) gränssnitt var tillgängligt, kunde fältvalideringar implementeras i frontend eller backend, vilket säkerställer att en användare inte får ange ogiltiga fältvärden.

Till exempel, Om en ansökan behöver datumformatet för att vara DD / MM / ÅÅÅÅ kan vi använda denna validering på formuläret som samlar in information för att säkerställa att ansökan tar emot och behandlar ett giltigt datum.

Detta är dock inte detsamma för API-applikationer. Vi måste se till att API: et är välskrivet och kan genomdriva alla dessa valideringar, skilja mellan giltiga och ogiltiga data och returnera statuskoden och valideringsfelmeddelandet till slutanvändaren genom ett svar.

c) Att testa riktigheten av svaren från API för giltigt och ogiltigt svar är verkligen avgörande. Om en statuskod på 200 (vilket betyder allt okej) tas emot som svar från test-API, men om svarstexten säger att ett fel har påträffats är detta en defekt.

Dessutom, om själva felmeddelandet är felaktigt, kan det vara mycket vilseledande för slutkunden som försöker integrera med detta API.

I skärmdumpen nedan har användaren angett ogiltig vikt, vilket är mer än de acceptabla 2267 kg. API: et svarar med felstatuskoden och felmeddelandet. Felmeddelandet nämner dock felaktigt viktenheterna som kg istället för KG. Detta är en defekt som kan förvirra slutkunden.

API-testning - felaktigt felmeddelande

(ii) Test av belastning och prestanda

API: er är avsedda att vara skalbara av design.

Detta gör i sin tur Load and Prestandatester viktigt, särskilt om det system som utformas förväntas betjäna tusentals förfrågningar per minut eller timme, beroende på kravet. Rutinmässigt utförande av belastnings- och prestationstester på API: et kan hjälpa till att jämföra prestanda, toppbelastning och brytpunkt.

Dessa data är användbara när du planerar att skala upp en applikation. Att ha denna information tillgänglig hjälper till att stödja beslut och planering, särskilt om organisationen planerar att lägga till fler kunder, vilket skulle innebära fler inkommande förfrågningar.

Till exempel , låt oss säga att baserat på de angivna kraven vet vi att API: n som är utformat behöver betjäna minst 500 förfrågningar per timme och upprätthålla den genomsnittliga svarstiden på mindre än 0,01 sekunder.

Baserat på våra belastnings- och prestandatester fick vi reda på att så länge API tar emot mindre än 500 förfrågningar per timme, kan det upprätthålla SLA under genomsnittlig svarstid. Men om den tar emot ytterligare 200 förfrågningar ökar den genomsnittliga svarstiden och brytpunkten uppnås när den inkommande begäran överstiger 1200 per timme.

Vanligtvis ser man att tyngdpunkten ofta ligger på API: s funktionella aspekter under de inledande designfaserna. Med tiden går en produkt att stödja flera live-klienter, det är då testet för API-prestanda och Load-test kommer in i bilden på ett mer rutinmässigt sätt.

(iii) Säkerhetstestning

Programmeringsgränssnitt eller API: er är sårbara och är den enklaste åtkomstpunkten för skadliga hackare som vill ha tillgång till data eller få kontroll över en applikation.

Detta kan leda alla företag till juridiska problem, där oavsiktliga personer och / eller organisationer på grund av en säkerhetsöverträdelse kan komma åt klientens data via ett ärevördigt API.

Säkerhetstestning är en specialiserad testgren och bör hanteras av specialister. Säkerhetstestresurserna kan komma från organisationen eller oberoende konsulter.

Läs också = >> Vad är paktavtalstestning

Hur man introducerar API-testning i din organisation

Processen för att införa API-testning i vilken organisation som helst liknar den process som används för att implementera eller rulla ut något annat testverktyg och ramverk.

Tabellen nedan sammanfattar huvudstegen tillsammans med det förväntade resultatet för varje steg.

FasStegFörväntat resultat
VerktygsvalSamla krav och identifiera begränsningar
Förstå kraven för att undersöka marknaden för lämpligt API-testverktyg.
T.ex.
Vilken typ av API testas - SOAP eller REST?
Behöver vi anställa testare för den här rollen eller utbilda befintlig testare?
Vilken typ av tester kommer att utföras - funktionella, prestandatester etc.
Vad är budgeten för genomförandet?
Utvärdera tillgängliga verktygJämför tillgängliga verktyg och kortlista 1 eller 2 verktyg som bäst uppfyller kraven.
Bevis på konceptImplementera en delmängd av tester med det kortlistade verktyget.
Presentera resultat för intressenter.
Slutför verktyget som ska implementeras.
GenomförandeKomma igångBeroende på ditt val av verktyg, skulle du behöva installera det verktyg du behöver på en PC, virtuell maskin eller server.
Om det valda verktyget är prenumerationsbaserat skapar du nödvändiga teamkonton.
Träna laget om det behövs.
Komma igångSkapa tester
Utför tester
Rapportera brister

Vanliga utmaningar och sätt att mildra dem

Låt oss diskutera några av de vanliga utmaningarna som QA-team står inför när vi försöker implementera ett API-testramverk i en organisation.

# 1) Välja rätt verktyg

Att välja rätt verktyg för jobbet är den vanligaste utmaningen. Det finns flera API-testverktyg som finns på marknaden.

Det kan verka väldigt tilltalande att implementera det senaste, dyraste verktyget som finns på marknaden - men om det inte ger de önskade resultaten så är det verktyget till ingen nytta.

Välj därför alltid verktyget som tillgodoser 'måste-ha' -kraven baserat på dina organisatoriska behov.

Här är ett exempel på utvärderingsmatris för verktyg för tillgängliga API-verktyg

VerktygPrissättningAnteckningar
Tvål UI Gratis version tillgänglig för SoapUI Open Source (funktionstestning)* REST, SOAP och andra populära API- och IoT-protokoll.

* Ingår i gratisversionen
SOAP och REST ad hoc-testning
Meddelande påstående
Drag & Drop-testskapande
Testloggar
Testkonfiguration
Test från inspelningar
Enhetsrapportering.

* Komplett lista över funktioner finns på deras hemsida.
Brevbärare Gratis Postman App tillgänglig* Mest använda för REST.
* Funktioner finns på deras hemsida.
Parasoft Det är ett betalt verktyg, kräver köp av en licens och kräver sedan installation innan verktyget kan användas.* Omfattande API-testning: funktionell, belastning, säkerhetstestning, testdatahantering
vREST Baserat på antal användare* Automatiserad REST API-testning.
* Spela in och spela om.
* Tar bort beroende från frontend och backend med mock API.
* Kraftfull responsvalidering.
* Fungerar för testapplikationer som distribueras på localhost / intranät / internet.
* JIRA Integration, Jenkins Integration Import från Swagger, Postman.
HttpMaster Express Edition: Gratis att ladda ner
Professionell version: Baserat på antal användare
* Hjälper vid testning av webbplatser och API-test.
* Andra funktioner inkluderar en förmåga att definiera globala parametrar, ger användaren möjlighet att skapa kontroller för datasvarvalidering med hjälp av den stora uppsättningen valideringstyper som den stöder.
Runscope Baserat på antalet användare och plantyper
* För övervakning och testning av API: er.
* Kan användas för datavalidering för att säkerställa att korrekta data returneras.
* Innehåller funktionen för spårning och avisering i händelse av eventuella API-transaktionsfel (om din applikation kräver betalningsvalidering kan det här verktyget visa sig vara ett bra val).
PingAPI Gratis för 1 projekt (1 000 begäran)* Gynnsamt för automatiserad API-testning och övervakning.

# 2) Testspecifikationer saknas

Som testare måste vi känna till de förväntade resultaten för att effektivt testa en applikation. Detta är ofta en utmaning, eftersom vi måste ha tydliga exakta krav för att få reda på de förväntade resultaten - vilket inte är fallet.

Till exempel överväga kraven nedan:

'Ansökan bör endast acceptera ett giltigt leveransdatum och alla ogiltiga krav bör avvisas'

Dessa krav saknas viktiga detaljer och är mycket tvetydiga - hur definierar vi ett giltigt datum? Vad sägs om formatet? Returnerar vi något avvisningsmeddelande till slutanvändaren etc.?

Exempel på tydliga krav:

1) Ansökan bör endast acceptera ett giltigt leveransdatum.

Leveransdatum anses vara giltigt om det är det

  • Inte tidigare
  • Större eller lika med dagens datum
  • Finns i acceptabelt format: DD / MM / ÅÅÅÅ

två)

Svar Statuskod = 200
Meddelande: OK

3) Leveransdatum som inte uppfyller ovanstående kriterier bör betraktas som ogiltigt. Om en kund skickar ett ogiltigt leveransdatum måste kunden svara med följande felmeddelanden:

3.1

Svar Statuskod INTE 200
Fel: Leveransdatumet är ogiltigt. se till att datumet är i DD / MM / ÅÅÅÅ-format

3.2

Svar Statuskod INTE 200
Fel: Förutsatt att leveransdatumet har varit tidigare

# 3) Inlärningskurva

Som nämnts tidigare är metoden för API-testning annorlunda jämfört med den metod som följts när man testar GUI-baserade applikationer.

Om du anställer specialister antingen internt eller konsulter för API-testning kan inlärningskurvan för API-testmetoden eller API-testverktyget vara minimal. Varje inlärningskurva, i det här fallet, skulle associeras med att skaffa produkt- eller applikationskunskap.

Om en befintlig teammedlem har tilldelats att lära sig API-testning kan inlärningskurvan, beroende på valet av verktyg, vara medium till hög, tillsammans med att testmetoden ändras. Inlärningskurvan för produkten eller applikationen i sig kan vara lågmedium beroende på om testaren har testat den applikationen tidigare eller inte.

# 4) Befintlig skicklighetsuppsättning

Detta kopplas direkt till den tidigare punkten om inlärningskurvan.

Om en testare övergick från GUI-baserad testning skulle testaren behöva ändra testmetoden och lära sig det nya verktyget eller ramverket efter behov. T.ex. Om API: t accepterar förfrågningarna i JSON-format, måste testaren lära sig vad JSON är för att börja skapa testerna.

testa intervjufrågor och svar för erfarna

Fallstudie

Uppgift

För att skala upp en befintlig applikation ville ett företag erbjuda en produkt i API såväl som en standard GUI-applikation. QA Team ombads att tillhandahålla en testtäckningsplan för att säkerställa att de är redo att tillgodose API-testning utöver de vanliga GUI-baserade testerna.

Utmaningar

  • Ingen av de andra mjukvaruprodukterna hade API-baserad arkitektur, och för att hantera testning kring denna uppgift måste teamet etablera API-testprocessen från grunden. Detta innebär att verktygen skulle utvärderas, listas, slutföras och teamet måste utbildas för testerna.
  • Det tilldelades ingen ytterligare budget för att förvärva och implementera verktyget. Detta innebär att teamet var tvungen att välja ett kostnadsfritt eller öppen källkod API-testverktyg och att någon från det befintliga teamet måste utbildas för att ta denna uppgift.
  • Det fanns inga krav för API-fält och datavalidering. Kraven var 'skulle fungera på samma sätt som motsvarande GUI-applikation'.

Den metod som teamet följer för att mildra risker och arbeta kring utmaningarna

  • QA-teamet arbetade tillsammans med projektgruppen för att identifiera följande krav:
    • API-typ (REST / SOAP): RESTEN
    • Test som krävs (funktionell, belastning, säkerhet): Endast funktionstestning
    • Automatiserade tester krävs (Ja / Nej): Valfritt för tillfället
    • Testrapporter (Ja / Nej): Nödvändig
  • QA-team gjorde verktygsutvärdering av tillgängliga API-testverktyg baserat på måste-ha-kraven. Postman API Tool slutfördes som ett verktyg efter eget val eftersom det var gratis och lätt att använda också, vilket minimerade inlärningskurvan och hade potential att automatisera tester och kom med bra inbyggda rapporter.
  • Samma testare som testade applikationen utbildades för att använda Postman för att skapa inledande tester och därmed eliminera eventuella produktkunskapsluckor.
  • För att hantera de saknade kraven byggde projektgruppen dokumentationen på hög nivå på fältnivå med Swagger. Detta lämnade dock vissa luckor när det gäller acceptabla dataformat och detta togs upp av projektgruppen och de förväntade formaten enades om och dokumenterades.

Slutsats

API-baserade applikationer har vunnit popularitet på senare tid. Dessa applikationer är mer skalbara jämfört med traditionella applikationer / programvara och möjliggör enklare integration med andra API: er eller applikationer.

Denna API-testhandledning förklarade i detalj allt om API-testning, Shift Left-testning, webbtjänster och webb-API. Vi undersökte också skillnaderna mellan Web Services vs Web API med exempel.

I den andra delen av handledningen diskuterade vi hela spektrumet av API-testning, hur man introducerar API-testning i din organisation och några vanliga utmaningar i denna process tillsammans med lösningar för dem.

Kolla in vår kommande handledning för att lära dig mer om webbtjänster tillsammans med exempel !!

NÄSTA självstudie

Rekommenderad läsning

^