Hyrje
Në shumë projekte me të cilat kam punuar, njerëzit nuk e kanë personalizuar TestRail dhe janë kufizuar në cilësimet standarde. Prandaj, në këtë artikull do të përpiqem të përshkruaj një shembull të cilësimeve të personalizuara që mund t'ju ndihmojnë të rritni efikasitetin e punës suaj. Për shembull, do të marrim një projekt zhvillimi aplikacionesh mobile.
Një disklamer i vogël. Në këtë artikull nuk ka përshkrim të funksionalitetit bazë të TestRail (për këtë ka shumë guida) dhe shprehjeve promovuese që përshkruajnë me ngjyra pse duhet të zgjidhni këtë ofrues për krijimin e një depozite me teste.
Plani i justifikimit (çfarë do të realizohet)
Kërkesat e përgjithshme
Rasti duhet të mund të kalojë nga çdo person
Rastet duhet të ruajnë aktualitetin sa më gjatë të jetë e mundur
Rastet duhet të mbulojnë funksionalitetin e aplikacionit mobil në mënyrën më të plotë të mundshme, në masën që nuk e dëmton dy pikat e para
Ndara në TestCase dhe TestScenario
Krijimi i shpejtë i TestRun të llojeve të ndryshme
Smoke
Regress
Testimi i ndikimit etj.
Optimizimi i mbështetjes për rastet
Heqja e "screenshot-eve të vdekur" dhe kalimi në "të dhëna të lëvizshme"
Kërkesat
Për të redaktuar fushat do t'ju nevojitet akses administratori
Zgjedhja e llojit të projektit
Mund të zgjidhni tre lloje projekti:

Ne do të zgjedhim llojin e paracaktuar. Në të do të jenë të aksesueshme njëkohësisht të gjitha rastet. Do ta përdorim filtrimin e mençur dhe do të menaxhojmë dinamikisht të gjitha rastet njëkohësisht.
Shtimi i fushave për shikimin e listës së rasteve të testit
Do të shtojmë një fushë për të treguar prioritetin e rasteve të testit:

Gjithashtu, mund të shtoni edhe fusha të tjera.
Konfigurimi i fushave dhe etiketave të rastit të testit
Hapim menunë e konfigurimeve:

Na nevojiten këto fusha:
Fusha "Përmbledhja" (kapitulli i rastit të testit)
![]()
Kjo fushë tashmë ekziston, thjesht po sistematizohemi përdorimin e saj. Do të ndajmë rastet në TestCase dhe TestScenario. Për një lexueshmëri më të mirë të një liste të madhe rastesh, është më mirë të marrësh vesh paraprakisht për rregullat e shkruarjes së përmbledhjes.
TestScenario:
Shembulli: TestScenario â Skenari kryesor i pĂ«rdorimit tĂ« aplikacionit mobil
TestCase:
Shembulli: MainScreen â Seksioni i autorizimit â Shkruani emrin e pĂ«rdoruesit
Në përmbledhjen e rastit, ne shohim kuptimin klasik: "çfarë, ku, kur". Po ashtu, vizualisht ndajmë skenarët e testit në nivel të lartë dhe rastet e testit në nivel të ulët në formatin më të përshtatshëm për automatizim.
Tagu "StartScreen" (ekrani nga i cili fillon TestScenario, gjithashtu shumë raste testi mund të prekin ekranet fqinjë)
Për çfarë mund të nevojitet: ne do të heqim nga teksti i rasteve hapat tipikë që e çojnë përdoruesin në ekranin e rastit të tanishëm të testit. (hapat tipikë për krijimin e një situate të caktuar testi) Të gjitha hapat tipikë për të gjitha rastet e testit do të shkruhen në një skedar të vetëm. Do të shkruaj më shumë rreth tij ndaras.
Krijojmë një fushë të re:

Plotësojmë komponentët e fushës së re:

Në këtë rast, ne krijojmë një fushë zgjedhjeje nga lista e vlerave. Shkruajmë vlerat e kësaj fushe:

Vini re se id-të e vlerave nuk fillojnë nga një dhe nuk janë radhitur njëra pas tjetrës. Përse është bërë kështu? Sepse, nëse do të kemi raste testi me id të futur,

dhe pas kësaj do të nevojitet të krijojmë një ekran të tretë mes dy ekzistuesve,

do ta na duhet të rishkruajmë id, dhe pasi që për të janë lidhur tashmë etiketat e rasteve ekzistuese të teksteve, ato do të hiqen thjesht. Kjo do të jetë shumë e pakëndshme.
Etiketa «Screen» (emri i ekranit që prek TestCase)
Për çfarë mund të nevojitet: një nga ankeret për testimin e impaktit. Për shembull, zhvilluesit e kanë bërë një veçori të re të bukur. Na nevojitet ta testojmë, por për këtë na duhen të kuptojmë se çfarë kjo veçori mund të ketë prekur. Si parazgjedhje, mund të bazohemi në paradigmat se ekrane të ndryshme (Activity) të aplikacionit kanë klasa të ndryshme dhe për rrjedhojë 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» (linku në proxy DB me të dhëna testuese të ndryshueshme)
Më tej ne do të përpiqemi të zgjidhim problemin e mbështetjes së aktualitetit të të dhënave në testcases:
Linket në maketat aktuale (kjo është shumë më mirë se të bësh skrinshot të vdekur)
Hapat tipikë deri në ekranin me situatën testuese
SQL kërkesat
Linket në të dhëna të jashtme dhe të dhëna të tjera
Në vend që të shkruajmë të dhënat testuese brenda çdo rast testi, ne do të krijojmë një skedar të jashtëm dhe do të bëjmë lidhje me të në të gjithë rastet e testit. Kur të përditësojmë këto të dhëna, nuk do të kemi nevojë të kalojmë përmes të gjithë rasteve të testit për t'i ndryshuar ato, por do të mund të ndryshojmë këto të dhëna vetëm në një vend. Nëse dikush i pa përgatitur hap rastin e testit, ai do të shohë brenda tij një lidhje me skedarin dhe një sugjerim se ku duhet të shkojë për të dhënat testuese.
Të gjitha këto të dhëna ne do t'i paketojmë në një skedar të jashtëm, i cili do të jetë në dispozicion për të gjithë ata që duan në projekt. Për shembull, mund të përdorim Google Sheet ose Excel dhe të konfigurojmë brenda skedarit një funksion kërkimi. Pse pikërisht këta ofrues? Kjo është për shkak se ne i referohemi parimeve që çdo person në ekip duhet të jetë në gjendje të hapë dhe kalojë rastin e testit pa pasur nevojë të instalojë para-përgatitje ndonjë mjeti.
Për Google Sheet mund të përdoren pyetje SQL. Shembull:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'"Për Excel mund të konfigurojnë makro të lehta për kërkimin e menjëhershëm. (filtrimi) Shembull .
Ideeja nuk është e re dhe përshkruhet në librin e parë të testuesit "Testimi dot com". (autori Savin Roman) Ne thjesht do të integrojmë në TestRail metodat e propozuara nga Romani Savin. Për këtë, do të krijojmë një fushë me një lidhje në skedarin e krijuar:

plotësojmë vlerën e paracaktuar të lidhjes, në mënyrë që në çdo rast të ri testimi të ketë tashmë lidhjen:

Nëse vendndodhja e skedarit të jashtëm ndryshon (ne parashikojmë çdo rast të paparashikueshëm), atëherë mund ta ndryshoni lehtësisht në të gjitha rastet e testit menjëherë një ose disa fusha:


Fusha "Përshkrimet" (përshkrimi ose ideja e rastit të testit, udhëzime standarde)
Për cilat arsye mund të nevojitet: Në këtë fushë tekstuale do të vendosim një përshkrim të shkurtër të rastit të testit dhe udhëzime standarde.
Shembuj: TĂ« gjitha tĂ« dhĂ«nat e testeve (maketat aktuale, pĂ«rdorimi i mjeteve dhe tĂ« dhĂ«na tĂ« tjera) nga ky rast testi janĂ« tĂ« shĂ«nuara me lidhje {âŠ} dhe ndodhen nĂ« skedarin MovableData. Lidhja pĂ«r MovableData Ă«shtĂ« nĂ« fushĂ«n pĂ«rkatĂ«se lart.

Tagu "Komponent" (komponenti i aplikacionit mobil)
Për çfarë mund të nevojitet: për testimin e ndikimit. Nëse një aplikacion mobil mund të ndahet në komponentë (të cilët ndikojnë sa më pak njëri-tjetrin), ndryshimet në një komponent do të jenë të mjaftueshme (me disa rreziqe) për t'u verifikuar brenda këtij komponenti, dhe do të ketë më pak bazë për të kryer regresion të përgjithshëm të gjithçkaje. Nëse ka informacion që një komponent mund të ndikojë në një tjetër, atëherë krijohet një matricë testimi ndikimi.
Shembuj komponentësh: GooglePay, Porosi, Përdoruesit, Harta, Autorizimi etj.

Tagu «TAG» (Të tjerë trego për filtrimin)
Etiketimi i rastit tĂ« testit me etiketat pĂ«r filtrimin e rastĂ«sishĂ«m.Â
ShumĂ« tĂ« dobishme pĂ«r:Â
për hartimin e shpejtë të TestRun për detyra të ndryshme standard: smoke, regresion etj.
nëse testet do të automatizohen ose janë tashmë të automatizuara
çdo etiketë tjetër
Shembuj: Smoke, Automatizuar, WhiteLabel, PërDelete etj.


Rregullimi i rendit të shfaqjes së fushave në rastin e testit
Kemi krijuar shumë fusha të reja, ka ardhur koha për t'i rregulluar ato në një rend të përshtatshëm:

Krijimi i TestRun
Tani do të krijojmë një test run të ri me rastet aktuale për të kryer testimin e smoke në tre klikime:

Këshilla të tjera të dobishme
Nëse në TestRail ka disa projekte, mos harroni të krijoni fushat e reja vetëm për projektin tuaj, përndryshe kolegët nga ekipet fqinj do të befasohen shumë nga shfaqja e fushave të reja të pazakonta. Mund të kenë marrëveshje lokale.

2. Rastet me numĂ«r tĂ« madh fushash janĂ« mĂ« tĂ« lehta pĂ«r tâu kopjuar nga njĂ« grup tĂ« ngjashĂ«m sesa tĂ« krijoni tĂ« reja:

3. Mund të përdoren llogaritë në mënyrë të përbashkët. Për shembull: një llogari administratori, disa llogari përdoruesish.
Përfundimi
Shembujt e përmendur më sipër janë zbatuar në disa projekte dhe kanë treguar efikasitetin e tyre. Shpresoj se do t'ju ndihmojnë të përmirësoni kuptimin tuaj për këtë mjet dhe do t'ju ndihmojnë të krijoni 'testoblloqe' efektive dhe të rehatshme. Do të isha shumë mirënjohës, nëse në komentet e mësipërme do të përshkruani përvojën tuaj të përdorimit të TestRail dhe këshillat e dobishme.
Linket:
Libri:
Faleminderit shumë për vëmendjen!
Burimi: habr.com
