TestRail - Individuální nastavení pro projekt

úvod

V mnoha projektech, se kterými jsem pracoval, si lidé TestRail nepřizpůsobili a spravovali to se standardním nastavením. Proto se v tomto článku pokusím popsat příklad jednotlivých nastavení, které vám mohou pomoci zvýšit efektivitu vaší práce. Vezměme si například projekt vývoje mobilních aplikací.

Malé vyloučení odpovědnosti. Tento článek nepopisuje základní funkcionalitu TestRail (existuje na to mnoho návodů) a prodejní výrazy barvitě popisující, proč si k vytvoření úložiště s testy musíte vybrat právě tohoto dodavatele.

Zdůvodnění plánu (co bude realizováno)

1. Obecné požadavky

   1. Případ by měl mít možnost projít naprosto každým

   2. Případy by měly zůstat relevantní co nejdéle

   3. Pouzdra by měla co nejpečlivěji pokrývat funkcionalitu mobilní aplikace do té míry, aby to nebylo v rozporu s prvními dvěma body.

2. Rozdělení na TestCase a TestScenario

3. Rychlé vytvoření TestRun různých typů

   1. Kouř

   2. Ústup

   3. Nárazové zkoušky atd.

4. Optimalizace podpory případu

   1. Odmítnutí „mrtvých“ pevně zakódovaných snímků obrazovky a přechod na „pohyblivá data“

požadavky

K úpravám polí budete potřebovat administrátorský přístup

Výběr typu projektu

Na výběr jsou tři typy projektů:

Zvolíme výchozí typ. K dispozici v něm budou všechna pouzdra zároveň. Využijeme chytré filtrování a dynamicky spravujeme všechny případy najednou.

Přidání polí pro zobrazení seznamu testovacích případů

Pojďme přidat pole pro zobrazení prioritních testovacích případů:

Můžete také přidat další pole.

Nastavení polí a značek testovacího případu

Otevření nabídky nastavení:

Potřebujeme tato pole:

Pole „Souhrn“ (záhlaví testovacího případu)

Toto pole již existuje, pouze systematizujeme jeho využití. Případy rozdělíme na TestCase a TestScenario. Pro lepší čitelnost velkého seznamu případů je lepší si předem domluvit pravidla pro psaní shrnutí.

Testovací scénář:

Příklad: TestScenario – hlavní případ použití mobilní aplikace

modelový případ:

Příklad: MainScreen - Sekce Autorizace - Vstup pro přihlášení

Celkově vidíme ve shrnutí případu klasické chápání: „co, kde, kdy“. Vizuálně také oddělujeme testovací skripty na vysoké úrovni a testovací případy nízké úrovně ve formě nejvhodnější pro automatizaci.

Tag "StartScreen" (obrazovka, ze které se spouští TestScenario, mnoho testovacích případů se také může dotýkat sousedních obrazovek)

K tomu, co může být potřeba: z textu případů odstraníme typické kroky, které uživatele vedou na obrazovku aktuálního testovacího případu. (typické kroky pro vytvoření konkrétní testovací situace) Všechny typické kroky pro všechny testovací případy budou zapsány do jednoho souboru. Podrobněji o tom napíšu samostatně.

Vytvořte nové pole:

Vyplňte součásti nového pole:

V tomto případě vytváříme výběrové pole ze seznamu hodnot. Zadejte hodnoty pro toto pole:

Všimněte si, že hodnoty id nezačínají na jedné a nejsou po sobě jdoucí. Proč se to dělá? Faktem je, že pokud jsme zaznamenali testovací případy se zadaným ID,

a poté musíme vytvořit třetí obrazovku mezi dvěma stávajícími,

pak budeme muset id přepsat, a protože jsou k němu již připojeny značky stávajících textových případů, jednoduše se smažou. Bude to velmi nepříjemné.

Tag "Screen" (název obrazovky, která ovlivňuje TestCase)

Co možná budete potřebovat: jednu z kotev pro nárazové zkoušky. Vývojáři například vytvořili skvělou novou funkci. Musíme to otestovat, ale k tomu musíme pochopit, co přesně by tato funkce mohla ovlivnit. Ve výchozím nastavení můžeme vycházet z paradigmatu, že různé obrazovky (Aktivity) aplikace mají různé třídy, a proto tvoří různé součásti aplikace. Samozřejmě je v tomto případě nutný individuální přístup.

Příklad: home_screen, MapScreen, PayScreen atd.

Pole MovableData (odkaz na proxy databázi s měnitelnými testovacími daty)

Dále se pokusíme vyřešit problém zachování relevance dat v testovacích případech:

1. Odkazy na aktuální rozvržení (je to mnohem lepší než pořizování mrtvých snímků obrazovky)

2. Typické kroky k obrazovce testovacího případu

3. SQL dotazy

4. Odkazy na externí data a další data

Místo psaní testovacích dat uvnitř každého testovacího případu vytvoříme jeden externí soubor a na všech testovacích případech na něj vytvoříme odkaz. Při aktualizaci těchto dat nebudeme muset procházet všechny testovací případy a měnit je, ale bude možné tato data změnit pouze na jednom místě. Pokud někdo nepřipravený otevře testovací případ, uvidí v těle testovacího případu odkaz na soubor a nápovědu, že do něj musíte přejít pro testovací data.

Všechna tato data zabalíme do jednoho externího souboru, který bude dostupný všem na projektu. Můžete například použít Google Sheet nebo Excel a nastavit vyhledávání uvnitř souboru. Proč právě tito prodejci? Faktem je, že vycházíme z paradigmatu, že každá osoba v týmu by měla být schopna otevřít a projít testovacím případem, aniž by bylo nutné nejprve instalovat nějaké nástroje.

pro Listu Google Lze použít SQL dotazy. Příklad:

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

pro vynikat Můžete nastavit pohodlná makra okamžitého vyhledávání. (filtrování) Příklad по ссылке.

Ve skutečnosti tato myšlenka není nová a je popsána v první knize testeru „Testing dot com“. (autor Savin Roman) Do TestRail jsme právě integrovali metody navržené Romanem Savinem. Chcete-li to provést, vytvořte pole s odkazem na vytvořený soubor:

vyplňte výchozí hodnotu odkazu tak, aby v každém novém testovacím případě již odkaz existoval:

Pokud se změní umístění externího souboru (zajistíme případnou vyšší moc), můžete pohodlně změnit jedno nebo více polí ve všech testovacích případech najednou:

Pole „Descriptions“ (popis nebo myšlenka testovacího případu, typické pokyny)

Co můžete potřebovat: Do tohoto textového pole umístíme stručný popis testovacího případu a typické pokyny.

Příklad: Všechna testovací data (aktuální rozložení, použití nástrojů a další data) z tohoto testovacího případu jsou označena odkazy {...} a jsou umístěna v MovableData. Odkaz na MovableData v odpovídajícím poli nahoře.

Značka "Component" (komponenta mobilní aplikace)

Co můžete potřebovat: pro testování nárazu. Pokud lze mobilní aplikaci rozdělit na komponenty (které se navzájem ovlivňují co nejméně), pak změny v jedné komponentě budou stačit (s určitými riziky) ke kontrole v rámci stejné komponenty a bude méně důvodů pro provádění obecných regresí. všeho a všeho. Pokud existují informace, že jedna komponenta může ovlivnit druhou, je sestavena matice nárazového testování.

Příklady komponent: GooglePay, Objednávka, Uživatelé, Mapa, Autorizace atd.

Značka „TAG“ (Další značky pro filtrování)

Označení testovacího případu štítky pro libovolné filtrování. 

Velmi užitečné pro: 

1. rychlá kompilace TestRun pro různé typické úkoly: kouř, regrese atd.

2. zda budou testy automatizované nebo již automatizované

3. jakékoli další značky

Příklad: Smoke, Automated, WhiteLabel, ForDelete atd.

Nastavení pořadí zobrazení polí v testovacím případě

Vytvořili jsme spoustu nových polí, je čas je uspořádat do pohodlného pořadí:

Vytváření TestRun

Nyní vytvoříme nový testovací běh s relevantními případy pro testování kouře třemi kliknutími:

Další užitečné tipy

1. Pokud je v TestRailu několik projektů, pak nezapomeňte vytvořit nová pole pouze pro váš projekt, jinak budou kolegové ze sousedních týmů velmi překvapeni výskytem nových neobvyklých polí. Místní mdloby jsou možné.

2. Případy s velkým počtem polí je snazší zkopírovat ze skupiny podobného typu než vytvářet nové:

3. Účty lze sdílet. Například: jeden správce, několik uživatelů.

Závěr

Výše uvedené příklady byly implementovány na několika projektech a prokázaly svou účinnost. Doufám, že vám pomohou lépe porozumět tomuto nástroji a pomohou vám vytvořit efektivní a pohodlné „skladiště těsta“. Byl bych velmi vděčný, kdybyste v komentářích popsali své zkušenosti s používáním TestRail a užitečné tipy.

Odkazy:

Webové stránky prodejce TestRail

Rezervovat: "Testování .COM" (autor Roman Savin)

Velmi děkuji za Vaši pozornost!

Zdroj: www.habr.com