run test cases parallel generate reports using karate tool
In deze tutorial wordt uitgelegd hoe u enkele basisbewerkingen op de API uitvoert, testcases parallel uitvoert en rapporten genereert met Karate Framework:
We hebben in onze vorige tutorial geleerd hoe we een basistestscript kunnen maken, we kunnen nu verder gaan met het leren van enkele basisbewerkingen die kunnen worden uitgevoerd tijdens het werken met de API en het Karate Framework. Er zijn veel van dergelijke bewerkingen en we zullen enkele veelgebruikte bewerkingen bespreken in deze tutorial.
We zullen ook ingaan op het proces van het parallel uitvoeren van testcases door een stapsgewijze aanpak te volgen. We zullen ook het huidige rapport bespreken dat automatisch wordt gegenereerd en het vergelijken met het komkommerrapport dat we kunnen genereren door een plug-in te integreren.
Wat je leert:
- Werken met API en Karate-testtool
- Testcases parallel uitvoeren
- Integreer de komkommer-plug-in voor rapportage
- Gevolgtrekking
Werken met API en Karate-testtool
Zoals besproken in de vorige tutorial, in het .voorzien zijn van bestand dat we hadden gemaakt, konden we verschillende trefwoorden gebruiken om verschillende bewerkingen op de API uit te voeren. Karate framework biedt ons verschillende trefwoorden die kunnen worden gebruikt om verschillende acties uit te voeren.
=> Aanbevolen literatuur: API-testen met Karate Framework
Diverse bewerkingen uitvoeren
# 1) Afdrukken van het antwoord in de console
Afdrukken is een trefwoord dat wordt geleverd door het Karate Framework om het resultaat in de console of het bestand af te drukken. Een van de meest voorkomende toepassingen is het afdrukken van de respons van de API. Dit kan erg handig zijn voor de gebruiker.
We kunnen dit doen door de volgende regels code te gebruiken:
De bovenstaande coderegels geven de volgende uitvoer:
Dit is hoe we het antwoord van de API in de console kunnen afdrukken voor het leesdoel, dat kan worden gebruikt op het moment van debuggen.
# 2) De variabelen declareren
We kunnen de variabelen declareren met behulp van het trefwoord def in het Karate-raamwerk en gebruik vervolgens de gedeclareerde variabelen in de code waar nodig.
In het onderstaande voorbeeld hebben we nog een paar regels code toegevoegd aan het bestaande userDetails.feature bestand om de variabelen in het script te helpen verklaren.
# 3) De daadwerkelijke reactie op de verwachte reactie bevestigen
Karate Framework helpt bij het uitvoeren van Assertion-gerelateerde bewerkingen met behulp van de bij elkaar passen trefwoord. De bij elkaar passen is slim omdat witruimte er niet toe doet en de volgorde van de toetsen niet belangrijk is.
Voor gebruik zoekwoord, we moeten het dubbele gelijkteken '==' gebruiken dat een vergelijking vertegenwoordigt.
Nu zullen we proberen enkele toepassingen van bij elkaar passen trefwoord.
a) Wanneer het volledige verwachte antwoord wordt vermeld in het .feature-bestand zelf.
Op bepaalde momenten hebben we enkele gegevens die we onmiddellijk in het bestand zelf willen valideren. Meestal worden dergelijke soorten gegevens genoemd tijdens het debuggen van de code.
We zouden hetzelfde kunnen doen in het .feature-bestand zelf, zoals hieronder wordt weergegeven:
Als je een verzoek stuurt naar de URL ‘Https://reqres.in/api/users/2’ in de browser, dan u krijgt het volgende antwoord:
We proberen het bovenstaande antwoord te valideren met behulp van het * .feature-bestand.
We hebben de bij elkaar passen sleutelwoord dat wordt geleverd door het Karate Framework, dat helpt bij het uitvoeren van verschillende soorten Beweringen in het API-antwoord.
Notitie : We zouden het API-antwoord in één regel moeten transformeren om de bovenstaande stap uit te voeren. U kunt elk van de beschikbare tools gebruiken online.
b) Wanneer de verwachte output wordt bewaard in een extern JSON-bestand.
In het bovenstaande voorbeeld hebben we een scenario besproken waarin we beperkte gegevens hadden en dezelfde respons die gemakkelijk te hanteren was, maar in de echte scenario's zullen we gigantische sets JSON-reacties hebben die we mogelijk moeten evalueren.
In die gevallen is het dus beter om het antwoord in het externe bestand te bewaren en het vervolgens te verifiëren.
In het onderstaande voorbeeld zullen we hetzelfde verder bespreken:
- U moet een ExpectedOutput.json bestand in onze projectmap, zoals weergegeven in de onderstaande afbeelding.
Maak een nieuwe pakketbron -> Maak een nieuw bestand ExpectedOutput.json
En sla het JSON-antwoord op in dit bestand en sla het op.
U moet de volgende code in uw userDetails.feature het dossier:
In het bovenstaande voorbeeld lezen we eerst het bestand ExpectedOutput.json en het opslaan van de respons ervan in de variabele verwacht resultaat de ... gebruiken volgende regels code:
Vervolgens plaatsen we de bewering met behulp van de volgende regels code, waarbij we de Werkelijke reactie met de verwacht resultaat antwoord met de “ operator.
c) Afstemmen / verifiëren van bepaalde waarden uit het antwoord
Tot nu toe hebben we de volledige reactie van de API geverifieerd, maar elke keer zou je niet de hele reactie willen verifiëren. Soms wilt u slechts een deel van de respons evalueren. Meestal doen we hetzelfde wanneer we de andere tools gebruiken voor API-testen of tijdens het maken van een framework.
Om het verder te begrijpen, nemen we het volgende JSON-antwoord als voorbeeld:
Als we willen verifiëren dat de parameter bedrijf moet de waarde hebben als StatusCode wekelijks, dan zullen we een JSON-pad moeten maken. Dit kan worden gedaan door het JSON-bestand te doorlopen en de '.' (Dot-operator)
Het JSON-pad voor het bovenstaande antwoord is:
ad.company == 'StatusCode wekelijks'
Hieronder staat het codefragment dat ons zal helpen bij het evalueren van de waarden voor de specifieke parameter. Deze code behoort tot de .voorzien zijn van het dossier.
Hieronder staat de regel code die de parametrische beweringen uitvoert.
Met behulp van het JSON-pad evalueren we de waarden voor de parameters.
Postoperaties uitvoeren
Tot nu toe hebben we de basisscenario's besproken van het testen van een API terwijl de methode ' KRIJGEN'. Maar als we in de echte omgeving werken, moeten we veel informatie naar de server sturen, dus in dat geval gebruiken we de ' POST' methode
In dit gedeelte krijgt u inzicht in het werken met het basis POST-verzoek.
Laten we een paar korte ideeën krijgen over de parameters die we nodig hebben voor het verzenden van het POST-verzoek.
# 1) Een POST-verzoek maken, wanneer de JSON-body wordt vermeld in * .feature-bestand
- Maak een userDetailsPost.feature met behulp van de vergelijkbare stappen die in de vorige zelfstudie zijn vermeld.
- Schrijf de volgende regels code:
Omdat het een POST-aanvraag is, die altijd vergezeld moet gaan van een body die naar de server moet worden gestuurd voor een bepaald antwoord, hebben we dat vermeld onder de volgende component:
verzoek: Het vereist een JSON-body als het verzoek dat vereist is met de POST-methode.
# 2) Een POST-verzoek aanmaken, wanneer de JSON-body in een extern bestand wordt vermeld
Meestal hebben we een enorm verzoeklichaam, dat moeilijk te vermelden is in het *.voorzien zijn van het dossier. Het is dus beter om het in het externe bestand te bewaren.
- U moet een PostBody.json-bestand maken in onze projectmap, zoals hieronder weergegeven. Maak een nieuwe pakketbron -> Maak een nieuw bestand PostBody.json en sla de JSON-body op in dit bestand en sla het op.
Notitie: We hebben de Body van de POST-methode genoemd in het bovenstaande JSON-bestand.
- U zou de volgende code in uw userDetailsPost moeten schrijven .voorzien zijn van het dossier:
We lezen de JSON Body van de PostBody.json met behulp van de volgende regels code:
Notitie: Al de userDeatils.feature bestanden die we tot nu toe hebben gemaakt, hebben de basic TestRunner.java bestand om ze uit te voeren, die we hebben gemaakt in onze Basic Test Script-zelfstudie zoals hieronder weergegeven:
Testcases parallel uitvoeren
Nu we de stappen hebben geleerd om een basistestscript te maken en enkele basisbewerkingen op de API hebben uitgevoerd, wordt het tijd dat we aan de slag gaan met het werken in de daadwerkelijke omgeving.
Meestal moeten we de testcases parallel uitvoeren om de uitvoering sneller te laten verlopen. Kortom, het idee is om meer output te krijgen in minder tijd.
Dit is een kernfunctie van het framework en is niet afhankelijk van de JUnit, Maven of Grade. Het stelt ons in staat om:
- Kies eenvoudig de functies en de tags om testsuites op een eenvoudige manier uit te voeren.
- Bekijk de parallelle resultaten in de map surefire-plugin.
- We kunnen zelfs de Cucumber JSON-rapporten integreren voor een betere gebruikersinterface (die binnenkort zal worden besproken).
In Karate Framework hoeven we niet veel stappen uit te voeren om de Parallelle uitvoering van onze Test Cases te starten. We hoeven alleen maar de volgende stappen te doorlopen:
1) We moeten nu de TestRunner.java bestand dat we tot nu toe hebben gebruikt. De code voor de parallelle uitvoering moet in het bovenstaande bestand worden geschreven.
Houd rekening met de volgende regel wanneer u uw code parallel uitvoert:
interviewvragen en antwoorden voor desktop support engineer
** We kunnen de annotatie @RunWith (Karate.class) niet gebruiken wanneer we proberen in een parallelle omgeving te werken.
Open het origineel TestRunner.java bestand en gebruik nu de volgende code:
** De volgende code is van toepassing op JUnit 4 Maven-afhankelijkheid
In het bovenstaande codefragment hebben we de onderstaande regel code opgenomen:
Resultaten resultaten = Runner.parallel (getClass (), 5);
Deze regel geeft opdracht om de Instance van de Test Cases parallel uit te voeren door de klassen dynamisch op te halen tijdens de Runtime.
twee) Maak een duplicaat userDetails.feature bestand zoals hieronder vermeld onder de src / test / java map.
Nu zijn we helemaal klaar voor de parallelle uitvoering met twee Kenmerken het dossier.
3) Ga naar TestRunner.java bestand aangemaakt in de bovenstaande stap en voer het uit als JUnit-test. Hiermee voeren we onze testcases parallel uit.
Om het gemakkelijk te kunnen lezen, wordt er wat informatie gepresenteerd door het Karate Framework in de console, telkens wanneer de test is voltooid.
Het resultaat ziet er ongeveer als volgt uit:
Met de parallelle uitvoering worden alle functies parallel uitgevoerd en zullen ook de scenario's in een parallel formaat worden uitgevoerd.
Door de bovenstaande stappen te volgen, kunt u de zeer eenvoudige parallelle uitvoering van de API-test starten met behulp van het Karate Framework.
U kunt leren over parallelle tests door de verschillende filters op de pagina te doorlopen Parallelle uitvoering
Integreer de komkommer-plug-in voor rapportage
Omdat we de JUnit runner voor de uitvoering van verschillende scenario's die in de verschillende *.voorzien zijn van bestanden, maakt het automatisch een rapport voor elk van de feature-bestanden die in het pad zijn opgeslagen target / trefzekere-rapporten.
Het genereert een Basis UI-geformatteerd rapport voor het presenteren van de uitgevoerde testcases.
Maar de rapporten die worden gegenereerd zijn niet erg prettig in termen van de gebruikersinterface, en om rapporten met de belanghebbenden te delen, hebben we iets nodig dat gebruikersvriendelijker en begrijpelijker is.
Om een dergelijk rapportageformaat te bereiken, biedt Karate Framework een optie om te integreren Plug-in voor komkommerrapportage wat ons zal helpen bij het genereren van een grafisch opgemaakt rapport, dat beter presentabel zal zijn.
Hieronder volgen de stappen om hetzelfde te integreren:
# 1) Voeg het volgende toe Komkommer-rapportage afhankelijkheid van uw POM.xml
#twee) Bewerk het bestand TestRunner.java als er slechts één *.voorzien zijn van bestand in het project.
We moeten ons TestRunner.java-bestand bijwerken met de volgende methode GenerReport () voor de Cucumber-plug-in.
In de hierboven genoemde code voeren we de volgende acties uit:
- Een nieuw exemplaar van File
- Het pad opgeven om de bestanden in de doelmap op te slaan
- Een ReportBuilder-object maken waarmee een nieuw komkommerrapport wordt gemaakt
Notitie : De bovenstaande code werkt prima als we een single hebben voorzien zijn van bestand in ons project.
# 3) Bewerk het bestand TestRunner.java als er meerdere * .feature bestanden in het Project.
We zouden een regel code moeten toevoegen (hieronder vetgedrukt gemarkeerd) om ervoor te zorgen dat parallelle uitvoering wordt uitgevoerd, terwijl de scenario's worden uitgevoerd voor het genereren van rapporten.
Na het uitvoeren van de bovengenoemde stappen, kunnen we met succes een goed vertegenwoordigd grafisch gebruikersinterface-rapport maken met behulp van de Komkommer - rapportage inpluggen.
We kunnen het rapport vinden op het volgende pad in ons project, zoals weergegeven in de onderstaande afbeelding:
Het volgende rapport is gegenereerd voor ons project, voor alle operaties die we tot nu toe hebben uitgevoerd in deze Karate Framework Tutorial:
Gevolgtrekking
Samenvattend hebben we in deze tutorial de basisbewerkingen besproken die dagelijks nuttig zijn bij het werken met de Karate kader en hoe uit te voeren meerdere * .feature-bestanden parallel. We hebben ook geleerd om een grafisch rapport te maken voor de gebruikers die de Komkommer rapportage inpluggen.
Eerst hebben we de basisbewerkingen besproken die op de API kunnen worden uitgevoerd. We hebben besproken hoe we de POST-body / -verzoek naar de server kunnen sturen, ofwel door de body te vermelden in het * .feature-bestand zelf (wat meestal niet een aanbevolen praktijk is) of door een extern bestand te gebruiken (een aanbevolen praktijk, om een schone code onderhouden).
Ten tweede, na het volgen van een paar basisstappen, konden we het testresultaat voor twee met succes uitvoeren *.voorzien zijn van bestanden die parallel werden uitgevoerd, gewoon door een paar regels code toe te voegen in het TestRunner.java bestand waardoor de parallelle run kan worden gestart.
Verder hebben we geleerd hoe we het oorspronkelijke JUnit-testrapport kunnen transformeren naar een komkommerrapport door het Komkommer-rapportage inpluggen. Met de plug-in kunnen we rapporten genereren die een betere gebruikersinterface hebben, veel begrijpelijker zijn voor de gebruiker en dus een betere gebruikerservaring bieden voor de belanghebbenden met wie deze rapporten worden gedeeld.
Inmiddels zou u in staat moeten zijn om een aantal basisbewerkingen uit te voeren, de testcases parallel uit te voeren en een gemakkelijk te lezen rapport voor de gebruikers te genereren.
Aanbevolen literatuur
- Karate Framework-zelfstudie: geautomatiseerde API-testen met karate
- 10 beste API-testtools in 2021 (SOAP- en REST API-testtools)
- Hoe komkommer met Jenkins te gebruiken: zelfstudie met voorbeelden
- Gids voor het genereren van omvangrapporten in Selenium WebDriver
- Specflow-rapportage: testrapporten genereren en selectieve tests uitvoeren
- Vereisten beheren, testcases uitvoeren en rapporten genereren met TestLink - Tutorial # 2
- Uw Appium-tests parallel uitvoeren met Appium Studio voor Eclipse
- Hoe u Appium-tests op grote schaal parallel uitvoert