Úvod
V mnoha projektech, na kterých jsem pracoval, lidé nepřizpůsobovali TestRail svým potřebám a spokojili se se standardními nastaveními. V tomto článku se proto pokusím popsat příklad individuálních nastavení, která vám mohou pomoci zvýšit efektivitu vaší práce. Pro příklad vezmeme projekt vývoje mobilní aplikace.
Malé upozornění. Tento článek neobsahuje popis základních funkcí TestRail (na to existuje mnoho návodů) ani prodejní vyjádření, která barevně popisují, proč byste měli zvolit právě tohoto dodavatele pro vytvoření repozitáře s testy.
Plán obhajoby (co bude realizováno)
Obecné požadavky
Případ by měl být schopen projít naprosto kýmkoliv
Případy by měly udržovat aktuálnost co nejdéle
Případy by měly co nejpečlivěji pokrývat funkčnost mobilní aplikace do té míry, jak to neodporuje prvním dvěma bodům
Rozdělení na TestCase a TestScenario
Rychlé vytváření TestRun různých typů
Smoke
Regress
Impact testování atd.
Optimalizace podpory případů
Odmítnutí 'mrtvých' hardcoded screenshotů a přechod na 'movable data'
Požadavky
Pro úpravu polí budete potřebovat administrátorský přístup
Výběr typu projektu
Můžete zvolit tři typy projektu:
Zvolíme typ výchozí. V něm budou současně dostupné všechny případy. Budeme používat inteligentní filtrování a dynamicky spravovat všechny případy najednou.
Přidání polí pro zobrazení seznamu testovacích případů
Přidáme pole pro zobrazení priority testovacích případů:
Můžete také přidat další pole.
Nastavení polí a tagů testovacího případu
Otevřeme nabídku nastavení:
Budeme potřebovat tato pole:
Pole 'Summary' (záhlaví testovacího případu)
Toto pole již existuje, pouze systematizujeme jeho použití. Budeme rozdělovat případy na TestCase a TestScenario. Pro lepší čitelnost velkého seznamu případů je lepší se předem dohodnout na pravidlech psaní shrnutí.
TestScenario:
Příklad: TestScenario — Hlavní scénář použití mobilní aplikace
TestCase:
Příklad: MainScreen — Sekce přihlašování — Zadání přihlašovacího jména
Celkově vidíme v shrnutí případu klasické chápání: "co, kde, kdy". Také vizuálně oddělujeme vrcholové testovací scénáře a nízkoúrovňové testovací případy v nejvhodnějším formátu pro automatizaci.
Tag „StartScreen“ (obrazovka, z které začíná TestScenario, také mnoho testovacích případů může zasahovat do sousedních obrazovek)
K čemu může sloužit: odstraníme z textu testovacích případů typické kroky, které vedou uživatele na obrazovku aktuálního testovacího případu. (typické kroky pro vytvoření určité testovací situace) Všechny typické kroky pro všechny testovací případy budou napsány v jednom souboru. O něm podrobněji napíšu samostatně.
Vytváříme nové pole:
Vyplňujeme komponenty nového pole:
V tomto případě vytváříme pole pro výběr ze seznamu hodnot. Vkládáme hodnoty tohoto pole:
Všimněte si, že id hodnot nezačíná od jedničky a není to v souvislé řadě. Proč to tak je? Je to proto, že pokud budeme mít zapsané testovací případy s uvedeným id,
a poté budeme potřebovat vytvořit třetí obrazovku mezi dvěma existujícími,
budeme muset přepsat id, a protože k němu už jsou přiřazeny tagy stávajících testovacích případů, jednoduše se odstraní. To bude velmi nepříjemné.
Tag „Screen“ (název obrazovky, kterou zasahuje TestCase)
K čemu může sloužit: jeden z ukotvení pro dopadové testování. Například, vývojáři udělali novou skvělou funkci. Musíme ji otestovat, ale k tomu musíme pochopit, co přesně tato funkce mohla ovlivnit. Obecně bychom mohli vycházet z paradigmat, že různé obrazovky (Activity) aplikace mají různé třídy a tím pádem tvoří různé komponenty aplikace. Samozřejmě v tomto případě je potřeba individuální přístup.
Příklad: home_screen, MapScreen, PayScreen atd.
Pole „MovableData“ (odkaz na proxy DB s měnitelnými testovacími daty)
Dále se pokusíme vyřešit problém s udržováním aktuálnosti dat v testovacích případech:
Odkazy na aktuální makety (to je mnohem lepší než dělat mrtvé screenshoty)
Typické kroky do obrazovky s testovací situací
SQL dotazy
Odkazy na externí data a další údaje
Místo toho, abychom vkládali testovací data do každého testovacího případu, vytvoříme jeden externí soubor a na všechny testovací případy se na něj odkazujeme. Při aktualizaci těchto dat nebude nutné procházet všechny testovací případy a měnit je, stačí změnit tato data pouze na jednom místě. Pokud někdo nepřipravený otevře testovací případ, uvidí v jeho těle odkaz na soubor a upozornění, že je třeba se na něj podívat pro testovací data.
Všechna tato data zabalíme do jednoho externího souboru, který bude dostupný všem zájemcům na projektu. Například můžeme použít Google Sheet nebo Excel a v souboru nastavit hledání. Proč právě tito dodavatelé? Je to proto, že vycházíme z paradigmatu, že každý člověk v týmu by měl být schopen otevřít a projít testovací případ bez nutnosti předem instalovat různé nástroje.
Pro Google Sheet můžeme používat SQL dotazy. Příklad:
=dotaz(DATA!A1:M1146;"
SELECT C,D
WHERE
C obsahuje '"&HLEDAT!A2&"'")Pro Excel můžeme nastavit pohodlné makra pro okamžité vyhledávání. (filtrování) Příklad .
Myšlenka není nová a je popsána v první knize testera "Testování dot com". (autor Roman Savin) My pouze integrujeme do TestRail metodiky navržené Romanem Savinem. Za tímto účelem vytvoříme pole s odkazem na vytvořený soubor:
vyplníme výchozí hodnotu odkazu, aby v každém novém testovacím případě byl už odkaz:
Pokud se umístění externího souboru změní (předpokládáme jakýkoli faktor), je možné pohodlně upravit hned několik polí ve všech testovacích případech:
Pole "Popis" (popis nebo myšlenka testovacího případu, standardní pokyny)
K čemu to může být užitečné: Do tohoto textového pole umístíme stručný popis testovacího případu a standardní pokyny.
Příklad: Všechna testovací data (aktuální makety, používání nástrojů a další data) z tohoto testovacího případu jsou označena odkazy {…} a nacházejí se v souboru MovableData. Odkaz na MovableData je v příslušném poli nahoře.
Tag „Komponenta“ (komponent mobilní aplikace)
Proč by mohl být použit: pro impaktní testování. Pokud je mobilní aplikace rozdělena na komponenty (které na sebe co nejméně vzájemně působí), pak je změnu v jednom komponentu možné (s určitými riziky) ověřit v rámci tohoto komponentu a tím se sníží důvody pro provádění obecných regresí všeho a všech. Pokud existují informace, že jeden komponent může ovlivnit jiný, sestaví se matice impaktního testování.
Příklad komponent: GooglePay, Objednávka, Uživatelé, Mapa, Autorizace atd.
Tag „TAG“ (Další tagy pro filtrování)
Tagování testovacího případu štítky pro libovolné filtrování.
Velmi užitečné pro:
rychlé sestavení TestRun pro různé typické úkoly: smoke, regres a atd.
zda budou testy automatizovány nebo již jsou automatizovány
jakékoliv další tagy
Příklad: Smoke, Automatizované, WhiteLabel, NaSmazání atd.
Nastavujeme pořadí zobrazení polí v testovacím případu
Vytvořili jsme mnoho nových polí, je čas je uspořádat do pohodlného pořadí:
Vytvoření TestRunu
Nyní vytvoříme nový test run s aktuálními případy pro provedení smoke testování ve třech kliknutích:
Další užitečné tipy
Pokud je v TestRail více projektů, nezapomeňte vytvářet nová pole pouze pro Váš projekt, jinak budou kolegové z vedlejších týmů velmi překvapeni, když uvidí nová neobvyklá pole. Mohou nastat místní omdlení.
2. Případy s velkým množstvím polí se snadněji kopírují z podobné skupiny než se vytvářejí nové:
3. Lze používat účty společně. Například: jeden administrátorský, několik uživatelských.
Závěr
Výše uvedené příklady byly implementovány v několika projektech a prokázaly svou účinnost. Doufám, že pomohou zlepšit Vaše porozumění této nástroji a pomohou vytvářet efektivní a pohodlné „testovací úložiště“. Budu velmi vděčný, pokud v komentářích popíšete svou zkušenost s používáním TestRail a užitečné tipy.
Odkazy:
Kniha:
Děkuji mnohokrát za pozornost!
Zdroj: habr.com
