Rancangan Kasus Testing

10.2. Rancangan Kasus Testing

10.2.1. Komponen Data Kasus Testing

Uji kasus adalah sebuah dokumentasi yang terdiri dari masukan data dan kondisi operasi yang dibutuhkan untuk menjalankan sebuah pengujian bersama dengan hasil yang diharapkan. Tester diharapkan dapat menjalankan program untuk pengujian yang sesuai dengan dokumentasi uji kasus, dan kemudian membandingkan hasil aktualnya dengan hasil yang diharapkan yang telah dicatat dalam dokumen. Jika hasil yang diperoleh sepenuhnya sesuai dengan hasil yang diharapkan, tidak ada kesalahan atau setidaknya telah diidentifikasi. Ketika beberapa atau semua hasil tidak sesuai dengan hasil yang diharapkan, diidentifikasi kesalahan potensial. Metode pembagian kesetaraan kelas, dibahas dalam Bagian 9.5.1, diterapkan untuk mencapai efisien dan efektifitas uji kasus, untuk digunakan untuk pengujian kotak hitam.

Contoh Pertimbangkan uji kasus berikut untuk pajak properti dasar kota tahunan di apartemen. Pajak properti dasar kota (sebelum diskon untuk kelompok-kelompok tertentu dari penduduk kota) didasarkan pada parameter berikut:

S, ukuran apartemen (dalam meter persegi) N, jumlah orang yang tinggal di apartemen

A, B atau C, klasifikasi pinggiran sosial-ekonomi.

Aplikasi dari kasus testing akan menghasilkan salah satu atau lebih dari tipe hasil yang tidak diharapkan sebagai berikut :

 Urutan angka  Alfabet (nama, alamat, dll)  Pesan kesalahan, standar keluaran yang memberikan informasi kepada user tentang kekurangan

data, kesalahan data, kondisi yang tidak diharapkan.

10.2.2. Sumber Kasus Testing

Ada dua sumber dasar untuk kasus uji:  Contoh acak kasus kehidupan nyata. Contohnya:

o Rumah tangga (untuk menguji sistem informasi pajak kota) o Tagihan pengiriman (untuk menguji perangkat lunak penagihan baru) o Catatan kontrol (untuk menguji perangkat lunak baru yang mengontrol pembuatan produksi

tanaman) o Sebuah sampel yang mencatat peristiwa yang akan "dijalankan" sebagai uji kasus (untuk

menguji aplikasi online dari situs Internet, dan untuk aplikasi real-time).  Uji kasus buatan (juga disebut " simulasi uji kasus ") yang disiapkan oleh desainer tes. Jenis ini tidak mengacu pada pelanggan, pengiriman, atau produk tetapi kombinasi dari kondisi sistem operasi dan parameter (didefinisikan oleh satu set data input). Kombinasi ini dirancang untuk mencakup semua operasi perangkat lunak yang dikenal atau setidaknya semua situasi yang diperkirakan sering digunakan atau yang termasuk ke dalam kelas probabilitas kesalahan yang tinggi. Untuk metode kelas ekivalensi, lihat Bagian 9.5.1.

Implikasi menggunakan setiap sumber test case diringkas dan dibandingkan pada Tabel 10.3. Dalam kebanyakan kasus, file uji kasus harus menggabungkan contoh kasus dengan kasus buatan sehingga dapat mengatasi kekurangan satu sumber uji kasus dan untuk meningkatkan efisiensi proses pengujian. Dalam kasus penggabungan file uji kasus, rencana tes sering dilakukan dalam dua tahap: dalam tahap pertama, uji kasus buatan yang digunakan. Setelah koreksi kesalahan terdeteksi, sebuah sampel acak uji kasus digunakan pada tahap kedua.

Tabel 10.3. Perbandingan dari sumber data testing

Keterangan Tipe Sumber Kasus Testing

Buatan/Tiruan Upaya yang dibutuhkan untuk

Random

Upaya besar, parameter dari menyiapkan file

Upaya ringan, khususnya bila

keluaran yang diharapan telah

masing-masing kasus testing harus

diketahui dan tidak memerlukan

ditentukan dan keluaran yang

diharapkan melalui perhitungan Ukuran file testing yang dibutuhkan

perhitungan

Relatif tinggi seperti kebanyakan Relatif kecil dimungkinkan untuk kasus, merujuk pada situasi

menghindari pengulangan dari sederhana yang sering berulang. setiap kombinasi parameter Dalam rangka untuk

tertentu

mendapatkan jumlah yang cukup dari situasi non-standar, sebuah file uji kasus yang relatif besar perlu dikompile

Upaya yang diperlukan untuk

Upaya Tinggi (efisiensi rendah)

Upaya Rendah (efisiensi tinggi) melakukan tes perangkat lunak tes harus dilakukan untuk file uji karena file uji kasus yang Upaya Rendah (efisiensi tinggi) melakukan tes perangkat lunak tes harus dilakukan untuk file uji karena file uji kasus yang

dikompilasi relatif kecil untuk

rendah berasal dari

menghindari pengulangan

repetitiveness kondisi kasus, terutama untuk situasi sederhana

Efektivitas probabilitas deteksi

■ Relatif tinggi karena cakupan kesalahan

■ relatif rendah - kecuali file uji

kasus yang sangat besar - karena yang baik rendahnya persentase parameter kombinasi

■ Cakupan yang baik dari kondisi ■ Tidak ada cakupan dari kondisi error dengan desain file uji kasus

■ kemungkinan kecil untuk

error

mengidentifikasi kesalahan tak

■ Beberapa kemampuan untuk

terduga karena semua uji kasus

mengidentifikasi kesalahan tak

yang dirancang sesuai dengan

terduga untuk situasi tidak

parameter standar

terdaftar

Contoh Bertingkat

Perbaikan substansial dalam efisiensi random sampling uji kasus dicapai dengan menggunakan prosedur sampling yang bertingkat daripada random sampling standar dari seluruh penduduk. Sampling bertingkat memungkinkan kita untuk memecah sampel acak menjadi sub-populasi uji kasus, sehingga mengurangi proporsi mayoritas penduduk "biasa" yang diuji selama meningkatkan proporsi sampling dari populasi kecil dan populasi dengan potensi kesalahan yang tinggi. Metode aplikasi ini meminimalkan jumlah pengulangan pada waktu yang sama yang meningkatkan cakupan dari kondisi yang jarang dan langka.

Sebagai contoh, populasi Garden City sekitar 100 000 rumah tangga terbagi di kota itu sendiri (70%), pinggiran Orange (20%), pinggiran Lemon (7%) dan pinggiran Apple (3%). Pinggiran kota dan kota berbeda secara substansial dalam karakteristik dari rumah mereka dan status sosial-ekonomi. 5% dari rumah tangga, sebagian besar dari mereka penduduk kota, menikmati pengurangan pajak yang melibatkan 40 jenis diskon (cacat, keluarga besar, keluarga single-parent yang berpenghasilan rendah dengan lebih dari enam anak, dll). Awalnya, sampel 0,5% standar telah direncanakan. Kemudian digantikan oleh sampel acak bertingkat berikut:

Uji kasus untuk perangkat lunak yang digunakan kembali

Hal ini sangat umum untuk perangkat lunak yang digunakan kembali untuk memasukkan banyak aplikasi yang tidak diperlukan sistem perangkat lunak yang ada sekarang di samping aplikasi yang diperlukan. Dalam situasi seperti ini, perencana harus mempertimbangkan yang mana modul perangkat lunak yang digunakan kembali yang harus dites. Modul lain dari perangkat lunak yang digunakan kembali tidak akan diuji.