OO Software TestingDikompilasi oleh Dana dari berbagi sumber

Definisi Software TestingSoftware testing adalah aktivitas-aktivitas yang bertujuan untuk mengevaluasi atribut-atribut atau kemampuan sebuah program atau sistem dan penentuan apakah sesuai dengan hasil yang diharapkan [Hetzel88] Testing adalah proses pemeriksaan program dengan tujuan tertentu dalam menemukan kesalahan sebelum diserahkan ke pengguna

Verification:Apakah kita membangun produk dengan benar?Software seharusnya sesuai dengan spesifikasinya. Gunakan proses software yang bagus.Validation:Apakah kita membangun produk yang benar?Software seharusnya melakukan apa yang pengguna benar-benar butuhkanVerification vs. validation

Dapat menunjukan keberadaan kesalahan tapi BUKAN ketidakadaan kesalahan yang lainTest yang sukses adalah sebuah test yang menemukan satu atau lebih kesalahanSeharusnya digunakan bersama dengan verification statik untuk memberikan V&V sepenuhnyaProgram testing

Adalah proses yang berbedaVerification and validation: menunjukkan keberadaan cacat programDebugging: menemukan dan memperbaiki kecacatan-kecacatan iniTesting and debugging

Tujuan Dilakukan Software TestingUntuk meningkatkan kualitasUntuk Verification & Validation (V&V) Untuk estimasi reliability [Kaner93] [Lyu95]

Melakukan testing berarti melakukan Mendesain test.Mengimplementasikan test yang telah didesign. Mengevaluasi test tersebut.

Exhaustive Testingloop < 20 XTerdapat kemungkinan 1014 jalur eksekusi! Jika kita mengeksekusi satu test per millisecond, maka dibutuhkan 3.170 tahun untuk men-test program ini

Selective Testingloop < 20 XJalur eksekusi yang dipilih

Tahapan TestingPre-Implementation TestingPost implementation (Code Testing)Metode pengembangan software apapun yang digunakan, penguji bisa menggunakan dua teknik testing:White BoxBlack Box

White-Box Testing. Tujuan kita adalah menjamin semua statemen dan kondisi telah dieksekusi minimal sekali ..

Black-Box Testingrequirementseventsinputoutput

Strategi OO Testing[1]

Strategi OO Testing[2]Unit Testing Pengujian class/objectIntegration Testing object integration testingSystem Testing

Pengujian class/objectEncapsulated state Memeriksa interaksi method-method dengan data obyekInteraksi antar method Memeriksa interaksi method-method dari sebuah obyekPewarisan dan polimorfisme

Unit Testing[1]Tahapan testing yang paling awal. Tahap selanjutnya terdiri dari integration testing dan system testingBiasanya unit didefinisikan sebagai:Suatu fungsi atau prosedur tunggal yang kohesifSegmen terkecil dari kode program yang bisa dikompile secara terpisah.Sebuah fungsi yang pas pada suatu halaman tunggal.Kode yang bisa ditulis oleh seseorang dalam suatu kurun waktu.Definisi yang biasa dipakai yaitu definisi pada point pertama.

Unit Testing[2]Input untuk proses test planning terdiri dari requirement dan detailed design. Output dari proses test planning adalah unit test plan. Tahap selanjutnya adalah akuisisi data input dan output yang berasosiasi dengan masing-masing test. Hasil dari tahap ini dinamakan test set.Test di eksekusi.

Unit Testing[3]( IEEE )

Pengujian Method[1]Memverifikasi operasi pada nilai normal parameter (sebuah black box test yang berdasarkan pada kebutuhan unit)Memverifikasi operasi pada nilai limit parameter (black box)Memverifikasi operasi nilai diluar batas nilai parameter (black box)Memastikan bahwa semua instruksi di eksekusi (statement coverage)Cek semua path, termasuk semua cabang (decision coverage)Cek semua penggunaan object yang dipanggilMemverifikasi penanganan dari semua struktur data

Pengujian Method[2]Memverifikasi penanganan semua fileCek terminasi normal dari semua loop ( part of correctness proof)Cek terminasi abnormal dari semua loopCek terminasi normal dari semua rekursifCek terminasi abnormal dari semua rekursifMemverifikasi penanganan semua kondisi errorCek timing dan sinkronisasiverifikasi semua ketergantungan hardware

Class TestingKombinasikan penggunaan methodbiasanya 2-5pilih rangkaian pertama yang paling umummasukan rangkaian yang mungkin menyebabkan errorFokuskan unit test pada masing-masing atributinisialisasi, lalu eksekusi rangkaian method yang dipengaruhinyaVerifikasi masing-masing invariant class tidak berubahVerifikasi object transisi diantara state-state yang ada.Rencanakan rangkaian state/transisisiSet up object dalam inisial state dengan menyeting variableSediakan event pertama dan cek transisi yang terjadi

Pengujian integrasi objectMenguji unit yang telah diuji secara tunggal bekerja secara baik pula setelah digabungkan pada sistemMereka akan digabungkan ke dalam suatu grup logis yang koheren untuk diuji kembali( subsistem )Saat subsistem tersebut berhasil bekerja dengan baik maka akan dilanjutkan dengan menggabungkannya dengan subsistem yang lain dan seterusnya sampai membentuk suatu sistem utuh yang terujiHal yang diperhatikan yaitu memeriksa semua unit apakah bekerja bersama dengan baik. Penguji lebih mengkonsentrasikan pada interaksi unit daripada fungsionalitasnya

Merancang dan Melakukan Integration TestingPutuskan bagaimana dan dimana untuk menyimpan, menggunakan kembali dan mengkodekan integration testtunjukan dalam project schedule Ekesekusi unit-unit test sebanyak mungin sesuai dengan waktu yang tersediaGunakan test regresi Pastikan kebutuhan pembangunan telah dispesifikasikan.Gunakan use case yang harus diimplementasikanEksekusi system test

Artifact yang terlibat dalam proses integration testuse case model :Kumpulan use case yang menggambarkan penggunaan typical dari aplikasi, dan sequence diagram test cases : input untuk setiap testtest procedure : cara bagaimana test di set up, dieksekusi, dan dievaluasi(hasil). Dapat berupa prosedur manual ataupun menggunakan tools untuk test otomasitest evaluation : kesimpulan, detail dan effect dari error yang ditemukantest plan : Rencana keseluruhan testtest component : source code untuk test itu sendiri serta untuk code aplikasi yang akan di test defect (kerusakan) : laporan untuk setiap defect/error yang ditemukan, diklasifikasikan berdasarkan type dan tingkat peliknya kerusakan

Tahapan System Testing[1]Memeriksa apakah sistem sudah berlaku dengan benar atau belum saat digunakan oleh user.Memperkirakan apakah sistem dapat menanggulangi segala kondisi dan data mainstream.Memeriksa performansi behaviour dari sistem. Misal berapa lama waktu yang diperlukan sistem untuk mengerjakan suatu tugas yang diberikan.Menguji volume, stress dan storage untuk meeriksa performance dibawah kondisi ekstrim seperti jumlah input yang besar, high speed input, jumlah user yang banyak serta meningkatnya jumlah aktivitas secara tiba-tiba.

Tahapan System Testing[1]Semua perhitungan diperiksa ketepatannya dengan data dan kondisi yang telah diperkirakan maupun tidak.Menguji error handling dan recovery dari sistem seperti memeriksa bahwa akan keluar pesan error yang tepat pada setiap kondisi dan pemulihan yang baik setelah sistem mengalami fatal errror.Memeriksa kelayakan tingkat keamanan pada sistem agar user yang tidak berwenang tidak dapat memperoleh akses ke sistem.

Tipe-tipe system testing[1]volume : memfokuskan untuk input yang besarusability : mengukur reaksi user ( skala 1-10)performance : mengukur kecepatan pada beberapa keadaanconfigurasi : mengkonfogurasi untuk bermacam-macam hardware atau softwarecompatibility : komplabiliti dengan aplikasi lain ( contoh: mengukur waktu adaptasi)reliability/availability : mengukur ketahanan pada periode waktu yang lama

Tipe-tipe system testing[2]securityresource usage : mengukur penggunaan RAM, ruang disk, dllinstallability : di install pada bermacam-macam keadaan (mengukur waktu install)recoverability : mengukur waktu untuk me-recoverserviceability : mengukur waktu serviceload/stress: untuk data extreme dan traffic

Tipe-Tipe Testing lainnyaRegression TestingAcceptance Testing by user or a testing teamBeta TestingRelease testing

Regression TestingTerlalu sering memperbaiki kesalahan-kesalahan software memacu pada kesalahan-kesalahan baruSeorang programmer yang bijak memperbaiki suatu kesalahan pada program ia akan melaksanakan semua kasus uji dan dan memeriksa hasilnya apakah program tersebut masih menghasilkan hasil yang sama

Acceptance Testing by user or a testing teamAcceptance test dilakukan oleh customer setelah suatu software dipasarkan. Biasanya tes ini adalah sekumpulan formal tes yang dilakukan untuk mengetahui apakah sistem tersebut sesuai dengan kriteria penerimaan customerAcceptance test sering dilakukan diawal agar para programmer atau developer team bisa melakukannya sebelum secara formal memasarkan software tersebut

Beta TestingJika sebuah produk software akan dibangun untuk konsumsi publik maka diuji terlebih dahulu oleh orang luar sebelum akhirnya direlease. Beta testing dilakukan oleh sekumpulan orang yang merepresentasikan suatu tipe user yang akan mempergunakan software yang sedang dibangun. Peran mereka yaitu untuk memberikan feedback dari pengalaman mereka memakai produk tersebut dalam lingkungan kerja.

Release testingRelease testing adalah pengujian kelayakan suatu produk agar dapat dipasarkan keluar. Apakah semua disk atau CD sudah berisi file-file yang benar, apakah file-file yang digunakan sudah pada versi yang benar, apakah disk dan CDnya bebas dari virus dan terdapat dokumentasi yang lengkap didalamnya. Penguji akan melaksanakan pengujian tingkat tinggi terhadap apakah software telah melakukan apa yang telah diminta dengan membandingkan software, dokumentasi kebutuhan, materi marketing dan dokumentasi user.

Siapa yang melakukan testing?Orang yang melakukan pengujian akan bergantung pada tahap yang sedang dilakukan dan sumber yang dialokasikan untuk menguji produk software tertentu, yakni :ProgrammerTim pengujiBeta tester(Group yang mewakili pasar)CustomerMaintainer

Standar ANSI/IEEE untuk test dokumentasi[]introductiontest plan : item dalam test,ruang lingkup, pendekatan, resource, jadwal, personeltest design: item yang ditest, pendekatan, rencana detailtest case : kumpulan input dan eventtest procedures : langkah-langkah untuk menyeting dan mengeksekusi test case

Standar ANSI/IEEE untuk test dokumentasi[]test item transmittal report : item-item dalam test, lokasi fisik dari hasil, orang yang bertanggung jawab untuk transmittingtest log : kronologi record, lokasi fisik dari hasil, nama pengujitest incident report : dokumentasi dari setiap event yang terjadi selama test, yang membutuhkan investigasi lebih lanjuttest summary report : kesimpulan-kesimpulan dari keseluruhan point-point di atas

Testing Tools[1]Testing bervolume besar biasanya membutuhkan penggunaan tool-tool otomatis. Jacobson menyarankan bahwa 75% dari test lebih baik dilakukan secara otomatis daripada dilakukan secara manual. Kemampuan dari tools otomatis system test:merekam aksi mouse dan keyboard untuk memungkinkan pengulangan pemutaran kembalijalankan test script secara berulang-ulangmemungkinkan untuk merekam hasil test

Testing Tools[2]merekam waktu eksekusimerekam run time errormembuat dan mengatur regression testmenghasilkan test reportmenghasilkan test datamerekam penggunaan memorymengatur/mengelola test caseanalisa keseluruhan

Daftar PustakaBritton, Carol dan Doake, Jill, Object Oriented System Development: A gentle Introduction , Singapore: McGraw-Hill, Inc., 2001 Braude, Eric J.,Software Engineering: An Object Oriented Perspective, United State of America: John Wiley & Sons,Inc., 2000Bahrami, Ali, Object Oriented System Development, Singapore: McGraw-Hill, Inc., 1999Pressman, Roger S.,The 5th edition of Software Engineering: A Practitioner's Approach,McGraw-Hill.Sommerville, Ian, Software Engineering, 6th edition, Pearson Education, 2001http://www.cetus-links.org/oo_testing.htmlhttp://www.testing.com/writings/1-fault.htmhttp://www.rbsc.com/pages/who_who.html

**The fact is that NOTHING, not inspection, not formal proof, not testing, can give 100% certainty of no errors*To improve quality. As computers and software are used in critical applications, the outcome of a bug can be severe. Bugs can cause huge losses. Bugs in critical systems have caused airplane crashes, allowed space shuttle missions to go awry, halted trading on the stock market, and worse. Bugs can kill. Bugs can cause disasters. The so-called year 2000 (Y2K) bug has given birth to a cottage industry of consultants and programming tools dedicated to making sure the modern world doesn't come to a screeching halt on the first day of the next century. [Bugs] In a computerized embedded world, the quality and reliability of software is a matter of life and death. Quality means the conformance to the specified design requirement. Being correct, the minimum requirement of quality, means performing as required under specified circumstances. Debugging, a narrow view of software testing, is performed heavily to find out design defects by the programmer. The imperfection of human nature makes it almost impossible to make a moderately complex program correct the first time. Finding the problems and get them fixed [Kaner93], is the purpose of debugging in programming phase. For Verification & Validation (V&V) Just as topic Verification and Validation indicated, another important purpose of testing is verification and validation (V&V). Testing can serve as metrics. It is heavily used as a tool in the V&V process. Testers can make claims based on interpretations of the testing results, which either the product works under certain situations, or it does not work. We can also compare the quality among different products under the same specification, based on results from the same test. We can not test quality directly, but we can test related factors to make quality visible. Quality has three sets of factors -- functionality, engineering, and adaptability. These three sets of factors can be thought of as dimensions in the software quality space. Each dimension may be broken down into its component factors and considerations at successively lower levels of detail. Table 1 illustrates some of the most frequently cited quality considerations. Functionality (exterior quality) Engineering (interior quality) Adaptability (future quality) Correctness Efficiency Flexibility Reliability Testability Reusability Usability Documentation Maintainability Integrity Structure Table 1. Typical Software Quality Factors [Hetzel88] Good testing provides measures for all relevant factors. The importance of any particular factor varies from application to application. Any system where human lives are at stake must place extreme emphasis on reliability and integrity. In the typical business system usability and maintainability are the key factors, while for a one-time scientific program neither may be significant. Our testing, to be fully effective, must be geared to measuring each relevant factor and thus forcing quality to become tangible and visible. [Hetzel88] Tests with the purpose of validating the product works are named clean tests, or positive tests. The drawbacks are that it can only validate that the software works for the specified test cases. A finite number of tests can not validate that the software works for all situations. On the contrary, only one failed test is sufficient enough to show that the software does not work. Dirty tests, or negative tests, refers to the tests aiming at breaking the software, or showing that it does not work. A piece of software must have sufficient exception handling capabilities to survive a significant level of dirty tests. A testable design is a design that can be easily validated, falsified and maintained. Because testing is a rigorous effort and requires significant time and cost, design for testability is also an important design rule for software development. For reliability estimation [Kaner93] [Lyu95] Software reliability has important relations with many aspects of software, including the structure, and the amount of testing it has been subjected to. Based on an operational profile (an estimate of the relative frequency of use of various inputs to the program [Lyu95]), testing can serve as a statistical sampling method to gain failure data for reliability estimation. Software testing is not mature. It still remains an art, because we still cannot make it a science. We are still using the same testing techniques invented 20-30 years ago, some of which are crafted methods or heuristics rather than good engineering methods. Software testing can be costly, but not testing software is even more expensive, especially in places that human lives are at stake. Solving the software-testing problem is no easier than solving the Turing halting problem. We can never be sure that a piece of software is correct. We can never be sure that the specifications are correct. No verification system can verify every correct program. We can never be certain that a verification system is correct either.

*Design test sangat penting untuk efektivitas, sedangkan mengimplementasikan test penting untuk efesiensi, dan mengevaluasi test dapat meningkatkan efektivitas.

*Pre-Implementation TestingPengujian software bisa dan harus dilakukan selama proses pembangunan sofware. Pada tahap-tahap awal pembangunan seperti pada tahap analisa dan design, tipe pengujian yang dapat dilakukan berbeda dengan tipe pengujian yang dilakukan selama dan sesudah implementasi. Sebelum implementasi, ide-idelah yang diuji, sedangkan sesudah implementasi kodelah yang diuji. Pengujian pre-implementation tidak dilakukan oleh programmer ataupun tim penguji, melainkan oleh tim pengevaluasi seperti project manager, customer atau sistem developer(orang-orang yang secara aktif terlibat dalam proses pembangunan). Pengujian awal lebih sering dianggap sebagai review atas apa yang telah dilakukan selama ini. Pada pendekatan life cycle klasik, pekerjaan ini akan dilakukan di setiap akhir fase pembangunan dan akan menjadi review dari tahapan yang baru selesai.Para pengevaluasi memeriksa apakah spesifikasi dokumen yang dihasilkan di akhir tahap analisis sudah konsisten, dapat dikerjakan dengan mudah serta dapat menangkap kebutuhan klien secara akurat. Sekumpulan solusi alternatif yang dihasilkan pada tahap desain sistem akan dievaluasi untuk memeriksa solusi tersebut telah memenuhi spesifikasi kebutuhan, secara teknis, operasional, dan finansial mudah diimplementasikan, serta sejalan dengan kebijakan klien dan perusahaan.Pada spesifikasi teknis yang dihasilkan pada akhir tahap desain detail masih ide yang diuji, walaupun ide-ide ini sekarang telah secara formal tertulis pada dokumen-dokumen design. Salah satu solusi yang ditawarkan akan dipilih dan dirancang dengan detail. Reviewer akan memeriksa apakah rancangan tersebut sesuai dengan permintaan yang telah dijabarkan di tahap sebelumnya, telah selesai dan cocok dengan permintaan performansi secara logis dan fisik.

Post implementation (Code Testing)Metode pengembangan software apapun yang digunakan, penguji bisa menggunakan dua teknik testing:White BoxWhite box testing secara umum sebagai pengujian kotak putih, struktural, atau pengujian kotak kaca yang dilakukan oleh seseorang yang mempunyai akses kepada source code( biasanya programmer itu sendiri). Kasus uji dipilih untuk menguji bagian-bagian dari kode tersebut untuk menemukan masalah-masalah yang ada seperti pada cabang-cabang, perulangan dan batasan-batasan.Black BoxBlack Box testing juga diikenal sebagai uji spesifikasi dan fungsionalitas. Suatu unit atau program diuji tanpa adanya pengetahuan tentang struktur internal dari source codenya. Maka itu pengujian ini bisa dan harus dilakukan oleh orang lain selain programmer yang membuat program tersebut. Penguji memperlakukan kode program sebagai kotak hitam yang tidak bisa kita lihat dalamnya. Kasus uji dipilih berdasarkan sifat-sifat kode yang tampak dari luar yang dispesifikasikan pada dokumentasi program. Penguji hanya tertarik dengan apa yang dilakukan oleh kode tersebut, bukan bagaimana kode tersebut bekerja. Kode diuji dengan menginputkan data ke dalam kotak hitam dan memeriksa apakah outputnya sesuai dengan apa yang diperkirakan.

*Proses code testing dibedakan pada 3 fase yang berbeda:Unit TestingIntegration Testing System TestingPada pengujian OO sistem, tiga fase pengujian klasik (unit testing, integration testing dan system testing), dipetakan kepada class testing, object integration testing dan system testing. System testing dilakukan dari sudut pandang user dengan memakai pendekatan black box. Perbedaan antara pengujian sytem klasik dan sistem berorientasikan objek terdapat pada fase class dan fase object integration.

*Unit testing pada sistem OO biasanya berarti class testing, yaitu menguji instansiasi dari kelas. Testing ini merupakan pengujian yang lebih kompleks dan lebih melibatkan proses sebagai unit dasar dengan ruang lingkup yang lebih luas. Suatu kelas biasanya terdiri dari beberapa method, nilai atribut dan pewarisan dan relasi dengan kelas yang lain. Maka itu unit testing pada OO software perlu memiliki fasilitas-fasilitas yang biasanya tidak terdapat pada unit testing klasik seperti:Encapsulated stateSuatu operasi tidak dapat diuji secara isolasi karena sifatnya yang dipengaruhi oleh nilai atribut (status) dari objek tersebut. Kita perlu memeriksa apakah method-method yang ada berinteraksi secara tepat dengan data objek. Interaksi antar methodMethod-method dari sebuah objek perlu diuji relasinya satu sama lain untuk memeriksa apakah mereka berinteraksi secara tepat.Pewarisan dan polimorfismeTerdapat ketentuan umum pada literatur OO bahwa jika pewarisan telah digunakan secara benar, fitur-fitur yang tidak diubah dari kelas parent-nya tidak perlu diuji ulang di kelas turunannya. Pewarisan dinyatakan benar bila relasi IS-A terdapat diantara parent dan kelas turunannnya.Tetapi penguji harus memperhatikan poin-poin berikut walalupun fitur-fitur tersebut tidak mengalami perubahan:Kelas abstrak hanya bisa diuji decara tidak langsung yaitu menguji instan dari kelas turunannya.Kasus pengujian khusus harus dibuat untuk menguji mekanisme pewarisan bekerja dengan baik.Walaupun parent classnya kongkrit, sudah sepenuhnya diuji dan terbagi atas pembagian relasi IS-A yang benar, tetap ada kemungkinan-kemungkinan yang mengharuskan kita juga menguji operasi-operasi pewarisan. Bila suatu kelas merubah sebuah variable instan turunan yang berefek pada bagaimana operasi turunan bekerja, maka operasi tersebut perlu diuji ulang. Jika suatu operasi diubah atau ditulis ulang kembali maka operasi tersebut perlu diuji ulang pula.Kegunaan dari polimorfisme adalah menghasilkan kode yang elegan dan compact, tetapi juga dapat mengakibatkan testing semakin sulit. Identifikasi dari semua path yang melalui sebuah bagian kode yang menggunakan polimorfisme lebih sulit karena criteria yang mengindikasikan path yang berbeda tidak disebutkan secara spesifik pada kode seperti dalam kode proseduralnya. Walaupun belum ada persetujuan tentang standar tentang pengujian OO system, tetapi sudah diketahui bahwa fase class testing harus menguji setiap method, interaksi antar method, status enkapsulasi dan struktur pewarisan dari kelas tersebut.

*Pengujian integrasi objectIntegration testing menguji unit yang telah diuji secara tunggal bekerja secara baik pula setelah digabungkan pada sistem. Saat sebuah unit telah berhasil menjalani tahap unit testing, mereka akan digabungkan ke dalam suatu grup logis yang koheren untuk diuji kembali. Misalnya beberapa unit digabung untuk membuat sebuah subsistem untuk diuji. Saat subsistem tersebut berhasil bekerja dengan baik maka akan dilanjutkan dengan menggabungkannya dengan subsistem yang lain dan seterusnya sampai membentuk suatu sistem utuh yang teruji.Hal yang diperhatikan pada integration testing yaitu memeriksa semua unit untuk dapat bekerja bersama dengan baik. Penguji lebih mengkonsentrasikan pada interaksi unit daripada fungsionalitasnya.*