Ynlieding
Yn in protte projekten wêrmei't ik wurke, hawwe minsken TestRail net foar harsels oanpast en makken har mei standertynstellingen. Dêrom sil ik yn dit artikel besykje in foarbyld te beskriuwen fan yndividuele ynstellingen dy't jo kinne helpe om de effisjinsje fan jo wurk te ferbetterjen. Litte wy bygelyks in projekt foar ûntwikkeling fan mobile applikaasjes nimme.
In lytse disclaimer. Dit artikel befettet gjin beskriuwing fan 'e basisfunksjonaliteit fan TestRail (d'r binne in protte hantliedingen oer dit) en ferkeap-útdrukkingen dy't kleurich beskriuwe wêrom't jo dizze bepaalde ferkeaper moatte kieze om in repository te meitsjen mei tests.
Rjochtfeardigingsplan (wat sil útfierd wurde)
-
Algemiene easken
-
Absolút elkenien moat de saak trochjaan kinne.
-
Saken moatte sa lang mooglik relevant bliuwe
-
Cases moatte de funksjonaliteit fan 'e mobile applikaasje sa yngeand mooglik dekke, foarsafier't dit de earste twa punten net tsjinsprekt
-
-
Split yn TestCase en TestScenario
-
Fluch generaasje fan TestRun fan ferskate soarten
-
Reek
-
Regress
-
Impact testen, ensfh.
-
-
Optimalisaasje fan saakstipe
-
"Deade" hurdkodearre skermôfbyldings ferlitte en oerskeakelje nei "ferpleatse gegevens"
-
easken
Om fjilden te bewurkjen hawwe jo administrator tagong nedich
Selektearje in projekttype
D'r binne trije projekttypen om út te kiezen:
Wy sille it standerttype selektearje. Alle gefallen sille tagelyk beskikber wêze. Wy sille tûk filtering brûke en alle gefallen tagelyk dynamysk beheare.
Fjilden tafoegje om in list mei testgefallen te besjen
Litte wy in fjild tafoegje om prioriteitstestgefallen wer te jaan:
Jo kinne ek oare fjilden tafoegje.
It ynstellen fan testcasefjilden en tags
Iepenje it ynstellingsmenu:
Wy sille de folgjende fjilden nedich wêze:
"Gearfetting" fjild (koptekst foar testgefallen)
Dit fjild bestiet al, wy systematisearje gewoan it gebrûk. Wy sille gefallen ferdiele yn TestCase en TestScenario. Foar bettere lêsberens fan in grutte list fan saken is it better om foarôf iens te wurden oer de regels foar it skriuwen fan in gearfetting.
Testscenario:
Foarbyld: TestScenario - Basissenario foar it brûken fan in mobile applikaasje
Testcase:
Foarbyld: MainScreen - Autorisaasje seksje - Fier login yn
Yn totaal sjogge wy yn 'e gearfetting fan' e saak it klassike begryp: "wat, wêr, wannear." Wy skiede ek visueel testskripten op heech nivo en testgefallen op leech nivo yn 'e foarm dy't it meast geskikt is foar automatisearring.
Tag "StartScreen" (it skerm wêrfan TestScenario begjint; ek kinne in protte testgefallen oanbuorjende skermen oanreitsje)
Foar wat it nedich wêze kin: wy sille de tekst fan gefallen typyske stappen út 'e tekst fuortsmite dy't de brûker nei it skerm fan' e hjoeddeistige testsaak liede. (typyske stappen foar it meitsjen fan in spesifike testsituaasje) Alle typyske stappen foar alle testgefallen wurde yn ien bestân skreaun. Ik sil der apart oer skriuwe.
Meitsje in nij fjild:
Folje de komponinten fan it nije fjild yn:
Yn dit gefal meitsje wy in selekteare fjild út in list mei wearden. Fier de wearden fan dit fjild yn:
Tink derom dat de id-wearden net begjinne mei ien en binne net opienfolgend. Wêrom is dit dien? It punt is dat as wy testgefallen hawwe mei de ynfierde id opnommen,
en dêrnei moatte wy in tredde skerm meitsje tusken de twa besteande,
dan moatte wy de id opnij skriuwe, en om't de tags fan besteande tekstgefallen der al oan hechte binne, wurde se gewoan wiske. It sil wêze hiel onaangenaam.
Tag "Screen" (namme fan it skerm dat TestCase beynfloedet)
Wat jo miskien nedich hawwe: ien fan 'e ankers foar ympakttesten. Bygelyks, de ûntwikkelders makken in nije koele funksje. Wy moatte it testen, mar hjirfoar moatte wy begripe wat dizze funksje krekt kin beynfloedzje. Standert kinne wy begjinne fan it paradigma dat ferskate skermen (Aktiviteiten) fan in applikaasje ferskate klassen hawwe en dêrom ferskate komponinten fan 'e applikaasje foarmje. Fansels is yn dit gefal in yndividuele oanpak nedich.
Foarbyld: home_screen, MapScreen, PayScreen, ensfh.
"MovableData" fjild (keppeling nei in proxy-database mei feroare testgegevens)
Dêrnei sille wy besykje it probleem op te lossen fan it behâld fan de relevânsje fan gegevens yn testgefallen:
-
Keppelings nei hjoeddeistige yndielingen (dit is folle better dan deade skermôfbyldings te nimmen)
-
Typyske stappen om nei it skerm te kommen mei in testsituaasje
-
SQL-fragen
-
Keppelings nei eksterne gegevens en oare gegevens
Yn stee fan it skriuwen fan testgegevens binnen elke testgefal, sille wy ien ekstern bestân oanmeitsje, en keppelje nei it op alle testgefallen. By it bywurkjen fan dizze gegevens hoege wy net alle testgefallen troch te gean en se te feroarjen, mar it sil mooglik wêze om dizze gegevens op mar ien plak te feroarjen. As immen net taret in testsaak iepenet, sil hy yn it lichem fan 'e testsaak in keppeling nei in bestân sjen en in oanwizing dat hy der nei moat gean foar testgegevens.
Wy sille al dizze gegevens yn ien ekstern bestân pakke, dat sil beskikber wêze foar elkenien op it projekt. Jo kinne bygelyks Google Blêd of Excel brûke en in sykopdracht ynstelle yn it bestân. Wêrom dizze bepaalde ferkeapers? It feit is dat wy begjinne fan it paradigma dat elke persoan yn it team in testgefal kin iepenje en trochjaan sûnder earst ark te ynstallearjen.
foar Google Blêd jo kinne SQL-fragen brûke. Foarbyld:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")foar excel Jo kinne handige makro's foar direkte sykjen ynstelle. (filtering) Foarbyld .
Eins is it idee net nij en wurdt beskreaun yn it boek fan 'e earste tester "Testing dot com". (auteur Savin Roman) Wy yntegrearje gewoan de metoaden foarsteld troch Roman Savin yn TestRail. Om dit te dwaan, meitsje in fjild mei in keppeling nei it oanmakke bestân:
folje de standertwearde fan 'e keppeling yn, sadat elke nije testsaak al in keppeling hat:
As de lokaasje fan it eksterne bestân feroaret (wy soargje foar oermacht), dan kinne jo maklik ien of mear fjilden tagelyk feroarje yn alle testgefallen:
Fjild "Beskriuwings" (beskriuwing as idee fan in testgefal, standert ynstruksjes)
Wat jo miskien nedich binne: Yn dit tekstfjild pleatse wy in koarte beskriuwing fan 'e testgefal en standertynstruksjes.
Foarbyld: Alle testgegevens (aktuele opmaak, gebrûk fan ark en oare gegevens) fan dizze testgefal wurde oanjûn troch keppelings {...} en lizze yn it MovableData-bestân. Link nei MovableData yn it oerienkommende fjild oan 'e boppekant.
Tag "Komponent" (mobyl applikaasje komponint)
Wêr kin it foar nedich wêze: foar impacttesten. As in mobile applikaasje kin wurde ferdield yn komponinten (dy't inoar sa min mooglik beynfloedzje), dan binne feroarings yn ien komponint genôch (mei guon risiko's) om te kontrolearjen binnen deselde komponint, en sil d'r minder reden wêze om út te fieren algemiene regressions fan alles. As d'r ynformaasje is dat ien komponint in oar kin beynfloedzje, dan wurdt in effekttestmatriks gearstald.
Foarbyld komponinten: GooglePay, Order, Users, Map, Authorization, ensfh.
Tag "TAG" (Oare tags foar filterjen)
Tagging in test gefal mei tags foar willekeurich filterjen.
Hiel brûkber foar:
-
fluch kompilearje TestRun foar ferskate typyske taken: reek, regression, ensfh.
-
sille de testen wurde automatisearre of al automatisearre?
-
alle oare tags
Foarbyld: Smoke, Automated, WhiteLabel, ForDelete, etc.
It ynstellen fan de werjefte folchoarder fan fjilden yn de test gefal
Wy hawwe in protte nije fjilden oanmakke, it is tiid om se yn in handige folchoarder te regeljen:
TestRun oanmeitsje
No sille wy in nije testrun meitsje mei hjoeddeistige gefallen foar it útfieren fan reektests yn trije klikken:
Oare nuttige tips
-
As TestRail ferskate projekten hat, ferjit dan net om nije fjilden allinich foar jo projekt te meitsjen, oars sille kollega's fan oanbuorjende teams heul ferrast wurde troch it ferskinen fan nije ûngewoane fjilden. Lokale flauwerij is mooglik.
2. Cases mei in grut oantal fjilden binne makliker te kopiearjen fan in ferlykber groepstype dan om nije te meitsjen:
3. Accounts kinne wurde dield. Bygelyks: ien behearder, ferskate brûker.
konklúzje
De hjirboppe beskreaune foarbylden binne ymplementearre op ferskate projekten en hawwe har effektiviteit sjen litten. Ik hoopje dat se sille helpe om jo begryp fan dit ark te ferbetterjen en jo te helpen effektive en handige "test-opslach" te meitsjen. Ik soe tige tankber wêze as jo jo ûnderfining mei it brûken fan TestRail en nuttige tips beskriuwe yn 'e opmerkingen.
Ferwizings:
Boek:
Tige tank foar jo oandacht!
Boarne: www.habr.com