Pambuka
Ing akeh proyek sing aku kerjo, wong ora ngatur TestRail kanggo awake dhewe lan nggawe setelan standar. Mulane, ing artikel iki, aku bakal nyoba njlèntrèhaké conto setelan individu sing bisa mbantu nambah efisiensi karya. Contone, ayo njupuk proyek pangembangan aplikasi seluler.
Penafian cilik. Artikel iki ora ngemot gambaran saka fungsi dhasar TestRail (ana akeh Panuntun iki) lan dodolan expression colorfully njlentrehke apa sampeyan kudu milih vendor tartamtu iki kanggo nggawe gudang karo tes.
Rencana justifikasi (apa sing bakal ditindakake)
-
Syarat umum
-
Pancen sapa wae kudu bisa ngliwati kasus kasebut.
-
Kasus kudu tetep relevan kanggo anggere bisa
-
Kasus kudu nutupi fungsionalitas aplikasi seluler sabisa-bisa nganti ora mbantah rong poin pisanan.
-
-
Dibagi dadi TestCase lan TestScenario
-
Generasi cepet saka TestRun saka macem-macem jinis
-
smoke
-
Kuciwane
-
Pengujian dampak, lsp.
-
-
Optimisasi dhukungan kasus
-
Ninggalake gambar hardcoded "mati" lan ngalih menyang "data sing bisa dipindhah"
-
Requirements
Kanggo ngowahi kolom sampeyan butuh akses administrator
Pilih Tipe Proyek
Ana telung jinis proyek sing bisa dipilih:
Kita bakal milih jinis standar. Kabeh kasus bakal kasedhiya ing wektu sing padha. Kita bakal nggunakake nyaring cerdas lan ngatur kabeh kasus kanthi dinamis bebarengan.
Nambahake kolom kanggo ndeleng dhaptar kasus uji
Ayo nambah kolom kanggo nampilake kasus uji prioritas:
Sampeyan uga bisa nambah lapangan liyane.
Nyiyapake kolom lan tag test case
Bukak menu setelan:
Kita butuh lapangan ing ngisor iki:
Bidang "Ringkesan" (header kasus uji)
Bidang iki wis ana, kita mung sistematis panggunaane. Kita bakal dibagi kasus dadi TestCase lan TestScenario. Kanggo maca sing luwih apik saka dhaptar kasus sing akeh, luwih becik setuju sadurunge aturan nulis ringkesan.
Skenario Tes:
Conto: TestScenario - Skenario dhasar kanggo nggunakake aplikasi seluler
TestCase:
Conto: Layar Utama - Bagian wewenang - Ketik login
Secara total, kita ndeleng ringkesan kasus kasebut pemahaman klasik: "apa, ing ngendi, kapan." Kita uga misahake skrip tes tingkat dhuwur lan kasus tes tingkat rendah kanthi visual ing wangun sing paling cocog kanggo otomatisasi.
Tag "StartScreen" (layar saka ngendi TestScenario diwiwiti; uga, akeh kasus tes bisa ndemek layar jejer)
Kanggo apa sing perlu: kita bakal mbusak teks saka teks kasus langkah-langkah khas sing mimpin pangguna menyang layar kasus test saiki. (langkah khas kanggo nggawe kahanan test tartamtu) Kabeh langkah khas kanggo kabeh kasus test bakal ditulis ing siji file. Aku bakal nulis babagan iki kanthi luwih rinci kanthi kapisah.
Gawe lapangan anyar:
Isi komponen ing lapangan anyar:
Ing kasus iki, kita nggawe lapangan pilih saka dhaptar nilai. Ketik nilai lapangan iki:
Elinga yen nilai id ora diwiwiti kanthi siji lan ora berturut-turut. Apa iki rampung? Intine yen kita duwe kasus tes kanthi id sing direkam,
lan sawise iku kita kudu nggawe layar katelu ing antarane loro sing wis ana,
banjur kita kudu nulis ulang id kasebut, lan amarga tag kasus teks sing wis ana wis dipasang, mula mung bakal dibusak. Bakal banget ora nyenengake.
Tag "Layar" (jeneng layar sing mengaruhi TestCase)
Apa sampeyan bisa uga kudu: salah siji saka jangkar kanggo testing impact. Contone, pangembang nggawe fitur keren anyar. Kita kudu nyoba, nanging kita kudu ngerti apa sing bisa ditrapake fitur iki. Kanthi gawan, kita bisa miwiti saka paradigma sing beda layar (Aktivitas) saka aplikasi duwe kelas beda lan mulane minangka komponen beda saka aplikasi. Mesthi, ing kasus iki pendekatan individu dibutuhake.
Conto: layar ngarep, Layar Peta, Layar Pay, lsp.
Kolom "MovableData" (link menyang database proxy kanthi data tes sing bisa diganti)
Sabanjure, kita bakal nyoba ngatasi masalah njaga relevansi data ing kasus tes:
-
Link menyang tata letak saiki (iki luwih apik tinimbang njupuk gambar mati)
-
Langkah-langkah khas kanggo nyedhaki layar kanthi kahanan tes
-
pitakon SQL
-
Pranala menyang data eksternal lan data liyane
Tinimbang nulis data tes ing saben kasus tes, kita bakal nggawe siji file eksternal, lan nyambung menyang kabeh kasus tes. Nalika nganyari data iki, kita ora kudu ngliwati kabeh kasus tes lan ngganti, nanging data iki mung bisa diganti ing sak panggonan. Yen ana wong sing ora siyap mbukak kasus tes, dheweke bakal weruh ing awak kasus tes link menyang file lan tandha yen dheweke kudu pindhah menyang data tes.
Kita bakal ngemas kabeh data iki dadi siji file eksternal, sing bakal kasedhiya kanggo kabeh wong ing proyek kasebut. Contone, sampeyan bisa nggunakake Google Sheet utawa Excel lan nyetel telusuran ing file kasebut. Napa vendor tartamtu iki? Kasunyatane yaiku kita miwiti saka paradigma manawa sapa wae ing tim kudu bisa mbukak lan ngliwati kasus uji tanpa kudu nginstal piranti apa wae.
Kanggo Google Sheet sampeyan bisa nggunakake pitakon SQL. Tuladha:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Kanggo Excel Sampeyan bisa nyetel makro telusuran cepet sing trep. (nyaring) Tuladha .
Bener, ide kasebut ora anyar lan diterangake ing buku tester pisanan "Testing dot com". (penulis Savin Roman) Kita mung nggabungake metode sing diusulake dening Roman Savin menyang TestRail. Kanggo nindakake iki, gawe kolom kanthi link menyang file sing digawe:
isi nilai standar link supaya saben test case anyar wis duwe link:
Yen lokasi file eksternal diganti (kita nyedhiyakake force majeure), mula sampeyan bisa kanthi gampang ngganti siji utawa luwih kolom bebarengan ing kabeh kasus tes:
Bidang "Deskripsi" (deskripsi utawa gagasan kasus uji, instruksi standar)
Apa sing sampeyan butuhake: Ing kolom teks iki, kita bakal menehi katrangan ringkes babagan kasus uji lan instruksi standar.
Conto: Kabeh data uji (tata letak saiki, panggunaan piranti lan data liyane) saka kasus uji iki dituduhake kanthi pranala {...} lan ana ing file MovableData. Link menyang MovableData ing lapangan sing cocog ing sisih ndhuwur.
Tag "Komponen" (komponen aplikasi seluler)
Apa sing bisa uga dibutuhake: kanggo testing impact. Yen aplikasi seluler bisa dipérang dadi komponen (sing bisa mengaruhi saben liyane), banjur owah-owahan ing siji komponen bakal cukup (kanthi sawetara risiko) kanggo dicenthang ing komponen sing padha, lan bakal ana alesan kurang kanggo nindakake. regresi umum kabeh. Yen ana informasi manawa siji komponen bisa mengaruhi liyane, banjur matriks testing impact dikompilasi.
Conto komponen: GooglePay, Pesenan, Pangguna, Peta, Wewenang, lsp.
Tag "TAG" (Tag liyane kanggo nyaring)
Nandhani kasus uji kanthi tag kanggo nyaring kanthi sewenang-wenang.
Banget migunani kanggo:
-
ngumpulake TestRun kanthi cepet kanggo macem-macem tugas khas: kumelun, regresi, lsp.
-
tes bakal otomatis utawa wis otomatis?
-
sembarang tag liyane
Conto: Smoke, Automated, WhiteLabel, ForDelete, lsp.
Nyetel urutan tampilan kolom ing kasus uji
Kita wis nggawe akeh lapangan anyar, wektune kanggo ngatur kanthi trep:
Nggawe TestRun
Saiki kita bakal nggawe uji coba anyar kanthi kasus saiki kanggo nganakake tes kumelun kanthi telung klik:
Tips migunani liyane
-
Yen TestRail duwe sawetara proyek, mula aja lali nggawe lapangan anyar mung kanggo proyek sampeyan, yen kanca-kanca saka tim tetanggan bakal kaget banget karo tampilan lapangan sing ora biasa. pingsan lokal bisa.
2. Kasus kanthi akeh kolom luwih gampang disalin saka jinis grup sing padha tinimbang nggawe sing anyar:
3. Akun bisa dienggo bareng. Contone: siji administrator, sawetara pangguna.
kesimpulan
Conto sing diterangake ing ndhuwur wis dileksanakake ing sawetara proyek lan nuduhake efektifitase. Muga-muga dheweke bakal nambah pangerten babagan alat iki lan mbantu nggawe "panyimpenan tes" sing efektif lan trep. Aku bakal matur nuwun banget yen sampeyan njlèntrèhaké pengalaman sampeyan nggunakake TestRail lan tips migunani ing komentar.
Cathetan:
Buku:
Matur nuwun kanthi sanget kanggo perhatian sampeyan!
Source: www.habr.com