Software Testing

Definisi Software Testing Software 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 vs. validation “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 butuhkan

Program testing Dapat menunjukan keberadaan kesalahan tapi BUKAN ketidakadaan kesalahan yang lain Test yang sukses adalah sebuah test yang menemukan satu atau lebih kesalahan Seharusnya digunakan bersama dengan verification statik untuk memberikan V&V sepenuhnya The fact is that NOTHING, not inspection, not formal proof, not testing, can give 100% certainty of no errors

Testing and debugging Adalah proses yang berbeda Verification and validation: menunjukkan keberadaan cacat program Debugging: menemukan dan memperbaiki kecacatan-kecacatan ini

Tujuan Dilakukan Software Testing Untuk meningkatkan kualitas Untuk Verification & Validation (V&V) Untuk estimasi reliability [Kaner93] [Lyu95] 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.

Melakukan testing berarti melakukan Mendesain test. Mengimplementasikan test yang telah didesign. Mengevaluasi test tersebut. Design test sangat penting untuk efektivitas, sedangkan mengimplementasikan test penting untuk efesiensi, dan mengevaluasi test dapat meningkatkan efektivitas.

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

Selective Testing Jalur eksekusi yang dipilih loop < 20 X

Tahapan Testing Pre-Implementation Testing Post implementation (Code Testing) Metode pengembangan software apapun yang digunakan, penguji bisa menggunakan dua teknik testing:  White Box Black Box Pre-Implementation Testing Pengujian 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 Box White 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 Box Black 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.

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

Black-Box Testing requirements output input events

Strategi OO Testing[1] Proses code testing dibedakan pada 3 fase yang berbeda: Unit Testing Integration Testing System Testing   Pada 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.

Strategi OO Testing[2] Unit Testing  Pengujian class/object Integration Testing  object integration testing System Testing

Pengujian class/object Encapsulated state  Memeriksa interaksi method-method dengan data obyek Interaksi antar method  Memeriksa interaksi method-method dari sebuah obyek Pewarisan dan polimorfisme 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 state Suatu 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 method Method-method dari sebuah objek perlu diuji relasinya satu sama lain untuk memeriksa apakah mereka berinteraksi secara tepat. Pewarisan dan polimorfisme Terdapat 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.

Unit Testing[1] Tahapan testing yang paling awal. Tahap selanjutnya terdiri dari integration testing dan system testing Biasanya unit didefinisikan sebagai: Suatu fungsi atau prosedur tunggal yang kohesif Segmen 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 dipanggil Memverifikasi penanganan dari semua struktur data

Pengujian Method[2] Memverifikasi penanganan semua file Cek terminasi normal dari semua loop ( part of correctness proof) Cek terminasi abnormal dari semua loop Cek terminasi normal dari semua rekursif Cek terminasi abnormal dari semua rekursif Memverifikasi penanganan semua kondisi error Cek timing dan sinkronisasi verifikasi semua ketergantungan hardware

Class Testing Kombinasikan penggunaan method biasanya 2-5 pilih rangkaian pertama yang paling umum masukan rangkaian yang mungkin menyebabkan error Fokuskan unit test pada masing-masing atribut inisialisasi, lalu eksekusi rangkaian method yang dipengaruhinya Verifikasi masing-masing invariant class tidak berubah Verifikasi object transisi diantara state-state yang ada. Rencanakan rangkaian state/transisisi Set up object dalam inisial state dengan menyeting variable Sediakan event pertama dan cek transisi yang terjadi

Pengujian integrasi object Menguji unit yang telah diuji secara tunggal bekerja secara baik pula setelah digabungkan pada sistem Mereka 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 teruji Hal yang diperhatikan yaitu memeriksa semua unit apakah bekerja bersama dengan baik. Penguji lebih mengkonsentrasikan pada interaksi unit daripada fungsionalitasnya Pengujian integrasi object   Integration 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.

Merancang dan Melakukan Integration Testing Putuskan bagaimana dan dimana untuk menyimpan, menggunakan kembali dan mengkodekan integration test tunjukan dalam project schedule Ekesekusi unit-unit test sebanyak mungin sesuai dengan waktu yang tersedia Gunakan test regresi Pastikan kebutuhan pembangunan telah dispesifikasikan. Gunakan use case yang harus diimplementasikan Eksekusi system test

Artifact yang terlibat dalam proses integration test use case model :Kumpulan use case yang menggambarkan penggunaan typical dari aplikasi, dan sequence diagram test cases : input untuk setiap test test procedure : cara bagaimana test di set up, dieksekusi, dan dievaluasi(hasil). Dapat berupa prosedur manual ataupun menggunakan tools untuk test otomasi test evaluation : kesimpulan, detail dan effect dari error yang ditemukan test plan : Rencana keseluruhan test test 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 besar usability : mengukur reaksi user ( skala 1-10) performance : mengukur kecepatan pada beberapa keadaan configurasi : mengkonfogurasi untuk bermacam-macam hardware atau software compatibility : komplabiliti dengan aplikasi lain ( contoh: mengukur waktu adaptasi) reliability/availability : mengukur ketahanan pada periode waktu yang lama

Tipe-tipe system testing[2] security resource usage : mengukur penggunaan RAM, ruang disk, dll installability : di install pada bermacam-macam keadaan (mengukur waktu install) recoverability : mengukur waktu untuk me-recover serviceability : mengukur waktu service load/stress: untuk data extreme dan traffic

Tipe-Tipe Testing lainnya Regression Testing Acceptance Testing by user or a testing team Beta Testing Release testing

Regression Testing Terlalu sering memperbaiki kesalahan-kesalahan software memacu pada kesalahan-kesalahan baru Seorang 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 team Acceptance 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 customer Acceptance test sering dilakukan diawal agar para programmer atau developer team bisa melakukannya sebelum secara formal memasarkan software tersebut

Beta Testing Jika 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 testing Release 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 : Programmer Tim penguji Beta tester(Group yang mewakili pasar) Customer Maintainer

Standar ANSI/IEEE untuk test dokumentasi[] introduction test plan : item dalam test,ruang lingkup, pendekatan, resource, jadwal, personel test design: item yang ditest, pendekatan, rencana detail test case : kumpulan input dan event test 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 transmitting test log : kronologi record, lokasi fisik dari hasil, nama penguji test incident report : dokumentasi dari setiap event yang terjadi selama test, yang membutuhkan investigasi lebih lanjut test 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 kembali jalankan test script secara berulang-ulang memungkinkan untuk merekam hasil test

Testing Tools[2] merekam waktu eksekusi merekam run time error membuat dan mengatur regression test menghasilkan test report menghasilkan test data merekam penggunaan memory mengatur/mengelola test case analisa keseluruhan

Daftar Pustaka Britton, 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., 2000 Bahrami, Ali, “Object Oriented System Development”, Singapore: McGraw-Hill, Inc., 1999 Pressman, Roger S.,The 5th edition of Software Engineering: A Practitioner's Approach,McGraw-Hill. Sommerville, Ian, Software Engineering, 6th edition, Pearson Education, 2001 http://www.cetus-links.org/oo_testing.html http://www.testing.com/writings/1-fault.htm http://www.rbsc.com/pages/who_who.html