Úvod
V mnohých projektoch, s ktorými som pracoval, si ľudia neprispôsobili TestRail pre seba a vystačili si so štandardnými nastaveniami. Preto sa v tomto článku pokúsim popísať príklad jednotlivých nastavení, ktoré vám môžu pomôcť zlepšiť efektivitu vašej práce. Vezmime si napríklad projekt vývoja mobilnej aplikácie.
Malé odmietnutie zodpovednosti. Tento článok neobsahuje popis základnej funkcionality TestRail (je na to veľa návodov) a predajné výrazy farbisto popisujúce, prečo si na vytvorenie úložiska s testami musíte vybrať práve tohto dodávateľa.
Plán odôvodnenia (čo sa bude realizovať)
-
Všeobecné požiadavky
-
Absolútne každý by mal mať možnosť prejsť prípadom.
-
Prípady by mali zostať relevantné čo najdlhšie
-
Prípady by mali čo najdôkladnejšie pokrývať funkčnosť mobilnej aplikácie do tej miery, aby to neodporovalo prvým dvom bodom
-
-
Rozdeliť na TestCase a TestScenario
-
Rýchle generovanie TestRun rôznych typov
-
Dym
-
Regres
-
Nárazové skúšky atď.
-
-
Optimalizácia podpory prípadu
-
Opustenie „mŕtvych“ pevne zakódovaných snímok obrazovky a prechod na „pohyblivé údaje“
-
požiadavky
Na úpravu polí budete potrebovať administrátorský prístup
Výber typu projektu
Na výber sú tri typy projektov:
Vyberieme predvolený typ. Všetky puzdrá v ňom budú dostupné súčasne. Využijeme inteligentné filtrovanie a dynamicky spravujeme všetky prípady naraz.
Pridanie polí na zobrazenie zoznamu testovacích prípadov
Pridajme pole na zobrazenie prioritných testovacích prípadov:
Môžete pridať aj ďalšie polia.
Nastavenie polí a značiek testovacieho prípadu
Otvorte ponuku nastavení:
Budeme potrebovať nasledujúce polia:
Pole „Súhrn“ (hlavička testovacieho prípadu)
Toto pole už existuje, len systematizujeme jeho využitie. Prípady rozdelíme na TestCase a TestScenario. Pre lepšiu čitateľnosť veľkého zoznamu prípadov je lepšie si vopred dohodnúť pravidlá písania súhrnu.
Testovací scenár:
Príklad: TestScenario – Základný scenár používania mobilnej aplikácie
Testovacia situácia:
Príklad: MainScreen - časť Autorizácia - Zadajte prihlasovacie meno
Celkovo vidíme v zhrnutí prípadu klasické chápanie: „čo, kde, kedy“. Tiež vizuálne oddeľujeme testovacie skripty na vysokej úrovni a testovacie prípady nízkej úrovne vo forme najvhodnejšej pre automatizáciu.
Značka „StartScreen“ (obrazovka, z ktorej začína TestScenario; veľa testovacích prípadov sa tiež môže dotýkať susedných obrazoviek)
Na to, čo môže byť potrebné: odstránime z textu text prípadov typických krokov, ktoré vedú používateľa na obrazovku aktuálneho testovacieho prípadu. (typické kroky pre vytvorenie špecifickej testovacej situácie) Všetky typické kroky pre všetky testovacie prípady budú zapísané v jednom súbore. Podrobnejšie o tom napíšem samostatne.
Vytvorte nové pole:
Vyplňte komponenty nového poľa:
V tomto prípade vytvárame výberové pole zo zoznamu hodnôt. Zadajte hodnoty tohto poľa:
Upozorňujeme, že hodnoty id nezačínajú jednotkou a nie sú po sebe nasledujúce. Prečo sa to robí? Ide o to, že ak máme zaznamenané testovacie prípady so zadaným ID,
a potom budeme musieť vytvoriť tretiu obrazovku medzi dvoma existujúcimi obrazovkami,
potom budeme musieť prepísať id a keďže sú k nemu už pripojené značky existujúcich textových prípadov, jednoducho sa vymažú. Bude to veľmi nepríjemné.
Značka „Obrazovka“ (názov obrazovky, ktorá ovplyvňuje TestCase)
Čo možno budete potrebovať: jednu z kotiev na testovanie nárazom. Vývojári napríklad vytvorili novú skvelú funkciu. Musíme to otestovať, ale na to musíme pochopiť, čo presne môže táto funkcia ovplyvniť. Štandardne môžeme vychádzať z paradigmy, že rôzne obrazovky (aktivity) aplikácie majú rôzne triedy, a preto tvoria rôzne komponenty aplikácie. Samozrejme, v tomto prípade je potrebný individuálny prístup.
Príklad: home_screen, MapScreen, PayScreen atď.
Pole „MovableData“ (odkaz na proxy databázu s meniteľnými testovacími údajmi)
Ďalej sa pokúsime vyriešiť problém zachovania relevantnosti údajov v testovacích prípadoch:
-
Odkazy na aktuálne rozloženia (je to oveľa lepšie ako robiť mŕtve snímky obrazovky)
-
Typické kroky, ako sa dostať na obrazovku s testovacou situáciou
-
SQL dotazy
-
Odkazy na externé údaje a ďalšie údaje
Namiesto zapisovania testovacích údajov do každého testovacieho prípadu vytvoríme jeden externý súbor a prepojíme ho vo všetkých testovacích prípadoch. Pri aktualizácii týchto údajov nebudeme musieť prechádzať všetkými testovacími prípadmi a meniť ich, ale bude možné tieto údaje zmeniť len na jednom mieste. Ak niekto nepripravený otvorí testovací prípad, v tele testovacieho prípadu uvidí odkaz na súbor a nápovedu, že doň musí prejsť kvôli testovacím údajom.
Všetky tieto údaje zabalíme do jedného externého súboru, ktorý bude dostupný všetkým na projekte. Môžete napríklad použiť Google Sheet alebo Excel a nastaviť vyhľadávanie v rámci súboru. Prečo práve títo predajcovia? Faktom je, že vychádzame z paradigmy, že každá osoba v tíme by mala byť schopná otvoriť a prejsť testovacím prípadom bez toho, aby si najprv musela inštalovať nejaké nástroje.
pre Google Sheet môžete použiť SQL dotazy. Príklad:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")pre vynikať Môžete nastaviť pohodlné makrá okamžitého vyhľadávania. (filtrovanie) Príklad .
V skutočnosti táto myšlienka nie je nová a je opísaná v knihe prvého testera „Testing dot com“. (autor Savin Roman) Práve integrujeme metódy navrhnuté Romanom Savinom do TestRail. Ak to chcete urobiť, vytvorte pole s odkazom na vytvorený súbor:
vyplňte predvolenú hodnotu odkazu tak, aby každý nový testovací prípad už mal odkaz:
Ak sa zmení umiestnenie externého súboru (zabezpečujeme akúkoľvek vyššiu moc), potom môžete pohodlne zmeniť jedno alebo viac polí naraz vo všetkých testovacích prípadoch:
Pole „Descriptions“ (popis alebo myšlienka testovacieho prípadu, štandardné pokyny)
Čo môžete potrebovať: Do tohto textového poľa umiestnime stručný popis testovacieho prípadu a štandardné pokyny.
Príklad: Všetky testovacie údaje (aktuálne rozloženia, použitie nástrojov a ďalšie údaje) z tohto testovacieho prípadu sú označené odkazmi {...} a nachádzajú sa v súbore MovableData. Odkaz na MovableData v príslušnom poli v hornej časti.
Značka „Component“ (komponent mobilnej aplikácie)
Na čo to môže byť potrebné: na testovanie nárazu. Ak je možné mobilnú aplikáciu rozdeliť na komponenty (ktoré sa navzájom ovplyvňujú čo najmenej), potom zmeny v jednom komponente budú stačiť (s určitými rizikami) na kontrolu v rámci toho istého komponentu a bude menej dôvodov na vykonávanie všeobecné regresy všetkého. Ak existujú informácie, že jedna zložka môže ovplyvniť druhú, zostaví sa matica testovania vplyvu.
Príklady komponentov: GooglePay, Objednávka, Používatelia, Mapa, Autorizácia atď.
Značka „TAG“ (iné značky na filtrovanie)
Označenie testovacieho prípadu značkami na ľubovoľné filtrovanie.
Veľmi užitočné pre:
-
rýchle zostavenie TestRun pre rôzne typické úlohy: dym, regresia atď.
-
budú testy automatizované alebo už automatizované?
-
akékoľvek iné značky
Príklad: Smoke, Automated, WhiteLabel, ForDelete atď.
Nastavenie poradia zobrazenia polí v testovacom prípade
Vytvorili sme veľa nových polí, je čas usporiadať ich vo vhodnom poradí:
Vytvára sa TestRun
Teraz vytvoríme nový testovací chod s aktuálnymi prípadmi na vykonanie testovania dymu tromi kliknutiami:
Ďalšie užitočné tipy
-
Ak má TestRail niekoľko projektov, nezabudnite vytvoriť nové polia iba pre svoj projekt, inak budú kolegovia zo susedných tímov veľmi prekvapení objavením sa nových neobvyklých polí. Možné lokálne mdloby.
2. Prípady s veľkým počtom polí je jednoduchšie kopírovať z podobného typu skupiny, ako vytvárať nové:
3. Účty je možné zdieľať. Napríklad: jeden správca, niekoľko používateľov.
Záver
Vyššie opísané príklady boli implementované na niekoľkých projektoch a preukázali svoju účinnosť. Dúfam, že vám pomôžu lepšie pochopiť tento nástroj a pomôžu vám vytvoriť efektívne a pohodlné „testovacie úložiská“. Bol by som veľmi vďačný, keby ste v komentároch popísali svoje skúsenosti s používaním TestRail a užitočné tipy.
odkazy:
kniha:
Ďakujem vám veľmi pekne za vašu pozornosť!
Zdroj: hab.com