Menú

Executeu casos de prova en paral·lel i genereu informes mitjançant l'eina Karate

  • Principal
  • Altres
  • Executeu casos de prova en paral·lel i genereu informes mitjançant l'eina Karate

run test cases parallel generate reports using karate tool

Proveu El Nostre Instrument Per Eliminar Problemes

el millor programari de recuperació de fitxers de Windows 10

Aquest tutorial explica com realitzar algunes operacions bàsiques a l'API, executar casos de prova en paral·lel i generar informes amb Karate Framework:

Hem après a crear un script de prova bàsic al nostre tutorial anterior; ara podem avançar aprenent algunes operacions bàsiques que es poden realitzar mentre es treballa amb l’API i el Karate Framework. Hi ha moltes d'aquestes operacions i en parlarem d'algunes d'utilitzades habitualment en aquest tutorial.

També aprofundirem en el procés d'execució de casos de prova en paral·lel seguint un enfocament pas a pas. També parlarem de l’informe actual que es genera automàticament i el compararem amb l’informe Cucumber que podem generar integrant un connector.

Realització de diverses operacions, execució de casos de prova en paral·lel i generació d

Què aprendreu:

Treballar amb l'API i l'eina de proves de karate

Com es va comentar al tutorial anterior, al .característica fitxer que havíem creat, podríem utilitzar paraules clau diferents per realitzar diferents operacions a l'API. Karate framework ens proporciona diverses paraules clau que es poden utilitzar per realitzar diverses accions.

=> Lectura recomanada: Proves API amb Karate Framework

Realització de diverses operacions

# 1) Impressió de la resposta a la consola

Imprimir és una paraula clau que proporciona Karate Framework per imprimir el resultat a la consola o al fitxer. Un dels usos més habituals és imprimir la resposta de l'API. Això pot ser molt útil per a l'usuari.

Ho podem fer mitjançant les línies de codi següents:

Feature: fetching User Details Scenario: testing the get call for User Details Given url 'https://reqres.in/api/users/2' When method GET Then status 200 #We are printing the Response of the API using the print keyword# Then print response

Les línies de codi anteriors donaran la sortida següent:

18:15:44.495 (main) INFO com.intuit.karate - (print) { 'ad': { 'company': 'StatusCode Weekly', 'text': 'A weekly newsletter focusing on software development, infrastructure, the server, performance, and the stack end of things.', 'url': 'http://statuscode.org/' }, 'data': { 'last_name': 'Weaver', 'id': 2, 'avatar': 'https://s3.amazonaws.com/uifaces/faces/twitter/josephstein/128.jpg', 'first_name': 'Janet', 'email': 'janet.weaver@reqres.in' } }

Així és com podem imprimir la resposta de l'API a la consola amb la finalitat de llegir, que es pot utilitzar en el moment de la depuració.

# 2) Declaració de les variables

Podem declarar les variables mitjançant la paraula clau def al marc Karate i després utilitzeu les variables declarades al codi sempre que sigui necessari.

A l'exemple següent, hem afegit algunes línies de codi més a les existents userDetails.feature per ajudar a declarar les variables de l'script.

Feature: fetching User Details Scenario: testing the get call for User Details Given url 'https://reqres.in/api/users/2' When method GET Then status 200 #We are printing the Response of the API using the print keyword Then print response # Declaring and assigning a string value: Given def varName = 'value' # using a variable Then print varName

# 3) Afirmació de la resposta real a la resposta esperada

Karate Framework ajuda a realitzar les operacions relacionades amb l 'asserció mitjançant partit paraula clau. El partit és intel·ligent perquè l’espai en blanc no li importa i l’ordre de les tecles no és important.

Per utilitzar coincideix amb la paraula clau, hem de fer ús del signe de doble igualtat '==' que representa una comparació.

Ara intentarem aprofundir en alguns usos de partit paraula clau.

a) Quan es menciona tota la resposta esperada al propi fitxer .feature.

En determinats moments, tenim algunes dades que ens agradaria validar immediatament al propi fitxer. Normalment, aquest tipus de dades s’esmenten mentre es depura el codi.

Podríem fer el mateix al propi fitxer .feature com es mostra a continuació:

Feature: fetching User Details Scenario: testing the get call for User Details Given url 'https://reqres.in/api/users/2' When method GET Then status 200 #Asserting the reponse #response variable is holding the Actual response from API #Right hand side value is holding the expected Response And match response == {'ad':{'company':'StatusCode Weekly','text':'A weekly newsletter focusing on software development, infrastructure, the server, performance, and the stack end of things.','url':'http://statuscode.org/'},'data':{'last_name':'Weaver','id':2,'avatar': 'https://s3.amazonaws.com/uifaces/faces/twitter/josephstein/128.jpg','first_name':'Janet', 'email':'janet.weaver@reqres.in'}}

Si envieu una sol·licitud a l'URL 'Https://reqres.in/api/users/2' al navegador, doncs obtindreu la següent resposta:

{ 'ad': { 'company': 'StatusCode Weekly', 'text': 'A weekly newsletter focusing on software development, infrastructure, the server, performance, and the stack end of things.', 'url': 'http://statuscode.org/' }, 'data': { 'last_name': 'Weaver', 'id': 2, 'avatar': 'https://s3.amazonaws.com/uifaces/faces/twitter/josephstein/128.jpg', 'first_name': 'Janet', 'email': 'janet.weaver@reqres.in' } }

Intentem validar la resposta esmentada anteriorment mitjançant el fitxer * .feature.

Hem utilitzat el partit paraula clau proporcionada per Karate Framework, que ajuda a realitzar diferents tipus de fitxers Afirmacions a la resposta de l'API.

Nota : Hauríem de transformar la resposta de l'API en una línia per realitzar el pas anterior. Podeu utilitzar qualsevol de les eines disponibles en línia.

b) Quan la sortida esperada es manté en un fitxer JSON extern.

En l'exemple anterior, vam discutir un escenari en què teníem dades limitades i la mateixa resposta que era fàcil de manejar, però en els escenaris reals tindrem conjunts gegantins de respostes JSON que podríem haver d'avaluar.

Per tant, en aquests casos, és millor mantenir la resposta al fitxer extern i verificar-la.

A l'exemple següent discutirem el mateix:

  • Cal crear un fitxer ExpectedOutput.json a la nostra carpeta Projecte, tal com es mostra a la imatge següent.

Crea un recurs de paquet nou -> Crea un fitxer nou ExpectedOutput.json

I emmagatzemeu la resposta JSON en aquest fitxer i deseu-la.

ExpectedOutput.json1

Creeu un nou paquet de recursos

Hauríeu d’escriure el següent codi al vostre userDetails.feature dossier:

Feature: fetching User Details Scenario: testing the get call for User Details Given url 'https://reqres.in/api/users/2' When method GET Then status 200 #Verifying the JSON response by providing same in feature file And match response == {'ad':{'company':'StatusCode Weekly','text':'A weekly newsletter focusing on software development, infrastructure, the server, performance, and the stack end of things.','url':'http://statuscode.org/'},'data':{'last_name':'Weaver','id':2,'avatar': 'https://s3.amazonaws.com/uifaces/faces/twitter/josephstein/128.jpg','first_name': 'Janet','email':'janet.weaver@reqres.in'}} #Reading the file ExpectedOutput.json and storing same response in variable expectedResult Given expectedResult=read('./resources/ExpectedOutput.json') #Asserting the Actual Response with the Expected Response And match response == expectedResult

A l'exemple anterior, primer estem llegint el fitxer ExpectedOutput.json i emmagatzemant-ne la resposta a la variable Resultat Esperat utilitzant el següents línies de codi:

Given expectedResult=read('./resources/ExpectedOutput.json')

A continuació, posem l'asserció mitjançant les línies de codi següents, on coincidim amb Resposta real amb el Resultat Esperat resposta amb el ' == ' operador.

And match response == expectedResult

c) Coincidència / verificació de certs valors de la resposta

Fins ara hem verificat tota la resposta de l'API, però cada vegada no voldríeu verificar tota la resposta. De vegades, només voldríeu avaluar una part de la resposta. Normalment, fem el mateix quan fem servir les altres eines per provar API o mentre creem un framework.

Per entendre-ho més, prenem la següent resposta JSON com a exemple:

{ 'ad': { 'company': 'StatusCode Weekly' } }

Si volem verificar que el paràmetre empresa hauria de tenir el valor com StatusCode setmanal, llavors haurem de crear un camí JSON. Això es pot fer recorrent el fitxer JSON i utilitzant el símbol '.' (Operador de punts)

El camí JSON per a la resposta anterior serà:

ad.company == 'StatusCode setmanal'

A continuació es mostra el fragment de codi que ens ajudarà a avaluar els valors del paràmetre concret. Aquest codi pertany al fitxer .característica dossier.

Feature: fetching User Details Scenario: testing the get call for User Details Given url 'https://reqres.in/api/users/2' When method GET Then status 200 #Verifying the JSON response by providing same in feature file And match response == {'ad':{'company':'StatusCode Weekly', 'text':'A weekly newsletter focusing on software development, infrastructure, the server, performance, and the stack end of things.', 'url':'http://statuscode.org/'},'data':{'last_name':'Weaver','id':2,'avatar': 'https://s3.amazonaws.com/uifaces/faces/twitter/josephstein/128.jpg', 'first_name':'Janet','email':'janet.weaver@reqres.in'}} #Reading the file ExpectedOutput.json and storing same response in variable expectedResult Given expectedResult=read('./resources/ExpectedOutput.json') #Asserting the Actual Response with the Expected Response And match response == expectedResult ##Creating JSON path to verify the values of particular parameters## And match response.ad.url == 'http://statuscode.org/' And match response.data.first_name == 'Janet'

A continuació es mostra la línia de codi, que realitza les afirmacions paramètriques.

And match response.ad.url == 'http://statuscode.org/' And match response.data.first_name == 'Janet'

Mitjançant el camí JSON, estem avaluant els valors dels paràmetres.

Realització d’operacions post

Fins ara hem cobert els escenaris bàsics de provar una API quan el mètode era ' ACONSEGUIR'. Però quan treballem en un entorn real, hem d’enviar molta informació al servidor, de manera que en aquest cas fem servir el “ POST ” mètode .

Aquesta secció us proporcionarà informació sobre com treballar amb la sol·licitud POST bàsica.

Obtenim algunes idees breus sobre els paràmetres que necessitem per enviar la sol·licitud POST.

# 1) Creació d'una sol·licitud POST, quan el cos JSON s'esmenta al fitxer * .feature

  • Creeu una característica userDetailsPost fent els passos similars esmentats al tutorial anterior.
  • Escriviu les línies de codi següents:
Feature: Posting User Details Scenario: testing the POST call for User Creation Given url 'https://reqres.in/api/users' And request '{'name': 'morpheus','job': 'leader'}' When method POST Then status 201

Com que es tracta d'una sol·licitud POST, que sempre ha d'anar acompanyada d'un cos que cal enviar al servidor per obtenir una resposta determinada, hem esmentat que sota el component següent:

sol·licitud: Pren un cos JSON com a sol·licitud que es requereix amb el mètode POST.

# 2) Creació d'una sol·licitud POST, quan el cos JSON s'esmenta en un fitxer extern

Normalment, tindrem un òrgan de sol·licitud enorme, que seria difícil d'esmentar al * .característica dossier. Per tant, és millor guardar-lo al fitxer extern.

  • Cal crear un fitxer PostBody.json a la nostra carpeta Projecte, tal com es mostra a continuació. Creeu un recurs de paquet nou -> Creeu un fitxer nou PostBody.json i deseu el cos JSON en aquest fitxer i deseu-lo.

Creació d’una sol·licitud POST

quan es menciona el cos JSON al fitxer extern 1

Nota: Hem esmentat el cos del mètode POST al fitxer JSON anterior.

  • Haureu d’escriure el següent codi al vostre usuariDetallsPost .característica dossier:
Feature: Posting User Details Scenario: testing the POST call for User Creation using External File Given url 'https://reqres.in/api/users' Given postBody=read('./resources/PostBody.json') And request postBody When method POST Then status 201

Llegim el cos JSON des de PostBody.json amb les línies de codi següents:

Given postBody=read('./resources/PostBody.json')

Nota: Tot el userDeatils.feature Els fitxers que hem creat fins ara requeriran el bàsic TestRunner.java per executar-los, que hem creat al nostre tutorial bàsic de script de prova, tal com es mostra a continuació:

import org.junit.runner.RunWith; import com.intuit.karate.junit4.Karate; @RunWith(Karate.class) public class TestRunner { }

Executeu casos de prova en paral·lel

Ara, ja que hem après els passos per crear un script de prova bàsic i hem realitzat algunes operacions bàsiques a l'API, és hora que comencem a treballar a l'entorn real.

Normalment, hem d'executar els casos de prova en paral·lel, per fer l'execució més ràpida. Bàsicament, la idea és obtenir més resultats en menys temps.

Aquesta és una característica bàsica del marc i no depèn de JUnit, Maven o Grade. Ens permet:

  • Trieu fàcilment les funcions i les etiquetes per executar les suites de prova d’una manera senzilla.
  • Vegeu els resultats paral·lels a la carpeta surefire-plugin.
  • Fins i tot podem integrar els informes JSON de Cogombre per obtenir una millor interfície d’usuari (que es parlarà properament).

A Karate Framework, no cal que realitzem molts passos per iniciar l'execució en paral·lel dels nostres casos de prova. Només hem de seguir els passos següents:

1) Ara hem de canviar el fitxer TestRunner.java que hem estat fent servir fins ara. El codi per a l’execució en paral·lel s’ha d’escriure al fitxer anterior.

Tingueu en compte la següent línia mentre executeu el vostre codi en paral·lel:

el millor programari de recuperació de dades de Windows 10

** No podem utilitzar l’anotació @RunWith (Karate.class) quan intentem treballar en un entorn paral·lel.

Obriu l'original TestRunner.java fitxer i utilitzeu el codi següent ara:

import com.intuit.karate.Results; import com.intuit.karate.Runner; import org.junit.Test; // important: do not use @RunWith(Karate.class) ! public class TestRunner { @Test public void testParallel() { Results results = Runner.parallel(getClass(),5); } }

** S’aplicarà el següent codi Dependència de JUnit 4 Maven

Al fragment de codi anterior, hem inclòs la línia de codi següent:

Resultats dels resultats = Runner.parallel (getClass (), 5);

Aquesta línia indica que cal executar la instància dels casos de prova en paral·lel recuperant dinàmicament les classes en temps d'execució.

2) Creeu un duplicat userDetails.feature fitxer tal com s'esmenta a continuació al fitxer src / test / java carpeta.

userDetails.feature

Ara ja estem preparats per a l'execució en paral·lel 2 . característiques dossier.

3) Anar a TestRunner.java fitxer creat al pas anterior i executeu-lo com a prova JUnit. Amb això, executarem els nostres casos de prova en format paral·lel.

Per facilitar la llegibilitat, Karate Framework presenta una mica de informació a la consola, sempre que es completa l'execució de la prova.

El resultat és similar al següent:

consola

Amb l'execució en paral·lel, totes les funcions s'executaran en paral·lel i els escenaris també s'executaran en un format paral·lel.

Seguint els passos anteriors, podreu iniciar l'execució bàsica en paral·lel de la prova de l'API, mitjançant Karate Framework.

** Podeu estudiar les proves paral·leles recorrent els diversos filtres de la pàgina Execució paral·lela

Integrar el complement de cogombre per a la presentació d'informes

Com estem utilitzant el Corredor JUnit per a l'execució de diferents escenaris que s'han esmentat als diferents * .característica , crea automàticament un informe per a cadascun dels fitxers de funcions que s’emmagatzemen al camí target / surefire-reports.

Integració del complement Cogombre per a la presentació d

Genera un Informe formatat de la IU bàsica per presentar els casos de prova que s’han executat.

Però els informes que es generen no són molt agradables pel que fa a la interfície d’usuari i, per compartir informes amb els grups d'interès, necessitem quelcom que sigui més fàcil d'utilitzar i que sigui fàcil d'entendre.

Per tal d'aconseguir aquest format d'informes, Karate Framework ofereix una opció per integrar-se Complement d'informes de cogombre cosa que ens ajudarà a generar un informe formatat gràfic, que serà més presentable.

A continuació es detallen els passos per integrar-los:

# 1) Afegiu el següent Informe de cogombre dependència del vostre POM.xml

net.masterthought cucumber-reporting 3.8.0 test

# 2) Editeu el fitxer TestRunner.java quan només n'hi hagi un de sol * .característica fitxer al projecte.

Hem d’actualitzar el fitxer TestRunner.java, amb el següent mètode generateReport () per al complement Cucumber.

public class TestRunner { @Test public void testParallel() { generateReport(results.getReportDir()); assertTrue(results.getErrorMessages(), results.getFailCount() == 0); } public static void generateReport(String karateOutputPath) { Collection jsonFiles = FileUtils.listFiles(new File(karateOutputPath), new String() {'json'}, true); final List jsonPaths = new ArrayList(jsonFiles.size()); jsonFiles.forEach(file -> jsonPaths.add(file.getAbsolutePath())); Configuration config = new Configuration(new File('target'), 'demo'); ReportBuilder reportBuilder = new ReportBuilder(jsonPaths, config); reportBuilder.generateReports(); } }

Al codi esmentat anteriorment, realitzem les accions següents:

  • Creació d’una nova instància de fitxer
  • Proporcionar el camí per emmagatzemar els fitxers a la carpeta de destinació
  • Creació d’un objecte ReportBuilder que crearà un informe nou de Cogombre

Nota : El codi anterior funciona bé quan tenim un sol *. característica al nostre projecte.

# 3) Editeu el fitxer TestRunner.java quan n'hi hagi funció múltiple * fitxers al Projecte.

Hauríem d’afegir una línia de codi (ressaltada en negreta a continuació) per assegurar-nos que s’executa l’execució paral·lela, mentre s’executen els escenaris per a la generació d’informes.

public class TestRunner { @Test public void testParallel() { System.setProperty('karate.env', 'demo'); // ensure reset if other tests (e.g. mock) had set env in CI Results results = Runner.parallel(getClass(),5); generateReport(results.getReportDir()); assertTrue(results.getErrorMessages(), results.getFailCount() == 0); } public static void generateReport(String karateOutputPath) { Collection jsonFiles = FileUtils.listFiles(new File(karateOutputPath), new String() {'json'}, true); final List jsonPaths = new ArrayList(jsonFiles.size()); jsonFiles.forEach(file -> jsonPaths.add(file.getAbsolutePath())); Configuration config = new Configuration(new File('target'), 'demo'); ReportBuilder reportBuilder = new ReportBuilder(jsonPaths, config); reportBuilder.generateReports(); } }

Després de realitzar els passos esmentats, podrem crear amb èxit un informe d’interfície d’usuari gràfic ben representat mitjançant Cogombre: informes connectar.

Podem trobar l'informe al següent camí del nostre projecte, tal com es mostra a la imatge següent:

Cogombre: informes

El següent informe es va generar per al nostre projecte, per a totes les operacions que hem realitzat fins ara en aquest tutorial de Karate Framework:

Informe

Conclusió

Per resumir, en aquest tutorial hem comentat les operacions bàsiques que són útils en el dia a dia mentre treballem amb el Marc Karate i com executar-lo múltiples fitxers * .feature en paral · lel. També hem après a crear un informe gràfic per als usuaris que utilitzen el fitxer Informes de cogombre connectar.

En primer lloc, vam parlar de les operacions bàsiques que es poden realitzar a l'API. Vam discutir com podem enviar el cos / sol·licitud POST al servidor, ja sigui esmentant el cos al propi fitxer * .feature (que normalment no és una pràctica recomanada) o mitjançant un fitxer extern (una pràctica recomanada, per tal de mantenir un codi net).

En segon lloc, després de seguir uns quants passos bàsics, podríem executar amb èxit el resultat de la prova per a dos * .característica fitxers que s'han executat en paral·lel, només afegint algunes línies de codi al fitxer TestRunner.java fitxer que permet iniciar la carrera paral·lela.

A més d'això, vam aprendre a transformar l'informe de prova JUnit natiu en un informe de Cogombre integrant el Informes de cogombre connectar. El connector ens permet generar informes que tinguin una millor interfície d’usuari, siguin molt més comprensibles per a l’usuari i, per tant, proporcionin una millor experiència d’usuari als grups d'interès amb els quals es comparteixin aquests informes.

A hores d'ara, hauríeu de poder realitzar algunes operacions bàsiques, executar els casos de prova paral·lelament i generar un informe de fàcil lectura per als usuaris.

<

Lectura recomanada

^