TestRail ā€” projekta individuāli iestatÄ«jumi

Ievads

Daudzos projektos, ar kuriem es strādāju, cilvēki nepielāgoja TestRail sev un iztika ar standarta iestatÄ«jumiem. Tāpēc Å”ajā rakstā es mēģināŔu aprakstÄ«t atseviŔķu iestatÄ«jumu piemēru, kas var palÄ«dzēt uzlabot jÅ«su darba efektivitāti. Piemēram, ņemsim mobilo aplikāciju izstrādes projektu.

Neliela atruna. Å ajā rakstā nav apraksta par TestRail pamata funkcionalitāti (par to ir daudz ceļvežu) un pārdoÅ”anas izteiksmes, kas krāsaini apraksta, kāpēc jums ir jāizvēlas tieÅ”i Å”is pārdevējs, lai izveidotu repozitoriju ar testiem.

Pamatojums plāns (kas tiks īstenots)

  1. Vispārīgās prasības

    1. Pilnīgi jebkuram vajadzētu būt iespējai nodot lietu.

    2. Gadījumiem ir jāpaliek aktuāliem pēc iespējas ilgāk

    3. Gadījumos pēc iespējas rūpīgi jāaptver mobilās lietojumprogrammas funkcionalitāte, lai tas nebūtu pretrunā ar pirmajiem diviem punktiem.

  2. Sadalīt TestCase un TestScenario

  3. Ātra dažādu veidu TestRun Ä£enerÄ“Å”ana

    1. DÅ«mi

    2. Regresēt

    3. Trieciena pārbaude utt.

  4. Lietu atbalsta optimizācija

    1. AtteikÅ”anās no ā€œmiruÅ”ajiemā€ cietkodētajiem ekrānuzņēmumiem un pāreja uz ā€œpārvietojamiem datiemā€

Prasības

Lai rediģētu laukus, jums bÅ«s nepiecieÅ”ama administratora piekļuve

Projekta veida izvēle

Ir pieejami trīs projektu veidi, no kuriem izvēlēties:

TestRail ā€” projekta individuāli iestatÄ«jumi

Mēs izvēlēsimies noklusējuma veidu. Tajā vienlaikus bÅ«s pieejami visi korpusi. Mēs izmantosim viedo filtrÄ“Å”anu un dinamiski pārvaldÄ«sim visus gadÄ«jumus vienlaikus.

Lauku pievienoŔana, lai skatītu testa gadījumu sarakstu

Pievienosim lauku prioritāro pārbaudes gadījumu parādīŔanai:

TestRail ā€” projekta individuāli iestatÄ«jumi

Varat arī pievienot citus laukus.

Pārbaudes gadījumu lauku un tagu iestatīŔana

Atveriet iestatījumu izvēlni:

TestRail ā€” projekta individuāli iestatÄ«jumi

Mums būs nepiecieŔami Ŕādi lauki:

Lauks ā€œKopsavilkumsā€ (pārbaudes gadÄ«juma galvene)

TestRail ā€” projekta individuāli iestatÄ«jumi

Å is lauks jau pastāv, mēs tikai sistematizējam tā izmantoÅ”anu. Mēs sadalÄ«sim gadÄ«jumus TestCase un TestScenario. Lai liels lietu saraksts bÅ«tu labāk salasāms, labāk ir iepriekÅ” vienoties par kopsavilkuma rakstÄ«Å”anas noteikumiem.

Testa scenārijs:

Piemērs: TestScenario ā€” pamata scenārijs mobilās lietojumprogrammas lietoÅ”anai

TestCase:

Piemērs: Galvenais ekrāns - Autorizācijas sadaļa - Ievadiet pieteikÅ”anos

Kopumā lietas kopsavilkumā redzam klasisko izpratni: ā€œkas, kur, kadā€. Mēs arÄ« vizuāli nodalām augsta lÄ«meņa testa skriptus un zema lÄ«meņa testa gadÄ«jumus automatizācijai vispiemērotākajā formā.

Tags ā€œStartScreenā€ (ekrāns, no kura sākas TestScenario; arÄ« daudzi testa gadÄ«jumi var pieskarties blakus esoÅ”ajiem ekrāniem)

PriekÅ” kam tas var bÅ«t nepiecieÅ”ams: mēs no teksta noņemsim gadÄ«jumu teksta tipiskus soļus, kas ved lietotāju uz paÅ”reizējās pārbaudes lietas ekrānu. (tipiskas darbÄ«bas konkrētas pārbaudes situācijas izveidoÅ”anai) Visas tipiskās darbÄ«bas visiem testa gadÄ«jumiem tiks ierakstÄ«tas vienā failā. Par to sÄ«kāk rakstÄ«Å”u atseviŔķi.

Izveidojiet jaunu lauku:

TestRail ā€” projekta individuāli iestatÄ«jumi

Aizpildiet jaunā lauka sastāvdaļas:

TestRail ā€” projekta individuāli iestatÄ«jumi

Å ajā gadÄ«jumā mēs izveidojam atlases lauku no vērtÄ«bu saraksta. Ievadiet Ŕī lauka vērtÄ«bas:

TestRail ā€” projekta individuāli iestatÄ«jumi

Lūdzu, ņemiet vērā, ka ID vērtības nesākas ar vienu un nav secīgas. Kāpēc tas tiek darīts? Lieta ir tāda, ka, ja mums ir reģistrēti testa gadījumi ar ievadīto ID,

TestRail ā€” projekta individuāli iestatÄ«jumi

un pēc tam mums bÅ«s jāizveido treÅ”ais ekrāns starp diviem esoÅ”ajiem ekrāniem,

TestRail ā€” projekta individuāli iestatÄ«jumi

tad mums bÅ«s jāpārraksta id, un, tā kā tam jau ir pievienoti esoÅ”o teksta gadÄ«jumu tagi, tie vienkārÅ”i tiks izdzēsti. Tas bÅ«s ļoti nepatÄ«kami.

Tags ā€œScreenā€ (ekrāna nosaukums, kas ietekmē TestCase)

Kas jums varētu bÅ«t nepiecieÅ”ams: viens no trieciena testÄ“Å”anas enkuriem. Piemēram, izstrādātāji izveidoja jaunu lielisku funkciju. Mums tas ir jāpārbauda, ā€‹ā€‹taču mums ir jāsaprot, ko tieÅ”i Ŕī funkcija varētu ietekmēt. Pēc noklusējuma mēs varam sākt no paradigmas, ka dažādiem lietojumprogrammas ekrāniem (aktivitātēm) ir dažādas klases un tāpēc tie veido dažādas lietojumprogrammas sastāvdaļas. Protams, Å”ajā gadÄ«jumā ir nepiecieÅ”ama individuāla pieeja.

Piemērs: sākuma ekrāns, MapScreen, PayScreen utt.

TestRail ā€” projekta individuāli iestatÄ«jumi

Lauks ā€œMovableDataā€ (saite uz starpniekservera datu bāzi ar maināmiem testa datiem)

Tālāk mēs mēģināsim atrisināt datu atbilstÄ«bas saglabāŔanas problēmu testa gadÄ«jumos:

  1. Saites uz paÅ”reizējiem izkārtojumiem (tas ir daudz labāk nekā nedzÄ«vu ekrānuzņēmumu uzņemÅ”ana)

  2. Tipiskas darbības, lai nokļūtu ekrānā ar testa situāciju

  3. SQL vaicājumi

  4. Saites uz ārējiem datiem un citiem datiem

Tā vietā, lai rakstÄ«tu testa datus katrā testa piemērā, mēs izveidosim vienu ārēju failu un saiti uz to visos testa gadÄ«jumos. Atjauninot Å”os datus, mums nebÅ«s jāiziet cauri visi testa gadÄ«jumi un tie jāmaina, bet Å”os datus varēs mainÄ«t tikai vienā vietā. Ja kāds nesagatavots atver testa gadÄ«jumu, viņŔ pārbaudes gadÄ«juma pamattekstā redzēs saiti uz failu un mājienu, ka viņam jāiet uz to, lai iegÅ«tu pārbaudes datus.

Mēs visus Å”os datus iesaiņosim vienā ārējā failā, kas bÅ«s pieejams ikvienam projekta dalÄ«bniekam. Piemēram, varat izmantot Google izklājlapu vai Excel un failā iestatÄ«t meklÄ“Å”anu. Kāpēc tieÅ”i Å”ie pārdevēji? Fakts ir tāds, ka mēs sākam no paradigmas, ka jebkurai personai komandā ir jāspēj atvērt un nokārtot testa gadÄ«jumu, vispirms neinstalējot nekādus rÄ«kus.

Par Google lapa varat izmantot SQL vaicājumus. Piemērs:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

Par izcelties Varat iestatÄ«t ērtus tÅ«lÄ«tējās meklÄ“Å”anas makro. (filtrÄ“Å”ana) Piemērs ŠæŠ¾ ссыŠ»ŠŗŠµ.

PatiesÄ«bā ideja nav jauna, un tā ir aprakstÄ«ta pirmā testētāja grāmatā ā€œTesting dot comā€. (autors Savins Romans) Mēs tikai integrējam Romāna Savina piedāvātās metodes programmā TestRail. Lai to izdarÄ«tu, izveidojiet lauku ar saiti uz izveidoto failu:

TestRail ā€” projekta individuāli iestatÄ«jumi

aizpildiet saites noklusējuma vērtību, lai katram jaunam testa gadījumam jau būtu saite:

TestRail ā€” projekta individuāli iestatÄ«jumi

Ja mainās ārējā faila atraÅ”anās vieta (paredzam jebkuru force majeure), tad visos testa gadÄ«jumos varat ērti mainÄ«t vienu vai vairākus laukus vienlaikus:

TestRail ā€” projekta individuāli iestatÄ«jumiTestRail ā€” projekta individuāli iestatÄ«jumi

Lauks ā€œAprakstiā€ (pārbaudes gadÄ«juma apraksts vai ideja, standarta instrukcijas)

Kas jums var bÅ«t nepiecieÅ”ams: Å”ajā teksta laukā mēs ievietosim Ä«su testa gadÄ«juma aprakstu un standarta instrukcijas.

Piemērs: Visi testa dati (paÅ”reizējie izkārtojumi, rÄ«ku izmantoÅ”ana un citi dati) no Ŕī testa gadÄ«juma ir norādÄ«ti ar saitēm {...} un atrodas MovableData failā. Saite uz MovableData attiecÄ«gajā laukā augÅ”pusē.

TestRail ā€” projekta individuāli iestatÄ«jumi

Tags ā€œComponentā€ (mobilās lietojumprogrammas komponents)

Kam tas varētu būt vajadzīgs: trieciena pārbaudei. Ja mobilo aplikāciju var sadalīt komponentos (kas pēc iespējas mazāk ietekmē viena otru), tad pietiks ar izmaiņām vienā komponentā (ar zināmiem riskiem), lai tās pārbaudītu viena komponenta ietvaros, un būs mazāk iemesla veikt visa vispārēja regresija. Ja ir informācija, ka viens komponents var ietekmēt citu, tad tiek sastādīta trieciena pārbaudes matrica.

Sastāvdaļu piemēri: GooglePay, Pasūtījums, Lietotāji, Karte, Autorizācija utt.

TestRail ā€” projekta individuāli iestatÄ«jumi

Tags "TAG" (citi tagi filtrēŔanai)

Testa gadÄ«juma marÄ·Ä“Å”ana ar tagiem patvaļīgai filtrÄ“Å”anai. 

Ä»oti noderÄ«ga: 

  1. ātri apkopojot TestRun dažādiem tipiskiem uzdevumiem: dūmiem, regresijai utt.

  2. vai testi būs automatizēti vai jau automatizēti?

  3. jebkuri citi tagi

Piemērs: Smoke, Automated, WhiteLabel, ForDelete utt.

TestRail ā€” projekta individuāli iestatÄ«jumiTestRail ā€” projekta individuāli iestatÄ«jumi

Lauku parādīŔanas secības iestatīŔana testa gadījumā

Esam izveidojuÅ”i daudz jaunu lauku, ir pienācis laiks tos sakārtot ērtā secÄ«bā:

TestRail ā€” projekta individuāli iestatÄ«jumi

TestRun izveide

Tagad mēs izveidosim jaunu testa braucienu ar paÅ”reizējiem gadÄ«jumiem dÅ«mu pārbaudes veikÅ”anai ar trÄ«s klikŔķiem:

TestRail ā€” projekta individuāli iestatÄ«jumi

Citi noderīgi padomi

  1. Ja TestRail ir vairāki projekti, tad neaizmirstiet izveidot jaunus laukus tikai savam projektam, pretējā gadÄ«jumā kolēģi no kaimiņu komandām bÅ«s ļoti pārsteigti par jaunu neparastu lauku parādÄ«Å”anos. Iespējams vietējs ģībonis.

TestRail ā€” projekta individuāli iestatÄ«jumi

2. Gadījumus ar lielu skaitu lauku ir vieglāk kopēt no līdzīga grupas veida, nevis izveidot jaunus:

TestRail ā€” projekta individuāli iestatÄ«jumi

3. Kontus var koplietot. Piemēram: viens administrators, vairāki lietotāji.

Secinājums

IepriekÅ” aprakstÄ«tie piemēri ir Ä«stenoti vairākos projektos un ir pierādÄ«juÅ”i savu efektivitāti. Es ceru, ka tie palÄ«dzēs uzlabot jÅ«su izpratni par Å”o rÄ«ku un palÄ«dzēs izveidot efektÄ«vas un ērtas ā€œtesta krātuvesā€. BÅ«Å”u ļoti pateicÄ«gs, ja komentāros aprakstÄ«siet savu TestRail lietoÅ”anas pieredzi un noderÄ«gus padomus.

Saites:

TestRail pārdevēja vietne

Grāmata: ā€œTesting .COMā€ (autors Romāns Savins)

Liels paldies par jūsu uzmanību!

Avots: www.habr.com

Pievieno komentāru