Uvod
U mnogim projektima s kojima sam radio, ljudi nisu prilagođavali TestRail za sebe i upravljali su standardnim postavkama. Stoga ću u ovom članku pokušati opisati primjer pojedinačnih postavki koje vam mogu pomoći da povećate efikasnost vašeg rada. Na primjer, uzmimo projekt razvoja mobilne aplikacije.
Mala izjava o odricanju odgovornosti. Ovaj članak ne opisuje osnovnu funkcionalnost TestRail-a (postoji mnogo vodiča za ovo) i prodajne izraze koji živopisno opisuju zašto trebate odabrati ovog dobavljača da biste kreirali spremište sa testovima.
Plan-opravdanje (šta će se implementirati)
-
Opšti zahtevi
-
Slučaj bi trebao moći da prođe apsolutno bilo koga
-
Slučajevi bi trebali ostati relevantni što je duže moguće
-
Slučajevi treba da pokriju funkcionalnost mobilne aplikacije što je moguće pažljivije u mjeri u kojoj to nije u suprotnosti s prve dvije tačke.
-
-
Razdvajanje na TestCase i TestScenario
-
Brzo formiranje TestRun različitih tipova
-
dim
-
Nazadovanje
-
Ispitivanje uticaja itd.
-
-
Optimizacija podrške za slučaj
-
Odbijanje "mrtvih" tvrdo kodiranih snimaka ekrana i prelazak na "pokretne podatke"
-
zahtjevi
Trebat će vam administratorski pristup za uređivanje polja
Odabir tipa projekta
Postoje tri vrste projekata koje možete izabrati:
Mi ćemo izabrati zadani tip. U njemu će svi koferi biti dostupni u isto vrijeme. Koristit ćemo pametno filtriranje i dinamički upravljati svim slučajevima odjednom.
Dodavanje polja za pregled liste test slučajeva
Dodajmo polje za prikaz prioritetnih test slučajeva:
Možete dodati i druga polja.
Postavljanje polja i oznaka test slučaja
Otvaranje menija postavki:
Potrebna su nam ova polja:
Polje „Sažetak“ (zaglavlje testnog slučaja)
Ovo polje već postoji, mi samo sistematiziramo njegovu upotrebu. Slučajeve ćemo podijeliti na TestCase i TestScenario. Za bolju čitljivost velike liste slučajeva, bolje je unaprijed dogovoriti pravila za pisanje sažetka.
Test scenario:
Primjer: TestScenario - Glavni slučaj upotrebe mobilne aplikacije
test case:
Primjer: Glavni ekran - odjeljak za autorizaciju - unos za prijavu
Ukupno, u sažetku slučaja vidimo klasično razumijevanje: „šta, gdje, kada“. Također vizualno razdvajamo test skripte visokog nivoa i test slučajeve niskog nivoa u najprikladnijem obliku za automatizaciju.
Označite "StartScreen" (ekran sa kojeg počinje TestScenario, također mnogi testni slučajevi mogu dodirnuti susjedne ekrane)
Za ono što može biti potrebno: uklonit ćemo tipične korake iz teksta slučajeva koji vode korisnika na ekran trenutnog test slučaja. (tipični koraci za kreiranje specifične test situacije) Svi tipični koraci za sve test slučajeve biće napisani u jednoj datoteci. O tome ću detaljnije pisati zasebno.
Kreirajte novo polje:
Popunite komponente novog polja:
U ovom slučaju kreiramo polje za odabir sa liste vrijednosti. Unesite vrijednosti za ovo polje:
Imajte na umu da id vrijednosti ne počinju od jedan i nisu uzastopne. Zašto se to radi? Činjenica je da ako imamo evidentirane test slučajeve sa unesenim ID-om,
a nakon toga trebamo napraviti treći ekran između dva postojeća,
onda ćemo morati da prepišemo id, a pošto su oznake postojećih tekstualnih slučajeva već prikačene uz njega, oni se jednostavno brišu. Biće veoma neprijatno.
Oznaka "Ekran" (naziv ekrana koji utiče na TestCase)
Ono što vam može zatrebati: jedno od sidara za ispitivanje na udar. Na primjer, programeri su napravili sjajnu novu funkciju. Moramo ga testirati, ali za ovo moramo razumjeti na šta bi ova funkcija mogla utjecati. Podrazumevano, možemo poći od paradigme da različiti ekrani (aktivnosti) aplikacije imaju različite klase i stoga čine različite komponente aplikacije. Naravno, u ovom slučaju je potreban individualni pristup.
Primjer: home_screen, MapScreen, PayScreen, itd.
Polje MovableData (veza na proxy bazu podataka sa promjenjivim test podacima)
Zatim ćemo pokušati riješiti problem održavanja relevantnosti podataka u test slučajevima:
-
Linkovi na stvarne izglede (ovo je mnogo bolje od pravljenja mrtvih snimaka ekrana)
-
Tipični koraci do ekrana test slučaja
-
SQL upiti
-
Linkovi na eksterne podatke i druge podatke
Umjesto pisanja testnih podataka unutar svakog testnog slučaja, napravićemo jednu eksternu datoteku, a na svim test slučajevima ćemo napraviti link ka njoj. Prilikom ažuriranja ovih podataka nećemo morati prolaziti kroz sve test slučajeve i mijenjati ih, već će te podatke biti moguće mijenjati samo na jednom mjestu. Ako neko nespreman otvori test slučaj, videće u telu test slučaja vezu do datoteke i nagoveštaj da morate da odete do nje za testne podatke.
Sve ove podatke ćemo spakovati u jednu eksternu datoteku, koja će biti dostupna svima na projektu. Na primjer, možete koristiti Google Sheet ili Excel i postaviti pretragu unutar datoteke. Zašto baš ovi dobavljači? Činjenica je da polazimo od paradigme da svaka osoba u timu treba da bude u mogućnosti da otvori i položi test slučaj bez potrebe da prethodno instalira bilo kakve alate.
Do Google list SQL upiti se mogu koristiti. primjer:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Do nadmašiti Možete postaviti pogodne makroe za trenutno pretraživanje. (filtriranje) Primjer .
Zapravo, ideja nije nova i opisana je u prvoj knjizi testera “Testing dot com”. (autor Savin Roman) Mi samo integrišemo metode koje je predložio Roman Savin u TestRail. Da biste to učinili, kreirajte polje s vezom do kreirane datoteke:
popunite zadanu vrijednost veze tako da u svakom novom test slučaju već postoji veza:
Ako se lokacija vanjske datoteke promijeni (mi predviđamo bilo kakvu višu silu), tada možete jednostavno promijeniti jedno ili više polja u svim test slučajevima odjednom:
Polje "Opisi" (opis ili ideja testnog slučaja, tipične upute)
Šta vam može zatrebati: U ovo tekstualno polje postavićemo kratak opis test slučaja i tipična uputstva.
Primjer: Svi testni podaci (stvarni izgledi, upotreba alata i drugi podaci) iz ovog test slučaja su označeni sa {...} vezama i nalaze se u MovableData. Veza do MovableData u odgovarajućem polju na vrhu.
Oznaka "Komponenta" (komponenta mobilne aplikacije)
Šta vam može zatrebati: za ispitivanje na udar. Ako se mobilna aplikacija može podijeliti na komponente (koje što manje utiču jedna na drugu), tada će promjene u jednoj komponenti biti dovoljne (uz određene rizike) za provjeru unutar iste komponente, a bit će manje razloga za provođenje općih regresija. svega i svačega. Ako postoje informacije da jedna komponenta može utjecati na drugu, tada se sastavlja matrica za ispitivanje utjecaja.
Primjeri komponenti: GooglePay, Narudžba, Korisnici, Mapa, Autorizacija, itd.
Oznaka "TAG" (Ostale oznake za filtriranje)
Označavanje test slučaja oznakama za proizvoljno filtriranje.
Veoma korisno za:
-
brza kompilacija TestRun-a za različite tipične zadatke: dim, regresija, itd.
-
da li će testovi biti automatizovani ili već automatizovani
-
bilo koje druge oznake
Primjer: Smoke, Automated, WhiteLabel, ForDelete, itd.
Podešavanje redosleda prikaza polja u test slučaju
Napravili smo puno novih polja, vrijeme je da ih rasporedimo po prikladnom redoslijedu:
Kreiranje TestRun-a
Sada ćemo kreirati novi probni rad s relevantnim slučajevima za testiranje dima u tri klika:
Ostali korisni savjeti
-
Ako u TestRailu postoji nekoliko projekata, onda ne zaboravite kreirati nova polja samo za svoj projekat, inače će kolege iz susjednih timova biti jako iznenađeni pojavom novih neobičnih polja. Moguća je lokalna nesvjestica.
2. Slučajevi sa velikim brojem polja lakše je kopirati iz grupe slične vrste nego kreirati nove:
3. Računi se mogu dijeliti. Na primjer: jedan administrator, nekoliko korisnika.
zaključak
Navedeni primjeri su implementirani na nekoliko projekata i pokazali su svoju efikasnost. Nadam se da će vam pomoći da poboljšate vaše razumijevanje ovog alata i pomoći vam da kreirate efikasno i praktično "skladištenje tijesta". Bio bih vam jako zahvalan ako u komentarima opišete svoje iskustvo korištenja TestRaila i korisne savjete.
Reference:
knjiga:
Hvala vam puno na pažnji!
izvor: www.habr.com