Chapter 9
Software testing – strategies Testing software adalah tool pertama untuk menjamin kualitas software yang diterapkan untuk mengontrol kualitas produk software sebelum pengiriman atau instalasi di tempat pelanggan. Pada awalnya, testing terbatas pada tahap akhir pembangunan, setelah seluruh paket telah selesai. Kemudian, pentingnya deteksi dini terhadap cacat pada software menyebabkan konsep jaminan kualitas berubah. Prara profesional SQA didorong untuk memperluas kegiatan testing terhadap coding pada setiap bagian proses produksi, yang menyebabkan adanya testing setiap unit dari modul software dan testing terintegrasi seluruh modul. Umumnya semua kegiatan testing adalah dengan cara menjalankan aplikasi mereka langsung dari kodenya, tidak dengan cara meninjau dokumentasi pembangunan. Beberapa penulis cenderung untuk memperluas lingkup testing lebih jauh dan mempertimbangkan bahwa semua siklus hidup jaminan kualitas software difungsikan sebagai suatu jenis kegiatan testing . Testing software tidak diragukan lagi sebagai konsumen terbesar dari sumber daya jaminan kualitas software. Dalam sebuah survei yang dilakukan pada bulan November 1994, Perry (1995) menemukan bahwa rata-rata, 24% dari anggaran pembangunan proyek dialokasikan untuk testing . Selain itu, 32% dari anggaran manajemen proyek direncanakan untuk kegiatan testing . Sehubungan dengan sumber daya waktu, rata-rata 27% dari waktu proyek adalah berupa jadwal untuk testing . Peserta survei juga menunjukkan bahwa mereka berencana untuk mengalokasikan waktu yang lebih substansial (rata-rata 45%) untuk testing tetapi karena beberapa tekanan yang biasanya timbul menjelang akhir proyek, maka manajer proyek umumnya terpaksa mengurangi waktu testing yang sudah dijadwalkan. Jenis testing ini tentunya bukan satu-satunya tool SQA yang diterapkan terhadap kode software. Tool lainnya misalnya dengan inspeksi dan penelusuran terhadap kode yang dicetak terlebih dahulu, tanpa benar-benar menjalankan program. Prosedur-prosedur seperti ini disinyalir menghasilkan hasil yang baik dalam mengidentifikasian cacat kode. Namun demikian, cara ini tidak pernah dapat menggantikan fungsi testing sebelumnya, yang dapat meneliti fungsi produk software dalam kondisi yang benar-benar digunakan oleh pelanggan. 9.1 Definisi dan tujuan Berbagai definisi untuk software testing yang ditemukan dalam literatur mengungkapkan lingkup proses yang bervariasi, yang mungkin terbatas atau diperluas. Definisi (klasik) menurut Myers (1979, Bab 10) "Testing adalah proses eksekusi program dengan maksud untuk menemukan kesalahan. " Definisi yang agak inklusif, kegiatan mulai dari pemeriksaan kode yang dilakukan oleh seorang pemimpin tim, uji coba menjalankan software yang dilakukan oleh seorang rekan, serta tes dyang ilakukan oleh unit testing , semua dapat dianggap kegiatan testing.
Dua definisi testing oleh IEEE Std 610,12 (IEEE, 1990): (1) Proses mengoperasikan suatu sistem atau komponen dalam kondisi tertentu, mengamati atau hasil rekaman, dan membuat evaluasi dari beberapa aspek dari sistem atau komponen.
(2) Proses menganalisa item software untuk mendeteksi perbedaan antara kondisi yang ada dan yang diperlukan (suatu bug) dan mengevaluasi fitur dari setiap item software.
Perlu dicatat bahwa menurut definisi kedua, menjalankan program sebagai bagian dari proses testing adalah tidak diperlukan.
Definisi yang diterapkan dalam buku ini menekankan karakteristik operasi testing secara formal . Lihat Bingkai 9.1. Bingkai 9.1. Software tes - definisi Software tesing adalah proses formal yang dilakukan oleh tim pengujian khusus di mana suatu unit perangkat lunak, beberapa unit perangkat lunak yang terintegrasi atau seluruh paket perangkat lunak diperiksa dengan menjalankan program pada komputer. Semua tes yang terkait dilakukan sesuai dengan prosedur pengujian yang disetujui pada kasus uji yang disetujui. Kata-kata dan frase ditekankan dalam definisi tersebut memungkinkan kita untuk membandingkan karakteristik kunci dari testing software dengan orang software sebagai alat-alat jaminan kualitas siklus hidup:
Formal - rencana uji Software merupakan bagian dari pengembangan proyek dan rencana kualitas, dijadwalkan terlebih dahulu dan sering menjadi item sentral dalam pengembangan kesepakatan yang ditandatangani antara pelanggan dan pengembang. Dengan kata lain, pemeriksaan software secara ad hoc oleh rekan atau pemeriksaan teratur oleh pemimpin tim pemrograman tidak dapat dianggap sebagai tes software. Tim testing khusus. Sebuah tim independen atau konsultan eksternal yang mengkhususkan diri dalam testing ditugaskan untuk melakukan tugas-tugas ini terutama dalam rangka untuk menghilangkan bias dan untuk menjamin testing yang efektif oleh para profesional terlatih. Selain itu, secara umum diterima bahwa testing yang dilakukan oleh pengembang sendiri akan menghasilkan hasil yang buruk, seperti orang-orang yang mengembangkan produk asli akan sulit untuk mengungkapkan kesalahan yang mereka tidak dapat mengidentifikasi sebelumnya. Menjalankan program - Segala bentuk kegiatan jaminan kualitas yang tidak melibatkan kegiatan ‘menjalankan software’, misalnya pemeriksaan kode, tidak dapat dianggap sebagai dari kegiatan testing. Persetujuan prosedur testing. Proses testing dilakukan sesuai dengan rencana dan prosedur testing yang telah disetujui sebagai suatu prosedur SQA yang diadopsi oleh organisasi yang sedang mengembangkan software. Persetujuan kasus uji. Kasus uji untuk diperiksa dan didefinisikan secara penuh dalam perencanaan uji. Tidak ada kelalaian atau penambahan yang diharapkan terjadi selama testing . Dengan kata lain, setelah prosesuji dimulai, tester tidak diperkenankan untuk mengambil kebijaksanaan dengan cara menghilangkan kasus uji yang anggapnya berlebihan atau menambahkan sebuah kasus uji baru, meskipun mungkin menjanjikan.
Tujuan testing ini ditampilkan dalam Bingkai 9.2 Bingkai 9.2 Tujuan software testing Tujuan langsung
Untuk mengidentifikasi dan mengungkapkan kesalahan sebanyak mungkin dalam software yang diuji. Untuk membawa software yang yang diuji ke tingkat kualitas yang dapat diterima, setelah kesalahan yang diidentifikasi dikoreksi dan di testing ulang. Untuk melakukan tes yang diperlukan secara efisien dan efektif, dalam keterbatasan anggaran dan penjadwalan.
Tujuan tidak langsung
Untuk mengkompilasi catatan kesalahan software untuk digunakan dalam pencegahan kesalahan (oleh tindakan koreksi dan pencegahan).
Myers (1979) dengan rapi meringkas masalah ini: "Jika tujuan Anda adalah untuk menunjukkan tidak adanya kesalahan Anda tidak akan menemukan banyak. Jika tujuan Anda adalah untuk menunjukkan adanya kesalahan, Anda akan menemukan sebagian besar dari mereka. " Kata-kata dari tujuan kedua mencerminkan fakta bahwa software yang bebas bug adalah merupakan aspirasi yang utopis. Oleh karena itu, kami lebih memilih ungkapan "tingkat kualitas yang dapat diterima ", yang berarti bahwa persentase tertentu dari bug, dapat ditoleransi untuk pengguna, akan tetap tidak teridentifikasi setelah instalasi software. Persentase ini jelas bervariasi oleh paket software dan pengguna, tetapi harus lebih rendah untuk paket risiko kegagalan yang tinggi. 9.2 Strategi testing software Meskipun metodologi testing dapat bervariasi, seringkali jauh, ini diterapkan dalam kerangka dua strategi testing dasar:
Untuk menguji software secara keseluruhan, setelah paket selesai tersedia; atau dikenal sebagai "testing big bang". Untuk menguji software sedikit demi sedikit, dalam modul yang sudah selesai (unit test), kemudian untuk menguji kelompok modul terintegrasi dengan modul yang baru selesai (tes integrasi). Proses ini berlanjut sampai semua modul paket telah diuji. Setelah fase ini selesai, seluruh paket diuji secara keseluruhan (uji sistem). Strategi testing biasanya disebut "testing incremental". Selanjutnya, testing incremental juga dilakukan menurut dua strategi dasar: bottom-up dan top-down. Kedua strategi testing incremental berasumsi bahwa paket software dibangun dari hirarki modul software. Dalam testing top-down, modul pertama diuji adalah modul utama, modul tingkat tertinggi dalam struktur software; modul terakhir yang diuji adalah modul tingkat terendah. Di bottom-up testing , urutan testing dibalik: modul tingkat terendah diuji pertama, dengan modul utama diuji terakhir.
Gambar 9.1 mengilustrasikan testing top-down dan bottom-up dari sebuah proyek pengembangan software yang sama terdiri dari 11 modul. Pada bagian atas, Gambar 9.1 (a), proses pengembangan software dan testing selanjutnya dilakukan bottom-up, dalam empat tahap, sebagai berikut:
Tahap 1: tes unit modul 1 sampai 7. Tahap 2: Tes Integrasi A dari modul 1, dan 2 dikembangkan dan diuji di tahap 1, dan terintegrasi dengan modul 8, yang dikembangkan pada tahap saat ini. Tahap 3: Dua tes integrasi terpisah, B, pada modul 3, 4, 5 dan 8, terintegrasi dengan modul 9, dan C, untuk modul 6 dan 7, terintegrasi dengan modul 10.
Tahap 4: Sistem testing dilakukan setelah B dan C telah terintegrasi dengan modul 11, yang dikembangkan pada tahap saat ini.
Pada Gambar 9.1 (b), pengembangan software dan testing dilakukan top-down dalam enam tahap. Ini harus jelas bahwa perubahan strategi testing memperkenalkan perubahan besar dalam jadwal tes. Testing akan dilakukan sebagai berikut:
Tahap 1: testing unit modul 11. Tahap 2: tes integrasi sebuah modul terintegrasi dengan modul 11 9 dan 10, yang dikembangkan pada tahap saat ini. Tahap 3: uji Integrasi B dari A terintegrasi dengan modul 8, yang dikembangkan pada tahap saat ini. Tahap 4: uji Integrasi C B terintegrasi dengan modul 6 dan 7, yang dikembangkan pada tahap saat ini. Tahap 5: tes Integrasi D C terintegrasi dengan modul 1, dan 2 dikembangkan di tahap saat ini.
Tahap 6: uji sstem D terintegrasi dengan modul 3, 4 dan 5, yang dikembangkan pada tahap saat ini.
Jalur tambahan yang ditunjukkan pada Gambar 9.1 hanya dua dari banyak kemungkinan jalur. Jalur yang ada pada contoh adalah "horizontal berurutan", meskipun dapat memilih jalan yang "vertikal berurutan" ("kedalaman pertama"). Jika kita mengubah jalur horizontal berurutan dari urutan atas-bawah ditunjukkan pada Gambar 9.1 (b), untuk urutan vertikal, testing akan dilakukan seperti berikut: Tahap 1: Unit testing modul 11. Tahap 2: Tes Integrasi A integrasi dari modul 11 dengan modul 9, yang dikembangkan pada tahap saat ini. Tahap 3: Integrasi uji B dari A dengan modul 8, yang dikembangkan pada tahap saat ini. Tahap 4: Integrasi uji C B dengan modul 1 dan 2, yang dikembangkan pada tahap saat ini. Tahap 5: Integrasi tes D C dengan modul 10, dikembangkan di saat panggung. Tahap 6: Integrasi uji T dari integrasi D dengan modul 6 dan 7, yang dikembangkan pada tahap saat ini. Tahap 7: Sistem testing dilakukan setelah E telah terintegrasi dengan modul 3, 4, dan 5 dikembangkan dalam tahap saat ini. Bottom-up vs top-down strategi Keuntungan utama dari strategi bottom-up adalah kinerjanya yang relatif mudah, sedangkan kerugian utama adalah keterlambatan di mana program secara dapat diamati pada tahap testing modul terakhir. Keuntungan utama dari strategi top-down adalah adanya kemungkinan untuk menunjukkan fungsi seluruh program segera setelah selsai modul tingkat paling atas. Dalam banyak kasus, ini karakteristik memungkinkan untuk melakukan identifikasi lebih darin hasil analisis dan kesalahan desain yang berhubungan dengan algoritma, persyaratan fungsional, dan sejenisnya. Kerugian utama dari strategi ini adalah kesulitan relatif mempersiapkan stub yang diperlukan, yang sering membutuhkan pemrograman yang sangat rumit. Kerugian lain adalah kesulitan yang relatif dalam menganalisis hasil tes. Ahli testing terus memperdebatkan strategi mana yang lebih baik - bottom-up atau top-down. Sementara posisi yang diambil bervariasi, tampaknya bahwa strategi yang dipilih sebenarnya ditentukan oleh pengembang, apakahbottom-up atau top-down. Jelas, penguji harus mengikuti pendekatan pengembang karena sangat penting bahwa testing akan dilakukan segera setelah modul telah dikodekan. Pelaksanaan strategi testing yang berbeda dari strategi pembangunan akan menyebabkan penundaan substansial dalam penjadwalan tes. Big bang vs testing incremental Penerapan strategi testing big bang berdampak pada kerugian yang sangat parah, kecuali program yang di test berukuran sangat kecil dan sederhana. Identifikasi kesalahan menjadi cukup rumit sehubungan dengan jumlah software yang besar. Meskipun sumber daya telah diinvestasikan, efektivitas pendekatan ini relatif sedikit. Selain itu, ketika dihadapkan dengan seluruh paket software, koreksi kesalahan seringkali merupakan tugas yang berat, membutuhkan pertimbangan yang matang atas kemungkinan efek samping dari proses koreksi pada beberapa modul pada satu dan waktu yang sama. Kendala ini jelas membuat estimasi sumber daya testing yang diperlukan dan jadwal testing menjadi tidak jelas. Berbeda dengan testing big bang, bahwa esting incremental menyajikan beberapa keuntungan, yang utama adalah sebagai berikut:
(1) Incremental testing biasanya dilakukan pada modul-modul software yang relatif kecil, seperti unit atau tes integrasi. Hal ini membuat lebih mudah untuk mengidentifikasi persentase kesalahan bila dibandingkan dengan testing pada seluruh paket software. (2) Identifikasi dan koreksi kesalahan akan jauh lebih sederhana dan membutuhkan sumber daya yang lebih sedikit karena itu dilakukan pada volume yang terbatas dari software.
Singkatnya, dalam incremental testing, sebagian besar dari kesalahan dapat diidentifikasi dan dikoreksi pada tahap awal pengembangan dan testing, yang mencegah lolosnya kecacatan ke tahap pengembangan yang lebih kompleks, di mana mereka akan memerlukan sumber daya lebih signifikan untuk koreksi. Kerugian utama dari testing incremental adalah jumlah sumber daya pemrograman yang diperlukan untuk persiapan stubs dan driver untuk unit dan tes integrasi. Kelemahan utama lain adalah kebutuhan untuk melaksanakan beberapa operasi testing untuk program yang sama (testing big bang hanya membutuhkan operasi testing tunggal).
9.3. Klasifikasi testing software Tes software dapat diklasifikasikan menurut konsep testing atau klasifikasi persyaratan yang berlaku (lihat Bab 3).
9.3.1 Klasifikasi menurut konsep testing Ada sebuah perdebatan atas apakah fungsi testing software semata-mata hanya dengan melihat output yang cukup sesuai sebagai tingkat kualitas yang dapat diterima. Beberapa menyatakan bahwa struktur internal software dan perhitungan (yaitu, struktur matematika yang mendasari, juga dikenal sebagai "mekanisme" software) harus dimasukkan ke dalam proses testing. Berdasarkan dua konsep atau pendekatan yang berbeda, dua jenistesting telah dikembangkan:
Black Box Testing (fungsionalitas) . Mengidentifikasi bug suatu software dengan melihat output yang salah. Testing black box mengabaikan jalur internal perhitungan dan pengolahan yang dilakukan. White Box Testing (struktural) . Memeriksa jalur perhitungan internal untuk mengidentifikasi bug.
Bingkai 9.3 Black Box and white Box Testing - IEEE definisi Black box testing : (1) Testing yang mengabaikan mekanisme internal sistem atau komponen dan fokus semata-mata pada output yang dihasilkan dalam menanggapi input yang dipilih dan kondisi eksekusi. (2) Testing dilakukan untuk mengevaluasi pemenuhan sistem atau komponen dengan kebutuhan fungsional yang ditentukan. White box testing : Testing yang memperhitungkan mekanisme internal sistem atau komponen. Karena pertimbangan biaya, sebagian besar testing dilakukan saat ini testing black box, yang relatif lebih murah.
9.3.2 Klasifikasi sesuai dengan kebutuhan Bab 3 menyajikan model klasik McCall untuk klasifikasi persyaratan kualitas software. Modelnya telah ditambahkan pada klasifikasi tes yangakan dilakukan untuk memastikan proses testing mencakup seluruh persyaratan masing-masing. Persyaratan dan tes yang sesuai ditunjukkan dalam Tabel 9.1. Penerapan white box dan black box testing dalam tes persyaratan kinerja telah mengungkapkan keuntungan dan kerugian dari setiap konsep testing . Lebih khusus, seperti yang sudah tersirat, white box menguji pengolahan data dan ketepatan perhitungan sedangkan black box menguji output yang benar. Tes maintainability dapat diimplementasikan oleh kedua white box dan black box tes, sebagai temuan dari masing-masing konsep testing saling melengkapi.
9.4 White box testing Realisasi dari konsep testing white box memerlukan verifikasi dari setiap pernyataan program dan komentar. Seperti yang ditunjukkan pada Tabel 9.2, testing white box memungkinkan tes kinerja pengolahan data dan perhitungan ketepatan, tes software kualifikasi, tes pemeliharaan dan tes usabilitas. Dalam rangka untuk melakukan tes kebenaran data yang pengolahan dan perhitungan, setiap operasi komputasi dalam urutan operasi yang diciptakan oleh masing-masing kasus uji harus diperiksa. Beralih ke kualifikasi software, fokus test ini bergeser ke pemeriksaan kode software (termasuk komentar) sesuai dengan standar coding dan instruksi kerja. Maintainability test mengacu pada fitur-fitur khusus, seperti yang dipasang untuk mendeteksi penyebab kegagalan, modul struktur yang mendukung adaptasi software dan perbaikan software, dll. Tes reusability memeriksa sejauh bahwa reused software dapat dimasukkan dalam paket dan adaptasi dilakukan dalam rangka membuat bagian-bagian dari software saat ini agar dapat digunakan kembali untuk paket software masa depan.
9.4.1 Tes kebenaran pengolahan data dan perhitungan Menerapkan konsep testing white box, yang didasarkan pada pemeriksaan pengolahan data untuk setiap kasus uji. Dua pendekatan alternatif telah muncul:
Cakupan jalur - rencana uji untuk menutupi semua jalur yang mungkin, di mana cakupan diukur dengan persentase jalan tertutup. Cakupan baris - merencanakan tes untuk menutup semua baris kode program, di mana cakupan diukur dengan persentase garis tertutup.
9.4.2 Kebenaran tes dan cakupan jalur Jalur yang berbeda dalam sebuah modul software yang diciptakan oleh pilihan dalam pernyataan bersyarat, seperti IF-THEN-ELSE atau DO WHILE atau DO UNTIL. Testing jalan adalah dimotivasi oleh aspirasi untuk mencapai cakupan yang lengkap dari sebuah program dengan menguji semua path yang mungkin. Oleh karena itu, " line coverage" metrik mengukur kelengkapan tes jalan adalah didefinisikan sebagai persentase dari jalur program yang dijalankan selama uji (diaktifkan oleh uji kasus termasuk dalam prosedur testing ). 9.4.3 Kebenaran cakupan tes dan baris Konsep cakupan line memerlukan bahwa, untuk cakupan baris penuh, setiap baris kode akan dieksekusi setidaknya sekali selama proses testing . Cakupan metrik baris untuk kelengkapan testing baris ("testing jalur dasar") rencana diidefinisikan sebagai persentase dari baris memang dijalankan selama testing . Untuk lebih memahami esensi testing jalur dasar dari sebuah program, referensi ke flow chart dan grafik aliran program dapat membantu. Dalam diagram alir, daimon menyajikan pilihan yang dicakup oleh pernyataan bersyarat (keputusan), sedangkan empat persegi panjang atau persegi panjang suksesi merupakan bagian software menghubungkan pernyataan bersyarat mereka. Dalam grafik aliran program, node mewakili bagian software dan dengan demikian menggantikan persegi aliran satu atau lebih tabel. Tepi mengindikasikan urutan dari bagian software. Node yang memiliki dua atau lebih ujung meninggalkan mewakili pernyataan bersyarat. Contoh berikut menunjukkan flow chart dan grafik aliran program untuk modul software Argometer yang menghitung tarif taksi.
Sumber: Software Quality Assurance From theory to implementation by Daniel Galin Terjemahan: Dadang Latif, M.Kom
