Introductie
In veel projecten waarmee ik heb gewerkt, hebben mensen TestRail niet voor zichzelf aangepast en genoegen genomen met standaardinstellingen. Daarom zal ik in dit artikel proberen een voorbeeld te beschrijven van individuele instellingen die u kunnen helpen de efficiëntie van uw werk te verbeteren. Laten we bijvoorbeeld een ontwikkelingsproject voor mobiele applicaties nemen.
Een kleine disclaimer. Dit artikel bevat geen beschrijving van de basisfunctionaliteit van TestRail (er zijn veel handleidingen hierover) en verkoopuitingen die op kleurrijke wijze beschrijven waarom u deze specifieke leverancier moet kiezen om een repository met tests te maken.
Verantwoordingsplan (wat wordt er geïmplementeerd)
-
Algemene vereisten
-
Absoluut iedereen zou de zaak moeten kunnen passeren.
-
Cases moeten zo lang mogelijk relevant blijven
-
Cases moeten de functionaliteit van de mobiele applicatie zo grondig mogelijk bestrijken, voor zover dit niet in tegenspraak is met de eerste twee punten
-
-
Opgesplitst in TestCase en TestScenario
-
Snelle generatie van TestRun van verschillende typen
-
Rook
-
Regressie
-
Impacttests, enz.
-
-
Optimalisatie van case-ondersteuning
-
Het verlaten van “dode” hardgecodeerde schermafbeeldingen en het overschakelen naar “verplaatsbare gegevens”
-
Voorwaarden
Om velden te bewerken heeft u beheerderstoegang nodig
Een projecttype selecteren
Er zijn drie projecttypen waaruit u kunt kiezen:
We selecteren het standaardtype. Alle cases zullen er tegelijkertijd in beschikbaar zijn. We zullen slimme filtering gebruiken en alle cases in één keer dynamisch beheren.
Velden toevoegen om een lijst met testgevallen te bekijken
Laten we een veld toevoegen om prioritaire testgevallen weer te geven:
U kunt ook andere velden toevoegen.
Testcasevelden en tags instellen
Open het instellingenmenu:
We hebben de volgende velden nodig:
Veld “Samenvatting” (koptekst testcase)
Dit veld bestaat al, we systematiseren alleen het gebruik ervan. We verdelen cases in TestCase en TestScenario. Voor een betere leesbaarheid van een grote lijst met cases is het beter om vooraf afspraken te maken over de regels voor het schrijven van een samenvatting.
Testscenario:
Voorbeeld: TestScenario - Basisscenario voor het gebruik van een mobiele applicatie
Testcase:
Voorbeeld: Hoofdscherm - Autorisatiesectie - Voer login in
In totaal zien we in de samenvatting van de zaak het klassieke begrip: “wat, waar, wanneer.” Ook scheiden we high-level testscripts en low-level testcases visueel van elkaar in de vorm die het meest geschikt is voor automatisering.
“StartScreen”-tag (het scherm van waaruit TestScenario begint; ook kunnen veel testgevallen aangrenzende schermen raken)
Voor wat het nodig kan zijn: we zullen uit de tekst de tekst van de typische stappen verwijderen die de gebruiker naar het scherm van de huidige testcase leiden. (typische stappen voor het creëren van een specifieke testsituatie) Alle typische stappen voor alle testgevallen worden in één bestand geschreven. Ik zal er afzonderlijk meer over schrijven.
Maak een nieuw veld:
Vul de componenten van het nieuwe veld in:
In dit geval maken we een selectieveld uit een lijst met waarden. Voer de waarden van dit veld in:
Houd er rekening mee dat de id-waarden niet met één beginnen en niet opeenvolgend zijn. Waarom wordt dit gedaan? Het punt is dat als we testgevallen hebben waarbij de ingevoerde ID is vastgelegd,
en daarna zullen we een derde scherm moeten maken tussen de twee bestaande,
dan zullen we de id moeten herschrijven, en aangezien de tags van bestaande tekstgevallen er al aan zijn gekoppeld, zullen ze eenvoudigweg worden verwijderd. Het zal heel onaangenaam zijn.
Tag “Scherm” (naam van het scherm dat van invloed is op TestCase)
Wat je misschien nodig hebt: een van de ankers voor impacttests. De ontwikkelaars hebben bijvoorbeeld een nieuwe coole functie gemaakt. We moeten het testen, maar hiervoor moeten we begrijpen wat deze functie precies kan beïnvloeden. Standaard kunnen we uitgaan van het paradigma dat verschillende schermen (Activiteiten) van een applicatie verschillende klassen hebben en daarom verschillende componenten van de applicatie vormen. Uiteraard is in dit geval een individuele aanpak nodig.
Voorbeeld: home_screen, MapScreen, PayScreen, etc.
Veld “MovableData” (link naar een proxydatabase met veranderlijke testgegevens)
Vervolgens zullen we proberen het probleem van het behouden van de relevantie van gegevens in testgevallen op te lossen:
-
Links naar huidige lay-outs (dit is veel beter dan dode screenshots maken)
-
Typische stappen om bij een testsituatie op het scherm te komen
-
SQL-query's
-
Koppelingen naar externe gegevens en andere gegevens
In plaats van testgegevens in elke testcase te schrijven, zullen we één extern bestand maken en hiernaar linken in alle testcases. Bij het updaten van deze gegevens hoeven we niet alle testgevallen te doorlopen en te wijzigen, maar is het wel mogelijk om deze gegevens op slechts één plek te wijzigen. Als iemand onvoorbereid een testcase opent, ziet hij in de hoofdtekst van de testcase een link naar een bestand en een hint dat hij daarheen moet gaan voor testgegevens.
We bundelen al deze gegevens in één extern bestand, dat voor iedereen in het project beschikbaar zal zijn. U kunt bijvoorbeeld Google Spreadsheet of Excel gebruiken en een zoekopdracht binnen het bestand instellen. Waarom deze specifieke leveranciers? Feit is dat we uitgaan van het paradigma dat iedere persoon in het team een testcase moet kunnen openen en doorstaan zonder eerst tools te hoeven installeren.
Voor Google-spreadsheet U kunt SQL-query's gebruiken. Voorbeeld:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Voor Excel U kunt handige macro's voor direct zoeken instellen. (filteren) Voorbeeld .
Eigenlijk is het idee niet nieuw en wordt beschreven in het boek van de eerste tester “Testing dot com”. (auteur Savin Roman) We integreren zojuist de door Roman Savin voorgestelde methoden in TestRail. Maak hiervoor een veld aan met een link naar het aangemaakte bestand:
vul de standaardwaarde van de link in zodat elke nieuwe testcase al een link heeft:
Mocht de locatie van het externe bestand wijzigen (wij houden rekening met eventuele overmacht), dan kunt u in alle testgevallen gemakkelijk één of meerdere velden tegelijk wijzigen:
Veld “Beschrijvingen” (beschrijving of idee van een testcase, standaardinstructies)
Wat u mogelijk nodig heeft: In dit tekstveld plaatsen wij een korte beschrijving van de testcase en standaardinstructies.
Voorbeeld: Alle testgegevens (huidige lay-outs, gebruik van tools en andere gegevens) uit deze testcase worden aangegeven met links {...} en bevinden zich in het MovableData-bestand. Link naar MovableData in het overeenkomstige veld bovenaan.
Tag “Component” (mobiele applicatiecomponent)
Waarvoor kan het nodig zijn: voor impacttests. Als een mobiele applicatie kan worden opgedeeld in componenten (die elkaar zo min mogelijk beïnvloeden), dan zullen wijzigingen in één component voldoende zijn (met enige risico’s) om binnen dezelfde component te worden gecontroleerd, en zal er minder aanleiding zijn om acties uit te voeren. algemene regressies van alles. Als er informatie is dat het ene onderdeel het andere kan beïnvloeden, wordt een impacttestmatrix opgesteld.
Voorbeeldcomponenten: GooglePay, Bestelling, Gebruikers, Kaart, Autorisatie, etc.
Tag "TAG" (andere tags om te filteren)
Een testcase taggen met tags voor willekeurige filtering.
Zeer nuttig voor:
-
snel TestRun samenstellen voor verschillende typische taken: roken, regressie, enz.
-
Zullen de tests geautomatiseerd zijn of al geautomatiseerd?
-
eventuele andere labels
Voorbeeld: Rook, Geautomatiseerd, WhiteLabel, ForDelete, etc.
De weergavevolgorde van velden in de testcase instellen
We hebben veel nieuwe velden gemaakt, het is tijd om ze in een handige volgorde te ordenen:
TestRun maken
Nu gaan we in drie klikken een nieuwe testrun maken met actuele cases voor het uitvoeren van rooktesten:
Andere handige tips
-
Als TestRail meerdere projecten heeft, vergeet dan niet om alleen voor uw project nieuwe velden aan te maken, anders zullen collega's van naburige teams zeer verrast zijn door het verschijnen van nieuwe ongebruikelijke velden. Lokaal flauwvallen is mogelijk.
2. Cases met een groot aantal velden zijn gemakkelijker te kopiëren uit een vergelijkbaar groepstype dan nieuwe aan te maken:
3. Accounts kunnen worden gedeeld. Bijvoorbeeld: één beheerder, meerdere gebruikers.
Conclusie
De hierboven beschreven voorbeelden zijn op verschillende projecten geïmplementeerd en hebben hun effectiviteit bewezen. Ik hoop dat ze u zullen helpen uw begrip van deze tool te verbeteren en u te helpen effectieve en handige ‘testopslagplaatsen’ te creëren. Ik zou het zeer op prijs stellen als u in de opmerkingen uw ervaringen met het gebruik van TestRail en nuttige tips beschrijft.
referenties:
Boek:
Bedankt voor jullie aandacht!
Bron: www.habr.com