Šī pamācība ir ievads API testēšanā, izmantojot Karate Framework. Uzziniet vairāk par Karate testēšanas skripta struktūru un soļiem pirmā testēšanas skripta izveidei:
API ir akronīms, kas apzīmē lietojumprogrammu saskarni (Application Programming Interface). Vienkāršoti runājot, to var definēt kā programmatūras starpnieku, kas nodrošina saziņu starp lietojumprogrammām.
API testēšana mums ir nepieciešama, jo:
- Rezultāti tiek publicēti ātrāk, tāpēc vairs nav jāgaida, lai pārliecinātos, vai API darbojas pareizi.
- Pateicoties ātrākai reakcijai, arī šo API izvietošana notiek ātrāk, tādējādi nodrošinot ātrāku aprites laiku.
- Agrīna kļūdu atklāšana, vēl pirms lietotnes lietotāja saskarnes izveides, ļauj mums mazināt riskus un novērst kļūdas.
- Iespējama liela apjoma piegāde īsākā laikā.
Lai varētu strādāt ar API testēšanu, tirgū ir pieejami dažādi rīki, piemēram, Postman, Mocha un Chai. Tie ir uzrādījuši labus rezultātus un efektīvu izmantošanu API testēšanai, tomēr tie ir ļoti atkarīgi no koda. Lai tos varētu izmantot, ir jābūt tehniski zinošam un jāpārzina programmēšanas valodas.
Karatē ietvarstruktūra lieliski atrisina šo iepriekšējo programmatūras rīku problēmu.
Kas ir karatē sistēma
Karatē? Parunāsim par karatē. Vai tas ir no Japānas? Kā jūs domājat? Iespējams, ka to savā brīvajā laikā bija attīstījis izcilais Brūss Lī.
Lai gan mēs vēlētos iedziļināties karatē interesantajās saknēs, pagaidām parunāsim par to. Karatē rīks ko ir izstrādājis Pēteris Tomass , viens no lieliskajiem rīkiem, kas nāk palīgā API testētājiem.
Karate ietvarstruktūra darbojas pēc Cucumber programmas rakstīšanas stila, kas atbilst BDD pieejai. Sintakse ir viegli saprotama arī neprogrammētājiem. Un šī ietvarstruktūra ir vienīgais API testēšanas rīks, kurā API automatizācija un veiktspējas testēšana ir apvienota vienā atsevišķā rīkā.
Tas nodrošina lietotājiem iespēju paralēli izpildīt testa gadījumus un veikt JSON & amp; XML pārbaudes.
Izmantojot šo informāciju, var secināt dažus galvenos punktus, lai detalizētāk izprastu karatē rīku:
- Karate ir BDD testēšanas ietvars, nevis TDD.
- Tā ir izstrādāta tā, lai to varētu ērti lietot arī cilvēki, kas nav programmētāji. Šī funkcija ir nozīmīga, jo tā ļauj daudz plašāk izmantot un piekļūt daudziem cilvēkiem neatkarīgi no viņu tehniskās sagatavotības vai spējām.
- Testa rakstīšanai tiek izmantots Cucumber funkciju fails un Gherkins valoda, kas ir ļoti viegli saprotama.
Visas šīs funkcijas padara to par vienu no visizdevīgākajiem automatizācijas rīkiem, kas pieejami mūsdienās.
Vēsture Karatē ietvara
Izveidoja Peter Thomas' 2017. gadā, šīs programmatūras mērķis ir padarīt testēšanas funkcionalitāti viegli pieejamu ikvienam. Tā tika rakstīta Java valodā, un lielākā daļa cilvēku gaidīja, ka arī tās faili būs tajā pašā valodā, tomēr, par laimi, tas tā nav.
Tā drīzāk izmanto Gherkins failus, kas izriet no tās saiknes ar Cucumber ietvaru. Automatizācijas programmatūra ir Cucumber paplašinājums, tāpēc savā darbībā pārmanto Gherkins failu izmantošanu. Lielākā atšķirība starp abām programmatūrām ir tā, ka Karate testēšanas laikā neizmanto Java, bet Cucumber izmanto.
Tieši šī iemesla dēļ tas ir piemērots arī tiem, kas nav programmētāji, jo Gherkins sintakse ir ļoti viegli lasāma un visaptveroša. Tas ir iemesls, kāpēc Karate ir vispiemērotākais un ieteicamākais, lai ieietu automatizētā API testēšanas pasaulē.
Tālāk ir aprakstītas dažas Karate testēšanas sistēmas funkcijas:
- Izmantota viegli saprotama gorkšņu valoda.
- Tam nav nepieciešamas tādas tehniskās programmēšanas zināšanas kā Java.
- Tā pamatā ir populārie gurķu standarti.
- Viegli izveidot sistēmu.
- Paralēlā testēšana ir pamatfunkcija, ko nodrošina pats Karate, tāpēc mums nav jābūt atkarīgiem no Maven, Gradle , utt.
- Lietotāja saskarne Testa atkļūdošanas atkļūdošanai.
- Funkciju faila izsaukšana no cita faila.
- Nodrošina atbalstu datu draivera testēšanai, kas ir izveidots pašu uzņēmumā, tāpēc nav nepieciešams būt atkarīgam no ārējiem ietvariem.
- Iebūvēti natīvie atpūtas pārskati. Turklāt to var integrēt ar Cucumber, lai nodrošinātu labākus UI pārskatus un lielāku skaidrību.
- Nodrošina iekšējo atbalstu konfigurācijas pārslēgšanai dažādās testēšanas vidēs (QA, Stage, Prod, Pre-Prod).
- Viengabalains atbalsts CI/CD integrācijai, kas var būt noderīgs.
- Spēj apstrādāt dažādus HTTP izsaukumus:
- Web Socket atbalsts
- SOAP pieprasījums
- HTTP
- Pārlūkprogrammas sīkfailu apstrāde
- HTTPS
- HTML-formas dati
- XML pieprasījums
Karatē Vs Rest-Assured salīdzinājums
Atpūtieties droši : Tā ir uz Java balstīta bibliotēka REST pakalpojumu testēšanai. Tā izmanto Java valodu koda rindu rakstīšanai. Tā palīdz testēt daudzas pieprasījumu kategorijas, kas tālāk ļauj pārbaudīt dažādas biznesa loģikas kombinācijas.
Karatē sistēma : Uz Cucumber/Gherkins balstīts rīks, ko izmanto SOAP & amp; REST pakalpojumu testēšanai.
Šajā tabulā ir uzskaitītas dažas būtiskākās atšķirības starp Rest-Assured & amp; Karatē sistēma:
| S.Nr. | Pamats | Karatē sistēma | REST nodrošināts |
|---|---|---|---|
| 1 | Valoda | Tajā izmanto gurķu un kornišonu kombināciju. | Tā izmanto Java valodu |
| 2 | Kods Izmērs | Parasti koda rindu ir mazāk, jo tās atbilst Cucumber līdzīgai struktūrai. | Koda rindu skaits ir lielāks, jo tas ir saistīts ar Java valodas izmantošanu. |
| 3 | Nepieciešamās tehniskās zināšanas | Ne- Programmētāji var viegli uzrakstīt Gherkins kodu | Java koda rakstīšanai nepieciešamas tehniskās zināšanas |
| 4 | Uz datiem balstīta testēšana | Nepieciešams izmantot TestNG vai līdzvērtīgu rīku, lai atbalstītu to pašu. | Datu testēšanas atbalstam var izmantot iekšējās birkas. |
| 5 | Vai tas nodrošina SOAP izsaukumu atbalstu | Jā, tas nodrošina | Tas ir saistīts tikai ar REST pieprasījumu |
| 6 | Paralēlā testēšana | Jā, paralēlā testēšana ir viegli atbalstāma arī ar paralēlo pārskatu ģenerēšanu. | Lai gan cilvēki ir mēģinājuši to darīt, neveiksmju rādītājs ir lielāks nekā panākumu rādītājs. |
| 7 | Ziņošana | Tas nodrošina iekšēju pārskatu sniegšanu, tāpēc nav jābūt atkarīgam no ārējiem spraudņiem. Mēs to pat varam integrēt ar Cucumber pārskatu sniegšanas spraudni, lai uzlabotu lietotāja interfeisu. | Nepieciešamība būt atkarīgam no ārējiem spraudņiem, piemēram, Junit, TestNG |
| 8 | CSV atbalsts ārējiem datiem | Jā, no Karate 0.9.0 | Nē, jāizmanto Java kods vai bibliotēka |
| 9 | Web UI automatizācija | Jā, no Karate 0.9.5 Web-UI automatizācija ir iespējama. | Nē, tas netiek atbalstīts |
| 10 | GET paraugs | Dotais param val1 = 'name1' | given(). |
Tādējādi, kā liecina iepriekš minētās atšķirības, var droši apgalvot, ka karatē ir viena no vieglākajām lietām, ko var darīt ikviens.
Darbam ar karatē sistēmu nepieciešamie rīki
Tagad, kad esam ieguvuši pamatzināšanas par Karate Framework, aplūkosim procesus un rīkus, kas nepieciešami Karate vides iestatīšanai.
#1) aptumsums
Eclipse ir integrētā izstrādes vide, ko izmanto datorprogrammēšanas jomā. To galvenokārt izmanto Java programmēšanai. Kā minēts iepriekš, Karate ir rakstīts Java valodā, tāpēc ir loģiskāk, kāpēc Eclipse ir IDE API testēšanas programmatūrai. Vēl viens iemesls ir tas, ka tas ir atvērtā koda rīks, un tas ir diezgan spēcīgs iemesls, lai izvēlētos šo rīku.
Piezīme: Mēs pat varētu izmantot IntelliJ, Visual Studio un citus tirgū pieejamos redaktorus.
#2) Maven
Tas ir kompilēšanas automatizācijas rīks, ko galvenokārt izmanto Java projektu veidošanai. Tas ir viens no veidiem, kā izveidot Karate vidi un rakstīt kodu. Lai iestatītu Eclipse ar Maven prasībām, varat noklikšķināt šeit, lai instalētu Maven.
Strādājot ar Maven, izmantojiet Maven atkarības, kas palīdzētu jums atbalstīt Karate Framework.
Kopā ar Maven pom.xml tiks izmantotas šādas atkarības.
com.intuit.karate karate-apache 0.9.5 test com.intuit.karate karate-junit4 0.9.5 test
Piezīme: Jaunākās versijas varētu būt pieejamas Maven repozitorijā.
#3) Gradle
Gradle ir alternatīva Maven, un to var izmantot līdzvērtīgā apjomā. Tiem ir gan līdzības, gan atšķirības, taču tos var vienlīdz labi izmantot, lai izveidotu vidi mūsu Karate kodiem.
Tas ir vieglāk lietojams, elastīgāks un to ieteicams izmantot, ja mūsu lietojumprogrammai ir zināmas modulēšanas un pārvaldības prasības ar vairākiem spraudņiem. Gradle iestatīšanas kods izskatītos apmēram šādi,
testCompile 'com.intuit.karate:karate-junit4:0.6.0' testCompile 'com.intuit.karate:karate-apache:0.6.0'
Piezīme: Varat izmantot MAVEN vai GRADLE.
#4) Java vides iestatīšana jūsu sistēmā
Nepieciešams iestatīt JDK un JRE vidi, lai sāktu darbu ar Karate Framework skriptiem.
Karatē testa skripta struktūra
Karate testa skripts ir pazīstams ar to, ka tam pieder paplašinājums ".feature". Šī īpašība ir pārmantota no Cucumber. Vienlīdz atļauta ir arī failu organizācija Java konvencijā. Jūs varat brīvi organizēt savus failus atbilstoši Java pakotņu konvencijām.
Tomēr Maven vadlīnijās ir norādīts, ka datnes, kas nav Java faili, ir jāglabā atsevišķi. Tās tiek glabātas a src/test/resources struktūrā. Un Java faili tiek glabāti zem src/main/java .
Taču Karate Framework veidotāji ir pārliecināti, ka ir ieteicams turēt blakus gan Java, gan ne Java failus. Viņuprāt, ir daudz vieglāk meklēt *.java un *.feature failus, ja tie tiek turēti kopā, nevis pēc Maven standarta struktūras.
To var viegli izdarīt, mainot savu pom.xml šādi (Maven):
src/test/java **/*.java ...
Tālāk ir izklāstīta karatē pamatprincipu vispārējā struktūra:
Tagad, tā kā šis Karate Framework izmanto Runner failu, kas arī ir nepieciešams Cucumber, lai palaistu funkciju failus, tāpēc lielākā daļa rakstīšanas sekos Cucumber standartiem.
Taču atšķirībā no Cucumber soļiem Karate nav nepieciešama skaidra definīcija, kas, savukārt, palielina elastību un atvieglo darbību. Mums nav nepieciešams pievienot papildu līmi, kas parasti ir jāpievieno, ja ievērojam Cucumber ietvaru.
"Runner" klases nosaukums lielākoties ir TestRunner.java.
Tad TestRunner.java fails iegūs šādu formu:
import com.intuit.karate.junit4.Karate; import org.junit.runner.RunWith; @RunWith(Karate.class) public class TestRunner { } Un, runājot par .feature failā ir iekļauti visi testēšanas scenāriji, kas jātestē, lai pārliecinātos, ka API darbojas atbilstoši gaidītajām prasībām.
Vispārējais *.feature fails izskatās apmēram tā, kā parādīts tālāk:
Funkcija: lietotāju datu iegūšana Scenārijs: testēšana, lai iegūtu lietotāju datus Dotais url '//reqres.in/api/users/2' Kad metode GET Tad statuss 200
Pirmā pamata karatē testa skripta izveide
Šī sadaļa palīdzēs jums sākt darbu pie sava pirmā testa skripta izveides, kas būs noderīgs, lai konvertētu API karatē ietvara veidā.
Pirms mēs rakstām Karate testēšanas pamatskriptu, lūdzu, instalējiet savā datorā šādus rekvizītus:
- Eclipse IDE
- Maven. Iestatiet atbilstošo Maven ceļu.
- JDK & amp; JRE. Iestatiet atbilstošo ceļu.
Apskatīsim pakāpenisku pieeju:
#1) Izveidot jaunu MAVEN Projekts Eclipse redaktorā
- Atvērt Eclipse
- Noklikšķiniet uz Fails. Izvēlieties Jauns projekts.
- Izvēlieties Maven projektu
- Izvēlieties darbvietas atrašanās vietu.
- Izvēlieties arhetipu (parasti mēs izvēlamies " Maven-archetype-quickstart 1.1 " vienkāršiem Maven projektiem).
- Norādiet Group ID & amp; Artifact ID (mūsu piemērā mēs izmantojām šādas vērtības).
- Grupas ID : Karatē
- Artefakta ID: KarateTestScriptsSample
- Lai pabeigtu iestatīšanu, noklikšķiniet uz Finish.
#2) Pēc izveides projekta Explorer logā būs redzama šāda struktūra.
#3) Iekļaut visas atkarības.
Mūsu pirmais solis pēc iestatīšanas būs. iekļaut visas atkarības Mēs saglabāsim visas birkas zem POM.xml (Pieņemot, ka jūs jau zināt par POM.xml lietošanu).
- Atveriet POM.xml un kopējiet tālāk norādīto kodu zem atkarības birkas un saglabājiet failu.
com.intuit.karate karate-apache 0.9.5 test com.intuit.karate karate-junit4 0.9.5 test
Spiediet šeit, lai apskatītu avotu.
#4) Pieņemsim Prāta vētra scenāriju, ko mēs gatavojamies pārbaudīt šajā Karatē pamata testa skriptā.
Scenārijs:
Mēs testēsim API, izmantojot šo URL.
Ceļš: api/users/2
Metode: GET
Un mums ir jāapstiprina , vai pieprasījums atgriež Veiksmes kods (200) vai nē.
Vienkāršāk sakot, mēs vienkārši testēsim API paraugu, lai pārbaudītu, vai tas tiek veiksmīgi izpildīts.
Piezīme: Mēs izmantojam API paraugu, kas ir pieejams testēšanai. Varat izvēlēties jebkuru PATH vai atsaukties uz savu API.
Spiediet šeit, lai apskatītu avotu.
#5) Tagad mūsu nākamais solis būtu izveidot .feature failu.
Kā jau minēts ievaddaļā. .feature fails ir īpašība, kas ir mantota no Cucumber. Šajā failā mēs ierakstīsim testēšanas scenārijus, kas jāizpilda, lai veiktu API testēšanu.
- Iet uz mapi src/test/java jūsu projektā.
- Noklikšķiniet uz tā ar peles labo pogu un izveidojiet jaunu failu - userDetails.feature. Pēc tam noklikšķiniet uz pogas Pabeigt.
Tagad mapē redzēsiet šādu failu src/test/java
Portāls Zaļās krāsas ikona atgādina .feature fi le programmā Cucumber, ko mēs tikko izveidojām.
- Kad fails ir izveidots, tagad mēs rakstīsim savus testa scenārijus, kas tiks apskatīti nākamajā sadaļā.
#6) Tā kā mums ir scenārijs un tukšs . funkcija failu gatavs, tagad sāksim darbu ar mūsu pirmo skriptu. Sāksim kodēt
Ierakstiet šādu Koda rindu zem userDetails.feature faila, ko izveidojām 5. solī:
Funkcija: lietotāju datu iegūšana Scenārijs: testēšana, lai iegūtu lietotāju datus Dotais url '//reqres.in/api/users/2' Kad metode GET Tad statuss 200
Mēģināsim izprast komponentus, kas ir ierakstīti iepriekš minētajā failā:
- Funkcija: Atslēgvārds paskaidro testējamās funkcijas nosaukumu.
- Pamatinformācija: Šī ir izvēles sadaļa, kas tiek uzskatīta par priekšnoteikumu sadaļu. To var izmantot, lai definētu, kas viss ir nepieciešams API testēšanai. Tajā ir ietverts HEADER, URL & amp; PARAM iespējas.
- Scenārijs: Katrā funkciju failā, ko redzēsiet, būs vismaz viena funkcija (lai gan tā var dot vismaz vienu funkciju). vairāki Tas ir testa gadījuma apraksts.
- Ņemot vērā: Tas ir solis, kas jāizpilda pirms jebkura cita testa soļa veikšanas. Tā ir obligāti veicama darbība.
- Kad: Tajā norādīts nosacījums, kas jāizpilda, lai veiktu nākamo testa soli.
- Tad: Tajā ir teikts, ka tas, kas būtu jādara gadījumā, ja nosacījums, kas minēts Kad ir izpildīts.
Piezīme: Visi iepriekš minētie atslēgvārdi ir no Gherkins valodas. Tie ir standarta veids, kā rakstīt testēšanas skriptus, izmantojot Cucumber.
Vēl daži vārdi, kas izmantoti funkciju failā, ir šādi:
- 200: Tas ir statusa/atbildes kods, ko mēs gaidām (statusa kodu sarakstu skatiet šeit).
- GET: Tā ir API metode, piemēram, POST, PUT utt.
Mēs ceram, ka šis paskaidrojums jums bija viegli saprotams. Tagad jūs varēsiet saskarties ar to, kas tieši ir rakstīts iepriekš minētajā failā.
Tagad mums ir jāizveido TestRunner.java fails
Kā paskaidrots iepriekš minētajā sadaļā, Cucumber ir nepieciešams Runner fails, kas būtu nepieciešams, lai izpildītu .feature failu, kurā ir testēšanas scenāriji.
- Iet uz mapi src/test/java jūsu projektā
- Noklikšķiniet uz tā ar peles labo pogu un izveidojiet jaunu Java failu: TestRunner.java
- Kad fails ir izveidots, zem tās ievietojiet šādas koda rindas:
import org.junit.runner.RunWith; import com.intuit.karate.junit4.Karate; @RunWith(Karate.class) public class TestRunner { } - Test Runner ir fails, kas tagad tiks izpildīts, lai veiktu vēlamo scenāriju, kas ir uzrakstīts 5. solī.
#7) Tagad mēs esam gatavi ar abiem failiem TestRunner.Java un userDeatils.feature. Vienīgais uzdevums, kas mums atlicis, ir Palaist scenārijs.
- Dodieties uz TestRunner.java failu un noklikšķiniet uz tā ar peles labo pogu, kā parādīts attēlā zemāk.
- Izvēlieties Run As -> Junit Tests
- Tagad, kad tas būs atlasīts, jūs sāksiet novērot, ka testa gadījums ir uzsākts.
- Pagaidiet, līdz testa skripts tiks izpildīts. Kad tas būs izdarīts, logā redzēsiet kaut ko tādu, kā parādīts attēlā zemāk.
- Beidzot varam teikt, ka esam veiksmīgi izveidojuši savu pirmo pamata Testa skripts izmantojot Karatē sistēma.
#8) Visbeidzot, Karate sistēma nodrošina arī HTML atskaites prezentāciju par veikto izpildi.
- Dodieties uz mērķa mapi -> surefire-reports-> Šeit redzēsiet savu HTML pārskatu, kuru varat atvērt.
** Lai iegūtu labāku izskatu, iesakām to atvērt, izmantojot pārlūku Chrome.
- Jums tiks parādīts šāds HTML ziņojums, kurā attēlots Scenāriji & amp; tests kas ir izpildīts minētajam scenārijam:
Secinājums
Šajā pamācībā mēs esam apsprieduši API testēšanu, dažādus tirgū pieejamos testēšanas rīkus un to, kā Karate Framework ir labāks risinājums salīdzinājumā ar citiem rīkiem.
Lai izveidotu savu pirmo pamata testa skriptu, mēs izmantojām pakāpenisku pieeju. Mēs sākām ar pamata testa skripta Maven projekts Eclipse IDE vidē lai izveidotu .feature failu, kas satur visu testēšanas scenāriju un Runner failu, lai izpildītu .feature failā minēto testa gadījumu.
Vairāku soļu beigās mēs varējām redzēt testa rezultātu izpildes pārskatu.
Mēs ceram, ka šī pamācība bija noderīga iesācējiem, lai uzzinātu, kā izveidot savu pirmo testa skriptu, izmantojot Karate Framework, un veikt API testēšanu. Šī detalizētā pieeja soli pa solim ir lielisks veids, kā palaist un izpildīt dažādus API testus.
NĀKOTE>>