Inleiding
In veel projecten waaraan ik heb gewerkt, configureerden mensen TestRail niet naar hun eigen behoeften en werden de standaardinstellingen gebruikt. Daarom zal ik in dit artikel een voorbeeld van individuele instellingen beschrijven die u kunnen helpen uw werk efficiënter te maken. Laten we als voorbeeld een project voor de ontwikkeling van een mobiele applicatie nemen.
Een kleine disclaimer. In dit artikel wordt de basisfunctionaliteit van TestRail niet beschreven (daarvoor zijn veel gidsen beschikbaar) en zijn er geen opdringerige uitdrukkingen die beschrijven waarom u precies deze leverancier zou moeten kiezen voor het maken van een repository voor tests.
Plan-onderbouwing (wat zal worden uitgevoerd)
Algemene vereisten
De case moet door absoluut elke persoon kunnen worden doorlopen
Cases moeten zo lang mogelijk actueel blijven
Cases moeten de functionaliteit van de mobiele applicatie zo goed mogelijk dekken, voor zover dit niet in strijd is met de eerste twee punten
Scheiding in TestCase en TestScenario
Snelle generatie van TestRun van verschillende types
Smoke
Regress
Impacttesten, enz.
Optimalisatie van de ondersteuning van cases
Afzien van 'dode' hardcoded screenshots en overschakelen naar 'movable data'
Vereisten
Voor het bewerken van velden heeft u beheerdersrechten nodig
Kiezen van het type project
U kunt uit drie typen projecten kiezen:
We zullen het standaardtype kiezen. Hiermee zijn alle cases tegelijkertijd beschikbaar. We gaan slimme filtering gebruiken en dynamisch al onze cases tegelijk beheren.
Velden toevoegen voor het bekijken van de lijst met testcases
Laten we een veld toevoegen voor het weergeven van de prioriteit van testcases:
Ook kunnen andere velden worden toegevoegd.
Instelling van velden en tags voor testcases
We openen het instellingenmenu:
We hebben de volgende velden nodig:
Veld 'Summary' (kop van de testcase)
Dit veld bestaat al, we systematiseren alleen het gebruik ervan. We zullen cases scheiden in TestCase en TestScenario. Voor een betere leesbaarheid van een lange lijst met cases is het beter om vooraf afspraken te maken over de regels voor het schrijven van de summary.
TestScenario:
Voorbeeld: TestScenario — Hoofdgebruiksscenario van de mobiele applicatie
TestCase:
Voorbeeld: MainScreen — Autorisatie sectie — Invoeren van de gebruikersnaam
In de summary van de case zien we de klassieke betekenis: 'wat, waar, wanneer'. Daarnaast scheiden we visueel de high-level testscenario's van de low-level testcases op een manier die het meest geschikt is voor automatisering.
Het tag «StartScreen» (het scherm waarmee het TestScenario begint, ook veel testcases kunnen aangrenzende schermen raken)
Waarvoor dit nodig kan zijn: we zullen typische stappen uit de tekst van testcases verwijderen die de gebruiker naar het scherm van de huidige testcase leiden. (typische stappen voor het creëren van een bepaalde testsituatie) Alle typische stappen voor alle testcases worden in één bestand genoteerd. Hierover zal ik apart meer schrijven.
Een nieuw veld aanmaken:
De componenten van het nieuwe veld invullen:
In dit geval maken we een keuzelijst aan. We voeren de waarden voor dit veld in:
Let op dat de id-waarden niet bij één beginnen en niet opeenvolgend zijn. Waarom is dit zo? Het komt doordat als we testcases hebben waarin deze id is ingevoerd,
en we daarna een derde scherm tussen twee bestaande moeten creëren,
we de id's moeten herschrijven. Aangezien deze al zijn gekoppeld aan de tags van bestaande testcases, zouden ze simpelweg verdwijnen. Dit zou zeer onaangenaam zijn.
Het tag «Screen» (de naam van het scherm dat door de TestCase wordt aangeraakt)
Waarvoor dit nodig kan zijn: een van de ankers voor impacttesten. Bijvoorbeeld, ontwikkelaars hebben een nieuwe, coole functie gemaakt. We moeten deze testen, maar daarvoor moeten we begrijpen wat deze functie zou kunnen beïnvloeden. Standaard kunnen we uitgaan van de paradigm dat verschillende schermen (Activity) van de app verschillende klassen hebben en derhalve verschillende componenten van de app vormen. Uiteraard is in dit geval een individuele benadering nodig.
Voorbeeld: home_screen, MapScreen, PayScreen, enz.
Veld «MovableData» (link naar de proxy-database met wijzigbare testgegevens)
Daarna zullen we proberen het probleem van de actualiteit van gegevens in testcases op te lossen:
Links naar actuele mock-ups (dit is veel beter dan dode screenshots maken)
Typische stappen tot het scherm met de testsituatie
SQL-queries
Links naar externe gegevens en andere gegevens
In plaats van testgegevens binnen elke testcase te schrijven, zullen we één extern bestand creëren en in alle testcases naar dit bestand verwijzen. Bij het bijwerken van deze gegevens hoeven we niet alle testcases door te nemen en deze te wijzigen; we kunnen de gegevens eenvoudig op één plek aanpassen. Als iemand die niet voorbereid is een testcase opent, zal hij in de body van de testcase een link naar het bestand zien en de aanwijzing dat hij daar moet zijn voor testgegevens.
Al deze gegevens verpakken we in één extern bestand, dat voor iedereen die dat wil beschikbaar zal zijn binnen het project. We kunnen bijvoorbeeld Google Sheets of Excel gebruiken en binnen het bestand zoeken instellen. Waarom deze leveranciers? Omdat we uitgaan van de paradigm dat iedere teamlid een testcase moet kunnen openen en doorlopen zonder dat hij vooraf allerlei tools hoeft te installeren.
Voor Google Sheets we kunnen SQL-query's gebruiken. Voorbeeld:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Voor Excel we kunnen handige macro's voor directe zoekopdrachten (filtering) instellen. Voorbeeld .
Eigenlijk is het idee niet nieuw en is het beschreven in het eerste boek van een tester, “Testing dot com” (auteur Roman Savin). We integreren slechts de methoden die Roman Savin voorstelt in TestRail. Hiervoor creëren we een veld met een link naar het gemaakte bestand:
we vullen de standaardwaarde van de link in, zodat elke nieuwe testcase al een link bevat:
Als de locatie van het externe bestand verandert (we houden rekening met elke overmacht), kan het gemakkelijk zijn om in alle testcases tegelijk één of meerdere velden te wijzigen:
Het veld "Descriptions" (beschrijving of idee van de testcase, standaardinstructies)
Waarvoor kan het nodig zijn: In dit tekstveld plaatsen we een korte beschrijving van de testcase en standaardinstructies.
Voorbeeld: Alle testgegevens (huidige modellen, gebruik van hulpmiddelen, en andere gegevens) uit deze testcase zijn aangegeven met links {…} en bevinden zich in het bestand MovableData. De link naar MovableData staat in het bijbehorende veld bovenaan.
Tag "Component" (component van de mobiele applicatie)
Waarvoor het nodig kan zijn: voor impacttesting. Als een mobiele applicatie kan worden verdeeld in componenten (die zo min mogelijk invloed op elkaar uitoefenen), is het voldoende (met enkele risico's) om wijzigingen in één component binnen datzelfde component te testen, wat de noodzaak voor algehele regressietests vermindert. Als er informatie is dat één component een ander kan beïnvloeden, wordt er een impacttestmatrix opgesteld.
Voorbeeldcomponenten: GooglePay, Order, Users, Map, Autorisatie, enz.
Tag «TAG» (Overige tags voor filtering)
Tagging van testcases met labels voor willekeurige filtering.
Zeer nuttig voor:
snelle samenstelling van TestRun voor verschillende standaardtaken: smoke, regressie, enz.
of de tests geautomatiseerd worden of al geautomatiseerd zijn
enige andere tags
Voorbeeld: Smoke, Automated, WhiteLabel, ForDelete, enz.
We stellen de volgorde van velden in de testcase in
We hebben veel nieuwe velden gemaakt, het is tijd om ze in een handige volgorde te plaatsen:
Creëren van TestRun
Nu gaan we een nieuwe test run aanmaken met actuele testcases voor het uitvoeren van smoke testing in drie klikken:
Andere nuttige tips
Als er meerdere projecten in TestRail zijn, vergeet dan niet om nieuwe velden alleen voor uw project te creëren, anders zullen collega's uit aangrenzende teams erg verrast zijn door de komst van nieuwe ongebruikelijke velden. Lokale flauwvallen zijn mogelijk.
2. Testcases met veel velden zijn gemakkelijker te kopiëren uit een vergelijkbare groepstype dan nieuwe te maken:
3. U kunt accounts gezamenlijk gebruiken. Bijvoorbeeld: één beheerdersaccount, meerdere gebruikersaccounts.
Conclusie
De hierboven beschreven voorbeelden zijn in verschillende projecten geïmplementeerd en hebben hun effectiviteit aangetoond. Ik hoop dat ze u helpen uw begrip van deze tool te verbeteren en efficiënte en gebruiksvriendelijke 'testopslagplaatsen' te creëren. Ik zou zeer dankbaar zijn als u in de comments uw ervaringen met TestRail en nuttige tips beschrijft.
Links:
Boek:
Heel erg bedankt voor uw aandacht!
Bron: habr.com
