Inilah yang sebenarnya terjadi dalam proyek saya, dan hari ini saya akan memberi tahu Anda bagaimana Anda dapat mengurangi jumlah kasus uji lebih lanjut tanpa kehilangan kualitas.
Benda uji
Pertama, saya akan ceritakan sedikit tentang produknya. Di Tinkoff, tim kami mengembangkan blok - ini adalah komponen React yang terdiri dari implementasi dan konfigurasi. Implementasinya adalah komponen itu sendiri, yang telah kami kembangkan dan yang dilihat pengguna di browser. Konfigurasinya adalah JSON yang menetapkan parameter dan konten objek ini.
Tugas utama balok adalah menjadi cantik dan ditampilkan dengan cara yang sama untuk pengguna yang berbeda. Pada saat yang sama, pemblokiran dapat berubah secara signifikan dari konfigurasi dan konten.
Misalnya, blok bisa seperti ini - tanpa latar belakang, dengan tombol dan gambar di kanan:
Atau seperti ini - dengan latar belakang, tanpa tombol dan dengan gambar di kiri:
Atau, secara umum, seperti ini - dengan tautan alih-alih tombol dan tanpa daftar di teks:
Semua contoh di atas adalah satu dan blok yang sama yang memiliki satu versi konfigurasi (struktur JSON yang dapat ditangani oleh komponen React khusus ini), tetapi isinya berbeda.
Sirkuit itu sendiri:
{
components: {
background: color,
panel: {
panelProps: {
color: {
style: ['outline', 'color', 'shadow', 'custom'],
background: color
},
size: ['s', 'm', 'l'],
imagePosition: ['left', 'right']
},
title: {
text: text,
size: ['s', 'l'],
htmlTag: ['div', 'b', 'strong', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6']
},
description: {
text: html,
htmlTag: ['div', 'b', 'strong', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6']
},
image: {
alt: text,
title: text,
image: {
src: image,
srcset: [{
src: image,
condition: ['2x', '3x']
}],
webpSrcset: [{
src: image,
condition: ['1x', '2x', '3x']
}]
},
imageAlign: ['top', 'center', 'bottom']
},
button: {
active: boolean,
text: text,
color: {
style: ['primary', 'secondary', 'outline', 'outlineDark', 'outlineLight', 'textLink', 'custom'],
backgroundColor: color
},
onClick: {
action: ['goToLink', 'goToBlock', 'showBlock', 'crossSale', 'callFormEvent'],
nofollow: boolean,
url: url,
targetBlank: boolean,
title: text,
noindex: boolean,
guid: guid,
guidList: [{
guid: guid
}],
formId: guid,
crossSaleUrl: url,
eventName: text
},
htmlTag: ['div', 'b', 'strong', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6']
},
href: url
}
}
}
Blok dengan gambar di sebelah kanan akan memiliki nilai
components.panel.imagePosition = right. Dan blok dengan gambar di sebelah kiri memiliki components.panel.imagePosition = left. Untuk blok dengan tombol - components.button.active = truedan sebagainya. Saya harap prinsipnya jelas. Ini adalah bagaimana semua parameter blok ditetapkan.
Kasus dari kombinasi parameter
Pada artikel ini, saya tidak akan membahas masalah pembuatan versi diagram blok, aturan pengisian konten atau dari mana data berasal. Semua ini adalah topik terpisah yang tidak memengaruhi kompilasi sekumpulan kasus uji. Hal utama yang perlu diketahui: kita memiliki banyak parameter yang memengaruhi komponen kita, dan masing-masing parameter dapat mengambil kumpulan nilainya sendiri.
Untuk contoh di atas, saya memilih blok dengan konfigurasi yang cukup sederhana. Tetapi bahkan di dalamnya, memeriksa semua kombinasi nilai dari semua parameter akan memakan waktu sangat lama, terutama jika Anda harus mempertimbangkan kompatibilitas lintas-browser. Biasanya Pengujian Berpasangan datang untuk menyelamatkan di sini, atau pengujian berpasangan. Banyak artikel telah ditulis tentang dia dan bahkan ada pelatihan . Jika Anda tiba-tiba tidak menemukan - pastikan untuk membaca.
Mari kita perkirakan berapa banyak test case yang akan kita dapatkan saat menerapkannya. Kami memiliki lebih dari 25 parameter, dan beberapa di antaranya mengambil sebanyak 7 dan 9 varian nilai. Ya, Anda dapat mengabaikan sesuatu: misalnya, jika Anda memeriksa tata letak, pedoman tersebut tidak penting bagi Anda. Namun menggunakan Pengujian Berpasangan, Anda masih akan mendapatkan lebih dari 80 kasus pengujian. Dan ini, seperti yang sudah saya tulis, bukanlah blok yang paling rumit dan tanpa memperhitungkan kompatibilitas lintas-browser. Kami sekarang memiliki lebih dari 150 blok, dan jumlahnya terus bertambah, jadi kami tidak mampu menangani begitu banyak kasus jika kami ingin menjaga kecepatan pengujian dan merilis versi baru.
Kasus dari satu parameter
Metode pengujian berpasangan didasarkan pada pernyataan bahwa sebagian besar kerusakan disebabkan oleh interaksi tidak lebih dari dua faktor. Artinya, sebagian besar bug memanifestasikan dirinya baik pada satu nilai parameter, atau pada kombinasi nilai dua parameter. Kami memutuskan untuk mengabaikan bagian kedua dari pernyataan ini dan berasumsi bahwa memeriksa satu parameter masih akan menemukan sebagian besar bug.
Kemudian ternyata untuk pengujian, kita perlu memeriksa setiap nilai dari setiap parameter minimal satu kali. Tetapi pada saat yang sama, setiap blok membawa seluruh konfigurasi. Kemudian, dalam setiap kasus baru, Anda dapat memeriksa nilai maksimum yang belum diverifikasi untuk meminimalkan jumlah kasus.
Mari menganalisis algoritme untuk membuat kasus menggunakan contoh yang disederhanakan. Mari kita ambil komponen tombol dari skema kita dan buat kasus uji untuk itu:
button: {
active: boolean,
text: text,
color: {
style: ['primary', 'secondary', 'outline', 'custom'],
backgroundColor: color
}
Untuk menyederhanakan contoh, saya telah mengurangi panjang daftar menjadi
button.color.style.
Langkah 1. Buat opsi konten untuk setiap bidang
Semuanya di sini seperti dalam pengujian berpasangan: Anda perlu memahami nilai apa yang dapat diambil masing-masing bidang. Misalnya,
button.activedalam kasus kami, mungkin hanya ada dua nilai: trueatau false. Secara teoritis, lebih banyak opsi mungkin muncul, misalnya, undefinedtidak adanya kunci itu sendiri.
Di sini, menurut pendapat saya, penting untuk mendefinisikan dengan sangat jelas batasan dan fungsionalitas sistem Anda dan tidak memeriksa hal-hal yang tidak perlu. Artinya, jika pemeriksaan kunci wajib atau validasi nilai diterapkan di sistem pihak ketiga, maka fungsi ini perlu diperiksa di sistem pihak ketiga. Dan kita sebaiknya hanya menggunakan data yang "benar" sebagai kasus.
Pada umumnya, prinsip yang sama digunakan dalam piramida pengujian. Jika diinginkan, pengujian integrasi yang paling penting dapat ditambahkan kepada kami - misalnya, untuk memeriksa pemrosesan kunci yang belum tiba. Tetapi harus ada jumlah minimum tes semacam itu. Pendekatan lain adalah mengejar pengujian lengkap, yang, seperti yang diketahui semua orang, tidak mungkin.
Jadi, kami telah mengidentifikasi opsi konten untuk setiap bidang dan membuat tabel berikut:
Tabel ini mencakup setiap kelas ekivalensi dari setiap parameter, tetapi hanya sekali.
Ini adalah kelas nilai dalam kasus kami, kelas:
- text_s - string pendek;
- text_m - string yang lebih panjang;
- no_color - tanpa warna;
- rnd_color adalah warna apa saja.
Langkah 2. Memperkaya tabel dengan data
Karena setiap blok membawa konfigurasi penuh, kita perlu menambahkan beberapa data yang relevan ke sel kosong:
Sekarang setiap kolom adalah satu kasus.
Pada saat yang sama, karena kami memilih sendiri data yang hilang, kami dapat membuat kasus berdasarkan prioritas. Misalnya, jika kita mengetahui bahwa teks pendek lebih sering digunakan pada tombol daripada teks berukuran sedang, ada baiknya kita lebih sering memeriksanya.
Pada contoh di atas, Anda juga dapat memperhatikan kasus "drop" - kasus di mana beberapa parameter tidak dicentang sama sekali, meskipun ada di tabel. Dalam hal ini,
button.color.style: secondarytidak akan diperiksa penampilan, karena tidak masalah gaya apa yang dimiliki tombol yang dinonaktifkan.
Untuk mencegah kasus "dihilangkan" yang mengarah ke bug, kami biasa menganalisis kumpulan nilai yang dihasilkan. Analisis dilakukan satu kali saat membuat kasus uji, dan semua kasus "dibatalkan" ditambahkan secara manual ke kasus uji akhir. Solusi semacam itu untuk masalah ini agak kikuk, tetapi murah (kecuali, tentu saja, Anda jarang mengubah konfigurasi objek yang diuji).
Solusi yang lebih umum adalah dengan membagi semua nilai menjadi dua kelompok:
- nilai yang tidak aman (nilai yang dapat menyebabkan "hilangnya" kasus);
- aman (yang tidak dapat menyebabkan "jatuh").
Setiap nilai yang tidak aman diperiksa dalam kasus pengujiannya sendiri, Anda dapat memperkaya kasus dengan data yang aman. Untuk nilai yang aman, tabel disusun sesuai dengan instruksi di atas.
Langkah 3. Memperjelas nilai
Sekarang yang tersisa hanyalah menghasilkan nilai konkret daripada kelas kesetaraan.
Di sini, setiap proyek harus memilih varian nilainya sendiri, berdasarkan karakteristik objek yang diuji. Beberapa nilai sangat mudah dibuat. Misalnya, Anda dapat mengambil warna apa saja untuk sebagian besar bidang. Untuk beberapa blok, saat memeriksa warnanya, Anda harus menambahkan gradien, tetapi dipindahkan ke kelas ekivalensi yang terpisah.
Dengan teks, ini sedikit lebih rumit: jika Anda membuat string dari karakter acak, maka tanda hubung, daftar, tag, spasi tidak putus tidak akan diuji. Kami menghasilkan panjang baris pendek dan sedang dari teks asli, memangkasnya ke jumlah karakter yang diinginkan. Dan di teks panjang kami memeriksa:
- html tag (salah satu);
- tautan;
- daftar tak bernomor.
Serangkaian kasus ini berasal langsung dari implementasi blok kami. Misalnya, semua tag html disertakan bersama, jadi tidak ada gunanya menguji setiap tag. Dalam hal ini, tautan dan daftar diperiksa secara terpisah, karena keduanya memiliki pemrosesan visual yang terpisah (menyorot pada hover dan shootout).
Ternyata untuk setiap proyek Anda perlu membuat kumpulan konten Anda sendiri berdasarkan implementasi objek yang diuji.
Algoritma
Tentu saja, pada pandangan pertama mungkin tampak bahwa algoritmanya rumit dan tidak sepadan dengan usaha. Tetapi jika Anda menghilangkan semua detail dan pengecualian yang saya coba gambarkan di setiap paragraf di atas, ternyata cukup sederhana.
Langkah 1. Tambahkan semua nilai yang mungkin ke tabel parameter:
Langkah 2. Nilai duplikat ke dalam sel kosong:
Langkah 3. Ubah nilai abstrak menjadi nilai konkret dan dapatkan kasus:
Setiap kolom tabel adalah satu kasus.
Keuntungan dari pendekatan ini
Metode menghasilkan kasus uji ini memiliki beberapa keuntungan penting.
Lebih sedikit kasus
Pertama dan terpenting, terdapat lebih sedikit kasus dibandingkan pengujian berpasangan. Jika kita mengambil contoh yang disederhanakan dengan sebuah tombol, kita mendapatkan 4 case, bukan 8 dalam pengujian berpasangan.
Semakin banyak parameter yang ada dalam objek yang diuji, semakin signifikan penghematan kasing. Misalnya, untuk blok penuh yang disajikan di awal artikel, kami mendapatkan 11 kasus, dan dengan bantuan pairwise - 260.
Jumlah kasus tidak meningkat ketika fungsinya menjadi lebih kompleks
Kelebihan kedua adalah ketika parameter baru diperhitungkan selama pengujian, jumlah kasus tidak selalu meningkat.
Misalnya, sebuah parameter
button.color.textColordengan kelas kesetaraan nilai no_colordan ditambahkan ke tombol kita rnd_color. Kemudian 4 kasus akan tersisa, hanya satu parameter lagi yang akan ditambahkan ke masing-masing:
Jumlah kasus akan meningkat hanya jika beberapa parameter memiliki nilai lebih dari jumlah kasus.
Anda dapat lebih sering memeriksa yang penting
Dengan memperkaya nilai (langkah 2 dalam algoritme), prioritas yang lebih tinggi atau nilai yang lebih berisiko dapat lebih sering diperiksa.
Misalnya, jika kita tahu bahwa pengguna sebelumnya lebih sering menggunakan teks yang lebih pendek, dan sekarang mereka menggunakan teks yang lebih panjang, kita dapat memperkaya kasus dengan teks yang lebih panjang dan lebih sering masuk ke kasus pengguna yang sebenarnya.
Bisa otomatis
Algoritme di atas cukup setuju dengan otomatisasi. Tentu saja, kasing yang dihasilkan oleh algoritme tidak akan terlihat seperti kasing asli daripada kasing yang dibuat oleh manusia. Setidaknya dengan mencocokkan warna dan memotong teks.
Tetapi di sisi lain, sudah dalam proses pengembangan tanpa partisipasi penguji, kasus muncul, yang sangat mengurangi putaran umpan balik.
kerugian
Secara alami, pembuatan casing seperti itu jauh dari peluru perak dan memiliki kekurangan.
Kesulitan menganalisis hasil
Saya rasa Anda memperhatikan bahwa dalam proses menghasilkan kasus, data pengujian dicampur satu sama lain. Karena itu, ketika kasusnya jatuh, menjadi lebih sulit untuk mengidentifikasi penyebab jatuhnya. Bagaimanapun, beberapa parameter yang digunakan dalam kasus ini sama sekali tidak mempengaruhi hasil tes.
Ini sangat menyulitkan untuk mengurai hasil tes, di satu sisi. Namun, di sisi lain, jika objek yang diuji membutuhkan sejumlah besar parameter yang dibutuhkan, hal ini juga menyulitkan untuk menemukan penyebab bug.
Bug mungkin terlewat
Kembali ke awal artikel: saat menggunakan metode ini, kami mengizinkan kemungkinan melewatkan bug yang disebabkan oleh kombinasi dua parameter atau lebih. Tapi kami menang dalam kecepatan, jadi terserah Anda untuk memutuskan mana yang lebih penting untuk setiap proyek tertentu.
Agar tidak ketinggalan bug dua kali, kami memperkenalkan Kebijakan Bug Nol dan mulai menutup setiap bug yang terlewat dengan kasus uji tambahan - tidak lagi dibuat secara otomatis, tetapi ditulis dengan tangan. Ini memberikan hasil yang sangat baik: sekarang kami memiliki lebih dari 150 blok (objek yang diuji), beberapa rilis per hari dan dari 0 hingga 3 bug non-kritis yang terlewat per bulan.
kesimpulan
Jika objek yang diuji memiliki berbagai parameter masukan dan Anda ingin mencoba mengurangi jumlah kasus dan, sebagai hasilnya, waktu untuk pengujian, saya sarankan mencoba metode di atas untuk menghasilkan kasus menggunakan satu parameter.
Menurut pendapat saya, ini ideal untuk komponen front-end: Anda dapat mengurangi waktu lebih dari tiga kali, misalnya, untuk memeriksa tampilan melalui pengujian tangkapan layar. Dan perkembangannya akan lebih cepat karena munculnya kasus pada tahap paling awal.
Tentu saja, jika Anda menguji autopilot Tesla baru, Anda tidak dapat mengabaikan bahkan kemungkinan kecil untuk melewatkan bug. Namun dalam banyak kasus, jangan lupa bahwa kecepatan di dunia modern adalah kriteria kualitas yang sangat penting. Dan peningkatan kecepatan memberikan hasil yang lebih positif daripada beberapa masalah kecil yang ditemukan.
Dan untuk yang paling bertanggung jawab, di artikel berikutnya saya akan memberi tahu Anda bagaimana Anda juga dapat melindungi diri Anda dari bug rumit yang disebabkan oleh kombinasi parameter menggunakan kasus khusus dan StoryBook.