Pengenalan
Dalam banyak projek yang saya bekerjasama, orang ramai tidak menyesuaikan TestRail untuk diri mereka sendiri dan melakukan tetapan standard. Oleh itu, dalam artikel ini saya akan cuba menerangkan contoh tetapan individu yang boleh membantu anda meningkatkan kecekapan kerja anda. Sebagai contoh, mari kita ambil projek pembangunan aplikasi mudah alih.
Penafian kecil. Artikel ini tidak mengandungi penerangan tentang kefungsian asas TestRail (terdapat banyak panduan mengenai perkara ini) dan ungkapan jualan yang menerangkan dengan penuh warna mengapa anda perlu memilih vendor tertentu ini untuk mencipta repositori dengan ujian.
Pelan justifikasi (apa yang akan dilaksanakan)
-
Keperluan umum
-
Semestinya sesiapa sahaja boleh lulus kes itu.
-
Kes harus kekal relevan selama mungkin
-
Kes hendaklah meliputi kefungsian aplikasi mudah alih sebersih mungkin sehingga ke tahap ini tidak bercanggah dengan dua perkara pertama
-
-
Berpecah kepada TestCase dan TestScenario
-
Penjanaan pantas TestRun pelbagai jenis
-
Asap
-
Menyesal
-
Ujian kesan, dsb.
-
-
Pengoptimuman sokongan kes
-
Meninggalkan tangkapan skrin berkod keras "mati" dan bertukar kepada "data alih"
-
Keperluan Jawatan
Untuk mengedit medan anda memerlukan akses pentadbir
Memilih Jenis Projek
Terdapat tiga jenis projek untuk dipilih:
Kami akan memilih jenis lalai. Semua kes akan tersedia di dalamnya pada masa yang sama. Kami akan menggunakan penapisan pintar dan mengurus semua kes secara dinamik sekaligus.
Menambah medan untuk melihat senarai kes ujian
Mari tambah medan untuk memaparkan kes ujian keutamaan:
Anda juga boleh menambah medan lain.
Menyediakan medan dan teg kes ujian
Buka menu tetapan:
Kami memerlukan medan berikut:
Medan "Ringkasan" (pengepala kes ujian)
Medan ini sudah ada, kita hanya mensistemkan penggunaannya. Kami akan membahagikan kes kepada TestCase dan TestScenario. Untuk kebolehbacaan yang lebih baik bagi senarai besar kes, adalah lebih baik untuk bersetuju terlebih dahulu mengenai peraturan untuk menulis ringkasan.
Senario Ujian:
Contoh: TestScenario - Senario asas untuk menggunakan aplikasi mudah alih
TestCase:
Contoh: Skrin Utama - Bahagian kebenaran - Masukkan log masuk
Secara keseluruhan, kita melihat dalam ringkasan kes pemahaman klasik: "apa, di mana, bila." Kami juga memisahkan skrip ujian peringkat tinggi dan kes ujian peringkat rendah secara visual dalam bentuk yang paling sesuai untuk automasi.
Teg "StartScreen" (skrin dari mana TestScenario bermula; juga, banyak kes ujian boleh menyentuh skrin bersebelahan)
Untuk perkara yang mungkin diperlukan: kami akan mengalih keluar teks kes langkah biasa daripada teks yang membawa pengguna ke skrin kes ujian semasa. (langkah biasa untuk mencipta situasi ujian tertentu) Semua langkah biasa untuk semua kes ujian akan ditulis dalam satu fail. Saya akan menulis mengenainya dengan lebih terperinci secara berasingan.
Buat medan baharu:
Isikan komponen medan baharu:
Dalam kes ini, kami mencipta medan pilihan daripada senarai nilai. Masukkan nilai medan ini:
Sila ambil perhatian bahawa nilai id tidak bermula dengan satu dan tidak berturut-turut. Mengapa ini dilakukan? Maksudnya ialah jika kita mempunyai kes ujian dengan id yang dimasukkan direkodkan,
dan selepas itu kita perlu membuat skrin ketiga antara dua yang sedia ada,
maka kita perlu menulis semula id, dan memandangkan tag kes teks sedia ada sudah dilampirkan padanya, ia hanya akan dipadamkan. Ia akan menjadi sangat tidak menyenangkan.
Tag "Skrin" (nama skrin yang mempengaruhi TestCase)
Perkara yang mungkin anda perlukan: salah satu sauh untuk ujian impak. Sebagai contoh, pembangun membuat ciri hebat baharu. Kita perlu mengujinya, tetapi untuk ini kita perlu memahami apa sebenarnya ciri ini boleh menjejaskan. Secara lalai, kita boleh bermula dari paradigma bahawa skrin yang berbeza (Aktiviti) aplikasi mempunyai kelas yang berbeza dan oleh itu membentuk komponen aplikasi yang berbeza. Sudah tentu, dalam kes ini pendekatan individu diperlukan.
Contoh: skrin_rumah, Skrin Peta, Skrin Berbayar, dsb.
Medan "MovableData" (pautan ke pangkalan data proksi dengan data ujian boleh ubah)
Seterusnya, kami akan cuba menyelesaikan masalah mengekalkan kaitan data dalam kes ujian:
-
Pautan ke reka letak semasa (ini lebih baik daripada mengambil tangkapan skrin mati)
-
Langkah biasa untuk sampai ke skrin dengan situasi ujian
-
pertanyaan SQL
-
Pautan ke data luaran dan data lain
Daripada menulis data ujian di dalam setiap kes ujian, kami akan membuat satu fail luaran dan memautkannya pada semua kes ujian. Apabila mengemas kini data ini, kami tidak perlu melalui semua kes ujian dan menukarnya, tetapi data ini boleh diubah hanya di satu tempat. Jika seseorang yang tidak bersedia membuka kes ujian, dia akan melihat dalam badan kes ujian itu pautan ke fail dan petunjuk bahawa dia perlu pergi ke kes itu untuk data ujian.
Kami akan membungkus semua data ini ke dalam satu fail luaran, yang akan tersedia untuk semua orang dalam projek itu. Sebagai contoh, anda boleh menggunakan Helaian Google atau Excel dan menyediakan carian dalam fail. Mengapa vendor tertentu ini? Hakikatnya ialah kita bermula dari paradigma bahawa mana-mana orang dalam pasukan sepatutnya boleh membuka dan lulus kes ujian tanpa perlu memasang apa-apa alatan terlebih dahulu.
Untuk Lembaran Google anda boleh menggunakan pertanyaan SQL. Contoh:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Untuk Excel Anda boleh menyediakan makro carian segera yang mudah. (penapisan) Contoh .
Sebenarnya, idea itu bukan baharu dan diterangkan dalam buku penguji pertama "Menguji dot com". (pengarang Savin Roman) Kami hanya menyepadukan kaedah yang dicadangkan oleh Roman Savin ke dalam TestRail. Untuk melakukan ini, buat medan dengan pautan ke fail yang dibuat:
isikan nilai lalai pautan supaya setiap kes ujian baharu sudah mempunyai pautan:
Jika lokasi fail luaran berubah (kami menyediakan sebarang force majeure), maka anda boleh menukar satu atau lebih medan dengan mudah sekali gus dalam semua kes ujian:
Medan "Penerangan" (huraian atau idea kes ujian, arahan standard)
Perkara yang mungkin anda perlukan: Dalam medan teks ini kami akan meletakkan penerangan ringkas tentang kes ujian dan arahan standard.
Contoh: Semua data ujian (reka letak semasa, penggunaan alatan dan data lain) daripada kes ujian ini ditunjukkan oleh pautan {...} dan terletak dalam fail MovableData. Pautan ke MovableData dalam medan yang sepadan di bahagian atas.
Tag "Komponen" (komponen aplikasi mudah alih)
Perkara yang mungkin diperlukan untuk: untuk ujian impak. Jika aplikasi mudah alih boleh dibahagikan kepada komponen (yang mempengaruhi satu sama lain seminimum mungkin), maka perubahan dalam satu komponen akan mencukupi (dengan beberapa risiko) untuk diperiksa dalam komponen yang sama, dan akan ada kurang sebab untuk melaksanakan regresi umum segala-galanya. Sekiranya terdapat maklumat bahawa satu komponen boleh mempengaruhi yang lain, maka matriks ujian impak disusun.
Contoh komponen: GooglePay, Pesanan, Pengguna, Peta, Keizinan, dsb.
Teg "TAG" (Teg lain untuk penapisan)
Menandai kes ujian dengan teg untuk penapisan sewenang-wenangnya.
Sangat berguna untuk:
-
cepat menyusun TestRun untuk pelbagai tugas biasa: asap, regresi, dsb.
-
adakah ujian akan diautomasikan atau sudah diautomasikan?
-
sebarang tag lain
Contoh: Asap, Automatik, WhiteLabel, ForDelete, dsb.
Menyediakan susunan paparan medan dalam kes ujian
Kami telah mencipta banyak medan baharu, sudah tiba masanya untuk menyusunnya dalam susunan yang mudah:
Mencipta TestRun
Sekarang kami akan membuat ujian baharu dengan kes semasa untuk menjalankan ujian asap dalam tiga klik:
Petua berguna lain
-
Jika TestRail mempunyai beberapa projek, maka jangan lupa untuk mencipta medan baru hanya untuk projek anda, jika tidak, rakan sekerja dari pasukan jiran akan sangat terkejut dengan kemunculan medan luar biasa baru. Pengsan tempatan mungkin.
2. Kes dengan bilangan medan yang banyak lebih mudah untuk disalin daripada jenis kumpulan yang serupa daripada mencipta yang baharu:
3. Akaun boleh dikongsi. Contohnya: seorang pentadbir, beberapa pengguna.
Kesimpulan
Contoh yang diterangkan di atas telah dilaksanakan pada beberapa projek dan telah menunjukkan keberkesanannya. Saya harap mereka akan membantu meningkatkan pemahaman anda tentang alat ini dan membantu anda mencipta "storan ujian" yang berkesan dan mudah. Saya akan sangat berterima kasih jika anda menerangkan pengalaman anda menggunakan TestRail dan petua berguna dalam ulasan.
Rujukan:
Buku:
Terima kasih banyak atas perhatian anda!
Sumber: www.habr.com