Cleanroom Testing

8.3 Cleanroom Testing

Strategi dan taktik clean room testing secara mendasar berbeda dengan pendekatan testing konvensional. Metode konvensional menarik serangkaian test case untuk mengungkap kesalahan pengkodean dan desain. Tujuan clean room testing adalah untuk memvalidasi persyaratan software dengan memperlihatkan bahwa suatu sampel statistik dari kasus-kasus penggunaan telah dieksekusi dengan baik. Tidak seperti testing konvensional, rekayasa

software dengan metode cleanroom tidak menekankan pada unit testing atau integration testing . Tetapi software lebih diuji dengan menentukan skenario penggunaan, dengan menentukan probabilitas penggunaan untuk setiap skenario, dan kemudian menetapkan tes acak yang sesuai dengan probabilitas tersebut. Kesalahan mencatat bahwa hasil software dengan metode cleanroom tidak menekankan pada unit testing atau integration testing . Tetapi software lebih diuji dengan menentukan skenario penggunaan, dengan menentukan probabilitas penggunaan untuk setiap skenario, dan kemudian menetapkan tes acak yang sesuai dengan probabilitas tersebut. Kesalahan mencatat bahwa hasil

kea daan dan operasi. Clearbox d igunakan untuk memodelkan desain prosedural yang diim plikasikan oleh data dan op erasi dari suatu state box . Verifikasi kebenaran diaplikasikan beg itu desain stru ktur kotak dilengkapi. Desain prosedural untuk suatu komponen software dipa rtisi ke dalam sedere tan subfungsi. Untuk membuktikan kebenaran masing-masing subfungsi, kondisi exit didefinisikan untuk setiap fungsi dan serangkaian subproof diap likasikan. Bila masing-ma sing kondisi exit dipenuhi, maka desain pasti benar. Sekali veri fikasi kebenaran lengkap, ma ka testing menggunakan statistik pun dimulai. Filo sofi cleanroom merupakan pendekatan yang teliti ke rekayasa By Hendranet software . Cleanroom mer upakan model proses software yang menekankan verifikasi matematis dari kebenaran dan sertifikasi da ri reliabilitas software . Garis di bagian bawah merupakan tingkat kegagalan yan g sangat ren dah, yang sangat sulit atau tidak mungkin dicapai dengan menggunakan mod el formal yang lebih sedikit.

8.3.1 Testing menggunakan statistik

Pengguna program komputer jarang merasa perlu memahami detail teknik dari desain. Ting kah laku pro gram yang tampak oleh pengguna dikendalikan oleh masukan dan event yan g sering dihasilkan oleh pengguna. Tetapi dalam sistem yang komplek, spektrum dari mas ukan dan e vent yang mungkin (misalnya, use cases ) dapat menjadi sangat luas. Subset apa dari use cases yan g akan secara memadai memverifikasi tingkah laku program? Itulah pert anyaan pertama yang d ilontarkan oleh pengujian menggunakan statistik. Testing menggunakan statistik adalah “ software berlaku sama dengan yang dimaksudkan oleh pengguna” [LIN94A]. Untuk melakukannya, tim clean room testing (disebut juga tim

spe sifikasi) harus menentukan distribusi probabillitas penggunaan untuk softaware tersebut. Spe sifikasi ( black box ) untuk masing-masing inkremen software dianalisis untuk menentukan sera ngkaian stimulus (mas ukan atau event ) yang menyebabkan software mengubah tingkah spe sifikasi) harus menentukan distribusi probabillitas penggunaan untuk softaware tersebut. Spe sifikasi ( black box ) untuk masing-masing inkremen software dianalisis untuk menentukan sera ngkaian stimulus (mas ukan atau event ) yang menyebabkan software mengubah tingkah

Stimulus program

Distribusi

Interval

Arm/disarm (AD)

1-49

Zone set (ZS)

50-63

Query (Q)

64-78

Test (T)

79-94

Panic alarm (PA)

95-99

Untuk memunculkan urutan test case penggunaan yang sesuai dengan distribusi probabilitas penggunaan, sederetan nomor acak dimunculkan antara 1 dan 99. Nomor acak tersebut berh ubungan dengan interval pada distribusi probabilitas (lihat tabel di atas). Dengan

dem ikian, urutan kasus-kasus penggunaan ditentukan se cara acak tetapi sesuai dengan By Hendranet

probabilitas kejadian stimulus yang sesuai. Sebagai contoh, diasumsikan urutan bilangan ran dom berikut ini:

13-94-22-24-45-56 81-19-31-69-45-9 38-21-52-84-86-97

Den gan memilih stimulus yang sesuai berdasarkan interval distribusi yang diperlihatkan pada tabel di atas, diperoleh use cases sebagai berikut:

AD-T-AD-AD-AD-ZS T-AD-AD-AD-Q-AD-AD AD-AD-ZS-T-T-PA

Tim testing mengeksekusi use case tersebut (dan lainnya) dan memverifikasi tingkah laku soft ware terhadap spesifikasi sistem. Timing untuk testing direkam sehingga waktu interval dap at ditentukan. Dengan mengg unakan waktu interval, tim sertifikasi dapat menghitung mean-time-failure. Bila sederetan panjang testing dilakukan tanpa kegagalan, maka MTTF

rendah dan reliabilitas perangkat lunak dapat diasumsikan tinggi.

8.3.2 Sertifikasi

Verifikasi dan teknik testing yang telah dibahas pada bab ini membawa kepada komponen software (dan keseluruhan inkremen) yang dapat disertifikasi. Dalam konteks pendekatan rekayasa software dengan metode cleanroom , sertifikasi mengimplikasikan bahwa reliabilitas (yang diukur dengan mean-time-failure , MTTF) dapat ditetapkan untuk masing-masing komponen. Pengaruh potensial dari komponen software yang dapat disertifikasi melebihi proyek

cleanroom tunggal. Komponen software reusable dapat disimpan bersama dengan skenario penggunanya, stimulus program, dan distribusi probabilitas. Masing-masing komponen akan memiliki reliabilitas yang disertifikasi di bawah skenario penggunaan dan testing yang digambarkan. Informasi ini tidak ternilai harganya bagi orang lain yang bermaksud menggunakan komponen-komponen tersebut. Pendekatan sertifikasi meliputi lima langkah [WOH94]:

1. Skenario penggunaan harus diciptak an.

2. Profil penggunaan ditentukan.

3. Test case dimunculkan dari struktur profil tersebut.

4. Testing dieksekusi dan data kegagalan direkam dan dianalisis.

5. Reliabilitas dihitung dan disetifikasi. Langkah 1 sampai 4 telah dibicarakan. Pada subbab ini kita akan berkonsentrasi pada sertifikasi reliabilitas. Perlu membuat tiga model untuk sertifikasi rekayasa software dengan metode cleanroom [POO93]:

By Hendranet

Model sampling . Testing software mengeksekusi end test case rando m dan disertifikasi bila tidak ada kegagalan atau jumlah kegagalan kurang dari jumlah yang ditentukan. Harga m ditarik secara sistematis untuk memastikan bahwa reliabilitas yang diperlukan telah tercapai. Model komponen . Sistem yang terdiri dari n komponen akan disertifikasi. Model komponen memungkinkan analis menentukan probabillitas bahwa komponen ini akan gagal sebelum penyelesaian. Model sertifikasi . Keseluruhan reliabilita s sistem diproyeksikan dan disertifikasi. Setelah testing menggunakan stati stik selesai dilakukan, tim sertifikasi memiliki informasi yang diperlukan untuk penyampaia n software yang memiliki MTTF sertifikasi yang dihitung dengan menggunakan masing-masing model tersebut. Diskusi lengkap mengenai komputasi sampling, model, komponen, dan sertifikasi tidak tercakup dalam lingkup buku ini. Pembaca yang tertarik dapat melihat [MUS87], [CUR86], dan [POO93] untuk memperoleh penjelasan tambahan.