API-testvejledning: En komplet guide til begyndere

api testing tutorial

Denne dybdegående API-testvejledning forklarer alt om API-test, webservices og hvordan man introducerer API-test i din organisation:

Få en dyb indsigt i API-test sammen med begrebet shift-left-test og webservices fra denne introduktionsvejledning.

Begreber som Web API, hvordan API fungerer (med et eksempel fra den virkelige verden) og hvordan det adskiller sig fra Web Services forklares godt med eksempler i denne vejledning.

=>RUL NEDfor at se hele listen over 5 dybdegående API-testvejledninger til begyndere

Hvad du lærer:

• Liste over API-testvejledninger
• Oversigt over selvstudier i denne API-testserie
• API-testvejledning
  • Skift venstre test
  • Softwareudvikling livscyklus (SDLC) inden skift til venstre testning
  • Faser af venstre skifttest
  • Web-API
  • Hvordan fungerer en API?
  • Webtjenester
  • Webtjenester vs Web API
• Introduktion til API-test i din organisation
  • Fokus Shift til API-test
  • Fuldt spektrum af API-test
    • (i) Funktionstest
    • (ii) Test af belastning og ydeevne
    • (iii) Sikkerhedstest
  • Sådan introduceres API-test i din organisation
  • Almindelige udfordringer og måder at mildne dem på
    • # 1) Valg af det rigtige værktøj
    • # 2) Manglende testspecifikationer
    • # 3) Læringskurve
    • # 4) Eksisterende færdighedssæt
  • Casestudie
• Konklusion
  • Anbefalet læsning

Liste over API-testvejledninger

Tutorial # 1: API-testvejledning: En komplet guide til begyndere
Tutorial # 2: Web Services-tutorial: Komponenter, arkitektur, typer og eksempler
Tutorial # 3: Top 35 ASP.Net- og Web API-interviewspørgsmål med svar
Tutorial # 4: POSTMAN Tutorial: API-test ved hjælp af POSTMAN
Tutorial # 5: Webtests test ved hjælp af Apache HTTP-klient

Oversigt over selvstudier i denne API-testserie

API-testvejledning

Dette afsnit hjælper dig med at få en grundlæggende forståelse af Web Services og Web API, som igen vil være nyttigt med at forstå de vigtigste begreber i de kommende tutorials i denne API Testing-serie.

API (Application Programming Interface) er et sæt af alle procedurer og funktioner, der giver os mulighed for at oprette en applikation ved at få adgang til data eller funktioner i operativsystemet eller platformene. Test af sådanne procedurer er kendt som API-test.

Skift venstre test

En af de vigtige typer af test, der i dag bliver spurgt i API-testinterviews, er Shift Left-test. Denne type test praktiseres i næsten alle projekter, der følger en Agile Methodology.

Før Shift Left Testing blev introduceret, kom softwaretest først i billedet, efter at kodningen var afsluttet, og koden blev leveret til testerne. Denne praksis førte til sidste øjebliks trængsel for at overholde fristen, og det hæmmede også produktkvaliteten i høj grad.

Bortset fra det var den indsats, der blev foretaget (da der blev rapporteret om mangler i den sidste fase før produktion), enorm, da udviklere skulle gennemgå både design- og kodningsfasen igen.

Softwareudvikling livscyklus (SDLC) inden skift til venstre testning

Traditionel SDLC-flow var: Krav -> Design -> Kodning -> Testning.

Ulemper ved traditionel testning

• Test er i yderste højrefløj. Der afholdes mange omkostninger, når en fejl identificeres i sidste øjeblik.
• Den tid, der er brugt på at løse fejlen og teste den igen, før den promoveres til produktion, er enorm.

Derfor dukkede en ny idé op for at flytte testfasen til venstre, hvilket derved førte til Shift Left Testing.

Foreslået læsning => Skift til venstre-test: Et hemmeligt mantra til softwaresucces

Faser af venstre skifttest

Venstre skift-test førte til en vellykket migrering fra fejldetektion til defektforebyggelse. Det hjalp også softwaren til hurtigt at fejle og løse alle fejlene tidligst.

Web-API

Generelt kan en Web API defineres som noget, der fører anmodningen fra et klientsystem til en webserver og sender svaret tilbage fra en webserver til en klientmaskine.

Hvordan fungerer en API?

Lad os tage et meget almindeligt scenario med at bestille en flyrejse på www.makemytrip.com, som er en online rejseservice, der samler information fra flere flyselskaber. Når du går til en flybestilling, indtaster du oplysninger som rejsedato / returdato, klasse osv. Og klikker på søgning.

Dette viser dig prisen på flere flyselskaber og deres tilgængelighed. I dette tilfælde interagerer applikationen med API'er fra flere flyselskaber og giver dermed adgang til flyselskabets data.

Et andet eksempel er www.trivago.com, der sammenligner og viser priser, tilgængelighed osv. For forskellige hoteller fra en bestemt by. Dette websted kommunikerer med API'er fra flere hoteller for at få adgang til databasen og viser priser og tilgængelighed fra deres websted.

Således kan en web-API defineres som 'en grænseflade, der letter kommunikationen mellem en klientmaskine og webserveren'.

Webtjenester

Webtjenester er (som Web API) de tjenester, der tjener fra en maskine til en anden. Men den største forskel, der opstår mellem API og Web Services, er at Web Services bruger et netværk.

Det er sikkert at sige, at alle webtjenester er web-API'er, men alle web-API'er er ikke webtjenester (forklaret i sidste del af artiklen). Webtjenester er således en delmængde af Web API. Se nedenstående diagram for at vide mere om Web API og Web Services.

Web API vs Web Services

Webtjenester vs Web API

Både Web API og Web Services bruges til at lette kommunikationen mellem klienten og serveren. Den største forskel kommer kun i den måde, de kommunikerer på.

Hver af dem kræver et anmodningsorgan, der er acceptabelt på et bestemt sprog, deres forskelle i at give en sikker forbindelse, deres hastighed på at kommunikere til serveren og svare tilbage til klienten osv.

Forskelle mellem webservices og web-API er angivet nedenfor til din reference.

Webtjeneste

• Webtjenester bruger generelt XML (Extensible Markup Language), hvilket betyder, at de er mere sikre.
• Webtjenester er mere sikre, da både webservices og API'er leverer SSL (Secure Socket Layer) under datatransmission, men det giver også WSS (Web Services Security).
• Web Service er et undersæt af Web API. For eksempel, Webtjenester er kun baseret på tre anvendelsesformer, dvs. SOAP, REST og XML-RPC.
• Webtjenester har altid brug for et netværk for at fungere.
• Webtjenester understøtter “En kode forskellige applikationer”. Dette betyder, at en mere generisk kode skrives på tværs af forskellige applikationer.

Web-API

• En Web API bruger normalt JSON (JavaScript Object Notation), hvilket betyder, at Web API er hurtigere.
• Web API er hurtigere, da JSON er letvægtet, i modsætning til XML.
• Web-API'er er superset af webservices. For eksempel, Alle tre typografier af Web Services er også til stede i Web API, men bortset fra det bruger den andre typografier som JSON - RPC.
• Web API kræver ikke nødvendigvis et netværk for at fungere.
• Web API understøtter muligvis interoperabilitet afhængigt af systemets eller applikationens art.

Introduktion til API-test i din organisation

I vores daglige liv er vi alle så vant til at interagere med apps med API'er, og alligevel tænker vi ikke engang på de back-end-processer, der driver den underliggende funktionalitet.

For eksempel, Lad os overveje, at du gennemsøger produkterne på Amazon.com, og du ser et produkt / et tilbud, som du virkelig kan lide, og du ønsker at dele det med dit Facebook-netværk.

I det øjeblik du klikker på Facebook-ikonet i delingssektionen på siden og indtaster dine Facebook-kontooplysninger for at dele, interagerer du med en API, der problemfrit forbinder Amazon-webstedet til Facebook.

Fokus Shift til API-test

Før vi diskuterer mere om API-test, skal vi diskutere årsagerne til, at de API-baserede applikationer har fået popularitet i nyere tid.

Der er flere grunde til, at organisationer skifter til API-baserede produkter og applikationer. Og få af dem er anført nedenfor til din reference.

# 1) API-baserede applikationer er mere skalerbare sammenlignet med traditionelle applikationer / software. Hastigheden for kodeudvikling er hurtigere, og den samme API kan servicere flere anmodninger uden større kode- eller infrastrukturændringer.

#to) Udviklingsteam har ikke brug for at starte kodning fra bunden hver gang de begynder at arbejde på at udvikle en funktion eller applikation. API'er genbruger oftest eksisterende, gentagelige funktioner, biblioteker, lagrede procedurer osv., Og dermed kan denne proces generelt gøre dem mere produktive.

For eksempel, Hvis du er en udvikler, der arbejder på et e-handelswebsted, og du vil tilføje Amazon som betalingsprocessor - behøver du ikke skrive koden fra bunden.

Alt hvad du skal gøre er at konfigurere integration mellem dit websted og Amazon API ved hjælp af integrationsnøgler og ringe til Amazon API til behandling af betalinger under kassen.

# 3) API'er muliggør nem integration med de andre systemer både til understøttede enkeltstående applikationer såvel som med API-baserede softwareprodukter.

For eksempel Lad os overveje, at du vil sende en forsendelse fra Toronto til New York. Du går online, navigerer til et velkendt fragt- eller logistikwebsted og indtaster de krævede oplysninger.

Efter at have givet de obligatoriske oplysninger, når du klikker på knappen Hent priser - i bagenden slutter dette logistikwebsted muligvis med flere operatør- og tjenesteudbyder-API'er og applikationer for at få de dynamiske priser for kombinationen af ​​oprindelse til destination af lokationer.

Fuldt spektrum af API-test

Test af API'er er ikke begrænset til at sende en anmodning til API og analysere svaret for korrekthed alene. API'erne skal testes for deres ydeevne under forskellige belastninger for sårbarheder.

Lad os diskutere dette detaljeret.

bedste wow private server til pvp

(i) Funktionstest

Funktionel test kan være en udfordrende opgave på grund af manglen på en GUI-grænseflade.

Lad os se, hvordan funktionel test tilgang for API'er adskiller sig fra GUI-baseret applikation, og vi vil også diskutere nogle eksempler omkring det.

til) Den mest åbenlyse forskel er, at der ikke er nogen GUI at interagere med. Testere, der normalt udfører GUI-baseret funktionel test, finder det lidt sværere at overgå til ikke-GUI-applikationstest sammenlignet med en person, der allerede er bekendt med det.

Oprindeligt, selv før du begynder at teste API'en, skal du teste og verificere selve godkendelsesprocessen. Godkendelsesmetoden vil variere fra en API til en anden API og vil involvere en slags nøgle eller token til godkendelse.

Hvis du ikke kan oprette forbindelse til API'en, kan yderligere test ikke fortsætte. Denne proces kan betragtes som sammenlignelig med brugergodkendelse i standardapplikationerne, hvor du har brug for gyldige legitimationsoplysninger for at logge ind og bruge applikationen.

b) Test af feltvalideringer eller validering af inputdata er meget vigtigt under test af API'er. Hvis en egentlig formbaseret (GUI) grænseflade var tilgængelig, kunne feltvalideringer implementeres i frontend eller back-end, hvorved det sikres, at en bruger ikke får adgang til ugyldige feltværdier.

For eksempel, Hvis en ansøgning har brug for datoformatet til at være DD / MM / ÅÅÅÅ, kan vi anvende denne validering på formularen, der indsamler oplysninger for at sikre, at ansøgningen modtager og behandler en gyldig dato.

Dette er dog ikke det samme for API-applikationer. Vi er nødt til at sikre, at API'en er velskrevet og er i stand til at håndhæve alle disse valideringer, skelne mellem gyldige og ugyldige data og returnere statuskoden og valideringsfejlmeddelelsen til slutbrugeren gennem et svar.

c) At teste rigtigheden af ​​svarene fra API for gyldigt og ugyldigt svar er virkelig afgørende. Hvis der modtages en statuskode på 200 (hvilket betyder alt okay) som et svar fra test API, men hvis svarsteksten siger, at der er stødt på en fejl, er dette en fejl.

Derudover, hvis selve fejlmeddelelsen er forkert, kan det være meget vildledende for slutkunden, der forsøger at integrere med denne API.

I skærmbilledet nedenfor har brugeren indtastet ugyldig vægt, hvilket er mere end de acceptable 2267 kg. API'en reagerer med fejlstatuskoden og fejlmeddelelsen. Fejlmeddelelsen nævner imidlertid forkert vægtenhederne som kg i stedet for KG. Dette er en fejl, der kan forvirre slutkunden.

(ii) Test af belastning og ydeevne

API'er er beregnet til at være skalerbare efter design.

Dette gør igen Load og Test af ydeevne vigtigt, især hvis det system, der designes, forventes at servicere tusindvis af anmodninger pr. minut eller time afhængigt af kravet. Rutinemæssigt at udføre belastnings- og ydelsestest på API'en kan hjælpe med at benchmarkere ydeevne, spidsbelastning og brudpunkt.

Disse data er nyttige, når du planlægger at opskalere en applikation. At have disse oplysninger tilgængelige hjælper med at understøtte beslutninger og planlægning, især hvis organisationen planlægger at tilføje flere kunder, hvilket vil betyde flere indgående anmodninger.

For eksempel , lad os sige, at vi på baggrund af de stillede krav ved, at den API, der er designet, skal servicere mindst 500 anmodninger i timen og opretholde den gennemsnitlige svartid på mindre end 0,01 sekunder.

Baseret på vores belastnings- og ydelsestest fandt vi ud af, at så længe API modtager mindre end 500 anmodninger i timen, er det i stand til at opretholde SLA for den gennemsnitlige svartid. Men hvis den modtager yderligere 200 anmodninger, stiger den gennemsnitlige svartid, og brudpunktet nås, når den indkommende anmodning overstiger 1200 pr. Time.

php interview spørgsmål og svar til erfaring

Normalt ses det, at der under de indledende designfaser ofte lægges vægt på API'ens funktionelle aspekter. Efterhånden som et år går, begynder et produkt at understøtte flere live klienter, det er når testen for API-ydeevne og Load-test kommer ind i billedet på en mere rutinemæssig måde.

(iii) Sikkerhedstest

Programmeringsgrænseflader eller API'er er sårbare og er det nemmeste adgangspunkt for ondsindede hackere, der ønsker adgang til data eller får kontrol over en applikation.

Dette kan føre enhver virksomhed til juridiske problemer, hvor utilsigtede personer og / eller organisationer på grund af et sikkerhedsbrud kan få adgang til klientens data via en ærværdig API.

Sikkerhedstest er en specialiseret testgren og skal håndteres af specialister. Sikkerhedstestressourcerne kan være fra organisationen eller uafhængige konsulenter.

Læs også = >> Hvad er test af pagtkontrakter

Sådan introduceres API-test i din organisation

Processen til introduktion af API-test i enhver organisation svarer til den proces, der anvendes til implementering eller udrulning af ethvert andet testværktøj og -ramme.

Tabellen nedenfor opsummerer de vigtigste trin sammen med det forventede resultat af hvert trin.

Almindelige udfordringer og måder at mildne dem på

Lad os diskutere nogle af de almindelige udfordringer, som QA-teams står over for, mens vi prøver at implementere en API-testramme i en organisation.

# 1) Valg af det rigtige værktøj

At vælge det rigtige værktøj til jobbet er den mest almindelige udfordring. Der er flere API-testværktøjer, der er tilgængelige på markedet.

Det kan synes meget tiltalende at implementere det nyeste og dyreste værktøj, der er tilgængeligt på markedet, men hvis det ikke giver de ønskede resultater, er det værktøj ikke til nogen nytte.

Derfor skal du altid vælge det værktøj, der imødekommer kravene til 'must-have' baseret på dine organisatoriske behov.

Her er en eksempelværktøjsevalueringsmatrix for de tilgængelige API-værktøjer

# 2) Manglende testspecifikationer

Som testere er vi nødt til at kende de forventede resultater for effektivt at teste en applikation. Dette er ofte en udfordring, for for at kende de forventede resultater skal vi have klare præcise krav - hvilket ikke er tilfældet.

For eksempel , overvej kravene nedenfor:

'Ansøgningen skal kun acceptere en gyldig leveringsdato, og alle ugyldige krav skal afvises'

Disse krav mangler nøgleoplysninger og er meget tvetydige - hvordan definerer vi en gyldig dato? Hvad med formatet? Returnerer vi nogen afvisningsmeddelelse til slutbrugeren osv.?

Eksempel på klare krav:

1) Ansøgningen bør kun acceptere en gyldig leveringsdato.

Leveringsdatoen betragtes som gyldig, hvis den er

• Ikke tidligere
• Større eller lig med dagens dato
• Er i acceptabelt format: DD / MM / ÅÅÅÅ

to)

Svar Status kode = 200
Besked: OK

3) Leveringsdatoen, der ikke opfylder ovenstående kriterier, skal betragtes som ugyldig. Hvis en kunde sender en ugyldig leveringsdato, skal den svare med følgende fejlmeddelelser:

3.1

Svar Statuskode IKKE 200
Fejl: Leveringsdatoen er ugyldig. Sørg for, at datoen er i DD / MM / ÅÅÅÅ-format

3.2

Svar Statuskode IKKE 200
Fejl: Forudsat leveringsdato er tidligere

# 3) Læringskurve

Som nævnt tidligere er tilgangen til API-test en anden sammenlignet med den tilgang, der blev fulgt under test af GUI-baserede applikationer.

Hvis du ansætter specialister enten internt eller konsulenter til API-test, kan læringskurven for API-testmetoden eller API-testværktøjet være minimal. Enhver læringskurve, i dette tilfælde, vil være forbundet med at erhverve produkt- eller applikationsviden.

Hvis et eksisterende teammedlem tildeles at lære API-test, kan læringskurven, afhængigt af det valgte værktøj, være medium til høj sammen med ændring af testmetoden. Læringskurven for selve produktet eller applikationen kan være lav-medium afhængigt af om denne testeren har testet den applikation før eller ej.

# 4) Eksisterende færdighedssæt

Dette hænger direkte sammen med det foregående punkt om indlæringskurven.

Hvis en tester overgik fra GUI-baseret test, ville testeren skulle ændre testmetoden og lære det nye værktøj eller den nye ramme efter behov. For eksempel. Hvis API accepterer anmodningerne i JSON-format, skal testeren lære, hvad JSON er, for at starte oprettelsen af ​​testene.

Casestudie

Opgave

For at opskalere en eksisterende applikation ønskede en virksomhed at tilbyde et produkt i API såvel som en standard GUI-applikation. QA Team blev bedt om at levere en testdækningsplan for at sikre, at de er klar til at imødekomme API-test ud over de almindelige GUI-baserede tests.

Udfordringer

• Ingen af ​​de andre softwareprodukter havde API-baseret arkitektur, og derfor er teamet nødt til at etablere API-testprocessen fra bunden for at imødekomme test omkring denne opgave. Dette betyder, at værktøjerne skulle evalueres, kortlistes, færdiggøres, og holdet skulle trænes til testene.
• Der var ikke afsat yderligere budget til anskaffelse og implementering af værktøjet. Dette betyder, at teamet skulle vælge et gratis eller open source API-testværktøj, og en person fra det eksisterende team skulle trænes i at tage denne opgave.
• Der var ingen krav til API-felter og datavalidering. Kravene var 'skulle fungere som det tilsvarende GUI-program'.

Den tilgang, som holdet fulgte for at afbøde risici og omgå udfordringerne

• QA-teamet arbejdede sammen med projektteamet for at identificere følgende krav:
  • API-type (REST / SOAP): HVILE
  • Nødvendige tests (funktionel, belastning, sikkerhed): Kun funktionel test
  • Automatiske tests påkrævet (Ja / Nej): Valgfri for nu
  • Testrapporter (Ja / Nej): Påkrævet
• QA-team foretog værktøjsevaluering af de tilgængelige API-testværktøjer baseret på kravene, du skal have. Postman API Tool blev færdiggjort som et værktøj efter eget valg, da det også var gratis og let at bruge, hvilket minimerede læringskurven og havde potentialet til at automatisere test og kom med gode indbyggede rapporter.
• Den samme tester, der testede applikationen, blev uddannet til at bruge Postman til at skabe indledende tests og derved eliminere eventuelle produktkendskabshuller.
• For at håndtere de manglende krav byggede projektteamet dokumentationen på højt feltniveau ved hjælp af Swagger. Dette efterlod dog nogle huller med hensyn til acceptable dataformater, og dette blev taget op af projektteamet, og de forventede formater blev aftalt og dokumenteret.

Konklusion

API-baserede applikationer har fået popularitet i nyere tid. Disse applikationer er mere skalerbare i forhold til de traditionelle applikationer / software og giver lettere integration med de andre API'er eller applikationer.

Denne API-testvejledning forklarede alt om API-test, Shift Left-test, Web Services og Web API i detaljer. Vi undersøgte også forskellene mellem Web Services vs Web API med eksempler.

I anden del af vejledningen diskuterede vi hele spektret af API-test, hvordan man introducerer API-test i din organisation og nogle almindelige udfordringer i denne proces sammen med løsninger til dem.

Tjek vores kommende tutorial for at vide mere om Web Services sammen med eksempler !!

NÆSTE vejledning

Anbefalet læsning

• Alpha-test og betatestning (En komplet guide)
• Funktionel testning mod ikke-funktionel testning
• Usability Testing Tutorial: En komplet startvejledning
• Build Verification Testing (BVT Testing) Komplet guide
• DevOps Testing Tutorial: Hvordan DevOps vil påvirke QA-test?
• Vejledning til testning af tilgængelighed (En komplet trinvis vejledning)
• Bedste softwaretestværktøjer 2021 (QA Test Automation Tools)
• Hvad er softwaretest? 100+ gratis manuelle testvejledninger