Innledning
I mange prosjekter jeg jobbet med, tilpasset folk ikke TestRail for seg selv og nøyde seg med standardinnstillinger. Derfor vil jeg i denne artikkelen prøve å beskrive et eksempel på individuelle innstillinger som kan hjelpe deg med å forbedre effektiviteten i arbeidet ditt. La oss for eksempel ta et utviklingsprosjekt for mobilapplikasjoner.
En liten ansvarsfraskrivelse. Denne artikkelen inneholder ikke en beskrivelse av den grunnleggende funksjonaliteten til TestRail (det er mange guider om dette) og salgsuttrykk som fargerikt beskriver hvorfor du må velge akkurat denne leverandøren for å lage et depot med tester.
Begrunnelsesplan (hva skal implementeres)
-
Generelle krav
-
Absolutt hvem som helst burde kunne vedta saken.
-
Saker bør forbli aktuelle så lenge som mulig
-
Saker bør dekke funksjonaliteten til mobilapplikasjonen så grundig som mulig i den grad dette ikke motsier de to første punktene
-
-
Del opp i TestCase og TestScenario
-
Rask generering av TestRun av ulike typer
-
Røyk
-
Gå tilbake
-
Konsekvenstesting osv.
-
-
Optimalisering av saksstøtte
-
Forlate "døde" hardkodede skjermbilder og bytte til "bevegelige data"
-
Krav
For å redigere felt trenger du administratortilgang
Velge en prosjekttype
Det er tre prosjekttyper å velge mellom:
Vi velger standardtypen. Alle saker vil være tilgjengelige i den samtidig. Vi vil bruke smart filtrering og administrere alle saker dynamisk på en gang.
Legger til felt for å vise en liste over testtilfeller
La oss legge til et felt for å vise prioriterte testtilfeller:
Du kan også legge til andre felt.
Sette opp testcasefelt og -tagger
Åpne innstillingsmenyen:
Vi trenger følgende felt:
«Sammendrag»-felt (overskrift for testtilfeller)
Dette feltet eksisterer allerede, vi systematiserer bare bruken. Vi vil dele saker inn i TestCase og TestScenario. For bedre lesbarhet av en stor saksliste er det bedre å avtale på forhånd reglene for å skrive et sammendrag.
Testscenario:
Eksempel: TestScenario - Grunnleggende scenario for bruk av en mobilapplikasjon
Testforsøk:
Eksempel: Hovedskjerm - Autorisasjonsseksjon - Skriv inn pålogging
Totalt ser vi i sammendraget av saken den klassiske forståelsen: "hva, hvor, når." Vi skiller også visuelt testskript på høyt nivå og testcaser på lavt nivå i den formen som er best egnet for automatisering.
"StartScreen"-tag (skjermen som TestScenario starter fra; mange testtilfeller kan også berøre tilstøtende skjermer)
For hva det kan trenges: Vi vil fjerne teksten til sakstypiske trinn fra teksten som fører brukeren til skjermen til den gjeldende testsaken. (typiske trinn for å lage en spesifikk testsituasjon) Alle typiske trinn for alle testcases vil bli skrevet i én fil. Jeg vil skrive om det mer detaljert separat.
Opprett et nytt felt:
Fyll ut komponentene i det nye feltet:
I dette tilfellet oppretter vi et utvalgt felt fra en liste over verdier. Skriv inn verdiene i dette feltet:
Vær oppmerksom på at id-verdiene ikke starter med én og ikke er fortløpende. Hvorfor gjøres dette? Poenget er at hvis vi har testtilfeller med den angitte ID-en registrert,
og etter det må vi lage en tredje skjerm mellom de to eksisterende,
da må vi skrive om ID-en, og siden taggene til eksisterende tekstsaker allerede er knyttet til den, vil de ganske enkelt bli slettet. Det vil være veldig ubehagelig.
Tagg «Skjerm» (navnet på skjermen som påvirker TestCase)
Det du kanskje trenger: et av ankrene for støttesting. For eksempel laget utviklerne en ny kul funksjon. Vi må teste det, men for dette må vi forstå nøyaktig hva denne funksjonen kan påvirke. Som standard kan vi ta utgangspunkt i paradigmet om at forskjellige skjermer (Aktiviteter) i en applikasjon har forskjellige klasser og derfor utgjør forskjellige komponenter i applikasjonen. Selvfølgelig er det nødvendig med en individuell tilnærming i dette tilfellet.
Eksempel: home_screen, MapScreen, PayScreen, etc.
"MovableData"-feltet (lenke til en proxy-database med utskiftbare testdata)
Deretter vil vi prøve å løse problemet med å opprettholde relevansen av data i testsaker:
-
Lenker til gjeldende oppsett (dette er mye bedre enn å ta døde skjermbilder)
-
Typiske trinn for å komme til skjermen med en testsituasjon
-
SQL-spørringer
-
Lenker til eksterne data og andre data
I stedet for å skrive testdata inne i hver testcase, vil vi lage én ekstern fil, og lenke til den på alle testcases. Ved oppdatering av disse dataene vil vi ikke måtte gå gjennom alle testtilfellene og endre dem, men det vil være mulig å endre disse dataene kun ett sted. Hvis noen uforberedt åpner en testsak, vil han se i selve testsaken en lenke til en fil og et hint om at han må gå til den for testdata.
Vi vil pakke alle disse dataene i én ekstern fil, som vil være tilgjengelig for alle på prosjektet. Du kan for eksempel bruke Google Sheet eller Excel og sette opp et søk i filen. Hvorfor akkurat disse leverandørene? Faktum er at vi tar utgangspunkt i paradigmet om at enhver person i teamet skal kunne åpne og bestå en testcase uten først å måtte installere noen verktøy.
For Google-ark du kan bruke SQL-spørringer. Eksempel:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")For Excel Du kan sette opp praktiske makroer for øyeblikkelig søk. (filtrering) Eksempel .
Ideen er faktisk ikke ny og er beskrevet i den første testerens bok "Testing dot com". (forfatter Savin Roman) Vi integrerer nettopp metodene foreslått av Roman Savin i TestRail. For å gjøre dette, lag et felt med en lenke til den opprettede filen:
fyll inn standardverdien for koblingen slik at hver ny testsak allerede har en lenke:
Hvis plasseringen av den eksterne filen endres (vi sørger for eventuell force majeure), kan du enkelt endre ett eller flere felt samtidig i alle testtilfeller:
Felt "Beskrivelser" (beskrivelse eller idé om en testsak, standardinstruksjoner)
Hva du kan trenge: I dette tekstfeltet vil vi plassere en kort beskrivelse av testtilfellet og standardinstruksjoner.
Eksempel: Alle testdata (gjeldende oppsett, bruk av verktøy og andre data) fra denne testsaken er angitt med lenker {...} og ligger i MovableData-filen. Link til MovableData i det tilsvarende feltet øverst.
Tag «Komponent» (mobilapplikasjonskomponent)
Hva det kan være nødvendig for: for slagtesting. Hvis en mobilapplikasjon kan deles inn i komponenter (som påvirker hverandre minst mulig), vil endringer i én komponent være nok (med noen risiko) til å kontrolleres innenfor samme komponent, og det vil være mindre grunn til å utføre generelle regresjoner av alt. Hvis det er informasjon om at en komponent kan påvirke en annen, blir det kompilert en effekttestmatrise.
Eksempelkomponenter: GooglePay, Ordre, Brukere, Kart, Autorisasjon osv.
Tag "TAG" (andre tagger for filtrering)
Merking av en testsak med tagger for vilkårlig filtrering.
Veldig nyttig for:
-
rask kompilering av TestRun for forskjellige typiske oppgaver: røyk, regresjon, etc.
-
vil testene være automatiserte eller allerede automatiserte?
-
eventuelle andre tagger
Eksempel: Smoke, Automated, WhiteLabel, ForDelete, etc.
Sette opp visningsrekkefølgen til feltene i testsaken
Vi har laget mange nye felt, det er på tide å ordne dem i en praktisk rekkefølge:
Oppretter TestRun
Nå skal vi lage en ny testkjøring med aktuelle tilfeller for å utføre røyktesting med tre klikk:
Andre nyttige tips
-
Hvis TestRail har flere prosjekter, så ikke glem å lage nye felt kun for prosjektet ditt, ellers vil kolleger fra nabolag bli veldig overrasket over utseendet til nye uvanlige felt. Lokal besvimelse er mulig.
2. Saker med et stort antall felt er lettere å kopiere fra en lignende gruppetype enn å opprette nye:
3. Kontoer kan deles. For eksempel: én administrator, flere brukere.
Konklusjon
Eksemplene beskrevet ovenfor har blitt implementert på flere prosjekter og har vist deres effektivitet. Jeg håper de vil bidra til å forbedre forståelsen din av dette verktøyet og hjelpe deg med å lage effektive og praktiske "testlagringer". Jeg vil være veldig takknemlig hvis du beskriver din erfaring med å bruke TestRail og nyttige tips i kommentarfeltet.
referanser:
Bok:
Tusen takk for oppmerksomheten!
Kilde: www.habr.com