TestRail – projekti individuaalsed seaded

Sissejuhatus

Paljudes projektides, millega ma töötasin, ei kohandanud inimesed TestRaili enda jaoks ja leppisid standardsätetega. Seetõttu püüan selles artiklis kirjeldada näidet üksikutest sätetest, mis võivad aidata teil oma tööd tõhustada. Võtame näiteks mobiilirakenduse arendusprojekti.

Väike lahtiütlemine. See artikkel ei sisalda TestRaili põhifunktsioonide kirjeldust (selle kohta on palju juhendeid) ega müügiväljendeid, mis kirjeldavad värvikalt, miks peate testidega hoidla loomiseks valima just selle hankija.

Põhjendusplaan (mida rakendatakse)

1. Üldnõuded

   1. Absoluutselt igaüks peaks suutma juhtumi läbida.

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

   3. Juhtumid peaksid katma mobiilirakenduse funktsionaalsust võimalikult põhjalikult niivõrd, et see ei oleks vastuolus kahe esimese punktiga

2. Jagage TestCase'iks ja TestScenarioks

3. Erinevat tüüpi TestRuni kiire genereerimine

   1. Suits

   2. Taanduda

   3. Löögikatsed jne.

4. Juhtumitoe optimeerimine

   1. "Surnud" kõvakodeeritud ekraanipiltide hülgamine ja lülitumine teisaldatavatele andmetele

Nõuded

Väljade muutmiseks vajate administraatori juurdepääsu

Projekti tüübi valimine

Valida on kolme projektitüübi vahel:

Valime vaiketüübi. Kõik juhtumid on selles saadaval korraga. Kasutame nutikat filtreerimist ja haldame dünaamiliselt kõiki juhtumeid korraga.

Väljade lisamine testjuhtumite loendi vaatamiseks

Lisame välja prioriteetsete testjuhtumite kuvamiseks:

Saate lisada ka muid välju.

Testjuhtumi väljade ja siltide seadistamine

Avage seadete menüü:

Vajame järgmisi välju:

Väli „Kokkuvõte” (testjuhtumi päis)

See valdkond on juba olemas, me alles süstematiseerime selle kasutamist. Jagame juhtumid TestCase'iks ja TestScenarioks. Suure juhtumiloendi paremaks loetavuse huvides on parem kokkuvõtte kirjutamise reeglid eelnevalt kokku leppida.

Teststsenaarium:

Näide: TestScenario – mobiilirakenduse kasutamise põhistsenaarium

TestCase:

Näide: Peaekraan - Autoriseerimisjaotis - Sisestage sisselogimine

Kokkuvõttes näeme juhtumi kokkuvõttes klassikalist arusaama: "mis, kus, millal." Samuti eraldame visuaalselt kõrgetasemelised testskriptid ja madala taseme testjuhtumid automatiseerimiseks kõige sobivamal kujul.

Märgend "StartScreen" (ekraan, millelt TestScenario algab; samuti võivad paljud testjuhtumid puudutada külgnevaid ekraane)

Milleks seda vaja võib minna: eemaldame tekstist juhtumite tüüpiliste sammude teksti, mis viivad kasutaja praeguse testjuhtumi ekraanile. (tavalised sammud konkreetse testisituatsiooni loomiseks) Kõik tüüpilised sammud kõigi testjuhtumite jaoks kirjutatakse ühte faili. Täpsemalt kirjutan sellest eraldi.

Looge uus väli:

Täitke uue välja komponendid:

Sel juhul loome väärtuste loendist valikuvälja. Sisestage selle välja väärtused:

Pange tähele, et ID-väärtused ei alga ühega ega ole järjestikused. Miks seda tehakse? Asi on selles, et kui meil on sisestatud ID-ga testjuhtumid salvestatud,

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

siis peame id ümber kirjutama ja kuna olemasolevate tekstijuhtumite sildid on sellele juba lisatud, siis need lihtsalt kustutatakse. See saab olema väga ebameeldiv.

Sildi "Ekraan" (ekraani nimi, mis mõjutab TestCase'i)

Mida võib vaja minna: üks löögitestide ankrutest. Näiteks tegid arendajad uue laheda funktsiooni. Peame seda testima, kuid selleks peame mõistma, mida see funktsioon täpselt mõjutada võib. Vaikimisi saame lähtuda paradigmast, et rakenduse erinevatel ekraanidel (Activities) on erinevad klassid ja need moodustavad seetõttu rakenduse erinevad komponendid. Loomulikult on sel juhul vaja individuaalset lähenemist.

Näide: home_screen, MapScreen, PayScreen jne.

Väli „MovableData” (link muudetavate testandmetega puhverserveri andmebaasile)

Järgmisena proovime lahendada andmete asjakohasuse säilitamise probleemi testjuhtumites:

1. Lingid praegustele paigutustele (see on palju parem kui surnud ekraanipiltide tegemine)

2. Tüüpilised sammud testolukorraga ekraanile jõudmiseks

3. SQL päringud

4. Lingid välisandmetele ja muudele andmetele

Selle asemel, et kirjutada igasse testjuhtumisse testandmeid, loome ühe välise faili ja lingime sellele kõikidel testjuhtumitel. Nende andmete uuendamisel ei pea me kõiki testjuhtumeid läbi tegema ja neid muutma, vaid neid andmeid on võimalik muuta vaid ühes kohas. Kui keegi, kes pole ettevalmistatud, avab testjuhtumi, näeb ta testjuhtumi põhiosas linki failile ja vihjet, et ta peab testiandmete saamiseks sinna minema.

Pakime kõik need andmed ühte välisesse faili, mis on kõigile projektis osalejatele kättesaadav. Näiteks saate kasutada Google'i arvutustabelit või Excelit ja seadistada failis otsingu. Miks just need müüjad? Fakt on see, et lähtume paradigmast, et iga meeskonna liige peaks suutma avada ja läbida testjuhtumi, ilma et peaks esmalt tööriistu installima.

eest Google Sheet saate kasutada SQL päringuid. Näide:

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

eest Excel Saate seadistada mugavaid kiirotsingu makrosid. (filtreerimine) Näide по ссылке.

Tegelikult pole idee uus ja seda kirjeldatakse esimese testija raamatus "Testing dot com". (autor Savin Roman) Integreerime just Roman Savini pakutud meetodid TestRaili. Selleks looge loodud faili lingiga väli:

täitke lingi vaikeväärtus, nii et igal uuel testjuhtumil oleks juba link:

Kui välise faili asukoht muutub (vaatame vääramatu jõu korral), siis saate kõikidel testjuhtudel mugavalt muuta ühte või mitut välja korraga:

Väli "Kirjeldused" (testjuhtumi kirjeldus või idee, standardjuhised)

Mida võib vaja minna: sellele tekstiväljale paneme testjuhtumi lühikirjelduse ja standardjuhised.

Näide: Kõik selle testjuhtumi testiandmed (praegused paigutused, tööriistade kasutamine ja muud andmed) on tähistatud linkidega {...} ja asuvad failis MovableData. Link MovableData'le ülaosas vastaval väljal.

Silt „Component” (mobiilirakenduse komponent)

Milleks seda vaja võib minna: löökide testimiseks. Kui mobiilirakenduse saab jagada komponentideks (mis mõjutavad üksteist võimalikult vähe), siis piisab (teatud riskidega) ühes komponendis tehtud muudatustest, et neid sama komponendi sees kontrollida ja on vähem põhjust teostada. kõige üldised regressioonid. Kui on teavet, et üks komponent võib teist mõjutada, koostatakse löögitesti maatriks.

Näidiskomponendid: GooglePay, Tellimus, Kasutajad, Kaart, Autoriseerimine jne.

Silt "TAG" (muud sildid filtreerimiseks)

Testjuhtumi märgistamine märgenditega suvaliseks filtreerimiseks. 

Väga kasulik: 

1. TestRuni kiire koostamine erinevate tüüpiliste ülesannete jaoks: suits, regressioon jne.

2. kas testid on automatiseeritud või juba automatiseeritud?

3. muud sildid

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

Väljade kuvamise järjekorra seadistamine testjuhtumis

Oleme loonud palju uusi välju, on aeg need mugavas järjekorras järjestada:

TestRuni loomine

Nüüd loome suitsutesti läbiviimiseks kolme klõpsuga uue katsekäigu praeguste juhtumitega:

Muud kasulikud näpunäited

1. Kui TestRailil on mitu projekti, siis ärge unustage luua uusi väljasid ainult oma projekti jaoks, vastasel juhul on kolleegid naabermeeskondadest uute ebatavaliste väljade ilmumisest väga üllatunud. Võimalik lokaalne minestamine.

2. Suure hulga väljadega juhtumeid on lihtsam sarnasest rühmatüübist kopeerida kui uusi luua:

3. Kontod saab jagada. Näiteks: üks administraator, mitu kasutajat.

Järeldus

Ülalkirjeldatud näiteid on rakendatud mitmes projektis ja need on näidanud oma tõhusust. Loodan, et need aitavad teil sellest tööriistast paremini aru saada ning aitavad luua tõhusaid ja mugavaid testsalvestusi. Oleksin väga tänulik, kui kirjeldaksite kommentaarides oma TestRaili kasutamise kogemust ja kasulikke näpunäiteid.

Lingid:

TestRaili müüja veebisait

Raamat: "Testing .COM" (autor Roman Savin)

Tänan teid väga tähelepanu eest!

Allikas: www.habr.com