TestRail – A projekt egyéni beállításai

Bevezetés

Számos projektben, amelyekkel dolgoztam, az emberek nem szabták testre a TestRailt, hanem beértek a szabványos beállításokkal. Ezért ebben a cikkben megpróbálok egy példát leírni olyan egyedi beállításokra, amelyek segíthetnek munkája hatékonyságának javításában. Vegyünk például egy mobilalkalmazás-fejlesztési projektet.

Egy kis felelősségkizárás. Ez a cikk nem tartalmazza a TestRail alapvető funkcióinak leírását (sok útmutató van erről), és olyan értékesítési kifejezéseket, amelyek színesen leírják, miért kell ezt a szállítót választania egy teszttár létrehozásához.

Indoklási terv (mi kerül végrehajtásra)

1. Általános követelmények

   1. Teljesen bárkinek képesnek kell lennie arra, hogy átadja az ügyet.

   2. Az eseteknek a lehető leghosszabb ideig relevánsnak kell maradniuk

   3. Az eseteknek a lehető legpontosabban ki kell fedniük a mobilalkalmazás funkcionalitását, amennyiben ez nem mond ellent az első két pontnak.

2. Osztva TestCase és TestScenario

3. Különböző típusú TestRun gyors generálása

   1. Füst

   2. Visszafejlődés

   3. Ütésvizsgálat stb.

4. Ügyek támogatásának optimalizálása

   1. A „halott” keménykódolt képernyőképek elhagyása és a „mozgatható adatokra” való váltás

követelmények

A mezők szerkesztéséhez rendszergazdai hozzáférésre van szükség

Projekttípus kiválasztása

Három projekttípus közül lehet választani:

Kiválasztjuk az alapértelmezett típust. Minden tok egyszerre lesz elérhető benne. Intelligens szűrést használunk, és dinamikusan kezeljük az összes esetet egyszerre.

Mezők hozzáadása a tesztesetek listájának megtekintéséhez

Adjunk hozzá egy mezőt a prioritási tesztesetek megjelenítéséhez:

Más mezőket is hozzáadhat.

Teszteset mezők és címkék beállítása

Nyissa meg a beállítások menüt:

A következő mezőkre lesz szükségünk:

„Összefoglaló” mező (teszteset fejléc)

Ez a terület már létezik, még csak rendszerezzük a használatát. Az eseteket TestCase-re és TestScenario-ra osztjuk. Az esetek nagy listájának jobb olvashatósága érdekében jobb, ha előre megállapodunk az összefoglaló írásának szabályairól.

Tesztforgatókönyv:

Példa: TestScenario – Alapvető forgatókönyv egy mobilalkalmazás használatához

Próbaper:

Példa: Főképernyő – Engedélyezés szakasz – Adja meg a bejelentkezést

Összességében az ügy összefoglalójában a klasszikus felfogást látjuk: „mit, hol, mikor”. Vizuálisan is elkülönítjük a magas szintű tesztszkripteket és az alacsony szintű teszteseteket, az automatizáláshoz leginkább megfelelő formában.

„StartScreen” címke (az a képernyő, amelyről a TestScenario elindul; emellett sok teszteset érintheti a szomszédos képernyőket)

Amire szükség lehet: eltávolítjuk a szövegből az esetek tipikus lépéseit, amelyek az aktuális teszteset képernyőjére vezetik a felhasználót. (tipikus lépések egy adott teszthelyzet létrehozásához) Az összes tesztesetre jellemző összes lépés egy fájlba lesz írva. Erről külön írok bővebben.

Hozzon létre egy új mezőt:

Töltse ki az új mező összetevőit:

Ebben az esetben egy kiválasztási mezőt hozunk létre az értékek listájából. Adja meg ennek a mezőnek az értékeit:

Kérjük, vegye figyelembe, hogy az azonosító értékek nem eggyel kezdődnek, és nem egymást követik. Miért történik ez? A lényeg az, hogy ha vannak teszteseteink a megadott azonosítóval rögzítve,

és ezután létre kell hoznunk egy harmadik képernyőt a két meglévő között,

akkor át kell írnunk az azonosítót, és mivel a meglévő szöveges esetek címkéi már hozzá vannak csatolva, egyszerűen törlődnek. Nagyon kellemetlen lesz.

Címke „Képernyő” (a képernyő neve, amely befolyásolja a TestCase-t)

Amire szüksége lehet: az egyik horgony az ütési teszteléshez. Például a fejlesztők egy új, nagyszerű funkciót készítettek. Tesztelnünk kell, de ehhez meg kell értenünk, hogy pontosan mit is befolyásolhat ez a funkció. Alapértelmezés szerint abból a paradigmából indulhatunk ki, hogy egy alkalmazás különböző képernyőinek (Activities) különböző osztályai vannak, és ezért az alkalmazás különböző összetevőit alkotják. Természetesen ebben az esetben egyéni megközelítésre van szükség.

Példa: kezdőképernyő, MapScreen, PayScreen stb.

„MovableData” mező (hivatkozás egy proxy adatbázishoz, megváltoztatható tesztadatokkal)

Ezután megpróbáljuk megoldani az adatok relevanciájának megőrzésének problémáját tesztesetekben:

1. Hivatkozások az aktuális elrendezésekhez (ez sokkal jobb, mint halott képernyőképek készítése)

2. Tipikus lépések a képernyőhöz jutáshoz egy teszthelyzettel

3. SQL lekérdezések

4. Külső adatokra és egyéb adatokra mutató hivatkozások

Ahelyett, hogy minden tesztesetbe tesztadatokat írnánk, egy külső fájlt hozunk létre, és minden tesztesetben hivatkozunk rá. Ezen adatok frissítése során nem kell az összes tesztesetet végigjárnunk és módosítanunk, hanem csak egy helyen lehet ezeket az adatokat módosítani. Ha valaki felkészületlenül nyit meg egy tesztesetet, akkor a teszteset törzsében egy fájlra mutató hivatkozást és egy utalást fog látni, hogy a tesztadatokért oda kell mennie.

Mindezeket az adatokat egyetlen külső fájlba csomagoljuk, amely mindenki számára elérhető lesz a projektben. Például használhatja a Google Táblázatot vagy az Excelt, és beállíthat egy keresést a fájlban. Miért pont ezek az eladók? A tény az, hogy abból a paradigmából indulunk ki, hogy a csapat bármely tagja képes legyen megnyitni és átmenni egy teszteseten anélkül, hogy először bármilyen eszközt telepítenie kellene.

mert Google lap használhat SQL lekérdezéseket. Példa:

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

mert Excel Kényelmes azonnali keresési makrókat állíthat be. (szűrés) Példa по ссылке.

Valójában az ötlet nem új, és az első tesztelő „Testing dot com” című könyvében van leírva. (szerző Savin Roman) Éppen a Roman Savin által javasolt módszereket integráljuk a TestRailbe. Ehhez hozzon létre egy mezőt a létrehozott fájlra mutató hivatkozással:

töltse ki a hivatkozás alapértelmezett értékét, hogy minden új tesztesethez legyen már hivatkozás:

Ha a külső fájl helye megváltozik (vis maior esetén biztosítunk), akkor kényelmesen, minden tesztesetben egyszerre módosíthat egy vagy több mezőt:

„Leírások” mező (egy teszteset leírása vagy ötlete, szabványos utasítások)

Amire szüksége lehet: Ebben a szövegmezőben elhelyezzük a teszteset rövid leírását és a szabványos utasításokat.

Példa: A tesztesetből származó összes tesztadatot (aktuális elrendezések, eszközök használata és egyéb adatok) a {...} hivatkozások jelzik, és a MovableData fájlban találhatók. Hivatkozás a MovableData oldalra a megfelelő mezőben felül.

„Component” címke (mobilalkalmazás-komponens)

Mire lehet szükség: ütésvizsgálathoz. Ha egy mobilalkalmazást komponensekre lehet osztani (amelyek a lehető legkevésbé érintik egymást), akkor az egyik komponens módosításait elegendő (bizonyos kockázattal) ugyanazon a komponensen belül ellenőrizni, és kevesebb ok lesz a végrehajtásra. mindennek általános regressziója. Ha van információ arról, hogy az egyik komponens hatással lehet a másikra, akkor egy ütésteszt-mátrixot állítanak össze.

Példaösszetevők: GooglePay, Megrendelés, Felhasználók, Térkép, Engedélyezés stb.

"TAG" címke (egyéb címkék a szűréshez)

Teszteset címkézése címkékkel tetszőleges szűréshez. 

Nagyon hasznos: 

1. a TestRun gyors összeállítása különféle tipikus feladatokhoz: füst, regresszió stb.

2. automatizáltak lesznek vagy már automatizáltak a tesztek?

3. bármilyen más címkét

Példa: Smoke, Automated, WhiteLabel, ForDelete stb.

A mezők megjelenítési sorrendjének beállítása a tesztesetben

Sok új mezőt hoztunk létre, itt az ideje, hogy kényelmes sorrendbe rendezzük őket:

A TestRun létrehozása

Most egy új tesztüzemet készítünk az aktuális esetekkel a füstvizsgálat elvégzéséhez három kattintással:

Egyéb hasznos tippek

1. Ha a TestRailnek több projektje is van, akkor ne felejtsen el új mezőket létrehozni csak a projektje számára, különben a szomszédos csapatok kollégái nagyon meglepődnek az új, szokatlan mezők megjelenésén. Helyi ájulás lehetséges.

2. A sok mezőt tartalmazó eseteket könnyebb átmásolni egy hasonló csoporttípusból, mint újakat létrehozni:

3. A fiókok megoszthatók. Például: egy rendszergazda, több felhasználó.

Következtetés

A fent leírt példákat több projektben is végrehajtották, és bebizonyították hatékonyságukat. Remélem, hogy segítenek jobban megérteni ezt az eszközt, és segítenek hatékony és kényelmes „teszttárolók” létrehozásában. Nagyon hálás lennék, ha a megjegyzésekben leírná a TestRail használatával kapcsolatos tapasztalatait és hasznos tippeket.

referenciák:

A TestRail gyártó webhelye

Könyv: „Testing .COM” (szerző Roman Savin)

Köszönöm szépen a figyelmet!

Forrás: will.com