Sissejuhatus
Paljude projektidega, millega ma olen töötanud, ei kohandanud inimesed TestRaili enda vajadustele ja jäid standardsete seadistuste juurde. Seetõttu püüan selles artiklis kirjeldada näidet individuaalsest seadistamisest, mis võib aidata teil tõsta oma töö efektiivsust. Näiteks võtame ette mobiilirakenduse arendusprojekti.
Väike märk. Selles artiklis ei käsitleta TestRail'i põhifunktsioone (selle kohta on palju juhendmaterjale) ega reklaamilauseid, mis värvikalt kirjeldavad, miks just seda teenusepakkujat valida testide hoidla loomiseks.
Teostatavusplaan (mida rakendatakse)
Üldnõuded
Juhtum peab olema läbiviidav absoluutselt igaühe poolt
Juhtumid peavad säilitama oma asjakohasuse nii kaua kui võimalik
Juhtumid peavad võimalikult põhjalikult katma mobiilirakenduse funktsioone, nii palju kui see ei ole vastuolus kahe esimese punktiga
Jaotamine TestCase'iks ja TestScenario'ks
Erinevat tüüpi TestRunide kiire loomine
Smoke
Regress
Mõjuhindamine jne.
Juhtumite toetamise optimeerimine
Keeldumine 'suretud' kõvasti kodeeritud ekraanipiltidest ja üleminek 'liikuvatele andmetele'
Nõuded
Kohandamisõiguse saamiseks on vajalik administraatori juurdepääs
Projekti tüübi valimine
Saate valida kolme projekti tüübi:
Valime vaikimisi tüübi. Sellel on samal ajal saadaval kõik juhtumid. Kasutame nutikat filtreerimist ja haldame kõiki juhtumeid dünaamiliselt.
Testjuhtumite loendi ülevaatamiseks väljade lisamine
Lisame välja testjuhtumite prioriteedi kuvamiseks:
Saame lisada ka teisi välju.
Testjuhtumi väljade ja siltide seadistamine
Avame seadistuse menüü:
Me vajame järgmisi väsi:
Väli „Summary” (testjuhtumi pealkiri)
See väli juba eksisteerib, me lihtsalt süstematiseerime selle kasutamise. Jagame juhtumeid TestCase'ideks ja TestScenario'iteks. Suure nimekirja juhtumite parema loetavuse jaoks on parem eelnevalt kokku leppida, kuidas summary'd kirjutada.
TestScenario:
Näide: TestScenario — Mobiilirakenduse põhikasutuse stsenaarium
TestCase:
Näide: MainScreen — Autoriseerimise jaotis — Logi sisse
Kokkuvõttes näeme juhtumi kokkuvõttes klassikalist arusaama: “mida, kus, millal”. Samuti jaotame visuaalselt kõrgema taseme teststsenaariumid ja madalama taseme testijuhised kõige paremini automatiseerimiseks sobivasse vormi.
Tag «StartScreen» (ekraan, millest TestScenario algab; samuti võivad paljusid testijuhiseid mõjutada naaberekraanid)
Milleks võib see vajalik olla: me eemaldame juhtumitekstist tüüpilised sammud, mis viivad kasutaja praeguse testijuhise ekraanile. (tüüpilised sammud kindla testimisolukorra loomiseks) Kõik tüüpilised sammud kõigi testijuhiste jaoks on kirjas ühes failis. Sellest räägin lähemalt eraldi.
Loome uue välja:
Täidame uue välja komponendid:
Antud juhul loome väärtuste valiku välja. Sisestame selle välja väärtused:
Pange tähele, et väärtuste id-d ei alga ühest ja ei käi järjestikku. Miks see nii on? Asi on selles, et kui meil on salvestatud testijuhised sisestatud id-ga,
ja seejärel on meil vaja luua kolmas ekraan kahe olemasoleva vahel,
siis peame id ümber kirjutama, ja kuna sellele on juba seotud olemasolevate tekstikastide sildid, siis need lihtsalt kaovad. See oleks väga ebameeldiv.
Silt „Screen“ (ekraan, mis puudutab TestCase'i)
Milleks võib olla vajalik: üks ankurduspunkt impakti testimiseks. Näiteks on arendajad loonud uue laheda funktsiooni. Me peame seda testima, kuid selleks peame mõistma, milliseid aspekte see funktsioon võis mõjutada. Eeldame, et rakenduse erinevad ekraanid (Activity) omavad erinevaid klasse ja seega moodustavad erinevaid rakenduse komponente. Muidugi on sellisel juhul vajalik individuaalne lähenemine.
Näide: home_screen, MapScreen, PayScreen jne.
Väli „MovableData“ (link muudetavate testandmete proxy andmebaasile)
Järgnevalt püüame lahendada probleemi andmete ajakohasuse toetamisega testkordeis:
Lingid kehtivatele makettidele (see on palju parem kui teha surnud ekraanipilte)
Tüüpilised sammud ekraanini, kus on testimisseade
SQL päringud
Lingid välistele andmetele ja muudele andmetele
Testandmete käsitsi sisestamise asemel loome ühe välist faili, millele viitame kõikides testjuhtumites. Kui need andmed uuendame, ei pea me läbima kõiki testjuhtumeid ja neid muutma, vaid saame neid muuta ainult ühes kohas. Kui keegi, kellel pole ettevalmistust, avab testjuhtumi, näeb ta testjuhtumi kehas viidet failile ja soovitust, et peaks minema sealt otsima testandmeid.
Kõik need andmed pakime ühte välist faili, mis on kõigile soovijatele projektil kättesaadav. Näiteks võib kasutada Google Sheeti või Excelit ja seadistada faili sees otsimise. Miks just need teenusepakkujad? Sest me lähtume paradigmaatilisest lähenemisest, et igaühel meeskonnas peaks olema võimalus avada ja läbida testjuhtumit ilma vajaduseta eelnevalt mingit tööriistade paigaldamist.
Kuna Google Sheet võib kasutada SQL päringuid. Näide:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'"Kuna Excel võib seadistada mugavad makrod kohese otsimise (filtreerimise) jaoks. Näide .
Oma idee pole uus ning on kirjeldatud testija esimeses raamatus "Testimine dot com". (autor Roman Savin) Me integreerime lihtsalt TestRail'i need Roman Savini meetodid. Selleks loome välja, kus on link loodud failile:
täidame vaikeväärtuse lingiga, et igas uues testjuhtumis oleks juba link:
Kui välise faili asukoht muutub (me arvestame igasuguste ettearvamatustega), saab mugavalt kõigis testjuhtumites korraga muuta ühte või mitut välja:
Väli "Descriptions" (testjuhtumi kirjeldus või idee, tüüpilised juhised)
Kellele see võib vajalik olla: Sellesse tekstivälja paigaldame lühikese kirjeldus testjuhtumist ja tüüpilised juhised.
Näide: Kõik testandmed (aktuaalsed maketid, tööriistade kasutamine ja muud andmed) antud testjuhtumis on viidatud linkidega {…} ja asuvad failis MovableData. Link MovableData-le asjakohases väljas üleval.
Silt "Component" (mobiilirakenduse komponent)
Milleks see võib vaja minna: impakti testimiseks. Kui mobiilirakenduse saab jagada komponentideks (mis mõjutavad üksteist võimalikult vähe), siis piisab ühe komponendi muudatuste kontrollimisest (mingite riskidega) selle sama komponendi ulatuses, ja see vähendab vajadust üldiste regressioonitestide tegemiseks. Kui on kindel info, et üks komponent võib mõjutada teist, koostatakse impakti testimise maatriks.
Komponentide näited: GooglePay, Tellimus, Kasutajad, Kaart, Autoriseerimine jne.
Silt «TAG» (Muud sildid filtreerimiseks)
Test juhtumite märgistamine, et teha juhuslikku filtreerimist.
Väga kasulik:
kiire TestRun koostamine erinevate tüüpiliste ülesannete jaoks: smoke, regress jne.
kas testid automatiseeritakse või on juba automatiseeritud
igal muul sildil
Näide: Smoke, Automatiseeritud, WhiteLabel, ForDelete jne.
Seadistame testjuhtumi väljade kuvamise järjekorra
Oleme loonud palju uusi välju, on aeg paigutada need mugavasse järjekorda:
TestRuni loomine
Nüüd loome uue test runi aktuaalsete juhtumitega smoke testimiseks kolme klikiga:
Teised kasulikud näpunäited
Kui TestRailis on mitu projekti, siis ärge unustage luua uusi välju ainult enda projekti jaoks, vastasel juhul üllatavad teie kolleegid naabertegevustest uute ebatavaliste väljade ilmumisega. Kohalikud minestamised on võimalikud.
2. Suure hulga väljadega juhtumite kopeerimine analooge grupist on lihtsam kui uute loomine:
3. Kontoid saab jagada. Näiteks: üks halduskonto ja mitu kasutajakontot.
Kokkuvõte
Ülaltoodud näiteid rakendati mitmes projektis ja need on osutunud tõhusaks. Loodan, et need aitavad teil paremini mõista seda tööriista ja luua tõhusaid ja mugavaid "testihoidlaid". Oleksin väga tänulik, kui jagaksite kommentaarides oma kogemusi TestRaili kasutamisel ja kasulikke näpunäiteid.
Lingid:
Raamat:
Suur aitäh tähelepanu eest!
Allikas: habr.com
