Java >> Java tutorial >  >> Java

API-testning og automatisering 101:The Essential Guide

Java

API står for A applikation P rogrammering I ngrænseflade. Typisk bruges API til at lette interaktionen mellem to forskellige applikationer ved at bruge ethvert kommunikationsmiddel. Når API'er bruges over webnetværk, betegner vi dem som 'webtjenester'. I nyere tid er API'er blevet rygraden i programmering. Ligesom i en applikation er det blevet almindelig praksis at skrive API'er til at kommunikere med databasen eller med et andet modul nu, og det er derfor, vi som tester skal teste API'erne for at få maksimal testdækning.

Som en del af integrationstestning kan API-automatisering hjælpe med at accelerere testen og øge effektiviteten. Da de fleste af virksomhederne bruger RESTful mikrotjenester/API'er på forretningslaget, er API-test blevet en kritisk komponent i testplanen for enhver udgivelse.

I enkleste vendinger er API en tjeneste, der hjælper to forskellige applikationer med at kommunikere med hinanden. For det meste bruges API'er til at abstrahere forretningslogikken og direkte databaseadgang til enhver applikation.

Logisk set kan vi adskille hele systemet i tre lag-

  1. Præsentationslag – Dette er brugergrænseflade (GUI), som er åben for slutbrugere. QA udfører funktionstest på dette lag.
  2. Forretningslag- Dette er applikationsbrugergrænsefladen, hvor logikken er skrevet. I tekniske termer er det her kode/algoritme findes. API'er kommer ind i billedet på dette lag.
  3. Databaselag- Hvor applikationsdata er til stede.

Med andre ord er API'en hjernen i vores forbundne verden. Det er sættet af værktøjer, protokoller, standarder og kode, der limer vores digitale verden sammen. På grund af deres dynamiske natur og muligheder, de leverer, giver API'er virksomheder mulighed for at blive mere agile, ting at blive mobile og alt at arbejde sammen på en strømlinet, integreret måde. Derfor tester API-test API'er på serviceniveau og ved integrationen niveau.

Teststrategi for API'er-

Under test af API'er bør testeren koncentrere sig om at bruge software til at foretage API-kald for at modtage et output, før de observerer og logger systemets svar. Vigtigst af alt, tester, at API'en returnerer et korrekt svar eller output under forskellige forhold. Dette output er typisk et af disse tre:

  • At bestået eller ikke bestået
  • Data eller oplysninger
  • Et kald til en anden API

Men der kunne heller ikke være noget output overhovedet, eller noget helt uforudset opstår. Dette gør testerens rolle afgørende for applikationsudviklingsprocessen. Og fordi API'er er det centrale omdrejningspunkt for data for mange applikationer, kan datadrevet test af API'er hjælpe med at øge testdækningen og nøjagtigheden.

Ved direkte test af API'en er det lidt mere udfordrende at angive beståede/ikke beståede scenarier. Hvis du sammenligner API-dataene i svaret eller sammenligner adfærden efter API-kaldet i en anden API, vil det dog hjælpe dig med at opsætte definitive valideringsscenarier.

API-testning er en af ​​de mest udfordrende dele af hele kæden af ​​softwaretest og QA-test, fordi den arbejder for at sikre, at vores digitale liv kører på en stadig mere problemfri og effektiv måde. Mens udviklere har en tendens til kun at teste de funktionaliteter, de arbejder på, er testere ansvarlige for at teste både individuelle funktionaliteter og en række eller kæde af funktionaliteter og opdage, hvordan de arbejder sammen fra ende til anden.

Typer af API-testning-

Identificer først, hvilken type test du skal udføre på API. Ligesom testere udfører forskellige typer test for funktioner i deres produkt, gælder det samme med API'er. Almindeligvis afprøvning af API'er inkluderer-

Enhedstest – For at teste funktionaliteten af ​​individuel drift. For f.eks. - Google leverer geokodnings-API, for at få længde- og breddegraden af ​​enhver placering. Dette tager normalt adresse som input og returnerer lat longs. Nu til enhedstest af denne API kan testeren bestå en anden placering og bekræfte resultatet.

Funktionel test- Denne type test fokuserer hovedsageligt på funktionalitet af API. Dette vil omfatte testsager for at verificere HTTP-svarkoder, validering af svar, fejlkoder i tilfælde af, at API returnerer en fejl osv.

Belastningstest- Denne type test er nødvendig i tilfælde, hvor API beskæftiger sig med enorme data og chancer for anvendelse, der kan bruges af ingen brugere på samme tid. Dette øger API-hits på samme tid, og det kan gå ned og ikke være i stand til at tage denne belastning.

Sikkerhedstest- Sikkerhedstest er særligt kritisk, da API bruges til at skabe et link mellem to forskellige applikationer. Kerneformålet med at bruge en API er at abstrahere eller skjule applikationens database fra andre. Dette kan omfatte testcases som autorisationstjek, sessionsstyring osv.

Interoperabilitetstest- Dette er for at teste, at API er tilgængeligt for de applikationer, hvor det burde være. Dette gælder SOAP API'er.

WS-overensstemmelsestest- API er testet for at sikre, at standarder såsom WS-adressering, WS-Discovery, WS-Federation, WS-Policy, WS-Security og WS-Trust er korrekt implementeret og brugt

Penetrationstest- Dette er for at finde sårbarheden ved API fra eksterne kilder.

Webtjenester/ API-protokoller-

Hvis vi taler om webtjenester, er der hovedsageligt to typer tjenester, eller vi kan sige protokoller-

HVILE – REST står for RE præsentationsS tate T ransfer, som er nyt på blokken i forhold til SOAP, hvilket betyder, at den skal overvinde alle problemerne med SOAP. REST er en letvægtsprotokol, som bruger URL til al den nødvendige information. Den bruger fire HTTP-metoder til at udføre opgave-

  1. Hent - For at få oplysningerne. For eksempel at få længde- og breddegrad i tilfælde af placeringsmapping API.
  2. Post- For at indsætte nogle data i ressource.
  3. Put- For at opdatere ressourcen.
  4. Slet - For at slette fra ressource.

REST er mere brugt nu om dage på grund af sin enkle og lette arkitektur.

SOAP API- står for S implér O bject A adgang til P rotocol. Den bruger XML til meddelelsesudveksling. Alle de oplysninger, der er nødvendige for at udføre denne opgave, er givet i dens WSDL, som er Web Service Description Language. SOAP er tung på grund af dets omfattende brugte standarder og XML. De vigtigste fordele ved SOAP frem for Rest er, at den har indbygget fejlhåndtering, og den kan bruges med andre protokoller som SMTP.

Værktøjer til API-testning og automatisering

Der er flere værktøjer til at teste API'erne. Når en tester kommer til at teste API, skal de bede om sit dokument, uanset om det er en REST eller SOAP API eller dens ikke-webbaserede API, skal der altid være et dokument, hvor detaljerne skal skrives. For at nærme sig API-test-

  1. Spørg efter Doc
  2. Skriv først sager om funktions- eller serviceniveau
  3. Skriv integrationstest
  4. Når API er stabilt nok og består de fleste af ovenstående tests, skal du udføre sikkerheds-, ydeevne- og belastningstest.
  • Et typisk API-dokument har alle oplysninger, der er relateret til API'et, såsom dets anmodningsformat, svar, fejlkoder, ressource, obligatoriske parametre, valgfri parametre, overskrifter osv. Dokumentet kan vedligeholdes i forskellige værktøjer såsom swagger, som er open source , Dapperdox, ReDoc osv.
  • Prøv derefter at skrive serviceniveausager til API. For eksempel hvis en API tager n parametre for at få svaret, hvor m er obligatoriske parametre, og andre er valgfrie, så bør en testsag være at prøve forskellige kombinationer af parametre og verificere svaret. En anden testcase kan muligvis bekræfte overskrifterne og forsøge at køre API uden at bestå godkendelse og bekræfte fejlkoden.
  • Dernæst kommer trinnet med integrationstest, hvor du skal teste API'en og alle dens afhængige API'er eller funktioner. Dette inkluderer også test af API-svar, de data, det skal returnere til en anden API eller metode, og hvad der sker, hvis denne API fejler.
  • Når API'et er stabilt, og funktionstestningen næsten er færdig, kan testeren udføre belastnings-, sikkerheds- og ydeevnetest.

API-automatisering

Vi har ofte brug for at automatisere testcases, som gentagne gange udføres. Til fx- Regressionstilfælde. Tilsvarende i tilfælde af API-testning kan der være nogle tilfælde, som vi skal udføre før hver udgivelse, og disse tilfælde kan automatiseres.

Der er mange værktøjer til API-automatisering, som er ret populære-

  1. SUPPE UI
  2. Katalon-studie
  3. Postbud
  4. Jmeter
  5. RestAssured
  6. CloudQA TruAPI

SUPPE UI- Det er et meget populært værktøj til API-testning. Du kan lave funktionelle, belastnings-, sikkerheds- og overholdelsestests på din API ved hjælp af SoapUI.

Katalon Studio- Bygget på toppen af ​​Selenium og Appium er Katalon Studio et gratis og kraftfuldt automatiseret testværktøj til webtest, API-test og mobiltest.

Postbud- Postman er gratis og hjælper dig med at være mere effektiv, mens du arbejder med API'er. Det har alle mulighederne til at udvikle og teste API'er.

Jmeter- Selvom Jmeter mest bruges til præstations- og belastningstest, kan det også bruges til API funktionel test i et godt omfang.

RestAssured- Rest-Assured er et Java-baseret bibliotek, der bruges til at teste RESTful Web Services. Biblioteket kan inkluderes i den eksisterende ramme og kalde dets metoder direkte til at hente svar i json-format og derefter udføre nødvendige handlinger.

Jeg tager et eksempel for at forklare de trin, der følges for grundlæggende API funktionel testning, her bruger jeg TruAPI værktøj leveret af CloudQA som er nyt og vinder popularitet-

Trin 1- For at køre API-anmodning skal du først vælge metodetype og indsætte URL for API'en. Tryk på knappen Send for at sende anmodningen til API, eller tryk på knappen Tilføj API-test for at gemme anmodningen-

Prøv denne prøvemetodetype og API-URL

  • Metodetype:GET
  • APIURL:https://um5fdww2pj.execute-api.us-east-1.amazonaws.com/dev/todos


Trin 2-Oplysninger om API-anmodning:

  • Det meste af API'en kræver yderligere input for at udføre anmodningen, såsom parametre, Headers, Body(JSON) og så videre.
  • For at tilføje parametre for anmodningen kan du vælge de respektive parametre fanen og tryk på Tilføj parameter knapper for at tilføje de nødvendige oplysninger.

Trin 3-Send en API-anmodning med godkendelse:

  • Hvis din hostede API har brug for en godkendelse, kan du gå til fanen Autorisation og vælge BasicAuth fra rullelisten (Standard er den indstillet som Noauth), og indtast derefter brugernavn og adgangskode. Du er nu klar til at sende godkendte anmodninger.
  • Hvert API-svar består af forskellige værdier som statuskode, brødtekst, overskrifter og tidspunktet for at fuldføre API-anmodningen. Nedenstående billede viser, hvordan modtaget API-svar portrætteres.

Tilføjelse af påstande:

  • I automatiseringsprocessen er det vigtigt, at du verificerer dit output ved hjælp af en påstand. For at tilføje en påstand i API Runner skal du gå til fanen Assertions. Du kan tilføje en eller flere påstande her.
  • Følg disse trin for at tilføje påstande:
    • Vælg svartype
    • Vælg påstandens tilstand
    • Indtast den værdi, der skal kontrolleres
  • Du er færdig med at tilføje påstanden

Variabler:

  • Fanen Variabler er nyttig til at gemme de værdier, der modtages som et svar fra en sendt API-anmodning. For at gemme svar skal du gå til fanen Variabler og følge disse trin:
    • Tilføj variabel
    • Giv et navn til variablen for bedre forståelse af teamet
    • Indtast JSON-stien for den værdi, der skal gemmes, fra svarteksten
    • For at bruge den lagrede værdi i variablen som forventet påstand kan du bruge __navnet på variablen__ i enhver anden API-anmodning.

Se eller udfør en gemt API-anmodning:

  • Når du er på API Runner-siden, skal du bruge knappen Vis gemte test til at se de gemte tests
  • Vælg en eller flere API-gemte tests, og kør de valgte tests som standard, testene viser oplysninger om den sidst udførte kørselsstatus
  • Resultaterne vil vise API-udførelseshistorikken

Dette er en enkelt API-udførelse og automatisering. For scenarier i den virkelige verden er vi ofte nødt til at oprette API-sæt, der består af alle regressionstestsager og køre dette som en del af regressionstestning. I agile er det afgørende at have et jakkesæt klar, så det kan integreres med CI og CD.

CloudQA kommer med en meget rig dokumentation om værktøjet, alle værktøjerne leveret af CloudQA er tilpasset ideen om "Kodeløs automatisering" og meget nemme at bruge for manuelle testere.

Link til dokumentation- https://doc.cloudqa.io/TruAPI.html

Logisk set kan vi adskille hele systemet i tre lag-

  1. Præsentationslag – Dette er brugergrænseflade (GUI), som er åben for slutbrugere. QA udfører funktionstest på dette lag.
  2. Forretningslag- Dette er applikationsbrugergrænsefladen, hvor logikken er skrevet. I tekniske termer er det her kode/algoritme findes. API'er kommer ind i billedet på dette lag.
  3. Databaselag- Hvor applikationsdata er til stede.

Java tag