TestRail — Projekti kohandamisvõimalused

Sissejuhatus

Paljuski projektides, millega ma olen töötanud, ei seadnud inimesed TestRail'i enda jaoks kohandatud ja piirdusid vaikeseadistustega. Seetõttu püüan selles artiklis kirjeldada näidet isiklikest seadistustest, mis võivad aidata teil oma töös tõhusust tõsta. Näiteks võtame mobiilirakenduse arendusprojekti.

Väike märkused. Selles artiklis ei käsitleta TestRail'i põhifunktsioone (selle kohta on palju juhendeid) ega reklaamtekste, mis ilusasti kirjeldavad, miks peaksite just selle teenusepakkuja valima testiRepo loomiseks.

Tegevusplaan (mida rakendatakse)

1. Üldine nõuded

   1. Juhtum peab suutma läbi minna absoluutselt igast inimesest

   2. Juhtumid peavad jääma asjakohaseks nii kaua kui võimalik

   3. Juhtumid peavad maksimaalselt katma mobiilirakenduse funktsionaalsust niipalju, kui see ei ole vastuolus kahe eelneva punktiga

2. Eraldamine TestCase'ide ja TestScenario'ide vahel

3. Kiire TestRun'i erinevat tüüpi loomine

   1. Smoke

   2. Regress

   3. Mõju testimine jne.

4. Juhtumite toetamise optimeerimine

   1. Keeldumine 'surnud' kõvade ekraanifotode kasutamisest ja üleminek 'liikuvate andmete' kasutamisele

Nõuded

Väljade redigeerimiseks on teil vajalik administraatori juurdepääs

Projektitüübi valik

Saate valida kolm projekti tüüpi:

Valime vaikimisi tüübi. Sellel on samal ajal ligipääsetavad kõik juhtumid. Me kasutame nutikat filtreerimist ja haldame kõiki juhtumeid dünaamiliselt.

Väljade lisamine testijuhtumite nimekirja vaatamiseks

Lisame välja testijuhtumite prioriteedi kuvamiseks:

Samuti on võimalik lisada muid välju.

Testijuhtumi väljade ja siltide seadistamine

Avame seadistamise menüü:

Meile on vajalikud järgmised väljad:

Väli „Kokkuvõte“ (testijuhtumi pealkiri)

See väli on juba olemas, me ainult süstematiseerime selle kasutamise. Jagame juhtumeid TestCase'ide ja TestScenario'ide vahel. Suure nimekirja juhtumite paremaks lugemiseks on parem eelnevalt kokku leppida kokkuvõtte koostamise regulatsioonis.

TestScenario:

Näide: TestScenario — Mobiilirakenduse põhikasutuse stsenaarium

TestCase:

Näide: MainScreen — Autoriseerimise sektsioon — Kasutajanime sisestamine

Kokkuvõttes näeme juhtumi kokkuvõttes klassikalist arusaama: “mida, kus, millal”. Samuti eraldame visuaalselt kõrgetasemelised teststsenaariumid ja madalamatasemelised testjuhtumid automaatika jaoks sobivas vormis.

Silt «StartScreen» (ekraan, millest TestScenario algab, samuti võivad paljud testjuhtumid puudutada kõrvalekraanid)

Milleks võib olla vajalik: me eemaldame tekstist testjuhtumite tüüpilised sammud, mis suunavad kasutaja praeguse testjuhtumi ekraanile. (tüüpilised sammud teatud testolukorra loomiseks) Kõik tüüpilised sammud kõigi testjuhtumite jaoks on kirjas ühes failis. Kirjutan sellest lähemalt eraldi.

Loome uue välja:

Täidame uue välja komponendid:

Antud juhul loome valikuvälja, mis sisaldab väärtuste loendit. Sisestame selle välja väärtused:

Pange tähele, et väärtuste id ei alga üksteisest ja ei tule järjestikku. Miks see nii on? Asi on selles, et kui meil on salvestatud testjuhtumid sisestatud id-ga,

ja pärast seda peame looma kolmanda ekraani kahe olemasoleva vahel,

siis peame id-d ümber kirjutama, ja kuna need on juba seotud olemasolevate testjuhtumite silte, siis need lihtsalt kaovad. See oleks väga ebameeldiv.

Silt «Screen» (ekraan, mida testjuhtum mõjutab)

Milleks võib olla vajalik: üks impakti testimise ankur. Näiteks, arendajad on loonud uue toreda funktsiooni. Me peame selle testima, kuid selleks on vajalik mõista, mida just see funktsioon võiks mõjutada. Üldiselt võib me toetuda paradigmale, et erinevatel rakenduse ekraanidel (Activity) on erinevad klassid ja seega koosnevad nad rakenduse erinevatest komponentidest. Kindlasti on sellisel juhul vajalik individuaalne lähenemine.

Näide: home_screen, MapScreen, PayScreen jne.

Väli «MovableData» (link proxy andmebaasile muudetavate testandmetega)

Edasi püüame lahendada probleem, kuidas hoida andmete aktuaalsust testjuhtumites:

1. Lingid aktuaalsete makettide juurde (see on palju parem kui teha surnud ekraanipilte)

2. Tüüpilised sammud testolukorra ekraanile

3. SQL päringud

4. Lingid välistesse andmetesse ja muudele andmetele

Kuna me ei soovi kirjutada testandmeid igasse testijuhtumisse, loome ühe välise faili, millele kõigis testijuhtumites viidatakse. Nende andmete värskendamisel ei pea me kõiki testijuhtumeid läbi vaatama ja muutma, vaid saame andmeid muuta ainult ühes kohas. Kui keegi ettevalmistamata avab testijuhtumi, näeb ta testijuhtumi kehas viidet failile ja vihjet, et tuleb minna sinna testandmete saamiseks.

Kogume kõik need andmed ühte välisesse faili, mis on projektis kõigile soovijatele kätte saadav. Näiteks võib kasutada Google Sheeti või Excelit ja seada faili sees otsingu. Miks just need teenusepakkujad? Sest meie lähtepunktiks on see, et iga meeskonna liige peab suutma testijuhtumit avada ja läbida ilma eelneva tööriistade installimiseta.

Tooge Google Sheet võib kasutada SQL-päringuid. Näide:

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

Tooge Excel võib seadistada mugavad makrod kiireks otsimiseks. (filtreerimiseks) Näide linki pidi.

Idee ei ole uus ja on kirjeldatud testimise esimese raamatu "Testimine dot com" (autor Roman Savin) esimeses osas. Me lihtsalt integreerime TestRail'isse Roman Savini soovitatud meetodid. Selleks loome välja, mis viitab loodud failile:

täidame vaikimisi viite väärtuse, et igas uues testijuhtumis oleks juba viide:

Kui välise faili asukoht muutub (emme ettenägemata juhtumia), siis saab mugavalt kõigis testijuhtumites kohe muuta ühte või mitut välja:

Väli "Descriptions" (testijuhtumi kirjeldus või idee, tüüpilised juhised)

Milleks võib olla vajalik: Siia tekstiväljale paneme lühikese testijuhtumi kirjelduse ja tüüpilised juhised.

Näide: Kõik testandmed (aktuaalsed maketid, tööriistade kasutamine ja muud andmed) antud testijuhtumist on tähistatud viidete {…} ja asuvad failis MovableData. Viide MovableData'le on vastavas väljas üleval.

Silt "Component" (mobiilirakenduse komponent)

Milleks võib vajalik olla: impakti testimise jaoks. Kui mobiilirakendust saab jagada komponentideks (mis mõjutavad üksteist võimalikult vähe), siis piisab, et testida muudatusi ühe komponendi raames (mõningate riskidega), vähendades vajadust üldiste regressioonitestide läbiviimiseks. Kui on teada, et üks komponent võib mõjutada teist, koostatakse impakti testimise matriits.

Komponentide näited: GooglePay, Tellimus, Kasutajad, Kaart, Autoriseerimine jne.

Silt „TAG“ (Muud filtreerimise sildid)

Testjuhtumi sildistamine juhuslikuks filtreerimiseks. 

Eriti kasulik: 

1. kiire TestRuni koostamine erinevate tüüpiliste ülesannete jaoks: smoke, regress jne.

2. kas testid automatiseeritakse või on juba automatiseeritud

3. igal muul siltil

Näide: Smoke, Automatiseeritud, WhiteLabel, ForDelete jne.

Seame testjuhtumi väljade kuvamise järjekorra

Oleme loonud palju uusi välju, nüüd on aeg need mugavasse järjekorda paigutada:

TestRuni loomine

Nüüd loome uue test run'i, mille eesmärk on läbida smoke testimine kolme klikiga:

Teised kasulikud näpunäited

1. Kui TestRailis on mitu projekti, siis ärge unustage luua uusi välju ainult oma projekti jaoks, muidu hämmastavad kolleegid naabermeeskondadest uute ebatavaliste väljade ilmumine. Võivad tekkida kohalikud šokid.

2. Läbi suure hulga väljade kopeerimine on lihtsam sarnase grupitüü puhul kui uute loomine:

3. Võite kasutada kontosid ühiselt. Näiteks: üks administraatori konto, mitu kasutajakontot.

Kokkuvõte

Ülaltoodud näited on rakendatud mitmetes projektides ja on näidanud oma tõhusust. Loodan, et need aitavad parandada teie arusaamist sellest tööriistast ja aitavad luua efektiivseid ning mugavaid 'testihoidlaid'. Oleksin väga tänulik, kui jagaksite oma kogemusi TestRaili kasutamisest ja kasulikke nõuandeid kommentaarides.

Lingid:

TestRail'i tarnija veebisait

Raamat: „Testimine .COM” (autor Roman Savin)

Aitäh tähelepanu eest!

Allikas: habr.com