Paraqitje
Në shumë projekte me të cilat kam punuar, njerëzit nuk e personalizuan TestRail për veten e tyre dhe u mjaftuan me cilësimet standarde. Prandaj, në këtë artikull do të përpiqem të përshkruaj një shembull të cilësimeve individuale që mund t'ju ndihmojnë të përmirësoni efikasitetin e punës suaj. Për shembull, le të marrim një projekt të zhvillimit të aplikacionit celular.
Një mohim i vogël. Ky artikull nuk përmban një përshkrim të funksionalitetit bazë të TestRail (ka shumë udhëzues për këtë) dhe shprehje shitjesh që përshkruajnë me ngjyra pse duhet të zgjidhni këtë shitës të veçantë për të krijuar një depo me teste.
Plani i justifikimit (çfarë do të zbatohet)
-
Kërkesa të përgjithshme
-
Absolutisht çdokush duhet të jetë në gjendje ta kalojë çështjen.
-
Rastet duhet të mbeten të rëndësishme për aq kohë sa të jetë e mundur
-
Rastet duhet të mbulojnë funksionalitetin e aplikacionit celular sa më shumë që të jetë e mundur në masën që kjo të mos jetë në kundërshtim me dy pikat e para
-
-
Ndani në TestCase dhe TestScenario
-
Gjenerimi i shpejtë i TestRun të llojeve të ndryshme
-
tym
-
Regresi
-
Testimi i ndikimit, etj.
-
-
Optimizimi i mbështetjes së rastit
-
Braktisja e pamjeve të ekranit "të vdekura" të koduara dhe kalimi te "të dhënat e lëvizshme"
-
Kërkesat
Për të modifikuar fushat, do t'ju duhet qasje administratori
Zgjedhja e një lloji projekti
Ekzistojnë tre lloje projektesh për të zgjedhur:
Ne do të zgjedhim llojin e paracaktuar. Të gjitha rastet do të jenë të disponueshme në të në të njëjtën kohë. Ne do të përdorim filtrimin inteligjent dhe do të menaxhojmë në mënyrë dinamike të gjitha rastet menjëherë.
Shtimi i fushave për të parë një listë të rasteve të testimit
Le të shtojmë një fushë për të shfaqur rastet e provës me përparësi:
Mund të shtoni edhe fusha të tjera.
Vendosja e fushave dhe etiketave të rasteve të provës
Hapni menunë e cilësimeve:
Do të na duhen fushat e mëposhtme:
Fusha "Përmbledhje" (titulli i rastit të testit)
Kjo fushë tashmë ekziston, ne thjesht po sistemojmë përdorimin e saj. Ne do t'i ndajmë rastet në TestCase dhe TestScenario. Për lexueshmëri më të mirë të një liste të madhe rastesh, është më mirë të bini dakord paraprakisht për rregullat për të shkruar një përmbledhje.
Skenari i Testit:
Shembull: TestScenario - Skenari bazë për përdorimin e një aplikacioni celular
Rasti Test:
Shembull: Ekrani Kryesor - Seksioni i Autorizimit - Fut login
Në total, ne shohim në përmbledhjen e çështjes kuptimin klasik: "çfarë, ku, kur". Ne gjithashtu veçojmë vizualisht skriptet e testimit të nivelit të lartë dhe rastet e testimit të nivelit të ulët në formën më të përshtatshme për automatizim.
Etiketa "StartScreen" (ekrani nga i cili fillon TestScenario; gjithashtu, shumë raste testimi mund të prekin ekranet ngjitur)
Për atë që mund të nevojitet: ne do të heqim nga teksti tekstin e rasteve hapa tipikë që e çojnë përdoruesin në ekranin e rastit aktual të provës. (hapat tipikë për krijimin e një situate testimi specifike) Të gjithë hapat tipikë për të gjitha rastet e testimit do të shkruhen në një skedar. Unë do të shkruaj për të më në detaje veç e veç.
Krijo një fushë të re:
Plotësoni përbërësit e fushës së re:
Në këtë rast, ne po krijojmë një fushë të zgjedhur nga një listë vlerash. Futni vlerat e kësaj fushe:
Ju lutemi vini re se vlerat e ID-së nuk fillojnë me një dhe nuk janë të njëpasnjëshme. Pse është bërë kjo? Çështja është se nëse kemi raste testimi me ID-në e futur të regjistruar,
dhe pas kësaj do të na duhet të krijojmë një ekran të tretë midis dy ekzistuesve,
atëherë do të duhet të rishkruajmë ID-në dhe meqenëse etiketat e rasteve ekzistuese të tekstit tashmë janë bashkangjitur me të, ato thjesht do të fshihen. Do të jetë shumë e pakëndshme.
Etiketoni "Ekrani" (emri i ekranit që ndikon në TestCase)
Çfarë mund t'ju duhet: një nga ankorat për testimin e ndikimit. Për shembull, zhvilluesit krijuan një veçori të re interesante. Ne duhet ta testojmë atë, por për këtë duhet të kuptojmë se çfarë saktësisht mund të ndikojë kjo veçori. Si parazgjedhje, mund të nisemi nga paradigma që ekrane të ndryshme (Aktivitete) të një aplikacioni kanë klasa të ndryshme dhe për këtë arsye përbëjnë komponentë të ndryshëm të aplikacionit. Sigurisht, në këtë rast nevojitet një qasje individuale.
Shembull: home_screen, MapScreen, PayScreen, etj.
Fusha "MovableData" (lidhja me një bazë të dhënash përfaqësuese me të dhëna të ndryshueshme testimi)
Tjetra, ne do të përpiqemi të zgjidhim problemin e ruajtjes së rëndësisë së të dhënave në rastet e testimit:
-
Lidhje me paraqitjet aktuale (kjo është shumë më e mirë se marrja e pamjeve të vdekura të ekranit)
-
Hapat tipikë për të dalë në ekran me një situatë provë
-
Pyetjet SQL
-
Lidhje me të dhëna të jashtme dhe të dhëna të tjera
Në vend që të shkruajmë të dhënat e testit brenda çdo rasti testimi, ne do të krijojmë një skedar të jashtëm dhe do ta lidhim atë në të gjitha rastet e testimit. Gjatë përditësimit të këtyre të dhënave, nuk do të na duhet të kalojmë nëpër të gjitha rastet e testimit dhe t'i ndryshojmë ato, por do të jetë e mundur të ndryshojmë këto të dhëna vetëm në një vend. Nëse dikush i papërgatitur hap një rast testimi, ai do të shohë në trupin e rastit të testimit një lidhje me një skedar dhe një aluzion që duhet të shkojë tek ai për të dhënat e testit.
Ne do t'i paketojmë të gjitha këto të dhëna në një skedar të jashtëm, i cili do të jetë i disponueshëm për të gjithë në projekt. Për shembull, mund të përdorni Google Sheet ose Excel dhe të vendosni një kërkim brenda skedarit. Pse këta shitës të veçantë? Fakti është se ne fillojmë nga paradigma që çdo person në ekip duhet të jetë në gjendje të hapë dhe kalojë një rast testimi pa pasur nevojë të instalojë më parë ndonjë mjet.
Për Fletën e Google ju mund të përdorni pyetje SQL. Shembull:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Për Lë pas Mund të konfiguroni makro të përshtatshme të kërkimit të menjëhershëm. (filtrim) Shembull .
Në fakt, ideja nuk është e re dhe përshkruhet në librin e testuesit të parë "Testing dot com". (autori Savin Roman) Ne thjesht po integrojmë metodat e propozuara nga Roman Savin në TestRail. Për ta bërë këtë, krijoni një fushë me një lidhje me skedarin e krijuar:
plotësoni vlerën e paracaktuar të lidhjes në mënyrë që çdo rast i ri testimi të ketë tashmë një lidhje:
Nëse vendndodhja e skedarit të jashtëm ndryshon (ne parashikojmë çdo forcë madhore), atëherë mund të ndryshoni me lehtësi një ose më shumë fusha menjëherë në të gjitha rastet e provës:
Fusha "Përshkrimet" (përshkrimi ose ideja e një rasti testimi, udhëzime standarde)
Çfarë mund t'ju nevojitet: Në këtë fushë teksti do të vendosim një përshkrim të shkurtër të rastit të testimit dhe udhëzime standarde.
Shembull: Të gjitha të dhënat e testit (paraqitjet aktuale, përdorimi i veglave dhe të dhëna të tjera) nga ky rast testimi tregohen nga lidhjet {...} dhe ndodhen në skedarin MovableData. Lidhja me MovableData në fushën përkatëse në krye.
Etiketoni "Komponent" (komponent i aplikacionit celular)
Për çfarë mund të nevojitet: për testimin e ndikimit. Nëse një aplikacion celular mund të ndahet në komponentë (të cilët prekin njëri-tjetrin sa më pak të jetë e mundur), atëherë ndryshimet në një komponent do të jenë të mjaftueshme (me disa rreziqe) për t'u kontrolluar brenda të njëjtit komponent dhe do të ketë më pak arsye për të kryer. regresione të përgjithshme të gjithçkaje. Nëse ka informacion që një komponent mund të ndikojë në një tjetër, atëherë përpilohet një matricë e testimit të ndikimit.
Shembull komponentë: GooglePay, Porosia, Përdoruesit, Harta, Autorizimi, etj.
Etiketoni "TAG" (Etiketa të tjera për filtrim)
Etiketimi i një rasti testimi me etiketa për filtrim arbitrar.
Shumë i dobishëm për:
-
përpilimi i shpejtë i TestRun për detyra të ndryshme tipike: tym, regresion, etj.
-
testet do të jenë të automatizuara apo të automatizuara tashmë?
-
çdo etiketë tjetër
Shembull: Smoke, Automated, WhiteLabel, ForDelete, etj.
Vendosja e rendit të shfaqjes së fushave në rastin e testimit
Ne kemi krijuar shumë fusha të reja, është koha t'i rregullojmë ato në një renditje të përshtatshme:
Krijimi i TestRun
Tani do të krijojmë një test të ri me rastet aktuale për kryerjen e testimit të tymit në tre klikime:
Këshilla të tjera të dobishme
-
Nëse TestRail ka disa projekte, atëherë mos harroni të krijoni fusha të reja vetëm për projektin tuaj, përndryshe kolegët nga ekipet fqinje do të befasohen shumë nga shfaqja e fushave të reja të pazakonta. Të fikët lokale janë të mundshme.
2. Rastet me një numër të madh fushash janë më të lehta për t'u kopjuar nga një lloj grupi i ngjashëm sesa për të krijuar të reja:
3. Llogaritë mund të ndahen. Për shembull: një administrator, disa përdorues.
Përfundim
Shembujt e përshkruar më sipër janë zbatuar në disa projekte dhe kanë treguar efektivitetin e tyre. Shpresoj se ata do t'ju ndihmojnë të përmirësoni të kuptuarit tuaj për këtë mjet dhe t'ju ndihmojnë të krijoni "magazina testimi" efektive dhe të përshtatshme. Do të isha shumë mirënjohës nëse përshkruani përvojën tuaj të përdorimit të TestRail dhe këshilla të dobishme në komente.
referencat:
Libri:
Faleminderit shume per vemendjen tuaj!
Burimi: www.habr.com