Kjør testtilfeller i parallelle og generer rapporter ved hjelp av Karate-verktøy

run test cases parallel generate reports using karate tool

Denne opplæringen forklarer hvordan du utfører noen grunnleggende operasjoner på API, kjører testtilfeller parallelt og genererer rapporter med Karate Framework:

Vi har lært hvordan du lager et grunnleggende testskript i vår forrige opplæring. Vi kan nå gå videre med å lære noen grunnleggende operasjoner som kan utføres mens vi arbeider med API og Karate Framework. Det er mange slike operasjoner, og vi vil diskutere noen ofte brukte i denne opplæringen.

Vi skal også fordype oss i prosessen med å kjøre testsaker parallelt ved å følge en trinnvis tilnærming. Vi vil også diskutere den gjeldende rapporten som blir generert automatisk og sammenligne den med agurkerapporten som vi kan generere ved å integrere et plugin.

Hva du vil lære:

• Arbeider med API og Karate Testing Tool
  • Utfører forskjellige operasjoner
  • Utfører postoperasjoner
• Kjør testtilfeller parallelt
• Integrer agurk-plugin for rapportering
• Konklusjon
  • Anbefalt lesing

Arbeider med API og Karate Testing Tool

Som diskutert i forrige opplæring, i .trekk filen vi hadde opprettet, kunne vi bruke forskjellige nøkkelord for å utføre forskjellige operasjoner på API. Karate framework gir oss flere nøkkelord som kan brukes til å utføre ulike handlinger.

=> Anbefalt lesing: API-testing med karate-rammeverk

Utfører forskjellige operasjoner

# 1) Skriver ut svaret i konsollen

Skrive ut er et nøkkelord som leveres av Karate Framework for å skrive ut resultatet i konsollen eller filen. En av de vanligste bruksområdene er å skrive ut svaret fra API. Dette kan være veldig nyttig for brukeren.

Vi kan gjøre dette ved å bruke følgende kodelinjer:

Ovennevnte kodelinjer gir følgende utdata:

Slik kan vi skrive ut svaret fra API-en i konsollen for lesemålet, som kan brukes når feilsøkingen skjer.

# 2) Deklarere variablene

Vi kan erklære variablene ved hjelp av nøkkelordet def i Karate-rammeverket, og bruk deretter de deklarerte variablene i koden der det er nødvendig.

I eksemplet nedenfor har vi lagt til noen flere linjer med kode til den eksisterende userDetails.feature filen for å forklare variablene i skriptet.

# 3) Å hevde det faktiske svaret på det forventede svaret

Karate Framework hjelper til med å utføre påstandsrelaterte operasjoner ved hjelp av kamp nøkkelord. De kamp er smart fordi hvite mellomrom ikke betyr noe for det, og rekkefølgen på tastene er ikke viktig.

For bruk samsvar nøkkelord, vi må bruke dobbeltlikhetstegnet “==” som representerer en sammenligning.

Nå vil vi prøve å utdype noen bruksområder av kamp nøkkelord.

a) Når hele forventet svar er nevnt i selve .feature-filen.

På bestemte tider har vi noen data som vi vil validere umiddelbart i selve filen. Vanligvis blir slike typer data nevnt under feilsøking av koden.

Vi kunne gjøre det samme i selve .feature-filen som vist nedenfor:

Hvis du sender en forespørsel til URL-en ‘Https://reqres.in/api/users/2’ i nettleseren, da vil du få følgende svar:

Vi prøver å validere ovennevnte svar ved hjelp av * .feature-filen.

Vi har brukt kamp nøkkelord som leveres av Karate Framework, som hjelper til å utføre forskjellige typer Påstander i API-svaret.

Merk : Vi må transformere API-responsen i en linje for å utføre trinnet ovenfor. Du kan bruke hvilket som helst verktøy som er tilgjengelig på nett.

b) Når forventet utdata holdes i en ekstern JSON-fil.

I eksemplet ovenfor diskuterte vi et scenario der vi hadde begrensede data og det samme svaret som var lett å håndtere, men i de virkelige scenariene vil vi ha gigantiske sett med JSON-svar som vi kanskje må evaluere.

Så i slike tilfeller er det bedre å beholde svaret i den eksterne filen og deretter bekrefte det samme.

I eksemplet nedenfor vil vi videre diskutere det samme:

• Trenger å lage en ExpectedOutput.json filen i prosjektmappen som vist på bildet nedenfor.

Opprett en ny pakkeressurs -> Opprett en ny fil ExpectedOutput.json

Og lagre JSON-svaret i denne filen og lagre den.

Du må skrive følgende kode i userDetails.feature fil:

I eksemplet ovenfor leser vi først filen ExpectedOutput.json og lagre responsen til den i variabelen forventet resultat bruker følgende kodelinjer:

Deretter legger vi påstanden ved hjelp av følgende kodelinjer, der vi samsvarer med Faktisk respons med forventet resultat svar med “ == ' operatør.

c) Matching / verifisering av visse verdier fra responsen

Til nå har vi bekreftet hele svaret fra API-en, men hver gang vil du ikke bekrefte hele svaret. Noen ganger vil du bare evaluere en del av svaret. Vanligvis gjør vi det samme når vi bruker de andre verktøyene for API-testing eller mens vi lager et rammeverk.

For å forstå det videre, la oss ta følgende JSON-svar som et eksempel:

Hvis vi vil bekrefte at parameteren selskap skal ha verdien som StatusCode Ukentlig, da må vi lage en JSON-bane. Dette kan gjøres ved å krysse JSON-filen og bruke “.” (Punktoperatør)

JSON-banen for svaret ovenfor vil være:

ad.company == “StatusCode Weekly”

Nedenfor er kodebiten som vil hjelpe oss med å evaluere verdiene for den bestemte parameteren. Denne koden tilhører .trekk fil.

Nedenfor er kodelinjen som utfører parametriske påstander.

Ved hjelp av JSON-banen evaluerer vi verdiene for parametrene.

Utfører postoperasjoner

Til nå har vi dekket de grunnleggende scenariene for å teste et API når metoden var “ FÅ'. Men når vi jobber i det virkelige miljøet, må vi sende mye informasjon til serveren, så i så fall bruker vi “ POST' metode .

Denne delen vil gi deg et innblikk i å jobbe med den grunnleggende POST-forespørselen.

La oss få noen korte ideer om parametrene vi trenger for å sende POST-forespørselen.

# 1) Opprette en POST-forespørsel når JSON-kroppen er nevnt i * .feature-filen

• Opprett en userDetailsPost.feature ved hjelp av lignende trinn nevnt i forrige opplæring.
• Skriv følgende kodelinjer:

Siden det er en POST-forespørsel, som alltid må ledsages av et organ som må sendes til serveren for et bestemt svar, har vi nevnt det under følgende komponent:

be om: Det tar et JSON-organ som forespørsel som kreves med POST-metoden.

# 2) Opprette en POST-forespørsel når JSON-kroppen er nevnt i en ekstern fil

Vanligvis vil vi ha et stort forespørselsorgan, som det vil være vanskelig å nevne i *.trekk fil. Så det er bedre å ha den i den eksterne filen.

• Trenger du å opprette en PostBody.json-fil i prosjektmappen som vist nedenfor. Opprett en ny pakkeressurs -> Opprett en ny fil PostBody.json og lagre JSON Body i denne filen og lagre den.

Merk: Vi har nevnt Body of the POST-metoden i JSON-filen ovenfor.

• Du må skrive følgende kode i userDetailsPost .trekk fil:

Vi leser JSON Body fra PostBody.json ved hjelp av følgende kodelinjer:

Merk: Alle de userDeatils.feature filer som vi har opprettet til nå, krever grunnleggende TestRunner.java fil for å utføre dem, som vi opprettet i vår Basic Test Script tutorial som vist nedenfor:

Kjør testtilfeller parallelt

Nå, siden vi har lært trinnene for å lage et grunnleggende testskript og utført noen grunnleggende operasjoner på API-et, er det på tide at vi kommer i gang med å jobbe i det faktiske miljøet.

Vanligvis må vi kjøre testkassene parallelt for å gjøre kjøringen raskere. I utgangspunktet er ideen å få mer produksjon på kortere tid.

Dette er et sentralt trekk ved rammeverket og avhenger ikke av JUnit, Maven eller Grade. Det lar oss:

• Velg enkelt funksjonene og kodene for å kjøre testserier på en enkel måte.
• Vis parallelle resultater under surefire-plugin-mappen.
• Vi kan til og med integrere Cucumber JSON-rapportene for bedre brukergrensesnitt (som vil bli diskutert om kort tid).

I Karate Framework trenger vi ikke å utføre mange trinn for å starte den parallelle kjøringen av testkassene våre. Vi trenger bare å gå gjennom følgende trinn:

1) Vi må nå endre TestRunner.java filen vi har brukt til nå. Koden for parallell kjøring må skrives i filen ovenfor.

Vær oppmerksom på følgende linje mens du kjører koden i Parallel:

metode som tar i en matrise

** Vi kan ikke bruke @RunWith (Karate.class) -kommentarer når vi prøver å jobbe i et parallelt miljø.

Åpne originalen TestRunner.java fil og bruk følgende kode nå:

** Følgende kode vil gjelde for JUnit 4 Maven avhengighet

I kodebiten ovenfor har vi tatt med nedenstående kodelinje-

Resultatresultater = Runner.parallel (getClass (), 5);

Denne linjen instruerer å kjøre Instance of the Test Cases in Parallel ved dynamisk å hente klassene på Runtime.

2) Lag et duplikat userDetails.feature filen som nevnt nedenfor under src / test / java mappe.

Nå er vi klar for parallell kjøring med to . egenskaper fil.

3) Gå til TestRunner.java fil opprettet i trinnet ovenfor og kjør den som JUnit Test. Med dette vil vi gjennomføre testsakene våre i parallelt format.

For enkel lesbarhet presenteres noe informasjon av Karate Framework i konsollen når testutførelsen er fullført.

Resultatet ser ut som følgende:

Med den parallelle kjøringen vil alle funksjonene utføres parallelt, og scenariene vil også kjøre i et parallelt format.

Ved å følge trinnene ovenfor, vil du kunne starte den helt grunnleggende parallelle kjøringen av API-testen ved hjelp av Karate Framework.

** Du kan studere om parallell testing ved å gå gjennom de forskjellige filtrene på siden Parallell utførelse

Integrer agurk-plugin for rapportering

Når vi bruker JUnit-løper for gjennomføring av forskjellige scenarier som er nevnt i de forskjellige *.trekk filer, oppretter den automatisk en rapport for hver av funksjonsfilene som er lagret i banen mål / surefire-rapporter.

Det genererer en Grunnleggende UI-formatert rapport for å presentere testsakene som er utført.

Men rapportene som blir generert er ikke veldig behagelige når det gjelder brukergrensesnittet, og for å dele rapporter med interessentene trenger vi noe som er mer brukervennlig og lett forståelig.

For å oppnå et slikt rapporteringsformat gir Karate Framework en mulighet til å integrere Agurkrapporteringsprogramtillegg som vil hjelpe oss med å generere en grafisk formatert rapport, som vil være mer presentabel.

Følgende er trinnene for å integrere det samme:

#1) Legg til følgende Agurkrapportering avhengighet av POM.xml

#to) Rediger TestRunner.java-filen når det bare er en enkelt *.trekk fil i prosjektet.

Vi må oppdatere TestRunner.java-filen med følgende generereReport () -metode for agurk-plugin.

I koden nevnt ovenfor utfører vi følgende handlinger:

• Opprette en ny forekomst av fil
• Gi stien for å lagre filene under målmappen
• Opprette et ReportBuilder-objekt som vil opprette en ny agurkerapport

Merk : Ovennevnte kode fungerer bra når vi har single *. trekk fil i prosjektet vårt.

# 3) Rediger TestRunner.java-filen når det er flere * .funksjon filer i prosjektet.

Vi trenger å legge til en kodelinje (uthevet med fet skrift nedenfor) for å sikre at parallell kjøring blir tatt vare på, mens scenariene blir utført for rapportgenerering.

Etter å ha utført de ovennevnte trinnene, vil vi kunne lage en velrepresentert grafisk brukergrensesnittrapport med Agurk - rapportering plugg inn.

Vi finner rapporten på følgende vei i prosjektet vårt, som vist på bildet nedenfor:

Følgende rapport ble generert for prosjektet vårt, for alle operasjonene vi har utført til nå i denne Karate Framework Tutorial:

Konklusjon

For å oppsummere har vi i denne opplæringen diskutert de grunnleggende operasjonene som er nyttige på daglig basis mens vi jobber med Karate Framework og hvordan du skal utføre flere * .funksjonsfiler parallelt. Vi lærte også å lage en grafisk rapport for brukerne ved hjelp av Agurkrapportering plugg inn.

Først diskuterte vi de grunnleggende operasjonene som kan utføres på API. Vi diskuterte hvordan vi kan sende POST-kroppen / forespørselen til serveren, enten ved å nevne kroppen i * .feature-filen i seg selv (som vanligvis ikke er en anbefalt praksis) eller ved å bruke en ekstern fil (en anbefalt praksis, for å opprettholde en ren kode).

For det andre, etter å ha fulgt noen få grunnleggende trinn, kunne vi utføre testresultatet for to *.trekk filer som ble utført parallelt, bare ved å legge til noen få kodelinjer i TestRunner.java fil som muliggjør initiering av parallellkjøringen.

Videre til dette lærte vi hvordan vi kan transformere den opprinnelige JUnit Test-rapporten til en agurkrapport ved å integrere Agurkrapportering plugg inn. Pluginen lar oss generere rapporter som har et bedre brukergrensesnitt, som er mye mer forståelig for brukeren, og dermed gir en bedre brukeropplevelse for interessentene som disse rapportene deles med.

Nå skal du kunne utføre noen grunnleggende operasjoner, kjøre testtilfellene parallelt og generere en lettlest rapport for brukerne.

<