pengenalan
Di banyak proyek yang saya kerjakan, orang tidak menyesuaikan TestRail untuk diri mereka sendiri dan hanya puas dengan pengaturan standar. Oleh karena itu, pada artikel kali ini saya akan mencoba menjelaskan contoh pengaturan individual yang dapat membantu Anda meningkatkan efisiensi pekerjaan Anda. Sebagai contoh, mari kita ambil proyek pengembangan aplikasi seluler.
Penafian kecil. Artikel ini tidak berisi deskripsi fungsionalitas dasar TestRail (ada banyak panduan mengenai hal ini) dan ekspresi penjualan yang menjelaskan dengan penuh warna mengapa Anda perlu memilih vendor khusus ini untuk membuat repositori dengan pengujian.
Rencana justifikasi (apa yang akan dilaksanakan)
-
Persyaratan umum
-
Benar-benar siapa pun harus bisa melewati kasus ini.
-
Kasus-kasus harus tetap relevan selama mungkin
-
Kasus harus mencakup fungsionalitas aplikasi seluler selengkap mungkin sejauh hal ini tidak bertentangan dengan dua poin pertama
-
-
Dibagi menjadi TestCase dan TestScenario
-
Pembuatan cepat TestRun dari berbagai jenis
-
Merokok
-
Regresi
-
Uji dampak, dll.
-
-
Optimalisasi dukungan kasus
-
Meninggalkan tangkapan layar hardcode yang “mati” dan beralih ke “data bergerak”
-
Persyaratan
Untuk mengedit bidang, Anda memerlukan akses administrator
Memilih Jenis Proyek
Ada tiga jenis proyek yang dapat dipilih:
Kami akan memilih tipe default. Semua kasing akan tersedia di dalamnya secara bersamaan. Kami akan menggunakan pemfilteran cerdas dan mengelola semua kasus secara dinamis sekaligus.
Menambahkan bidang untuk melihat daftar kasus uji
Mari tambahkan bidang untuk menampilkan kasus uji prioritas:
Anda juga dapat menambahkan bidang lainnya.
Menyiapkan bidang dan tag kasus uji
Buka menu pengaturan:
Kami membutuhkan bidang-bidang berikut:
Bidang "Ringkasan" (header kasus uji)
Bidang ini sudah ada, kami tinggal mensistematisasikan penggunaannya. Kami akan membagi kasus menjadi TestCase dan TestScenario. Untuk keterbacaan yang lebih baik dari daftar besar kasus, lebih baik menyepakati terlebih dahulu aturan penulisan ringkasan.
Skenario Tes:
Contoh: TestScenario - Skenario dasar untuk menggunakan aplikasi seluler
Kasus cobaan:
Contoh: Layar Utama - Bagian Otorisasi - Masukkan login
Secara total, kita melihat dalam ringkasan kasus pemahaman klasik: “apa, di mana, kapan.” Kami juga secara visual memisahkan skrip pengujian tingkat tinggi dan kasus pengujian tingkat rendah dalam bentuk yang paling sesuai untuk otomatisasi.
Tag “StartScreen” (layar tempat TestScenario dimulai; juga, banyak kasus uji dapat menyentuh layar yang berdekatan)
Untuk apa yang mungkin diperlukan: kami akan menghapus dari teks teks kasus langkah-langkah umum yang mengarahkan pengguna ke layar kasus uji saat ini. (langkah-langkah umum untuk menciptakan situasi pengujian tertentu) Semua langkah umum untuk semua kasus pengujian akan ditulis dalam satu file. Saya akan menulisnya lebih detail secara terpisah.
Buat bidang baru:
Isi komponen bidang baru:
Dalam hal ini, kami membuat bidang pilih dari daftar nilai. Masukkan nilai bidang ini:
Perlu diketahui bahwa nilai id tidak dimulai dengan satu dan tidak berurutan. Mengapa hal ini dilakukan? Intinya adalah jika kita memiliki kasus uji dengan id yang dimasukkan dicatat,
dan setelah itu kita perlu membuat layar ketiga di antara dua layar yang sudah ada,
maka kita harus menulis ulang idnya, dan karena tag dari case teks yang ada sudah dilampirkan padanya, maka tag tersebut akan dihapus begitu saja. Ini akan sangat tidak menyenangkan.
Tag “Layar” (nama layar yang mempengaruhi TestCase)
Apa yang mungkin Anda perlukan: salah satu jangkar untuk pengujian dampak. Misalnya, pengembang membuat fitur baru yang keren. Kita perlu mengujinya, tetapi untuk ini kita perlu memahami apa sebenarnya pengaruh fitur ini. Secara default, kita dapat memulai dari paradigma bahwa layar (Aktivitas) yang berbeda dari suatu aplikasi memiliki kelas yang berbeda dan oleh karena itu merupakan komponen aplikasi yang berbeda. Tentu saja dalam hal ini diperlukan pendekatan individual.
Contoh: home_screen, MapScreen, PayScreen, dll.
Bidang “MovableData” (tautan ke database proxy dengan data pengujian yang dapat diubah)
Selanjutnya, kami akan mencoba memecahkan masalah menjaga relevansi data dalam kasus uji:
-
Tautan ke tata letak saat ini (ini jauh lebih baik daripada mengambil tangkapan layar mati)
-
Langkah-langkah umum untuk membuka layar dengan situasi pengujian
-
Kueri SQL
-
Tautan ke data eksternal dan data lainnya
Daripada menulis data pengujian di dalam setiap kasus pengujian, kita akan membuat satu file eksternal, dan menautkannya ke semua kasus pengujian. Saat memperbarui data ini, kita tidak harus melalui semua kasus pengujian dan mengubahnya, namun data ini dapat diubah hanya di satu tempat. Jika seseorang yang tidak siap membuka kasus uji, dia akan melihat di badan kasus uji tersebut tautan ke file dan petunjuk bahwa dia harus membukanya untuk mendapatkan data pengujian.
Kami akan mengemas semua data ini ke dalam satu file eksternal, yang akan tersedia untuk semua orang di proyek. Misalnya, Anda dapat menggunakan Google Sheet atau Excel dan mengatur pencarian di dalam file. Mengapa vendor khusus ini? Faktanya adalah kami memulai dari paradigma bahwa setiap orang dalam tim harus dapat membuka dan lulus uji kasus tanpa harus menginstal alat apa pun terlebih dahulu.
Untuk Google Sheet Anda dapat menggunakan kueri SQL. Contoh:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Untuk Excel Anda dapat mengatur makro pencarian instan yang nyaman. (menyaring) Contoh .
Sebenarnya idenya bukanlah hal baru dan dijelaskan dalam buku penguji pertama “Testing dot com”. (penulis Savin Roman) Kami baru saja mengintegrasikan metode yang diusulkan oleh Roman Savin ke dalam TestRail. Untuk melakukan ini, buat bidang dengan tautan ke file yang dibuat:
isi nilai default link sehingga setiap test case baru sudah memiliki link:
Jika lokasi file eksternal berubah (kami menyediakan force majeure), maka Anda dapat dengan mudah mengubah satu atau lebih bidang sekaligus di semua kasus pengujian:
Bidang “Deskripsi” (deskripsi atau ide kasus uji, instruksi standar)
Apa yang mungkin Anda perlukan: Di kolom teks ini kami akan menempatkan deskripsi singkat tentang kasus uji dan instruksi standar.
Contoh: Semua data pengujian (tata letak saat ini, penggunaan alat, dan data lainnya) dari kasus pengujian ini ditunjukkan oleh tautan {...} dan terletak di file MovableData. Tautan ke MovableData di bidang terkait di bagian atas.
Tag “Komponen” (komponen aplikasi seluler)
Apa yang mungkin diperlukan: untuk pengujian dampak. Jika aplikasi seluler dapat dibagi menjadi beberapa komponen (yang saling mempengaruhi sesedikit mungkin), maka perubahan pada satu komponen saja sudah cukup (dengan beberapa risiko) untuk diperiksa dalam komponen yang sama, dan akan ada lebih sedikit alasan untuk melaksanakannya. regresi umum dari segalanya. Jika terdapat informasi bahwa suatu komponen dapat mempengaruhi komponen lainnya, maka disusun matriks pengujian dampak.
Contoh komponen: GooglePay, Pesanan, Pengguna, Peta, Otorisasi, dll.
Tag "TAG" (Tag lain untuk pemfilteran)
Memberi tag pada kasus uji dengan tag untuk pemfilteran sewenang-wenang.
Sangat berguna untuk:
-
dengan cepat mengkompilasi TestRun untuk berbagai tugas umum: asap, regresi, dll.
-
apakah tesnya akan otomatis atau sudah otomatis?
-
tag lainnya
Contoh : Smoke, Otomatis, WhiteLabel, ForDelete, dll.
Menyiapkan urutan tampilan bidang dalam kasus uji
Kami telah membuat banyak bidang baru, saatnya mengaturnya dalam urutan yang mudah:
Membuat TestRun
Sekarang kita akan membuat uji coba baru dengan kasus terkini untuk melakukan pengujian asap dalam tiga klik:
Tips bermanfaat lainnya
-
Jika TestRail memiliki beberapa proyek, jangan lupa untuk membuat bidang baru hanya untuk proyek Anda, jika tidak, rekan dari tim tetangga akan sangat terkejut dengan munculnya bidang baru yang tidak biasa. Pingsan lokal mungkin terjadi.
2. Kasus dengan jumlah field yang banyak lebih mudah disalin dari tipe grup yang serupa daripada membuat yang baru:
3. Akun dapat dibagikan. Misalnya: satu administrator, beberapa pengguna.
Kesimpulan
Contoh-contoh yang dijelaskan di atas telah diterapkan pada beberapa proyek dan telah menunjukkan efektivitasnya. Saya harap mereka akan membantu meningkatkan pemahaman Anda tentang alat ini dan membantu Anda membuat “penyimpanan pengujian” yang efektif dan nyaman. Saya akan sangat berterima kasih jika Anda menjelaskan pengalaman Anda menggunakan TestRail dan tips berguna di komentar.
Ссылки:
Buku:
Terima kasih banyak atas perhatiannya!
Sumber: www.habr.com