API Testing Tutorial: En komplett guide for nybegynnere

api testing tutorial

Denne grundige API-testveiledningen forklarer alt om API-testing, webtjenester og hvordan du introduserer API-testing i organisasjonen din:

Få en dyp innsikt i API-testing sammen med konseptet med skift-venstre-testing og webtjenester fra denne innledende veiledningen.

Konsepter som Web API, hvordan API fungerer (med virkelige eksempler) og hvordan er det forskjellig fra Web Services, er godt forklart med eksempler i denne veiledningen.

=>BLA NEDOVERfor å se hele listen over 5 dybdegående API-testveiledninger for nybegynnere

Hva du vil lære:

• Liste over API-testveiledninger
• Oversikt over opplæringsprogrammer i denne API-testserien
• API Testing Tutorial
  • Skift venstre testing
  • Software Development Life Cycle (SDLC) Before Shift Left Testing
  • Faser av venstre skift-testing
  • Web-API
  • Hvordan fungerer et API?
  • Nettjenester
  • Web Services vs Web API
• Vi presenterer API-testing i organisasjonen din
  • Fokus Shift til API-testing
  • Fullt spektrum av API-testing
    • (i) Funksjonstesting
    • (ii) Last- og ytelsestesting
    • (iii) Sikkerhetstesting
  • Hvordan introdusere API-testing i organisasjonen din
  • Vanlige utfordringer og måter å dempe dem på
    • # 1) Velge riktig verktøy
    • # 2) Manglende testspesifikasjoner
    • # 3) Læringskurve
    • # 4) Eksisterende ferdighetssett
  • Casestudie
• Konklusjon
  • Anbefalt lesing

Liste over API-testveiledninger

Opplæring # 1: API Testing Tutorial: En komplett guide for nybegynnere
Opplæring nr. 2: Opplæring i webtjenester: komponenter, arkitektur, typer og eksempler
Opplæring # 3: Topp 35 ASP.Net og Web API intervju spørsmål med svar
Opplæring # 4: POSTMAN-veiledning: API-testing ved hjelp av POSTMAN
Opplæring # 5: Nettjenestetesting med Apache HTTP-klient

Oversikt over opplæringsprogrammer i denne API-testserien

API Testing Tutorial

Denne delen vil hjelpe deg med å få en grunnleggende forståelse av Web Services og Web API, som igjen vil være nyttig for å forstå hovedkonseptene i de kommende opplæringene i denne API-testserien.

API (Application Programming Interface) er et sett med alle prosedyrer og funksjoner som lar oss lage en applikasjon ved å få tilgang til dataene eller funksjonene til operativsystemet eller plattformene. Testing av slike prosedyrer kalles API-testing.

Skift venstre testing

En av de viktigste typene testing som blir spurt i dag i API-testintervjuer, er Shift Left Testing. Denne typen tester praktiseres i nesten alle prosjekter som følger en smidig metodikk.

Før Shift Left Testing ble introdusert, kom programvaretesting inn i bildet først etter at kodingen var fullført og koden ble levert til testerne. Denne øvelsen førte til kjas i siste øyeblikk for å overholde fristen, og det hemmet også produktkvaliteten i stor grad.

Bortsett fra det, var innsatsen som ble gjort (da mangler ble rapportert i siste fase før produksjonen) enorm, ettersom utviklere måtte gjennomgå både design- og kodingsfasen på nytt.

Software Development Life Cycle (SDLC) Before Shift Left Testing

Tradisjonell SDLC-strømning var: Krav -> Design -> Koding -> Testing.

Ulemper ved tradisjonell testing

• Testing er helt til høyre. Det påløper mange kostnader når en feil blir identifisert i siste øyeblikk.
• Tiden det tar å løse feilen og teste den på nytt før den markedsføres til produksjon, er enorm.

Derfor dukket det opp en ny ide for å skifte testfasen til venstre, noe som dermed førte til Shift Left Testing.

Foreslått lese => Skift venstre-testing: Et hemmelig mantra for programvaresuksess

Faser av venstre skift-testing

Venstre skift-testing førte til en vellykket migrering fra feildeteksjon til mangelforebygging. Det hjalp også programvaren til å mislykkes raskt og løse alle feil tidligst.

beste programmet for å konvertere youtube til mp3

Web-API

Generelt sett kan en Web API defineres som noe som tar forespørselen fra et klientsystem til en webserver og sender tilbake svaret fra en webserver til en klientmaskin.

Hvordan fungerer et API?

La oss ta et veldig vanlig scenario med å bestille en flytur på www.makemytrip.com, som er en online reisetjeneste som samler informasjon fra flere flyselskaper. Når du går for en flybestilling, skriver du inn informasjon som reisedato / returdato, klasse osv. Og klikker på søk.

Dette vil vise deg prisen på flere flyselskaper og deres tilgjengelighet. I dette tilfellet samhandler applikasjonen med APIer fra flere flyselskaper og gir dermed tilgang til flyselskapets data.

Et annet eksempel er www.trivago.com som sammenligner og lister opp pris, tilgjengelighet osv. På forskjellige hoteller fra en bestemt by. Dette nettstedet kommuniserer med APIer på flere hoteller for å få tilgang til databasen og viser priser og tilgjengelighet fra deres nettsted.

Dermed kan et web-API defineres som 'et grensesnitt som letter kommunikasjonen mellom en klientmaskin og webserveren'.

Nettjenester

Webtjenester er (som Web API) tjenestene som tjener fra en maskin til en annen. Men den største forskjellen som oppstår mellom API og Web Services er at Web Services bruker et nettverk.

Det er trygt å si at alle webtjenester er web-API-er, men alle web-API-er er ikke web-tjenester (forklart i siste del av artikkelen). Dermed er Web Services en delmengde av Web API. Se diagrammet nedenfor for å lære mer om Web API og Web Services.

Web API vs Web Services

Web Services vs Web API

Både Web API og Web Services brukes til å lette kommunikasjonen mellom klienten og serveren. Den største forskjellen kommer bare i måten de kommuniserer på.

Hver av dem krever et forespørselsorgan som er akseptabelt på et bestemt språk, deres forskjeller i å gi en sikker forbindelse, deres hastighet på å kommunisere til serveren og svare tilbake til klienten, etc.

Forskjeller mellom webtjenester og web-API er oppført nedenfor for din referanse.

Nettjeneste

• Webtjenester bruker vanligvis XML (Extensible Markup Language), noe som betyr at de er sikrere.
• Webtjenester er sikrere ettersom både webtjenester og API-er gir SSL (Secure Socket Layer) under dataoverføring, men det gir også WSS (Web Services Security).
• Web Service er et delsett av Web API. For eksempel, Webtjenester er bare basert på tre bruksformer, dvs. SOAP, REST og XML-RPC.
• Webtjenester trenger alltid et nettverk for å fungere.
• Webtjenester støtter “One Code different applications”. Dette betyr at en mer generisk kode skrives på tvers av forskjellige applikasjoner.

Web-API

• En Web API bruker vanligvis JSON (JavaScript Object Notation), noe som betyr at Web API er raskere.
• Web API er raskere ettersom JSON er lettvektet, i motsetning til XML.
• Web-API-er er supersettet til Web Services. For eksempel, Alle tre stilene til Web Services er også til stede i Web API, men bortsett fra det, bruker den andre stiler som JSON - RPC.
• Web API krever ikke nødvendigvis et nettverk for å fungere.
• Web API støtter kanskje ikke interoperabilitet, avhengig av systemets eller applikasjonens art.

Vi presenterer API-testing i organisasjonen din

I vårt daglige liv er vi alle vant til å samhandle med appene med API-er, og likevel tenker vi ikke engang på back-end-prosessene som driver den underliggende funksjonaliteten.

For eksempel, La oss vurdere at du surfer gjennom produktene på Amazon.com, og du ser et produkt / avtale du virkelig liker, og du ønsker å dele det med Facebook-nettverket ditt.

I det øyeblikket du klikker på Facebook-ikonet på delingsdelen av siden og skriver inn din Facebook-kontoinformasjon for å dele, samhandler du med et API som sømløst kobler Amazon-nettstedet til Facebook.

Fokus Shift til API-testing

Før vi diskuterer mer om API-testing, la oss diskutere årsakene til at de API-baserte applikasjonene har blitt populære i nyere tid.

Det er flere grunner til at organisasjoner overgår til API-baserte produkter og applikasjoner. Og få av dem er vervet nedenfor for din referanse.

#1) API-baserte applikasjoner er mer skalerbare sammenlignet med tradisjonelle applikasjoner / programvare. Kodenes utvikling er raskere, og den samme API-en kan betjene flere forespørsler uten større kode eller infrastrukturelle endringer.

#to) Utviklingsteam trenger ikke å begynne å kode fra bunnen av hver gang de begynner å jobbe med å utvikle en funksjon eller applikasjon. APIer bruker ofte eksisterende, repeterbare funksjoner, biblioteker, lagrede prosedyrer osv., Og dermed kan denne prosessen gjøre dem mer produktive generelt.

For eksempel, Hvis du er en utvikler som jobber på et netthandelsnettsted og vil legge til Amazon som betalingsprosessor - trenger du ikke å skrive koden fra bunnen av.

Alt du trenger å gjøre er å sette opp integrasjon mellom nettstedet ditt og Amazon API ved hjelp av integrasjonsnøkler og ringe Amazon API for å behandle betalinger under kassen.

# 3) API-er tillater enkel integrasjon med de andre systemene både for støttede frittstående applikasjoner så vel som med API-baserte programvareprodukter.

For eksempel , La oss vurdere at du vil sende en forsendelse fra Toronto til New York. Du går online, navigerer til et godt kjent frakt- eller logistikknettsted og skriver inn nødvendig informasjon.

Etter å ha gitt den obligatoriske informasjonen, når du klikker på Get Rates-knappen - på baksiden, kan dette logistikknettstedet være i kontakt med flere operatør- og tjenesteleverandør-API-er og applikasjoner for å få dynamiske priser for kombinasjonen av opprinnelse til mål.

Fullt spektrum av API-testing

Testing av API-er er ikke begrenset til å sende en forespørsel til API og analysere svaret for korrekthet alene. API-ene må testes for ytelse under forskjellige belastninger for sårbarheter.

La oss diskutere dette i detalj.

(i) Funksjonstesting

Funksjonell testing kan være en utfordrende oppgave på grunn av mangel på et GUI-grensesnitt.

La oss se hvordan funksjonell testing tilnærming for API-er er forskjellig fra GUI-basert applikasjon, og vi vil også diskutere noen eksempler rundt det.

til) Den mest åpenbare forskjellen er at det ikke er noe GUI å samhandle med. Testere som vanligvis gjør GUI-basert funksjonstesting, synes det er litt vanskeligere å gå over til ikke-GUI-applikasjonstesting sammenlignet med noen som allerede er kjent med det.

I utgangspunktet, selv før du begynner å teste API-en, må du teste og verifisere selve autentiseringsprosessen. Autentiseringsmetoden vil variere fra ett API til et annet API og vil innebære en slags nøkkel eller token for autentisering.

Hvis du ikke klarer å koble til API-et vellykket, kan videre testing ikke fortsette. Denne prosessen kan betraktes som sammenlignbar med brukerautentisering i standardapplikasjonene der du trenger gyldig legitimasjon for å logge på og bruke applikasjonen.

b) Testing av feltvalidering eller validering av inndata er veldig viktig under testing av APIer. Hvis et faktisk skjemabasert (GUI) grensesnitt var tilgjengelig, kan feltvalideringer implementeres i frontenden eller bakenden, og derved sikre at en bruker ikke får lov til å angi ugyldige feltverdier.

For eksempel, Hvis en applikasjon trenger datoformatet for å være DD / MM / ÅÅÅÅ, kan vi bruke denne valideringen på skjemaet for å samle inn informasjon for å sikre at søknaden mottar og behandler en gyldig dato.

Dette er imidlertid ikke det samme for API-applikasjoner. Vi må sørge for at API er godt skrevet og er i stand til å håndheve alle disse valideringene, skille mellom gyldige og ugyldige data og returnere statuskoden og valideringsfeilmeldingen til sluttbrukeren gjennom et svar.

c) Å teste riktigheten av svarene fra API for gyldig og ugyldig respons er avgjørende. Hvis en statuskode på 200 (som betyr alt OK) mottas som et svar fra test-API, men hvis svarsteksten sier at det er oppstått en feil, er dette en feil.

I tillegg, hvis selve feilmeldingen er feil, kan det være veldig misvisende for sluttkunden som prøver å integrere med dette API-et.

I skjermbildet nedenfor har brukeren angitt ugyldig vekt, som er mer enn akseptable 2267 kg. API-et svarer med feilstatuskoden og feilmeldingen. Feilmeldingen nevner imidlertid feil vektenhetene som kg i stedet for KG. Dette er en mangel som kan forvirre sluttkunden.

(ii) Last- og ytelsestesting

APIer er ment å være skalerbare av design.

Dette gjør igjen Load and Ytelsestesting viktig, spesielt hvis systemet forventes å betjene tusenvis av forespørsler per minutt eller time, avhengig av kravet. Rutinemessig utføring av laste- og ytelsestester på API-et kan hjelpe til med å måle ytelse, toppbelastning og bruddpunkt.

Disse dataene er nyttige når du planlegger å skalere opp en applikasjon. Å ha denne informasjonen tilgjengelig vil bidra til å støtte beslutninger og planlegging, spesielt hvis organisasjonen planlegger å legge til flere kunder, noe som vil bety flere innkommende forespørsler.

For eksempel , la oss si at basert på kravene som er gitt, vet vi at API-en som er designet må betjene minst 500 forespørsler per time og opprettholde den gjennomsnittlige responstiden på mindre enn 0,01 sekunder.

Basert på våre belastnings- og ytelsestester fant vi ut at så lenge API mottar mindre enn 500 forespørsler per time, er det i stand til å opprettholde SLA for gjennomsnittlig responstid. Imidlertid, hvis den mottar ytterligere 200 forespørsler, øker den gjennomsnittlige responstiden og brytepunktet oppnås når den innkommende forespørselen overstiger 1200 per time.

Vanligvis er det sett at i de innledende designfasene, er det ofte lagt vekt på de funksjonelle aspektene ved API. Etter hvert som tiden går, begynner et produkt å støtte flere live-klienter, det er når testing for API-ytelse og Load testing kommer inn i bildet på en mer rutinemessig måte.

(iii) Sikkerhetstesting

Programmeringsgrensesnitt eller API-er er sårbare og er det enkleste tilgangspunktet for ondsinnede hackere som vil ha tilgang til data eller få kontroll over et program.

Dette kan føre ethvert selskap til juridiske problemer, der på grunn av et sikkerhetsbrudd utilsiktede personer og / eller organisasjoner har tilgang til klientens data via en ærverdig API.

Sikkerhetstesting er en spesialisert gren av testing og skal håndteres av spesialister. Sikkerhetstestingsressursene kan være fra organisasjonen eller uavhengige konsulenter.

Les også = >> Hva er paktkontrakttesting

Hvordan introdusere API-testing i organisasjonen din

Prosessen for å introdusere API-testing i enhver organisasjon er lik prosessen som brukes for å implementere eller utrulle andre testverktøy og rammeverk.

Tabellen nedenfor oppsummerer hovedtrinnene sammen med forventet utfall av hvert trinn.

Vanlige utfordringer og måter å dempe dem på

La oss diskutere noen av de vanlige utfordringene som QA-team står overfor mens de prøver å implementere et API-testrammeverk i en organisasjon.

# 1) Velge riktig verktøy

Å velge riktig verktøy for jobben er den vanligste utfordringen. Det er flere API-testverktøy som er tilgjengelige i markedet.

Det kan virke veldig tiltalende å implementere det nyeste og dyreste verktøyet som er tilgjengelig i markedet, men hvis det ikke gir de ønskede resultatene, er det ikke til nytte.

Derfor må du alltid velge verktøyet som adresserer 'må-ha'-kravene basert på dine organisatoriske behov.

Her er et eksempel på verktøy for evaluering av verktøy for tilgjengelige API-verktøy

# 2) Manglende testspesifikasjoner

Som testere må vi vite de forventede resultatene for å effektivt teste en applikasjon. Dette er ofte en utfordring, for å vite de forventede resultatene, må vi ha klare presise krav - noe som ikke er tilfelle.

For eksempel , vurder kravene gitt nedenfor:

'Søknaden skal bare godta en gyldig leveringsdato, og alle ugyldige krav bør avvises'

Disse kravene mangler viktige detaljer og er veldig tvetydige - hvordan definerer vi en gyldig dato? Hva med formatet? Returnerer vi noen avvisningsmelding til sluttbruker osv.?

Eksempel på klare krav:

1) Søknaden skal bare godta en gyldig leveringsdato.

Leveringsdatoen anses å være gyldig hvis den er

• Ikke tidligere
• Større eller lik dagens dato
• Er i akseptabelt format: DD / MM / ÅÅÅÅ

to)

Svarstatuskode = 200
Melding: OK

3) Leveringsdatoen som ikke oppfyller kriteriene ovenfor, bør betraktes som ugyldig. Hvis en kunde sender en ugyldig leveringsdato, må den svare med følgende feilmelding (er):

3.1

Svar Statuskode IKKE 200
Feil: Leveringsdatoen som er oppgitt er ugyldig. sørg for at datoen er i DD / MM / ÅÅÅÅ-format

3.2

verktøy for automatiseringstesting for mobilapplikasjoner

Svar Statuskode IKKE 200
Feil: Oppgitt leveringsdato er tidligere

# 3) Læringskurve

Som nevnt tidligere er tilnærmingen for API-testing annerledes sammenlignet med tilnærmingen som følges mens du tester GUI-baserte applikasjoner.

Hvis du ansetter spesialister enten interne eller konsulenter for API-testing, kan læringskurven til API-testtilnærmingen eller API-testverktøyet være minimal. Enhver læringskurve, i dette tilfellet, vil være forbundet med å tilegne seg produkt- eller applikasjonskunnskap.

Hvis et eksisterende teammedlem er tildelt å lære API-testing, kan læringskurven, avhengig av hvilket verktøy du velger, være middels til høy, sammen med å endre testtilnærmingen. Læringskurven for selve produktet eller applikasjonen kan være lavt, avhengig av om denne testeren har testet den applikasjonen før eller ikke.

# 4) Eksisterende ferdighetssett

Dette henger sammen med forrige punkt om læringskurven.

Hvis en tester gikk over fra GUI-basert testing, ville testeren trenge å endre testtilnærmingen og lære det nye verktøyet eller rammeverket etter behov. F.eks. Hvis APIen godtar forespørslene i JSON-format, må testeren lære hva JSON er for å begynne å lage testene.

Casestudie

Oppgave

For å skalere opp en eksisterende applikasjon ønsket et selskap å tilby et produkt i API, så vel som en standard GUI-applikasjon. QA Team ble bedt om å gi en testdekningsplan for å sikre at de er klare til å imøtekomme API-testing utover de vanlige GUI-baserte testene.

Utfordringer

• Ingen av de andre programvareproduktene hadde API-basert arkitektur, og for å imøtekomme testing rundt denne oppgaven, må teamet etablere API-testprosessen fra bunnen av. Dette betyr at verktøyene skulle evalueres, shortlistes, finaliseres, og teamet måtte trenes for testene.
• Det var ikke tildelt noe ekstra budsjett for anskaffelse og implementering av verktøyet. Dette betyr at teamet måtte velge et gratis eller åpen kildekode API-testverktøy, og noen fra det eksisterende teamet måtte trenes til å ta denne oppgaven.
• Det var ingen krav til API-felt og datavalidering. Kravene var 'skulle fungere likt det tilsvarende GUI-programmet'.

Tilnærmingen som følges av teamet for å redusere risikoen og omgå utfordringene

• QA-teamet jobbet sammen med prosjektgruppen for å identifisere følgende krav:
  • API-type (REST / SOAP): HVILE
  • Tester som kreves (funksjonell, belastning, sikkerhet): Kun funksjonell testing
  • Automatiske tester kreves (Ja / Nei): Valgfritt for nå
  • Testrapporter (Ja / Nei): Påkrevd
• QA team gjorde verktøy evaluering av tilgjengelig API-testverktøy basert på må-ha-kravene. Postman API Tool ble avsluttet som et verktøy de selv valgte, da det var gratis og enkelt å bruke også, og dermed minimerte læringskurven, og hadde potensial til å automatisere tester, og kom med gode innebygde rapporter.
• Den samme testeren som testet applikasjonen, ble opplært til å bruke Postman til å lage innledende tester og dermed eliminere eventuelle produktkunnskapshull.
• For å håndtere de manglende kravene bygde prosjektgruppen dokumentasjonen på høyt nivå på feltnivå ved hjelp av Swagger. Dette etterlot imidlertid noen hull i akseptable dataformater, og dette ble tatt opp av prosjektgruppen, og de forventede formatene ble avtalt og dokumentert.

Konklusjon

API-baserte applikasjoner har fått popularitet i nyere tid. Disse applikasjonene er mer skalerbare sammenlignet med de tradisjonelle applikasjonene / programvaren og muliggjør enklere integrering med de andre API-ene eller applikasjonene.

Denne veiledningen om API-testing forklarte alt om API-testing, Shift Left-testing, Web Services og Web API i detalj. Vi undersøkte også forskjellene mellom Web Services vs Web API med eksempler.

I den andre delen av opplæringen diskuterte vi hele spekteret av API-testing, hvordan du introduserer API-testing i organisasjonen din og noen vanlige utfordringer i denne prosessen sammen med løsninger for dem.

Ta en titt på vår kommende veiledning for å vite mer om Web Services sammen med eksempler!

NESTE veiledning

Anbefalt lesing

• Alpha Testing og Beta Testing (En komplett guide)
• Funksjonstesting mot ikke-funksjonell testing
• Veiledning for brukervennlighetstesting: En komplett guide
• Build Verification Testing (BVT Testing) Komplett guide
• DevOps Testing Tutorial: Hvordan DevOps vil påvirke QA-testing?
• Veiledning for tilgjengelighetsprøving (en komplett trinnvis veiledning)
• Beste verktøy for testing av programvare 2021 (QA Test Automation Tools)
• Hva er programvaretesting? 100+ gratis manuell testopplæring