Inleiding
In baie projekte waarmee ek gewerk het, het mense nie TestRail vir hulself aangepas nie en met standaardinstellings bestuur. Daarom sal ek in hierdie artikel probeer om 'n voorbeeld van individuele instellings te beskryf wat jou kan help om die doeltreffendheid van jou werk te verhoog. Kom ons neem byvoorbeeld 'n mobiele toepassingsontwikkelingsprojek.
Klein vrywaring. Hierdie artikel beskryf nie die basiese funksionaliteit van TestRail nie (daar is baie gidse hiervoor) en die verkoop van uitdrukkings wat kleurvol beskryf waarom jy hierdie spesifieke verskaffer moet kies om 'n bewaarplek met toetse te skep.
Plan-regverdiging (wat sal geïmplementeer word)
-
Algemene vereistes
-
Die saak behoort absoluut enigiemand verby te kan gaan
-
Gevalle moet so lank as moontlik relevant bly
-
Gevalle moet die funksionaliteit van die mobiele toepassing so noukeurig moontlik dek in die mate dat dit nie die eerste twee punte weerspreek nie.
-
-
Skeiding in TestCase en TestScenario
-
Vinnige vorming van TestRun van verskillende tipes
-
Rook
-
Regressie
-
Impaktoetsing, ens.
-
-
Case ondersteuning optimalisering
-
Verwerping van "dooie" hardgekodeerde skermkiekies en oorgang na "roerende data"
-
Vereistes
Jy sal administrateurtoegang nodig hê om velde te wysig
Kies 'n projektipe
Daar is drie tipes projek om van te kies:
Ons sal die verstek tipe kies. Alle gevalle sal terselfdertyd daarin beskikbaar wees. Ons sal slim filter gebruik en alle gevalle op een slag dinamies bestuur.
Voeg velde by om die lys van toetsgevalle te sien
Kom ons voeg 'n veld by om prioriteitstoetsgevalle te vertoon:
Jy kan ook ander velde byvoeg.
Stel velde en etikette van 'n toetsgeval
Maak die instellingskieslys oop:
Ons benodig hierdie velde:
"Opsomming"-veld (toetsgevalopskrif)
Hierdie veld bestaan reeds, ons sistematiseer net die gebruik daarvan. Ons sal gevalle verdeel in TestCase en TestScenario. Vir beter leesbaarheid van 'n groot lys sake, is dit beter om vooraf ooreen te kom oor die reëls vir die skryf van 'n opsomming.
Toets scenario:
Voorbeeld: TestScenario - Mobiele toepassing se hoofgebruiksgeval
toetsgeval:
Voorbeeld: Hoofskerm - Magtigingsafdeling - Aanmelding-inskrywing
In totaal sien ons in die samevatting van die saak 'n klassieke begrip: "wat, waar, wanneer". Ons skei ook hoëvlaktoetsskrifte en laevlaktoetsgevalle visueel in die mees geskikte vorm vir outomatisering.
Merk "StartScreen" (die skerm waarvandaan die TestScenario begin, ook baie toetsgevalle kan aangrensende skerms raak)
Vir wat dit nodig mag wees: ons sal die tipiese stappe uit die teks van die gevalle verwyder wat die gebruiker na die skerm van die huidige toetssaak lei. (Tipiese stappe vir die skep van 'n spesifieke toetssituasie) Alle tipiese stappe vir alle toetsgevalle sal in een lêer geskryf word. Ek sal afsonderlik in meer besonderhede daaroor skryf.
Skep 'n nuwe veld:
Vul die komponente van die nuwe veld in:
In hierdie geval skep ons 'n kiesveld uit 'n lys waardes. Voer die waardes vir hierdie veld in:
Let daarop dat die id-waardes nie by een begin nie en nie opeenvolgend is nie. Hoekom word dit gedoen? Die feit is dat as ons toetsgevalle met die ingevoerde ID aangeteken het,
en daarna moet ons 'n derde skerm tussen die twee bestaandes skep,
dan sal ons die id moet herskryf, en aangesien die etikette van die bestaande teksgevalle reeds daaraan geheg is, word dit eenvoudig uitgevee. Dit sal baie onaangenaam wees.
Merk "Skerm" (die naam van die skerm wat die TestCase beïnvloed)
Wat jy dalk nodig het: een van die ankers vir impaktoetsing. Die ontwikkelaars het byvoorbeeld 'n oulike nuwe funksie gemaak. Ons moet dit toets, maar hiervoor moet ons verstaan wat presies hierdie kenmerk kan beïnvloed. By verstek kan ons begin van die paradigma dat verskillende skerms (Aktiwiteite) van die toepassing verskillende klasse het en dus verskillende komponente van die toepassing uitmaak. Natuurlik, in hierdie geval is 'n individuele benadering nodig.
Voorbeeld: home_screen, MapScreen, PayScreen, ens.
MovableData-veld (skakel na instaanbedienerdatabasis met veranderlike toetsdata)
Vervolgens sal ons probeer om die probleem op te los om die relevansie van data in toetsgevalle te handhaaf:
-
Skakels na werklike uitlegte (dit is baie beter as om dooie skermkiekies te neem)
-
Tipiese stappe na die toetsgevalskerm
-
SQL-navrae
-
Skakels na eksterne data en ander data
In plaas daarvan om toetsdata binne elke toetsgeval te skryf, sal ons een eksterne lêer skep, en op alle toetsgevalle sal ons 'n skakel daarna maak. Wanneer hierdie data opgedateer word, hoef ons nie deur al die toetsgevalle te gaan en dit te verander nie, maar dit sal moontlik wees om hierdie data op slegs een plek te verander. As iemand onvoorbereid 'n toetssaak oopmaak, sal hy in die liggaam van die toetssaak 'n skakel na 'n lêer sien en 'n wenk dat jy daarheen moet gaan vir toetsdata.
Ons sal al hierdie data in een eksterne lêer pak, wat vir almal op die projek beskikbaar sal wees. Byvoorbeeld, jy kan Google Sheet of Excel gebruik en 'n soektog in die lêer opstel. Hoekom hierdie spesifieke verkopers? Die feit is dat ons uitgaan van die paradigma dat enige persoon in die span die toetssaak moet kan oopmaak en slaag sonder dat dit eers nodig is om enige gereedskap te installeer.
Vir Google-blad SQL-navrae kan gebruik word. Voorbeeld:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Vir Excel Jy kan gerieflike kitsoekmakro's opstel. (filtrering) Voorbeeld .
Eintlik is die idee nie nuut nie en word beskryf in die eerste boek van die toetser "Testing dot com". (outeur Savin Roman) Ons integreer net die metodes wat deur Roman Savin voorgestel is in TestRail. Om dit te doen, skep 'n veld met 'n skakel na die geskepde lêer:
vul die verstekwaarde van die skakel in sodat daar in elke nuwe toetsgeval reeds 'n skakel is:
As die ligging van die eksterne lêer verander (ons maak voorsiening vir enige force majeure), dan kan u gerieflik een of meer velde in alle toetsgevalle gelyktydig verander:
Veld "Beskrywings" (beskrywing of idee van die toetsgeval, tipiese instruksies)
Wat jy dalk nodig het: In hierdie teksveld sal ons 'n kort beskrywing van die toetsgeval en tipiese instruksies plaas.
Voorbeeld: Alle toetsdata (werklike uitlegte, gebruik van gereedskap en ander data) van hierdie toetsgeval is gemerk met {...}-skakels en is in die MovableData geleë. Skakel na MovableData in die ooreenstemmende veld aan die bokant.
"Komponent"-merker (mobiele toepassingskomponent)
Wat jy dalk nodig het: vir impaktoetsing. As 'n mobiele toepassing in komponente verdeel kan word (wat mekaar so min as moontlik beïnvloed), sal veranderinge in een komponent genoeg wees (met sekere risiko's) om binne dieselfde komponent na te gaan, en daar sal minder rede wees om algemene regressies uit te voer van alles en alles. As daar inligting is dat een komponent 'n ander kan beïnvloed, word 'n impaktoetsmatriks saamgestel.
Voorbeeldkomponente: GooglePay, Bestelling, Gebruikers, Kaart, Magtiging, ens.
Merker "TAG" (Ander merkers vir filtering)
Merk 'n toetsgeval met etikette vir arbitrêre filtering.
Baie nuttig vir:
-
vinnige samestelling van TestRun vir verskeie tipiese take: rook, regressie, ens.
-
of die toetse outomaties of reeds geoutomatiseer sal wees
-
enige ander merkers
Voorbeeld: Rook, Outomatiese, WhiteLabel, ForDelete, ens.
Stel die vertoonvolgorde van velde in die toetsgeval
Ons het baie nuwe velde geskep, dit is tyd om dit in 'n gerieflike volgorde te rangskik:
Skep TestRun
Nou sal ons 'n nuwe toetslopie skep met relevante gevalle vir rooktoetsing in drie klikke:
Ander nuttige wenke
-
As daar verskeie projekte in TestRail is, moenie vergeet om nuwe velde net vir jou projek te skep nie, anders sal kollegas van naburige spanne baie verbaas wees oor die voorkoms van nuwe ongewone velde. Plaaslike floute is moontlik.
2. Gevalle met 'n groot aantal velde is makliker om van 'n soortgelyke tipe groep te kopieer as om nuwes te skep:
3. Rekeninge kan gedeel word. Byvoorbeeld: een administrateur, verskeie gebruikers.
Gevolgtrekking
Bogenoemde voorbeelde is op verskeie projekte geïmplementeer en het hul doeltreffendheid getoon. Ek hoop hulle sal help om jou begrip van hierdie hulpmiddel te verbeter en jou te help om doeltreffende en gerieflike "deegberging" te skep. Ek sal baie dankbaar wees as jy jou ervaring met die gebruik van TestRail en nuttige wenke in die kommentaar beskryf.
verwysings:
Boek:
Baie dankie vir u aandag!
Bron: will.com