TestRail – individualūs projekto nustatymai

įvedimas

Daugelyje projektų, su kuriais dirbau, žmonės nepritaikė „TestRail“ sau ir tenkino standartinius nustatymus. Todėl šiame straipsnyje pabandysiu aprašyti atskirų nustatymų pavyzdį, kuris gali padėti pagerinti jūsų darbo efektyvumą. Pavyzdžiui, paimkime mobiliųjų aplikacijų kūrimo projektą.

Mažas atsisakymas. Šiame straipsnyje nėra pagrindinių „TestRail“ funkcijų aprašymo (yra daug vadovų apie tai) ir pardavimo išraiškų, spalvingai apibūdinančių, kodėl reikia pasirinkti būtent šį tiekėją, kad sukurtumėte saugyklą su testais.

Pateisinimo planas (kas bus įgyvendinta)

1. Bendrieji reikalavimai

   1. Absoliučiai bet kas turėtų turėti galimybę perduoti bylą.

   2. Bylos turėtų išlikti aktualios kuo ilgiau

   3. Atvejai turėtų kuo išsamiau aprėpti mobiliosios programos funkcionalumą, kad tai neprieštarautų pirmiesiems dviem punktams.

2. Padalinkite į „TestCase“ ir „TestScenario“.

3. Greita įvairių tipų TestRun generacija

   1. Dūmai

   2. Regresas

   3. Smūgio bandymai ir kt.

4. Atvejo palaikymo optimizavimas

   1. Atsisakyti „negyvų“ užkoduotų ekrano kopijų ir pereiti prie „kilnojamųjų duomenų“

reikalavimai

Norėdami redaguoti laukus, jums reikės administratoriaus prieigos

Projekto tipo pasirinkimas

Galima rinktis iš trijų projektų tipų:

Mes pasirinksime numatytąjį tipą. Visi dėklai jame bus pasiekiami vienu metu. Naudosime išmanųjį filtravimą ir dinamiškai valdysime visus atvejus vienu metu.

Laukų pridėjimas, kad peržiūrėtumėte bandomųjų atvejų sąrašą

Pridėkime lauką, kuriame būtų rodomi prioritetiniai bandymo atvejai:

Taip pat galite pridėti kitų laukų.

Bandomųjų atvejų laukų ir žymų nustatymas

Atidarykite nustatymų meniu:

Mums reikės šių laukų:

Laukas „Suvestinė“ (bandomojo atvejo antraštė)

Ši sritis jau egzistuoja, tik sisteminame jos panaudojimą. Mes suskirstysime atvejus į TestCase ir TestScenario. Norint geriau perskaityti didelį bylų sąrašą, geriau iš anksto susitarti dėl santraukos rašymo taisyklių.

Testo scenarijus:

Pavyzdys: TestScenario – pagrindinis mobiliosios programos naudojimo scenarijus

TestCase:

Pavyzdys: Pagrindinis ekranas – Leidimo skyrius – Įveskite prisijungimo vardą

Iš viso bylos santraukoje matome klasikinį supratimą: „kas, kur, kada“. Taip pat vizualiai atskiriame aukšto lygio testavimo scenarijus ir žemo lygio testavimo atvejus tinkamiausia automatizavimui forma.

„StartScreen“ žyma (ekranas, nuo kurio prasideda „TestScenario“; taip pat daugelis bandymų atvejų gali liesti gretimus ekranus)

Kam to gali prireikti: pašalinsime iš teksto atvejų tipinius žingsnius, kurie veda vartotoją į esamo bandomojo atvejo ekraną. (tipiniai žingsniai kuriant konkrečią bandymo situaciją) Visi tipiniai visų bandymo atvejų veiksmai bus įrašyti į vieną failą. Plačiau apie tai parašysiu atskirai.

Sukurkite naują lauką:

Užpildykite naujo lauko komponentus:

Šiuo atveju mes kuriame pasirinkimo lauką iš reikšmių sąrašo. Įveskite šio lauko reikšmes:

Atminkite, kad ID reikšmės neprasideda vienu ir nėra iš eilės. Kodėl tai daroma? Esmė ta, kad jei turime bandomuosius atvejus su įrašytu ID,

ir po to turėsime sukurti trečią ekraną tarp dviejų esamų,

tada turėsime perrašyti id, o kadangi prie jo jau prikabintos esamų teksto atvejų žymos, tai jos tiesiog bus ištrintos. Tai bus labai nemalonu.

Žyma „Ekranas“ (ekrano pavadinimas, kuris turi įtakos „TestCase“)

Ko jums gali prireikti: vieno iš inkarų smūgio bandymams. Pavyzdžiui, kūrėjai sukūrė naują šaunią funkciją. Turime tai išbandyti, bet tam turime suprasti, ką tiksliai ši funkcija gali paveikti. Pagal numatytuosius nustatymus galime pradėti nuo paradigmos, kad skirtingi programos ekranai (veikla) ​​turi skirtingas klases ir todėl sudaro skirtingus programos komponentus. Žinoma, šiuo atveju reikalingas individualus požiūris.

Pavyzdys: home_screen, MapScreen, PayScreen ir kt.

Laukas „MovableData“ (nuoroda į tarpinio serverio duomenų bazę su keičiamais bandymo duomenimis)

Toliau bandysime išspręsti duomenų aktualumo išlaikymo bandomaisiais atvejais problemą:

1. Nuorodos į dabartinius maketus (tai daug geriau nei daryti negyvas ekrano kopijas)

2. Įprasti žingsniai norint patekti į ekraną su bandymo situacija

3. SQL užklausos

4. Nuorodos į išorinius duomenis ir kitus duomenis

Užuot įrašę testo duomenis kiekvienoje bandomojoje byloje, sukursime vieną išorinį failą ir susiesime su juo visuose bandomuosiuose atvejuose. Atnaujinant šiuos duomenis mums nereikės pereiti visų bandomųjų atvejų ir juos keisti, tačiau šiuos duomenis bus galima pakeisti tik vienoje vietoje. Jei kas nors nepasiruošęs atidarys bandomąjį atvejį, bandomojo atvejo tekste jis pamatys nuorodą į failą ir užuominą, kad jam reikia eiti į jį, kad gautų bandymo duomenis.

Visus šiuos duomenis supakuosime į vieną išorinį failą, kuris bus prieinamas visiems projekto dalyviams. Pavyzdžiui, galite naudoti „Google“ lapą arba „Excel“ ir nustatyti paiešką faile. Kodėl būtent šie pardavėjai? Faktas yra tas, kad mes pradedame nuo paradigmos, kad bet kuris komandos narys turėtų turėti galimybę atidaryti ir išlaikyti bandomąjį atvejį, prieš tai neįdiegęs jokių įrankių.

Už "Google" lapelis galite naudoti SQL užklausas. Pavyzdys:

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

Už Excel Galite nustatyti patogias momentinės paieškos makrokomandas. (filtravimas) Pavyzdys по ссылке.

Tiesą sakant, idėja nėra nauja ir aprašyta pirmojo testuotojo knygoje „Testing dot com“. (autorius Savin Roman) Mes kaip tik integruojame Romano Savino pasiūlytus metodus į TestRail. Norėdami tai padaryti, sukurkite lauką su nuoroda į sukurtą failą:

įveskite numatytąją nuorodos reikšmę, kad kiekvienas naujas bandomasis atvejis jau turėtų nuorodą:

Pasikeitus išorinio failo vietai (nustatome nenugalimos jėgos atvejus), tuomet visais bandymo atvejais galite patogiai pakeisti vieną ar kelis laukus vienu metu:

Laukas „Aprašymai“ (bandomojo atvejo aprašymas arba idėja, standartinės instrukcijos)

Ko jums gali prireikti: Šiame teksto laukelyje patalpinsime trumpą bandomojo atvejo aprašymą ir standartines instrukcijas.

Pavyzdys: Visi šio bandymo atvejo bandymo duomenys (dabartinis išdėstymas, įrankių naudojimas ir kiti duomenys) yra pažymėti nuorodomis {...} ir yra MovableData faile. Susiekite su MovableData atitinkamame lauke viršuje.

Žyma „Komponentas“ (programos mobiliesiems komponentas)

Kam jo gali prireikti: smūgio bandymams. Jei mobiliąją aplikaciją galima suskirstyti į komponentus (kurie vienas kitą veikia kuo mažiau), pakaks vieno komponento pakeitimus (su tam tikra rizika) patikrinti tame pačiame komponente ir bus mažiau priežasčių atlikti bendros visko regresijos. Jei yra informacijos, kad vienas komponentas gali paveikti kitą, tada sudaroma smūgio bandymo matrica.

Komponentų pavyzdžiai: GooglePay, Užsakymas, Vartotojai, Žemėlapis, Autorizacija ir kt.

Žyma „TAG“ (kitos filtravimo žymos)

Bandomojo atvejo žymėjimas savavališko filtravimo žymomis. 

Labai naudinga: 

1. greitai sukompiliuojant TestRun įvairioms tipinėms užduotims: dūmams, regresijai ir kt.

2. testai bus automatizuoti ar jau automatizuoti?

3. bet kokios kitos žymos

Pavyzdys: Smoke, Automated, WhiteLabel, ForDelete ir kt.

Laukų rodymo tvarkos nustatymas bandymo atveju

Sukūrėme daug naujų laukų, pats laikas juos sutvarkyti patogia tvarka:

TestRun kūrimas

Dabar sukursime naują bandomąjį paleidimą su dabartiniais dūmų bandymo atvejais trimis paspaudimais:

Kiti naudingi patarimai

1. Jei „TestRail“ turi kelis projektus, nepamirškite sukurti naujų laukų tik savo projektui, kitaip kolegos iš kaimyninių komandų bus labai nustebinti naujų neįprastų laukų atsiradimu. Galimas vietinis alpimas.

2. Atvejus, kuriuose yra daug laukų, lengviau nukopijuoti iš panašaus tipo grupės, nei sukurti naujus:

3. Paskyros gali būti bendrinamos. Pavyzdžiui: vienas administratorius, keli vartotojai.

išvada

Pirmiau aprašyti pavyzdžiai buvo įgyvendinti keliuose projektuose ir parodė jų veiksmingumą. Tikiuosi, kad jie padės geriau suprasti šį įrankį ir padės sukurti efektyvias ir patogias „bandomąsias saugyklas“. Būčiau labai dėkingas, jei komentaruose apibūdintumėte savo patirtį naudojant TestRail ir naudingus patarimus.

Nuorodos:

TestRail pardavėjo svetainė

Knyga: „Testing .COM“ (autorius Roman Savin)

Labai ačiū už Jūsų dėmesį!

Šaltinis: www.habr.com