Cause-Effect Graphing Techniques
Caeuse-effect graphing merupakan desain teknik kasus ujicoba yang menyediakan representasi singkat mengenai kondisi logikal dan aksi yang berhubungan. Tekniknya mengikuti 4 tahapan berikut :
Caeuse-effect graphing merupakan desain teknik kasus ujicoba yang menyediakan representasi singkat mengenai kondisi logikal dan aksi yang berhubungan. Tekniknya mengikuti 4 tahapan berikut :
- Causes (kondisi input), dan Effects (aksi) didaftarkan untuk modul dan identifier yang dtujukan untukmasing-masing
- Causes-effect graph (seperti pada gambar dibawah) dibuat
- Graph dikonversikan kedalam tabel keputusan
- Aturan tabel keputusan dikonversikan kedalam kasus uji
Versi sederhana dari simbol
graph cause-effect seperti dibawah ini. Terdapat hubungan causes ci
dengan effects ei. Lainnya merupakan batasan relationship yang dapat
diaplikasikan pada causes maupun effects.
Untuk mengilustrasikan cause-effect graph perhatikan kasus tagihan berikut. Terdapat 4 kasus yang
didefinisikan, yaitu :
1 : residential indicator
2 : commercial indicator
3 : peak consumption 100 kWH
4 : off-peak consumption 100 kWH
Berdasarkan variasi kombinasi dari causes, maka effect berikut dapat terjadi :
101 : Schedule A billing
102 : Schedule B billing
103 : Schedule C billing
Causes-effect graph untuk contoh diatas dapat dilihat pada gambar (2), causes 1, 2, 3, 4 direpresentasikan di sisi kiri graph dan effects 101, 102, 103 direpresentasikan disisi kanan. Secondary causes dibagian tengah (contoh : 11, 12, 13, 14, ...). Dari gambar (2) dapat dibentuk decision table seperti gambar (3).
 |
| gambar 1 : Cause-Effect Graphing |
Untuk mengilustrasikan cause-effect graph perhatikan kasus tagihan berikut. Terdapat 4 kasus yang
didefinisikan, yaitu :
1 : residential indicator
2 : commercial indicator
3 : peak consumption 100 kWH
4 : off-peak consumption 100 kWH
Berdasarkan variasi kombinasi dari causes, maka effect berikut dapat terjadi :
101 : Schedule A billing
102 : Schedule B billing
103 : Schedule C billing
Causes-effect graph untuk contoh diatas dapat dilihat pada gambar (2), causes 1, 2, 3, 4 direpresentasikan di sisi kiri graph dan effects 101, 102, 103 direpresentasikan disisi kanan. Secondary causes dibagian tengah (contoh : 11, 12, 13, 14, ...). Dari gambar (2) dapat dibentuk decision table seperti gambar (3).
 |
| gambar 2 : Cause-Effect Graph |
 |
| Gambar 3 : Decision table |
Comparison Testing
Dalam beberapa situasi (seperti : aircraft avionic, nuclear power plant control) dimana keandalan suatu software amat kritis, beberapa aplikasi sering menggunakan software dan hardware ganda (redundant). Ketika software redundant dibuat, tim pengembangan software lainnya membangun versi independen dari aplikasi dengan menggunakan spesifikasi yang sama. Setiap versi dapat diuji dengan data uji yang sama untuk memastikan seluruhnya menyediakan output yang sama. Kemudian seluruh versi dieksekusi secara paralel dengan perbandingan hasil real-time untuk memastikan konsistensi.
Dianjurkan bahwa versi independen suatu software untuk aplikasi yang amat kritis harus dibuat, walaupun nantinya hanya satu versi saja yang akan digunakan dalam sistem. Versi independen ini merupakan basis dari teknik black box testing yang disebut comparison testing atau back-to-back testing. Ketika multiple implementasi dari spesifikasi yang sama telah diproduksi, kasus uji didesain dengan menggunakan teknik black box yang lain (misalkan equivalence partitioning) disediakan sebagai input untuk setiap versi dari software. Jika setiap outputnya sama, diasumsikan implementasinya benar, jika tidak, setiap versi di periksa untuk menentukan jika kerusakan terdapat pada satu atau lebih versi yang akan bertanggung jawab atas perbedaan tersebut.
Jika setiap spesifikasi dari seluruh versi telah dibuat dalam kesalahan, maka seluruh versi akan merefleksikan kesalahan. Sebagai tambahan, jika setiap versi independent memberikan hasil identik, tetapi salah, ujicoba hasil dan kondisi akan gagal untuk mendeteksi kesalahan.
UJICOBA UNTUK SISTEM REAL TIME
Karakteristik khusus untuk sistem realtime memberikan tantangan tersendiri ketika ujicoba dilaksanakan. Ketergantungannya dengan waktu, sifat alami dari beberapa aplikasi yang tidak sinkron, menambah kesulitan baru dan potensial sebagai elemen untuk ujicoba dengan waktu beragam. Tidak hanya ujicoba whitebox maupun blackbox, tetapi juga ketepatan waktu pengiriman data dan pemrosesan paralel. Contohnya software realtime yang mengontrol mesin fotocopy, yang dapat menerima interupsi dari operator (berupa penekanan tombol ‘RESET’ atau ‘DARKEN’ ) dengan tanpa kesalahan ketika mesin sedang berjalan (‘COPYING’ state). Operator yang sama akan menginterupsi, ketika mesin nberada dalam posisi ‘jamned’.
Sebegai tambahan, keterkaitan antara software real time dengan perangkat keras pendukungnya juga dapat menyebabkan masalah dalam ujicoba. Ujicoba software harus mempertimbangkan kesalahan perangkat keras yang disebabkan karena pemrosesan software. Belum ada uji kasus yang komprehensif yang dikembangkan untuk sistem realtime, tetapi 4 langkah strategi berikut dapat dilaksanakan :
- Task Testing, yaitu dengan mengujicobakan setiap task secara independen. Dalam hal ini metode whitebox dan blckbox testing dapat digunakan untuk menemukan kesalahan logika dan kesalahan fungsional, tetapi untuk kesalahan ketepatan waktu dan prilaku software (timing or behavioral errors), tidak dapat terdeteksi.
- Behavioral Testing, dengan menggunakan model sistem dengan CASE tool, memungkinkan untuk mensimulasikan prilaku sistem realtime dan menentukannya sebagai konsekwensi dari peristiwa eksternal. Aktivitas analisis ini dapat dilaksanakan sebagai dasar untuk desain kasus uji yang diadakan ketika sebuah sistem realtime berhasil dibuat. Dengan menggunakan teknik yang sesuai (seperti equivalence partitioning), event dikategorikan (misalnya : interrupts, control signals, data), misalkan event pada sebuah buah mesin fotocopy dapat berupa interupsi dari user (‘reset counter’), interupsi mekanikal (‘paper jamned’), interupsi sistem (‘toner low’), dan kesalahan bentuk (‘overheated’). Setiap kesalahan yang terjadi diuji secara individual, dan prolaku executable sistem diperiksa. Prilaku software diperiksa untuk menentukan apakah terdeteksi kesalahan prilaku sistem
- Intertask Testing, ketika sebuah kesalahan dari individual task berhasil diisolasi, ujucoba berlanjut kepada kesalahan pada waktu yang terkait. Task yang tidak sinkron yang berkomunikasi dengan task lainnya diuji dengan beberapa data dan pemrosesan untuk menentukan apakah kesalahan antar task akan terjadi. Sebagai tambahan task yang berkomunikasi via antrian pesan atau penyimpanan data, diujikan untuk menemukan kesalahan ukuran penyimpanan
- System Testing, software dan hardware telah disatukan dan diujikan dalam uji sistem sebagai satu kesatuan. Uji ini dilakukan untuk menemukan kesalahan pada software/hardware interface.
Dikarenakan ujicoba software menghabiskan sekitar 40% dari total usaha yang diperlukan untuk sebuah proyek pengembangan software, maka tools tools yang dapat mengurangi waktu uji sangat dibutuhkan. Dengan melihat manfaat potensialnya, maka dibentuklah generasi pertama dari automated test tools. Miller
mendeskripsikannya menjadi beberapa kategori, diantaranya :
- Static Analyzer, program sistem analisis ini mendukung untuk pembuktian dari pernyataan tanpa bukti statis, perintah-perintah yang lemah dalam struktur program dan format.
- Code Auditors, sebuah filter dengan kegunaan khusus yang digunakan untuk memeriksa kualitas software untuk memastikan bahwa software tersebut telah memenuhi standars pengkodean minimum
- Assertion Processors, sistem preprocessor/postprocessor ini digunakan untuk memberitahukan programmer dengan menyediakan klaim, yang disebut assertion, yaitu mengenai suatu perilaku program yang benar-benar ditemukan saat pelaksanaan program riil
- Test File Generators, merupakan pembangun processor, dan dipenuhi dengan definisi awal nilai, file masukan yang serupa untuk program yang sedang diujikan.
- Test Data Generators. merupakan sistem analisis otomatis yang membantu pengguna aplikasi dalam memilih data uji yang menyebabkan program berperilaku khusus
- Test Verifiers, tool ini mengukur cakupan uji internal, terkadang berhubungan dengan uji struktur kontrol dari objek uji, dan melaporkan cakupan nilai untuk para ahli jaminan kualitas
- Test Harnesses. Tools ini mendukung pemrosesan uji coba dengan (1) meng-instal program kandidat dalam lingkungan uji, (2) berikan input data, dan (3) simulasikan dengan menggunakan stubs perilaku dari modul-modul subordinat Output Comparators, tool ini membuatnya sangat memungkinkan untuk membantingkan sekumpulan output dari suatu program dengan sekumpulan output dari proses sebelumnya(yang telah diarsipkan) untuk menentukan perbedaan diantara keduanya
- 1. Symbolic Execution System, tool ini penampilkan ujicoba program dengan menggunakan input aljabar, dari pada nilai data numerik,. Software yang diuji akan menguji satu class data uji dari pada satu kasus uji spesifik. Output yang dihasilkan dalam bentuk aljabar dan dapat dibandingkan dengan output yang diharapkan yang telah ditulis dalam bentuk aljabar
- Environment Simulator, merupakan tool untuk sistem berbasis komputer khusus, yang mampu untuk
- menguji model lingkungan eksternal dari suatu software realtme, dan mensimulasikan kondisi operasi sesungguhnya secara dinamis.
- Data Flow Analyzer, tool ini melacak aliran data yang melewati sistem, dan berusaha untuk menemukan data reference yang belum didefinisikan , peng-indeks-an yang salah, dan kesalahan data terkait lainnya. kembali ke part I
