RPL BAB 8 (Pengujian)

Nama         : Santi

Npm           :43a87007150347

Kelas          : S1/SI/3B/P

BAB 8

Pengujian

Dalam proyek pengembangan perangkat lunak, kesalahan dapat diperkenalkan pada setiap tahap selama pengembangan.  Meskipun kesalahan yang terdeteksi setelah setiap tahap dengan teknik seperti inspeksi, beberapa kesalahan tetap tidak terdeteksi.  Pada akhirnya, ini yang tersisa kesalahan tercermin dalam kode. Oleh karena itu, kode akhir mungkin memiliki beberapa persyaratan kesalahan dan kesalahan desain, selain untuk kesalahan yang diperkenalkan selama coding aktivitas. Untuk memastikan kualitas perangkat lunak yang dikirimkan akhir, cacat ini harus dihapus. Ada dua jenis pendekatan untuk mengidentifikasi cacat pada software- statis dan dinamis. Dalam analisis statis, kode ini tidak dijalankan tetapi dievaluasi

melalui beberapa proses atau beberapa alat untuk mencari cacat. inspeksi kode,

yang kita bahas dalam bab sebelumnya, adalah salah satu pendekatan statis. Lain

adalah analisis statis kode melalui penggunaan alat-alat. Dalam analisis dinamis, kode

adalah dieksekusi, dan eksekusi yang digunakan untuk menentukan cacat. Pengujian adalah

Teknik dinamis umum paling yang digunakan. Memang, pengujian adalah yang paling

umum digunakan teknik untuk mendeteksi cacat, dan melakukan sangat kritis

peran untuk memastikan kualitas.

Selama pengujian, perangkat lunak yang diuji (SUT) dijalankan dengan himpunan berhingga

kasus uji, dan perilaku sistem untuk uji kasus ini dievaluasi

untuk menentukan apakah sistem kinerja seperti yang diharapkan. Tujuan dasar dari

pengujian adalah untuk meningkatkan kepercayaan diri dalam fungsi SUT. Dan seperti pengujian

sangat mahal dan dapat mengkonsumsi jumlah yang tidak terbatas dari usaha, tambahan

Tujuan praktis adalah untuk mencapai kepercayaan yang diinginkan seefisien mungkin.

Jelas, efektivitas dan efisiensi pengujian sangat bergantung pada tes

kasus yang dipilih. Banyak dari bab ini karena dikhususkan untuk menguji seleksi kasus.

Dalam bab ini kita akan membahas:

- Konsep dasar dan definisi yang berkaitan dengan pengujian, seperti kesalahan, kesalahan, kegagalan,

kasus uji, test suite, memanfaatkan uji, dll

- Pengujian proses pengujian-bagaimana direncanakan dan bagaimana pengujian unit adalah

dilakukan.

- Temukan Uji kasus menggunakan pendekatan pengujian black-box.

- Temukan Uji kasus menggunakan pendekatan kotak putih.

- Beberapa metrik seperti cakupan dan kehandalan yang dapat digunakan selama pengujian.

8.1 Konsep Pengujian

Pada bagian ini kita akan mendefinisikan beberapa istilah yang umum digunakan

ketika membahas pengujian. Kemudian kita akan membahas beberapa masalah dasar yang berkaitan dengan bagaimana

pengujian dilakukan, dan pentingnya psikologi tester.

8.1.1 Kesalahan, Fault, dan Kegagalan

Ketika mendiskusikan pengujian yang biasa kita gunakan istilah-istilah seperti kesalahan, kesalahan, kegagalan dll Mari kita mulai dengan mendefinisikan konsep-konsep ini jelas [52].

Kesalahan istilah digunakan dalam dua cara yang berbeda. Hal ini mengacu pada perbedaan tersebut

antara dihitung, mengamati, atau diukur nilai dan benar, ditetapkan, atau

nilai teoritis yang benar. Artinya, kesalahan mengacu pada perbedaan antara

output aktual dari perangkat lunak dan output yang benar. Dalam interpretasi ini, kesalahan

pada dasarnya adalah ukuran perbedaan antara aktual dan ideal. Kesalahan

juga digunakan untuk merujuk pada tindakan manusia yang menghasilkan perangkat lunak yang

mengandung cacat atau kesalahan. Definisi ini cukup umum dan mencakup semua tahap.

Kesalahan adalah suatu kondisi yang menyebabkan sistem gagal dalam melakukan nya dibutuhkan

fungsi. Sebuah kesalahan adalah alasan dasar untuk kerusakan perangkat lunak dan praktis

identik dengan bug istilah yang umum digunakan, atau agak lebih umum

cacat jangka. Kesalahan Istilah ini juga sering digunakan untuk merujuk pada cacat (mengambil

variasi definisi kedua error). Dalam buku ini kita akan terus menggunakan

istilah dengan cara yang umum digunakan, dan tidak ada perbedaan yang jelas akan

dibuat antara kesalahan dan kesalahan, kecuali jika diperlukan.

Kegagalan adalah ketidakmampuan sistem atau komponen untuk melakukan dibutuhkan

fungsi sesuai dengan spesifikasinya. Sebuah kegagalan perangkat lunak terjadi jika perilaku dari software

ini berbeda dengan perilaku tertentu. Kegagalan mungkin disebabkan

oleh faktor fungsional atau kinerja. Perhatikan bahwa definisi tidak menyiratkan

bahwa kegagalan harus diperhatikan. Ada kemungkinan bahwa kegagalan mungkin terjadi tapi tidak

terdeteksi. Ada beberapa implikasi dari definisi tersebut. Kehadiran kesalahan (dalam

negara) menyiratkan bahwa kegagalan harus terjadi, dan ketaatan kegagalan

menyiratkan bahwa suatu kesalahan harus hadir dalam sistem. Namun, kehadiran

kesalahan tidak berarti bahwa kegagalan harus terjadi. Kehadiran kesalahan dalam

sistem hanya menyiratkan bahwa kesalahan memiliki potensi untuk menyebabkan kegagalan. Apakah

kesalahan sebenarnya memanifestasikan dirinya dalam durasi waktu tertentu tergantung pada

bagaimana software dijalankan.

Ada konsekuensi langsung dari ini pada pengujian. Jika selama pengujian kami tidak

mengamati kesalahan, kita tidak bisa mengatakan apa-apa tentang ada atau tidak adanya

kesalahan dalam sistem. Jika, di sisi lain, kita amati beberapa kegagalan, kita bisa

mengatakan bahwa ada beberapa kesalahan dalam sistem. Hubungan ini dari kesalahan dan

Kegagalan membuat tugas memilih kasus uji untuk pengujian yang sangat menantang-an

Tujuan saat memilih uji kasus adalah untuk memilih orang-orang yang akan mengungkapkan cacat,

jika ada. Idealnya kami ingin set kasus uji harus sedemikian rupa sehingga jika ada

setiap cacat dalam sistem, beberapa kasus uji di set akan mengungkapkannya-sesuatu

mustahil untuk mencapai dalam kebanyakan situasi.

Perlu dicatat bahwa selama proses pengujian, hanya kegagalan yang diamati,

dimana kehadiran kesalahan disimpulkan. Artinya, pengujian hanya mengungkapkan

kehadiran kesalahan. Kesalahan yang sebenarnya diidentifikasi oleh kegiatan terpisah,

sering disebut sebagai "debugging." Dengan kata lain, untuk mengidentifikasi kesalahan, setelah

pengujian telah mengungkapkan adanya kesalahan, tugas mahal debugging

telah akan dilakukan. Ini adalah salah satu alasan mengapa pengujian adalah mahal

metode untuk identifikasi kesalahan.

 8.1.2 Uji Kasus, Test Suite, dan Test Harness

Sejauh ini kita telah menggunakan kasus uji istilah atau mengatur kasus uji informal. Mari kita

mendefinisikan mereka lebih tepat. Sebuah test case (sering disebut tes) dapat dianggap

sebagai terdiri dari satu set input tes dan kondisi eksekusi, yang dirancang

untuk latihan SUT dengan cara tertentu [52]. Umumnya, kasus uji juga

menentukan hasil yang diharapkan dari pelaksanaan SUT di bawah yang ditentukan

kondisi pelaksanaan dan masukan uji. Sekelompok kasus uji terkait yang

umumnya dilaksanakan bersama-sama untuk menguji beberapa perilaku tertentu atau aspek dari SUT

sering disebut sebagai test suite. Perhatikan bahwa dalam kasus uji, masukan uji dan kondisi ekseku

si disebutkan terpisah. Uji input adalah nilai-nilai tertentu dari parameter atau input lain yang diberikan

kepada SUT baik oleh pengguna atau program lain. Eksekusi kondisi, di sisi lain, mencerminkan keadaan

dari sistem dan lingkungan yang juga berdampak pada perilaku SUT. Jadi, misalnya, saat uji coba

fungsi untuk menambahkan catatan dalam database jika tidak sudah ada,

perilaku fungsi akan tergantung baik pada nilai catatan masukan sebagai

serta keadaan database. Dan kasus uji perlu menentukan baik. Untuk

Misalnya, kasus uji untuk fungsi ini mungkin menentukan rekor r sebagai masukan, dan

mungkin menentukan bahwa negara database sedemikian rupa sehingga r sudah ada di dalamnya.

Pengujian dapat dilakukan secara manual dengan tester melaksanakan uji kasus di

test suite dan kemudian memeriksa apakah perilaku tersebut sebagaimana ditetapkan dalam kasus uji.

Ini adalah proses yang sangat rumit, terutama ketika test suite berisi besar jumlah kasus uji. Itu menjadi

lebih rumit karena test suite sering harus dijalankan setiap kali SUT berubah. Oleh karena itu, saat ini

tren adalah untuk mengotomatisasi pengujian.

Dengan pengujian otomatis, kasus uji biasanya panggilan fungsi (atau metode

doa), yang melakukan semua kegiatan uji kasus-set data uji

dan kondisi pengujian, memanggil SUT per kasus uji, membandingkan

Hasil kembali dengan hasil yang diharapkan, dan menyatakan untuk tester apakah

SUT gagal atau lulus ujian. Dengan kata lain, dengan pengujian otomatis,

mengeksekusi kasus uji dasarnya berarti melaksanakan fungsi ini. Sebuah test suite

maka akan menjadi set fungsi tersebut, masing-masing mewakili kasus uji. Untuk menguji

SUT dengan test suite, umumnya skrip tes otomatis akan ditulis

yang akan memanggil uji kasus dalam urutan yang diinginkan.

Untuk memiliki suite tes dieksekusi secara otomatis, kita akan membutuhkan sebuah kerangka di

yang input tes dapat didefinisikan, input didefinisikan dapat digunakan oleh fungsi

mewakili kasus uji, test script otomatis dapat ditulis, SUT

dapat dieksekusi oleh script ini, dan hasil dari seluruh pengujian dilaporkan kepada

penguji. Banyak kerangka pengujian sekarang ada yang izin semua ini harus dilakukan dalam

cara yang sederhana. Sebuah kerangka pengujian juga kadang-kadang disebut memanfaatkan tes.

Sebuah memanfaatkan uji atau kerangka tes membuat kehidupan tester sederhana dengan memberikan

cara mudah mendefinisikan test suite, dijalankan, dan pelaporan hasil.

Dengan kerangka tes, tes suite didefinisikan sekali, dan kemudian setiap kali diperlukan,

pengujian lengkap dapat dilakukan dengan klik tombol atau memberikan perintah.

8.1.3 Psikologi Pengujian

Seperti disebutkan, dalam pengujian, perangkat lunak yang diuji (SUT) dijalankan dengan

mengatur kasus uji. Seperti yang dibahas, merancang satu set kasus uji yang akan menjamin

bahwa semua kesalahan akan terdeteksi tidak layak. Selain itu, tidak ada yang formal

atau metode yang tepat untuk memilih uji kasus. Meskipun ada sejumlah heuristik dan aturan praktis

untuk memutuskan uji kasus, memilih kasus uji masih kegiatan kreatif yang mengandalkan kecerdikan

tester. Karena ini, psikologi orang yang melakukan pengujian menjadi penting.

Sebuah tujuan dasar pengujian adalah untuk mendeteksi kesalahan yang mungkin ada di

program. Oleh karena itu, seseorang tidak harus memulai pengujian dengan maksud menunjukkan

bahwa karya Program; bukan maksud harus menunjukkan bahwa program tidak

kerja; untuk mengungkapkan cacat yang mungkin ada. Karena ini, pengujian juga telah

didefinisikan sebagai proses eksekusi program dengan maksud menemukan kesalahan

[68].

Penekanan pada maksud yang tepat dari pengujian tidak masalah sepele karena

uji kasus dirancang oleh manusia, dan manusia memiliki kecenderungan

untuk melakukan tindakan untuk mencapai tujuan yang mereka miliki dalam pikiran. Jadi, jika tujuannya adalah

untuk menunjukkan bahwa program kerjanya, kita dapat secara sadar atau tidak sadar

pilih kasus uji yang akan mencoba untuk menunjukkan tujuan itu dan yang akan mengalahkan

tujuan dasar pengujian. Di sisi lain, jika tujuannya adalah untuk menunjukkan bahwa

program tidak bekerja, kami akan menantang akal kita untuk menemukan kasus uji

mencapai tujuan itu, dan kita cenderung untuk mendeteksi lebih banyak kesalahan. Pengujian pada dasarnya adalah

Proses destruktif, di mana tester harus memperlakukan program sebagai musuh

yang harus dikalahkan oleh tester dengan menunjukkan adanya kesalahan. Ini adalah

salah satu alasan mengapa banyak organisasi mempekerjakan pengujian independen yang

pengujian dilakukan oleh tim yang tidak terlibat dalam membangun sistem.

8.1.4 Tingkat Pengujian

Pengujian biasanya diandalkan untuk mendeteksi kesalahan yang tersisa dari tahap awal,

selain kesalahan diperkenalkan selama coding sendiri. Karena ini, berbeda

tingkat pengujian yang digunakan dalam proses pengujian; setiap tingkat pengujian bertujuan untuk

menguji aspek yang berbeda dari sistem.

Tingkat dasar unit testing, pengujian integrasi, pengujian sistem, dan

ujian penerimaan. Tingkat ini berbeda dari pengujian upaya untuk mendeteksi berbeda

jenis kesalahan. Hubungan antara kesalahan diperkenalkan dalam fase yang berbeda, dan

tingkat yang berbeda dari pengujian ditunjukkan pada Gambar 8.1.

Tingkat pertama pengujian disebut unit testing, yang kita bahas di

bab sebelumnya. Unit pengujian pada dasarnya untuk verifikasi kode yang dihasilkan

oleh programmer individu, dan biasanya dilakukan oleh programmer dari

modul. Umumnya, sebuah modul yang ditawarkan oleh programmer untuk integrasi dan

menggunakan oleh orang lain hanya setelah telah unit diuji memuaskan.

Tingkat berikutnya pengujian sering disebut pengujian integrasi. Dalam hal ini, banyak unit yang

modul diuji digabungkan menjadi subsistem, yang kemudian diuji. Hasil

di sini adalah untuk melihat apakah modul dapat diintegrasikan dengan benar. Oleh karena itu, penekanannya adalah

Gambar 8.1: Tingkat pengujian.

pada pengujian antarmuka antara modul. Kegiatan pengujian ini dapat dianggap

menguji desain.

Tingkat berikutnya adalah pengujian sistem dan pengujian penerimaan. Berikut seluruh yang

sistem perangkat lunak diuji. Dokumen acuan untuk proses ini adalah

dokumen persyaratan, dan tujuannya adalah untuk melihat apakah perangkat lunak memenuhi persyaratan.

Hal ini sering latihan besar, yang untuk proyek-proyek besar dapat berlangsung banyak

minggu atau bulan. Ini pada dasarnya adalah latihan validasi, dan dalam banyak situasi

itu adalah satu-satunya kegiatan validasi. pengujian penerimaan sering dilakukan

dengan data yang realistis dari klien untuk menunjukkan bahwa perangkat lunak tersebut bekerja

memuaskan. Hal itu dapat dilakukan dalam pengaturan di mana perangkat lunak adalah untuk akhirnya

fungsi. pengujian penerimaan dasarnya menguji apakah sistem memuaskan

memecahkan masalah bagi yang ditugaskan.

Tingkat ini pengujian dilakukan ketika sistem sedang dibangun dari

komponen yang telah dikodekan. Ada lagi tingkat pengujian, yang disebut

pengujian regresi, yang dilakukan ketika beberapa perubahan yang dibuat untuk yang sudah ada

sistem. Kita tahu bahwa perubahan yang mendasar untuk perangkat lunak; perangkat lunak apapun harus

mengalami perubahan. Namun, ketika modifikasi yang dibuat untuk sistem yang ada,

pengujian juga harus dilakukan untuk memastikan bahwa modifikasi belum punya

efek samping yang tidak diinginkan membuat beberapa layanan sebelumnya rusak. Itu adalah,

selain memastikan perilaku yang diinginkan dari layanan baru, pengujian harus memastikan

bahwa perilaku yang diinginkan dari layanan lama dipertahankan. Ini adalah tugas

pengujian regresi. sistem dipertahankan, bersama dengan output yang dihasilkan oleh sistem yang lama.

uji kasus ini dijalankan lagi pada sistem dimodifikasi dan outputnya

dibandingkan dengan output sebelumnya untuk memastikan bahwa sistem ini bekerja sebagai

sebelum di uji kasus ini. Hal ini sering merupakan tugas besar ketika modifikasi

yang dibuat untuk sistem yang ada.

pengujian regresi lengkap sistem yang besar dapat mengambil cukup banyak

waktu, bahkan jika otomatisasi digunakan. Jika perubahan kecil dibuat untuk sistem,

sering pertimbangan praktis mengharuskan seluruh test suite tidak dieksekusi,

tapi pengujian regresi dilakukan dengan hanya sebagian dari kasus uji. ini membutuhkan

sesuai memilih kasus uji dari suite yang dapat menguji bagian-bagian dari

sistem yang dapat dipengaruhi oleh perubahan. Tes seleksi kasus untuk regresi

pengujian adalah area penelitian aktif dan banyak pendekatan yang berbeda telah

diusulkan dalam literatur untuk ini. Kita tidak akan membahas lebih jauh lagi.

8.2 Proses Pengujian

Tujuan dasar dari proses pengembangan perangkat lunak adalah untuk menghasilkan perangkat lunak yang

tidak memiliki kesalahan atau sangat sedikit kesalahan. Pengujian adalah kegiatan pengendalian kualitas yang

berfokus pada identifikasi cacat (yang kemudian dihapus). Kita telah melihat bahwa

berbagai tingkat pengujian yang diperlukan untuk mendeteksi cacat disuntikkan selama

berbagai tugas dalam proyek. Dan pada tingkat kelipatan SUTs dapat diuji. Dan

untuk pengujian setiap SUT, uji kasus harus dirancang dan kemudian dieksekusi.

Secara keseluruhan, pengujian dalam proyek adalah tugas kompleks yang juga mengkonsumsi maksimal

upaya. Oleh karena itu, pengujian harus dilakukan dengan benar dalam suatu proyek. pengujian

Proses untuk sebuah proyek terdiri dari tiga perencanaan tugas-test, uji kasus tingkat tinggi

desain, dan pelaksanaan tes. Kami akan membahas ini dalam bagian ini.

 Rencana 8.2.1 Uji

Secara umum, dalam sebuah proyek, pengujian dimulai dengan rencana tes dan berakhir

dengan keberhasilan pelaksanaan pengujian penerimaan. Sebuah rencana uji adalah dokumen umum

untuk seluruh proyek yang mendefinisikan ruang lingkup, pendekatan yang akan diambil, dan

jadwal pengujian, serta mengidentifikasi item tes untuk pengujian dan

personil yang bertanggung jawab untuk kegiatan yang berbeda dari pengujian. Rencana pengujian

dapat dilakukan dengan baik sebelum pengujian yang sebenarnya dimulai dan dapat dilakukan secara paralel

dengan kegiatan coding dan desain. Input untuk membentuk tes

Rencana adalah: (1) rencana proyek, (2) dokumen persyaratan, dan (3) arsitektur atau dokumen desain. Rencana proyek diperlukan untuk memastikan bahwa rencana uji

konsisten dengan rencana mutu secara keseluruhan untuk proyek dan jadwal pengujian

cocok dengan rencana proyek. Persyaratan dokumen dan desain

dokumen adalah dokumen-dokumen dasar yang digunakan untuk memilih unit test dan memutuskan

pendekatan yang akan digunakan selama pengujian. Sebuah rencana uji harus memuat

berikut:

- Spesifikasi Unit Uji

- Fitur yang akan diuji

- Pendekatan untuk pengujian

- Kiriman Uji

- Jadwal dan tugas alokasi

Seperti yang terlihat sebelumnya, tingkat yang berbeda dari pengujian harus dilakukan dalam sebuah proyek.

Tingkat ditentukan dalam rencana uji dengan mengidentifikasi unit tes untuk

proyek. Sebuah unit tes adalah seperangkat satu atau lebih modul yang membentuk perangkat lunak di bawah

test (SUT). Identifikasi unit tes menetapkan berbagai tingkat

pengujian yang akan dilakukan dalam proyek. Umumnya, sejumlah unit uji

terbentuk selama pengujian, mulai dari modul-tingkat yang lebih rendah, yang memiliki

menjadi unit diuji. Artinya, pertama modul yang harus diuji secara individual

ditetapkan sebagai unit tes. Kemudian unit-tingkat yang lebih tinggi ditentukan, yang mungkin

menjadi kombinasi dari unit sudah diuji atau menggabungkan beberapa sudah diuji

unit dengan beberapa modul belum teruji. Ide dasar di balik unit tes pembentuk

memastikan bahwa pengujian yang dilakukan secara bertahap, dengan kenaikan masing-masing

termasuk hanya beberapa aspek yang perlu diuji.

Merupakan faktor penting saat membentuk unit adalah "testability" dari unit. SEBUAH

Unit harus sedemikian rupa sehingga dapat dengan mudah diuji. Dengan kata lain, itu harus

mungkin untuk membentuk bermakna kasus uji dan melaksanakan unit tanpa banyak usaha

dengan uji kasus ini. Misalnya, sebuah modul yang memanipulasi data yang kompleks

struktur yang terbentuk dari input file dengan modul masukan mungkin tidak cocok

Unit dari sudut pandang testability, sebagai pembentuk uji bermakna kasus untuk

unit akan sulit, dan sopir rutinitas akan harus ditulis untuk mengkonversi

masukan dari file atau terminal yang diberikan oleh tester ke struktur data

cocok untuk modul. Dalam hal ini, mungkin akan lebih baik untuk membentuk unit dengan

termasuk modul input juga. Kemudian masukan berkas yang diharapkan oleh input

Modul dapat berisi uji kasus.

Fitur yang akan diuji mencakup semua fitur perangkat lunak dan kombinasi fitur

yang harus diuji. Sebuah fitur perangkat lunak adalah karakteristik software tertentu

atau tersirat oleh persyaratan atau dokumen desain. Ini mungkin termasuk

fungsionalitas, kinerja, kendala desain, dan atribut.  Pendekatan untuk pengujian menentukan pendekatan keseluruhan yang harus diikuti dalam

proyek saat ini. Teknik-teknik yang akan digunakan untuk menilai upaya pengujian

juga harus ditentukan. Hal ini kadang-kadang disebut kriteria pengujian atau

kriteria untuk mengevaluasi set kasus uji yang digunakan dalam pengujian. Pada sebelumnya

bagian kita bahas banyak kriteria untuk mengevaluasi dan memilih uji kasus.

kiriman pengujian harus ditentukan dalam rencana uji sebelum yang sebenarnya

pengujian dimulai. Kiriman bisa menjadi daftar kasus uji yang digunakan, rinci

Hasil pengujian termasuk daftar cacat yang ditemukan, ringkasan laporan tes, dan

Data tentang cakupan kode.

Rencana uji biasanya juga menentukan jadwal dan upaya untuk dibelanjakan pada

kegiatan yang berbeda dari pengujian, dan alat-alat yang akan digunakan. Jadwal ini harus

konsisten dengan jadwal proyek secara keseluruhan. Rencana rinci mungkin daftar

semua tugas pengujian dan mengalokasikan mereka untuk menguji sumber daya yang bertanggung jawab

untuk melakukan mereka. Banyak produk besar memiliki tim pengujian terpisah dan

Oleh karena itu rencana tes terpisah. Sebuah proyek yang lebih kecil mungkin termasuk rencana tes sebagai

bagian dari rencana kualitas dalam rencana manajemen proyek.

Pendekatan untuk pengujian menentukan pendekatan keseluruhan yang harus diikuti dalam

proyek saat ini. Teknik-teknik yang akan digunakan untuk menilai upaya pengujian

juga harus ditentukan. Hal ini kadang-kadang disebut kriteria pengujian atau

kriteria untuk mengevaluasi set kasus uji yang digunakan dalam pengujian. Pada sebelumnya

bagian kita bahas banyak kriteria untuk mengevaluasi dan memilih uji kasus.

kiriman pengujian harus ditentukan dalam rencana uji sebelum yang sebenarnya

pengujian dimulai. Kiriman bisa menjadi daftar kasus uji yang digunakan, rinci

Hasil pengujian termasuk daftar cacat yang ditemukan, ringkasan laporan tes, dan

Data tentang cakupan kode.

Rencana uji biasanya juga menentukan jadwal dan upaya untuk dibelanjakan pada

kegiatan yang berbeda dari pengujian, dan alat-alat yang akan digunakan. Jadwal ini harus

konsisten dengan jadwal proyek secara keseluruhan. Rencana rinci mungkin daftar

semua tugas pengujian dan mengalokasikan mereka untuk menguji sumber daya yang bertanggung jawab

untuk melakukan mereka. Banyak produk besar memiliki tim pengujian terpisah dan

Oleh karena itu rencana tes terpisah. Sebuah proyek yang lebih kecil mungkin termasuk rencana tes sebagai

bagian dari rencana kualitas dalam rencana manajemen proyek.

8.2.2 Uji Desain Case

Rencana uji berfokus pada bagaimana pengujian untuk proyek tersebut akan dilanjutkan, yang

unit akan diuji, dan pendekatan apa (dan alat) yang akan digunakan selama

berbagai tahap pengujian. Namun, itu tidak berurusan dengan rincian pengujian

unit, juga tidak menentukan uji kasus yang akan digunakan.

desain kasus uji harus dilakukan secara terpisah untuk masing-masing unit. Berdasarkan

Pendekatan yang ditentukan dalam rencana uji, dan fitur yang akan diuji, kasus uji

dirancang dan ditetapkan untuk menguji unit. Uji kasus spesifikasi memberi,

untuk setiap unit yang akan diuji, semua kasus uji, masukan yang akan digunakan dalam kasus tes,

kondisi sedang diuji oleh ujian, dan hasil yang diharapkan untuk tes mereka

kasus. Jika uji kasus yang ditentukan dalam dokumen, spesifikasi terlihat seperti

tabel bentuk yang ditunjukkan pada Gambar 8.2.

putaran yang berbeda dari pengujian. Artinya, kadang-kadang dokumen spesifikasi kasus uji

juga digunakan untuk merekam hasil pengujian. Dalam putaran pengujian,

hasil dari semua kasus uji dicatat (yaitu, lulus atau gagal). Mudah-mudahan, dalam beberapa

putaran semua kasus uji akan berlalu.

Dengan kerangka pengujian dan pengujian otomatis, script pengujian dapat

dianggap sebagai spesifikasi ujian, karena mereka jelas menunjukkan apa yang input

yang diberikan dan apa output yang diharapkan. Dengan komentar yang sesuai, maksud dari

kasus uji juga dapat dengan mudah ditentukan.

desain kasus uji merupakan kegiatan utama dalam proses pengujian. seleksi yang seksama

kasus uji yang memenuhi kriteria dan pendekatan tertentu sangat penting untuk

pengujian yang tepat. Kami kemudian akan mempertimbangkan teknik yang berbeda untuk merancang baik

uji kasus.

Ada beberapa alasan bagus mengapa kasus uji yang ditentukan sebelum mereka

digunakan untuk pengujian. Hal ini diketahui bahwa pengujian memiliki keterbatasan parah dan efektivitas

pengujian sangat bergantung pada sifat yang tepat dari uji kasus.

Oleh karena itu penting untuk memastikan bahwa himpunan kasus uji yang digunakan adalah dari tinggi

kualitas. Evaluasi kasus uji sering dilakukan melalui review uji kasus. Sebagai

untuk setiap review, dokumen atau pekerjaan produk formal diperlukan, untuk meninjau

uji kasus, tes dokumen kasus spesifikasi diperlukan. Ini adalah utama

Alasan untuk mendokumentasikan kasus uji. Dokumen uji kasus spesifikasi

Ulasan, menggunakan proses formil, untuk memastikan bahwa uji kasus yang

konsisten dengan kebijakan yang ditetapkan dalam rencana, memenuhi kriteria yang dipilih, dan

mencakup berbagai aspek unit yang akan diuji. Dengan meninjau kondisi

sedang diuji oleh kasus uji, pengulas juga dapat memeriksa apakah semua penting

kondisi sedang diuji.

Alasan lain untuk menentukan kasus uji dalam sebuah dokumen atau naskah adalah

bahwa dengan melakukan hal ini, tester dapat melihat pengujian unit dalam totalitas dan

efek dari total set uji kasus. Jenis evaluasi ini sulit dilakukan di

on-the-fly pengujian di mana kasus uji ditentukan sebagai hasil pengujian. Juga

memungkinkan mengoptimalkan jumlah kasus uji evaluasi dari test suite mungkin

menunjukkan bahwa beberapa kasus uji yang berlebihan.

Eksekusi 8.2.3 Uji Kasus

Dengan spesifikasi kasus uji, langkah berikutnya dalam proses pengujian adalah untuk

mengeksekusi mereka. Langkah ini juga tidak mudah. Spesifikasi kasus uji

hanya menentukan set kasus uji untuk unit yang akan diuji. Namun, mengeksekusi

uji kasus mungkin memerlukan pembangunan modul driver atau bertopik. Mungkin juga

membutuhkan modul untuk mengatur lingkungan sebagaimana tercantum dalam rencana uji dan uji

spesifikasi kasus. Hanya setelah semua ini siap bisa uji kasus dieksekusi  Jika kerangka uji yang digunakan, maka pengaturan lingkungan sebagai

serta masukan untuk kasus uji sudah dilakukan di skrip pengujian, dan eksekusi

sangat mudah.

Selama tes eksekusi kasus, cacat yang ditemukan. Cacat ini kemudian diperbaiki

dan tesing dilakukan lagi untuk memverifikasi perbaikan. Untuk memfasilitasi pelaporan dan pelacakan

cacat yang ditemukan selama pengujian (dan kegiatan pengendalian mutu lainnya), cacat yang ditemukan

sering login. Cacat logging sangat penting dalam suatu perangkat lunak besar

proyek yang mungkin memiliki ratusan atau ribuan cacat yang ditemukan oleh

orang yang berbeda pada berbagai tahap proyek. Seringkali orang yang perbaikan yang

cacat bukan orang yang menemukan atau melaporkan cacat. Misalnya, tester

mungkin menemukan cacat sementara pengembang kode sebenarnya memperbaikinya. Di

seperti skenario, pelaporan cacat dan penutupan tidak bisa dilakukan secara informal. Itu

penggunaan mekanisme informal dapat dengan mudah menyebabkan cacat yang ditemukan namun kemudian

dilupakan, sehingga cacat tidak mendapatkan dihapus atau usaha ekstra dalam temuan

cacat lagi. Oleh karena itu, cacat yang ditemukan harus dicatat dengan baik dalam sistem

dan penutupan mereka dilacak. Cacat logging dan pelacakan dianggap salah satu

praktik terbaik untuk mengelola proyek [17], dan diikuti oleh perangkat lunak yang paling

organisasi.

Mari kita memahami siklus hidup cacat. Sebuah cacat dapat ditemukan dengan

siapa pun kapan saja. Ketika cacat yang ditemukan, maka login kontrol cacat

sistem, bersama dengan informasi yang cukup tentang cacat. cacat kemudian

di negara "yang disampaikan," pada dasarnya menyiratkan bahwa telah login bersama

dengan informasi tentang hal itu. Pekerjaan memperbaiki cacat tersebut kemudian ditugaskan untuk beberapa

orang, yang umumnya penulis dokumen atau kode yang cacat

ditemukan. Orang yang ditugaskan melakukan debugging dan perbaikan cacat dilaporkan,

dan cacat kemudian memasuki "tetap" negara. Namun, cacat yang tetap adalah

masih tidak dianggap sebagai dilakukan sepenuhnya. Penetapan sukses cacat diverifikasi.

Verifikasi ini dapat dilakukan oleh orang lain (sering submitter), atau oleh

tim uji, dan biasanya melibatkan menjalankan beberapa tes. Setelah cacat memperbaiki adalah

diverifikasi, maka cacat dapat ditandai sebagai "tertutup." Dengan kata lain, umum

Siklus hidup cacat memiliki tiga negara-diajukan, tetap, dan ditutup, seperti yang ditunjukkan

pada Gambar 8.3. Sebuah cacat yang tidak tertutup juga disebut terbuka.

Mis, [58]). Idealnya, pada akhir proyek, tidak ada cacat terbuka harus tetap.

Namun, situasi yang ideal ini sering tidak praktis untuk sistem yang paling besar.

Selain menggunakan log untuk melacak cacat, data di log juga bisa

digunakan untuk tujuan analisis. Kami akan membahas beberapa analisis mungkin nanti di

bab

Pengujian 8.3 Black-Box

Sebagaimana telah kita lihat, baik desain kasus uji adalah kunci untuk pengujian sesuai SUT.

Tujuannya saat uji coba SUT adalah untuk mendeteksi sebagian besar (mudah-mudahan semua) dari cacat,

melalui sekecil serangkaian uji kasus mungkin. Karena tujuan dasar ini,

penting untuk memilih kasus uji dengan hati-hati-yang terbaik adalah uji kasus-kasus yang memiliki

probabilitas tinggi mendeteksi cacat, jika ada, dan juga yang eksekusi

akan memberikan keyakinan bahwa tidak ada kegagalan selama pengujian menunjukkan bahwa ada beberapa

(Mudah-mudahan tidak ada) cacat dalam perangkat lunak.

Ada dua pendekatan dasar untuk merancang uji kasus untuk digunakan dalam

pengujian: black-box dan white-box. Dalam kotak hitam pengujian struktur

Program tidak dianggap. Uji kasus diputuskan hanya berdasarkan dari

persyaratan atau spesifikasi program atau modul, dan internal

modul atau program tidak dipertimbangkan untuk pemilihan kasus uji. Di dalam

bagian, kami akan menyajikan beberapa teknik untuk menghasilkan kasus uji untuk kotak hitam

pengujian. pengujian kotak putih dibahas pada bagian berikutnya.

Dalam pengujian black-box, tester hanya tahu masukan yang bisa diberikan kepada

sistem dan apa keluaran sistem harus memberikan. Dengan kata lain, dasar

untuk memutuskan uji kasus adalah persyaratan atau spesifikasi dari sistem atau

modul. Bentuk pengujian juga disebut uji fungsional atau perilaku.

Prosedur pengujian fungsional yang paling jelas adalah pengujian mendalam, yang

tidak praktis. Salah satu kriteria untuk menghasilkan uji kasus adalah untuk menghasilkan mereka secara acak.

Strategi ini memiliki sedikit kesempatan untuk menghasilkan satu set kasus uji yang

dekat optimal (yaitu, yang mendeteksi kesalahan maksimum dengan uji minimum

kasus). Oleh karena itu, kita perlu beberapa kriteria lain atau aturan untuk memilih uji kasus.

Tidak ada aturan resmi untuk merancang uji kasus untuk pengujian fungsional. Namun,

ada sejumlah teknik atau heuristik yang dapat digunakan untuk memilih

uji kasus yang telah ditemukan untuk menjadi sangat sukses dalam mendeteksi kesalahan. Sini

kami menyebutkan beberapa teknik ini.

8.3.1 Equivalence Class Partisi

Karena kita tidak dapat melakukan pengujian mendalam, pendekatan alami berikutnya adalah membagi

domain input ke dalam satu set kelas kesetaraan, sehingga jika karya Program

benar untuk nilai, maka akan bekerja dengan benar untuk semua nilai-nilai lain dalam

kelas. Jika kita memang bisa mengidentifikasi kelas tersebut, maka pengujian program dengan satu

Nilai dari masing-masing kelas kesetaraan setara dengan melakukan tes lengkap

program.

Namun, tanpa melihat struktur internal program, itu adalah

mungkin untuk menentukan kelas kesetaraan yang ideal seperti (bahkan dengan internal

struktur, biasanya tidak bisa dilakukan). Metode kesetaraan kelas partisi

[68] mencoba untuk mendekati ideal ini. Kelas kesetaraan terbentuk dari input

dimana perilaku sistem ditentukan atau diharapkan untuk menjadi serupa. Setiap

kelompok masukan yang perilaku tersebut diharapkan akan berbeda dari orang lain

dianggap sebagai kelas kesetaraan yang terpisah. Dasar pemikiran pembentukan kesetaraan

kelas seperti ini adalah asumsi bahwa jika spesifikasi memerlukan sama

perilaku untuk setiap elemen dalam kelas nilai-nilai, maka program akan cenderung

dibangun sehingga baik berhasil atau gagal untuk masing-masing nilai di kelas itu.

Misalnya, spesifikasi modul yang menentukan nilai absolut

untuk bilangan bulat menentukan satu perilaku untuk bilangan bulat positif dan satu lagi untuk negatif

bilangan bulat. Dalam hal ini, kita akan membentuk dua kesetaraan kelas-satu yang terdiri dari

bilangan bulat positif dan terdiri lainnya dari bilangan bulat negatif.

Untuk perangkat lunak yang kuat, kita juga harus mempertimbangkan masukan tidak valid. Artinya, kita harus

mendefinisikan kelas kesetaraan untuk input tidak valid juga.

kelas kesetaraan biasanya dibentuk dengan mempertimbangkan setiap kondisi yang ditentukan

pada masukan sebagai menentukan kelas kesetaraan valid dan satu atau lebih valid

kelas kesetaraan. Sebagai contoh, jika kondisi masukan menentukan rentang nilai

(Katakanlah, 0 <count <Max), kemudian membentuk kelas kesetaraan valid dengan kisaran yang

dan dua kelas kesetaraan tidak valid, satu dengan nilai kurang dari batas bawah

rentang (yaitu, menghitung <0) dan yang lainnya dengan nilai yang lebih tinggi daripada yang lebih tinggi

terikat (hitung> Max). Jika input menetapkan seperangkat nilai-nilai dan persyaratan

menentukan perilaku yang berbeda untuk unsur yang berbeda di set, maka berlaku

kelas kesetaraan dibentuk untuk masing-masing elemen dalam set dan tidak valid

kelas untuk suatu entitas yang tidak termasuk ke set.

Salah satu pendekatan umum untuk menentukan kelas kesetaraan adalah sebagai berikut. Jika

ada alasan untuk percaya bahwa seluruh rentang input tidak akan diperlakukan

dengan cara yang sama, maka kisaran harus dipecah menjadi dua atau lebih kesetaraan

kelas, masing-masing terdiri dari nilai-nilai yang perilaku diharapkan untuk menjadi serupa.

Misalnya, untuk input karakter, jika kita memiliki alasan untuk percaya bahwa

Program akan melakukan tindakan yang berbeda jika karakter adalah huruf, angka, atau

karakter khusus, maka kita harus membagi input menjadi tiga kesetaraan valid kelas.

Pendekatan lain untuk membentuk kelas kesetaraan adalah untuk mempertimbangkan khusus

nilai yang perilaku dapat berbeda sebagai kelas kesetaraan. Untuk

Misalnya, nilai 0 bisa menjadi nilai khusus untuk input integer.

Juga, untuk setiap kelas kesetaraan valid, satu atau lebih valid kesetaraan kelas

harus diidentifikasi.

Hal ini sering berguna untuk mempertimbangkan kelas kesetaraan dalam output. Untuk output

kelas kesetaraan, tujuannya adalah untuk memiliki input sehingga output untuk tes yang

Kasus terletak di kelas keluaran kesetaraan. Sebagai contoh, pertimbangkan sebuah program untuk

menentukan tingkat pengembalian untuk beberapa investasi. Ada tiga keluaran jelas

tingkat kesetaraan kelas-positif pengembalian, tingkat pengembalian negatif, dan nol

tingkat pengembalian. Selama pengujian, penting untuk menguji masing-masing, yang

adalah, memberi masukan sehingga masing-masing tiga output ini dihasilkan. Menentukan

uji kasus untuk kelas keluaran mungkin lebih sulit, tetapi kelas keluaran memiliki

telah ditemukan untuk mengungkapkan kesalahan yang tidak diungkapkan oleh hanya mempertimbangkan input

kelas.

Setelah kelas kesetaraan yang dipilih untuk masing-masing input, maka masalah

adalah untuk memilih kasus uji sesuai. Ada berbagai cara untuk memilih uji kasus.

Salah satu strategi adalah memilih setiap kasus uji yang mencakup sebanyak kesetaraan valid

kelas karena dapat, dan satu kasus tes terpisah untuk setiap kelas kesetaraan tidak valid.

Strategi agak lebih baik yang membutuhkan lebih banyak uji kasus adalah memiliki kasus uji

menutupi paling banyak satu kelas kesetaraan berlaku untuk setiap masukan, dan memiliki satu terpisah

kasus uji untuk setiap kelas kesetaraan tidak valid. Dalam kasus terakhir, jumlah uji

kasus untuk kelas kesetaraan berlaku adalah sama dengan jumlah terbesar dari kesetaraan

kelas untuk setiap masukan, ditambah jumlah total kelas kesetaraan tidak valid.

Sebagai contoh, mempertimbangkan program yang mengambil dua input-string s dari

panjang sampai dengan N dan integer n. Program ini adalah untuk menentukan n atas

tertinggi terjadi karakter dalam s. tester percaya bahwa programmer

mungkin berurusan dengan berbagai jenis karakter secara terpisah. Satu set valid dan

kelas kesetaraan tidak valid untuk ini dapat dilihat pada Tabel 8.1.

Dengan ini sebagai kelas ekivalen, kita harus memilih uji kasus. SEBUAH

kasus uji untuk ini adalah sepasang nilai untuk s dan n. Dengan strategi pertama untuk

memutuskan uji kasus, satu kasus uji dapat: s sebagai string panjang kurang dari

N yang mengandung huruf kecil, huruf besar, angka, dan karakter khusus; dan n sebagai

jumlah 5. uji kasus satu ini meliputi semua kelas kesetaraan yang valid (EQ1

melalui EQ6). Kemudian kita akan memiliki satu kasus uji masing-masing untuk menutupi IEQ1, IEQ2,

dan IEQ3. Artinya, total empat kasus uji yang dibutuhkan.

Dengan pendekatan kedua, dalam satu kasus uji kita dapat menutupi satu kesetaraan

kelas untuk satu masukan saja. Jadi, satu kasus uji dapat: string angka, dan

jumlah 5. Ini mencakup EQ1 dan EQ6. Maka kita akan membutuhkan uji kasus untuk EQ2

melalui EQ5, dan uji kasus terpisah untuk IEQ1 melalui IEQ3.

8.3.2 Analisis Nilai Batas

Ia telah mengamati bahwa program yang bekerja dengan benar untuk satu set nilai-nilai di

kelas kesetaraan gagal pada beberapa nilai khusus. Nilai-nilai ini sering berbaring di

batas dari kelas kesetaraan. Uji kasus yang memiliki nilai-nilai pada batas-batas

kesetaraan kelas karena itu cenderung "-yield tinggi" uji kasus, dan

memilih uji kasus tersebut adalah tujuan dari analisis nilai batas. dalam batas

analisis nilai [68], kita memilih masukan untuk kasus uji dari kesetaraan

kelas, sehingga input terletak di tepi kelas ekivalen. Batas

nilai untuk setiap kelas kesetaraan, termasuk kelas ekivalen dari output,

harus ditutup. batas nilai uji kasus juga disebut "kasus-kasus ekstrim."

Oleh karena itu, kita dapat mengatakan bahwa kasus uji batas nilai adalah seperangkat input data yang

terletak di tepi atau batas dari kelas data input atau yang menghasilkan keluaran

yang terletak pada batas kelas data output.

Dalam kasus rentang, untuk analisis nilai batas hal ini berguna untuk memilih

elemen batas jangkauan dan nilai yang tidak valid hanya di luar kedua ujung

(Untuk dua kelas kesetaraan tidak valid). Jadi, jika kisaran adalah 0,0? x? 1.0, maka

uji kasus yang 0,0, 1,0 (input valid), dan -0.1, dan 1,1 (untuk input tidak valid).

Demikian pula, jika input adalah daftar, perhatian harus difokuskan pada pertama dan terakhir

elemen daftar. Kami juga harus mempertimbangkan output untuk analisis nilai batas. Jika

kelas kesetaraan dapat diidentifikasi dalam output, kita harus mencoba untuk menghasilkan uji

kasus yang akan menghasilkan output yang terletak pada batas kesetaraan yang

kelas. Selain itu, kami harus mencoba untuk membentuk uji kasus yang akan menghasilkan

output yang tidak terletak pada kelas kesetaraan. (Jika kita dapat menghasilkan masukan

Kasus yang menghasilkan output di luar kelas kesetaraan, kami telah mendeteksi

kesalahan.)

Seperti di kesetaraan kelas partisi, dalam analisis nilai batas kami pertama kali.

menentukan nilai untuk masing-masing variabel yang harus dilakukan selama pengujian.

Jika ada beberapa masukan, lalu bagaimana seharusnya set kasus uji terbentuk

meliputi nilai batas? Misalkan setiap variabel masukan memiliki jangkauan yang ditetapkan.

Kemudian ada enam nilai-batas ujung ekstrim dari jangkauan, hanya di luar

ujungnya, dan sebelum berakhir. Jika berbagai integer adalah min ke max,

maka enam nilai-nilai min-1, min, min + 1, max-1, max, max + 1. Seharusnya

ada n variabel input tersebut. Ada dua strategi untuk menggabungkan

nilai batas untuk variabel yang berbeda dalam kasus uji.

Dalam strategi pertama, kita pilih nilai batas yang berbeda untuk satu variabel,

dan menjaga variabel lain di beberapa nilai nominal. Dan kita pilih satu kasus uji

yang terdiri dari nilai nominal semua variabel. Dalam hal ini, kita akan memiliki 6n + 1

uji kasus. Untuk dua variabel X dan Y, 13 kasus tes akan seperti yang ditunjukkan pada

Gambar 8.4.

Gambar 8.4: Uji kasus untuk analisis nilai batas.

Strategi lain akan mencoba semua kemungkinan kombinasi untuk nilai untuk

variabel yang berbeda. Karena ada tujuh nilai untuk setiap variabel (enam batas

nilai-nilai dan satu nilai nominal), jika ada n variabel, akan ada total

uji 7N kasus-terlalu besar untuk pengujian praktis.

8.3.3 Berpasangan Pengujian

Ada umumnya banyak parameter yang menentukan perilaku perangkat lunak

sistem. Parameter ini bisa menjadi masukan langsung ke perangkat lunak atau implisit

pengaturan seperti yang untuk perangkat. Parameter ini dapat mengambil nilai yang berbeda, dan

untuk beberapa dari mereka perangkat lunak mungkin tidak bekerja dengan benar. Banyak cacat di

software umumnya melibatkan satu syarat, yaitu, beberapa nilai khusus salah satu.

parameter. cacat seperti ini disebut kesalahan single-mode [70]. contoh sederhana

dari single-mode kesalahan yang lunak tidak mampu mencetak untuk jenis tertentu dari

printer, sebuah perangkat lunak yang tidak dapat menghitung ongkos benar ketika wisatawan adalah

minor, dan perangkat lunak penagihan telepon yang tidak menghitung tagihan dengan benar

untuk negara tertentu.

kesalahan single-mode dapat dideteksi dengan menguji untuk nilai yang berbeda dari yang berbeda

parameter. Jadi, jika ada n parameter untuk sistem, dan masing-masing dari

mereka dapat mengambil nilai-nilai m yang berbeda (atau m kelas yang berbeda dari nilai-nilai, masing-masing kelas

yang dianggap sebagai yang sama untuk tujuan pengujian seperti di kelas kesetaraan

partisi), maka dengan setiap kasus uji kita dapat menguji satu nilai yang berbeda dari masing-masing

parameter. Dengan kata lain, kita dapat menguji untuk semua nilai yang berbeda di tes m

kasus.

Namun, semua kesalahan yang tidak single-mode dan ada kombinasi dari input

yang mengungkapkan adanya kesalahan: misalnya, perangkat lunak penagihan telepon yang

tidak menghitung dengan benar untuk malam panggilan (satu parameter) ke tertentu

negara (parameter lain), atau sistem tiket maskapai penerbangan yang memiliki salah

perilaku ketika kecil (satu parameter) adalah perjalanan kelas bisnis (lain

parameter) dan tidak tinggal selama akhir pekan (parameter ketiga). multimode ini

kesalahan dapat terungkap selama pengujian dengan mencoba kombinasi yang berbeda dari

nilai-parameter pendekatan yang disebut pengujian kombinatorial.

Sayangnya, pengujian kombinasi penuh sering tidak layak. Untuk sistem

dengan n parameter, masing-masing memiliki nilai-nilai m, jumlah kombinasi yang berbeda

adalah nm. Untuk sistem sederhana dengan 5 parameter, masing-masing memiliki 5 nilai yang berbeda,

jumlah total kombinasi adalah 3.125. Dan jika pengujian setiap kombinasi

membutuhkan waktu 5 menit, itu akan mengambil alih 1 bulan untuk menguji semua kombinasi. Jelas,

untuk sistem yang kompleks yang memiliki banyak parameter dan masing-masing parameter mungkin memiliki

banyak nilai, pengujian kombinatorial penuh tidak layak dan praktis teknik

diperlukan untuk mengurangi jumlah tes.

Beberapa penelitian telah menunjukkan bahwa sebagian besar kesalahan software yang terungkap pada beberapa

khusus nilai tunggal atau oleh interaksi dari sepasang nilai [25]. Itu, sebagian besar

kesalahan cenderung baik single-mode atau double-mode. Untuk pengujian untuk doublemode

kesalahan, kita tidak perlu menguji sistem dengan semua kombinasi parameter

nilai-nilai, tetapi perlu menguji sehingga semua kombinasi nilai untuk setiap pasangan

parameter tersebut dilakukan. Ini disebut pengujian berpasangan. Dalam pengujian berpasangan, semua pasangan nilai harus dilakukan selama pengujian. Jika

ada n parameter, masing-masing dengan nilai-nilai m, kemudian antara setiap dua parameter

kita harus m? pasang m. Parameter pertama akan memiliki ini banyak pasangan dengan masing-masing

dari n yang tersisa - 1 parameter, yang kedua akan memiliki pasangan baru dengan

n - 2 parameter (sebagai pasangan dengan yang pertama sudah termasuk dalam pertama

pasang parameter), ketiga akan memiliki pasangan dengan n - 3 parameter, dan sebagainya.

Artinya, jumlah pasangan adalah m? m? n? (N - 1) / 2.

Tujuan dari pengujian berpasangan adalah untuk memiliki satu set kasus uji yang mencakup semua

pasangan. Karena ada n parameter, kasus uji adalah kombinasi dari nilai-nilai

parameter ini dan akan mencakup (n-1) + (n-2) + ... = n (n-1) / 2 pasang. Dalam

kasus terbaik ketika masing-masing pasangan ditutupi tepat sekali oleh salah satu ujian, m2 yang berbeda

uji kasus akan diperlukan untuk menutupi semua pasangan.

Sebagai contoh, pertimbangkan produk perangkat lunak yang dikembangkan untuk beberapa

platform yang menggunakan browser sebagai interface-nya. Misalkan perangkat lunak yang

dirancang untuk bekerja selama tiga sistem operasi yang berbeda dan tiga yang berbeda

browser. Selain itu, sebagai produk memori intensif ada keinginan untuk

menguji kinerjanya di bawah tingkat yang berbeda dari memori. Jadi, kita memiliki berikut

tiga parameter dengan nilai-nilai yang berbeda:

Sistem operasi: Windows, Solaris, Linux

Ukuran memori: 128M, 256M, 512M

Browser: IE, Netscape, Mozilla

Untuk diskusi, kita dapat mengatakan bahwa sistem memiliki tiga parameter: A (operasi

sistem), B (ukuran memori), dan C (browser). Masing-masing dapat memiliki

tiga nilai yang akan kita sebut sebagai a1, a2, a3, b1, b2, b3, dan c1, c2, c3. Itu

jumlah total kombinasi berpasangan adalah 9 * 3 = 27. Jumlah kasus uji,

Namun, untuk menutupi semua pasangan jauh lebih sedikit. Sebuah ujian yang terdiri dari nilai-nilai

dari tiga parameter meliputi tiga kombinasi (A-B, B-C, dan A-C).

Oleh karena itu, dalam kasus terbaik, kita dapat mencakup semua 27 kombinasi dengan 27/3 = 9 kasus uji.

uji kasus ini ditunjukkan pada Tabel 8.2, bersama dengan pasangan mereka menutupi.  Seperti harus jelas, menghasilkan uji kasus untuk menutupi semua pasangan tidak sederhana

tugas. Minimum set kasus uji adalah bahwa di mana masing-masing pasangan ditutupi oleh

tepat satu kasus uji. Seringkali, hal itu tidak akan mungkin untuk menghasilkan set minimum

kasus uji, terutama ketika jumlah nilai parameter yang berbeda  berbeda. Berbagai algoritma telah diusulkan, dan beberapa program yang

tersedia secara online untuk menghasilkan uji kasus untuk menutupi semua pasangan.

Untuk situasi di mana generasi panduan layak, pendekatan berikut

dapat diikuti. Mulailah dengan awal kasus uji dibentuk oleh semua kombinasi

nilai-nilai untuk dua parameter yang memiliki jumlah terbesar dari nilai-nilai (seperti

kita harus memiliki setidaknya ini banyak kasus tes untuk menguji semua pasangan untuk kedua

parameter). Kemudian menyelesaikan setiap kasus uji ini dengan menambahkan nilai lainnya

parameter sehingga mereka menambahkan pasangan yang belum tercakup oleh

Kasus cobaan. Ketika semua selesai, membentuk tambahan kasus uji dengan menggabungkan sebagai

banyak pasangan terungkap mungkin. Pada dasarnya kita menghasilkan uji kasus tersebut

bahwa ujian mencakup banyak pasangan baru sebanyak mungkin. Dengan menghindari meliputi

pasang beberapa kali, kita dapat menghasilkan satu set kecil kasus uji yang mencakup semua

pasang. algoritma efisien menghasilkan jumlah terkecil kasus uji untuk

pengujian berpasangan ada. Dalam [25] contoh diberikan di mana untuk 13 parameter,

masing-masing memiliki tiga nilai yang berbeda, semua pasangan akan dibahas dalam hanya 15 kasus uji,

sedangkan jumlah total kombinasi lebih dari 1 juta!

pengujian berpasangan adalah cara praktis untuk menguji sistem perangkat lunak besar yang

telah banyak parameter yang berbeda dengan fungsi yang berbeda diharapkan untuk berbeda

nilai-nilai. Sebuah contoh akan menjadi sistem penagihan (untuk telepon, hotel, maskapai penerbangan, dll)

yang memiliki tingkat yang berbeda untuk nilai parameter yang berbeda. Ini juga merupakan praktis

Pendekatan untuk produk perangkat lunak pengujian tujuan umum yang diharapkan

berjalan pada platform yang berbeda dan konfigurasi, atau sistem yang diharapkan

bekerja dengan berbagai jenis sistem.

8.3.4 Kasus Khusus

Telah terlihat bahwa program sering menghasilkan perilaku yang salah ketika input

membentuk beberapa kasus khusus. Alasannya adalah bahwa dalam program, beberapa kombinasi dari

input perlu perlakuan khusus, dan memberikan penanganan yang tepat untuk khusus ini

kasus mudah diabaikan. Sebagai contoh, dalam sebuah rutinitas aritmatika, jika ada

divisi dan pembagi adalah nol, beberapa tindakan khusus telah diambil, yang bisa

mudah dilupakan oleh programmer. Ini kasus khusus membentuk khususnya

baik uji kasus, yang dapat mengungkapkan kesalahan yang biasanya tidak terdeteksi oleh

uji kasus lainnya.

kasus khusus akan sering bergantung pada struktur data dan fungsi

modul. Tidak ada aturan untuk menentukan kasus-kasus khusus, dan penguji memiliki

untuk menggunakan intuisi dan pengalamannya untuk mengidentifikasi kasus-kasus seperti tes. Karena itu,

menentukan kasus khusus juga disebut kesalahan menebak.

Psikologi sangat penting untuk kesalahan menebak. tester harus

memainkan "pembela setan" dan mencoba untuk menebak asumsi yang salah yang  programmer bisa membuat dan situasi programmer bisa memiliki

diabaikan atau tidak ditangani secara benar. Pada dasarnya, tester sedang mencoba untuk mengidentifikasi

situasi rawan kesalahan. Kemudian uji kasus yang ditulis untuk situasi ini. Untuk

Misalnya, dalam masalah menemukan jumlah kata yang berbeda dalam file

(Dibahas dalam bab-bab sebelumnya) beberapa kasus khusus dapat: file kosong,

hanya satu kata dalam file, hanya satu kata dalam satu baris, beberapa baris kosong di input

File, kehadiran lebih dari satu kosong antara kata-kata, semua kata yang sama,

kata-kata yang sudah disortir, dan kosong di awal dan akhir file.

asumsi yang salah biasanya dibuat karena spesifikasi yang tidak

menyelesaikan atau penulis spesifikasi mungkin tidak telah menyatakan beberapa properti,

dengan asumsi mereka untuk menjadi jelas. Setiap kali ada ketergantungan pada pemahaman diam-diam

daripada pernyataan eksplisit dari spesifikasi, ada ruang untuk membuat salah

asumsi. Sering, asumsi yang salah yang dibuat tentang lingkungan.

Namun, harus dicatat bahwa kasus-kasus khusus sangat tergantung pada

masalah, dan tester harus benar-benar mencoba untuk "masuk ke sepatu" dari desainer

dan coder untuk menentukan kasus ini.

8.3.5 Pengujian Negara Berbasis

Ada beberapa sistem yang pada dasarnya stateless di bahwa untuk input yang sama

mereka selalu memberikan output yang sama atau menunjukkan perilaku yang sama. banyak bets

sistem pengolahan, sistem komputasi, dan server jatuh dalam kategori ini. Di

hardware, sirkuit kombinasi jatuh dalam kategori ini. Pada tingkat yang lebih kecil, yang paling

fungsi seharusnya berperilaku dengan cara ini. Namun demikian, banyak

sistem yang perilakunya negara-berbasis di bahwa untuk masukan identik mereka berperilaku

berbeda pada waktu yang berbeda dan dapat menghasilkan output yang berbeda. Alasannya

untuk perilaku yang berbeda adalah bahwa keadaan dari sistem mungkin berbeda. di lain

kata-kata, perilaku dan output dari sistem tidak hanya tergantung pada input

tersedia, tetapi juga pada keadaan dari sistem. Keadaan dari sistem tergantung

pada input terakhir sistem telah menerima. Dengan kata lain, negara merupakan

dampak kumulatif dari semua input terakhir pada sistem. Dalam perangkat keras,

sistem sekuensial jatuh dalam kategori ini. Dalam perangkat lunak, banyak sistem yang besar jatuh

kategori ini sebagai negara terakhir yang ditangkap di database atau file dan digunakan untuk kontrol

perilaku sistem. Untuk sistem seperti ini, pendekatan lain untuk memilih

uji kasus adalah berbasis negara pendekatan pengujian [22].

Secara teoritis, perangkat lunak yang menyelamatkan negara dapat dimodelkan sebagai mesin negara.

Namun, ruang keadaan dari setiap program yang wajar adalah hampir tak terbatas,

karena merupakan produk silang dari domain dari semua variabel yang membentuk negara.

Bagi banyak sistem ruang keadaan dapat dibagi menjadi beberapa negara, masing-masing

mewakili kombinasi logis dari nilai-nilai variabel negara yang berbeda yang  berbagi beberapa properti yang menarik [9]. Jika himpunan negara dari suatu sistem adalah dikelola,

model keadaan dari sistem dapat dibangun. Sebuah model negara untuk sistem memiliki

empat komponen:

- Serikat. Merupakan dampak dari input masa lalu ke sistem.

- Transisi. Mewakili bagaimana keadaan sistem berubah dari satu negara

yang lain dalam menanggapi beberapa peristiwa.

- Acara. Input ke sistem.

- Tindakan. Output untuk acara.

Model negara menunjukkan apa yang terjadi transisi negara dan tindakan apa yang

dilakukan dalam suatu sistem dalam menanggapi peristiwa. Ketika model negara dibangun dari

persyaratan sistem, kita hanya dapat mencakup negara-negara, transisi, dan

tindakan yang dinyatakan dalam persyaratan atau dapat disimpulkan dari mereka. Jika

informasi lebih lanjut tersedia dari spesifikasi desain, maka keadaan kaya

Model dapat dibangun.

Misalnya, pertimbangkan contoh survei mahasiswa dibahas dalam Bab 5.

Menurut persyaratan, sistem yang akan dibuat untuk mengambil siswa

survei. Siswa mengambil survei dan dikembalikan hasil saat ini

survei. Hasil survei dapat menjadi tua sampai lima survei. Kami menganggap arsitektur

yang memiliki cache antara server dan database, dan di mana

survei dan hasil cache dan diperbarui hanya setelah lima survei, pada saat kedatangan

dari permintaan. arsitektur yang diusulkan memiliki database di belakang, yang mungkin

turun.

Untuk membuat model mesin negara dari sistem ini, kita melihat bahwa dari rangkaian

6 permintaan, pertama 5 dapat diperlakukan berbeda. Oleh karena itu, kita bagi menjadi dua

menyatakan: satu mewakili penerimaan dari 1 - 4 permintaan (state 1), dan

lainnya yang mewakili penerima permintaan 5 (state 2). Selanjutnya kita melihat bahwa

database dapat naik atau turun, dan itu bisa turun di setiap dari dua negara.

Namun, perilaku permintaan, jika database yang turun, mungkin berbeda.

Oleh karena itu, kita menciptakan sepasang negara (negara 3 dan 4). Setelah database memiliki

gagal, maka 5 permintaan pertama dilayani menggunakan data lama. Ketika suatu permintaan

menerima setelah menerima 5 permintaan, sistem memasuki negara gagal (state 5), di

yang tidak memberikan respon apapun. Ketika sistem pulih dari gagal

negara, itu harus segera memperbarui cache, maka pergi ke negara 2. Negara

Model untuk sistem ini ditunjukkan pada Gambar 8.5 (i merupakan masukan dari

pengguna untuk mengambil survei).

Perhatikan bahwa kita mengasumsikan bahwa model keadaan dari sistem dapat dibuat

dari spesifikasi atau desain. Ini adalah bagaimana sebagian besar pemodelan negara dilakukan, dan

itu adalah bagaimana model dibangun dalam contoh. Setelah model negara dibangun,

kita dapat menggunakannya untuk memilih uji kasus. Ketika desain diimplementasikan, tes ini

Gambar 8.5: Model Negara untuk sistem survei mahasiswa.

kasus dapat digunakan untuk menguji kode. Hal ini karena ini kita memperlakukan berbasis negara

pengujian sebagai strategi pengujian kotak hitam.

Namun, model negara sering membutuhkan informasi tentang desain

sistem. Dalam contoh di atas, beberapa pengetahuan tentang arsitektur digunakan.

Kadang-kadang membuat model negara mungkin memerlukan informasi rinci tentang

desain sistem. Misalnya, untuk kelas, kita telah melihat bahwa negara

pemodelan dilakukan selama desain, dan ketika banyak yang sudah diketahui tentang

kelas, atribut, dan metode. Karena ini, pengujian berbasis negara mungkin

dianggap sebagai agak antara kotak hitam dan pengujian kotak putih. Seperti itu

strategi kadang-kadang disebut abu-abu kotak pengujian.

Mengingat model keadaan sistem, bagaimana harus menguji kasus dihasilkan? Banyak

kriteria cakupan telah diusulkan [69]. Kami hanya membahas beberapa di sini. Seharusnya

set uji kasus T. Beberapa kriteria adalah:

- Semua cakupan transisi (AT). T harus memastikan bahwa setiap transisi dalam

Grafik negara dilaksanakan.

- Semua transisi pasangan cakupan (ATP). T harus melaksanakan semua pasangan yang berdekatan

transisi. (Sepasang transisi yang berdekatan terdiri dari dua transisi: suatu

transisi yang masuk ke negara dan transisi keluar dari negara itu.)

- Cakupan pohon Transisi (TT). T harus melaksanakan semua jalur sederhana, di mana

jalan yang sederhana adalah salah satu yang dimulai dari keadaan awal dan mencapai negara

bahwa ia telah dikunjungi di jalan ini atau keadaan akhir.

Kriteria pertama menyatakan bahwa selama pengujian semua transisi dipecat. Ini

juga akan memastikan bahwa semua negara yang dikunjungi. Cakupan Pasangan transisi adalah

Kriteria kuat mensyaratkan bahwa semua kombinasi yang masuk dan keluar  transisi untuk setiap negara harus dilakukan oleh T. Jika negara memiliki dua masuk

transisi t1 dan t2, dan dua transisi keluar t3 dan t4, kemudian satu set tes

kasus T yang mengeksekusi t1; t3 dan t2; t4 akan memuaskan AT. Namun, untuk memenuhi ATP,

T juga harus memastikan pelaksanaan t1; t4 dan t2; t3. Cakupan pohon transisi

bernama cara ini sebagai pohon transisi dapat dibangun dari grafik

dan kemudian digunakan untuk mengidentifikasi jalur. Di ATP, kita akan melampaui transisi,

dan menyatakan bahwa jalan yang berbeda dalam diagram negara harus dieksekusi selama

pengujian. ATP umumnya akan mencakup AT.

Untuk contoh di atas, himpunan kasus uji untuk AT diberikan di bawah pada Tabel

8.3. Berikut req () berarti bahwa permintaan untuk mengambil survei harus diberikan,

gagal () berarti bahwa database harus gagal, dan memulihkan () berarti bahwa

Database gagal harus dipulihkan.

Seperti yang kita lihat, pengujian berbasis negara menarik perhatian negara-negara dan transisi.

Bahkan dalam kasus sederhana di atas, kita dapat melihat skenario yang berbeda diuji

(Mis, perilaku sistem ketika database gagal, dan perilaku sistem ketika

gagal dan pulih setelah itu). Banyak dari skenario ini mudah untuk mengabaikan jika

uji kasus dirancang hanya dengan melihat domain input. Set uji

kasus lebih kaya jika kriteria lain yang digunakan. Untuk contoh ini, kita biarkan sebagai

latihan untuk menentukan kasus uji untuk kriteria lainnya.

Pengujian 8.4 White-Box

Pada bagian sebelumnya kita membahas pengujian black-box, yang berkaitan dengan

fungsi bahwa program diuji seharusnya melakukan dan tidak

berurusan dengan struktur internal program yang bertanggung jawab untuk benar-benar menerapkan

fungsi itu. Dengan demikian, pengujian black-box yang bersangkutan dengan fungsi

daripada pelaksanaan program. White-kotak pengujian, di sisi lain  tangan, berkaitan dengan pengujian pelaksanaan program. tujuannya

pengujian ini bukan untuk melaksanakan semua input atau output kondisi yang berbeda (meskipun

yang mungkin merupakan produk) tapi untuk melaksanakan pemrograman yang berbeda

struktur dan struktur data yang digunakan dalam program ini. Pengujian kotak putih juga

disebut pengujian struktural, dan kami akan menggunakan dua istilah bergantian.

Untuk menguji struktur dari sebuah program, pengujian struktural bertujuan untuk mencapai tes

kasus yang akan memaksa cakupan yang diinginkan dari struktur yang berbeda. berbagai kriteria

telah diusulkan untuk ini. Berbeda dengan kriteria pengujian fungsional, yang

sering tidak tepat, kriteria untuk pengujian struktural umumnya cukup

tepat karena mereka didasarkan pada struktur program, yang bersifat formal dan tepat.

Di sini kita akan membahas salah satu pendekatan untuk pengujian struktural: berbasis aliran kontrol

pengujian, yang paling umum digunakan dalam praktek.

8.4.1 Kriteria Flow Control Berbasis

Kriteria berbasis struktur yang paling umum didasarkan pada aliran kontrol

program. Dalam kriteria ini, grafik aliran kontrol dari program dianggap

dan cakupan berbagai aspek grafik ditetapkan sebagai kriteria. Karenanya,

sebelum kita mempertimbangkan kriteria, mari kita tepat menentukan grafik aliran kontrol untuk

sebuah program.

Biarkan grafik kontrol aliran (atau hanya mengalir grafik) dari program P G. A

node dalam grafik ini merupakan blok pernyataan yang selalu dieksekusi

bersama-sama, yaitu, setiap kali pernyataan pertama dijalankan, semua pernyataan lain

juga dieksekusi. Tepi (i, j) (dari simpul i ke simpul j) merupakan kemungkinan

transfer kontrol setelah mengeksekusi pernyataan terakhir dari blok diwakili

oleh simpul i ke pernyataan pertama dari blok yang diwakili oleh simpul j. Sebuah node

sesuai dengan blok yang pernyataan pertama adalah pernyataan awal P adalah

disebut node awal G, dan node sesuai dengan blok yang lalu

Pernyataan adalah pernyataan keluar disebut node keluar [73]. Sebuah jalan adalah terbatas

urutan node (n1, n2, ..., nk), k> 1, sehingga ada tepi (ni, ni + 1)

untuk semua node ni dalam urutan (kecuali node nk terakhir). Sebuah path lengkap adalah

jalan yang simpul pertama adalah awal node dan node terakhir adalah simpul keluar. Sekarang mari kita mempertimbangkan kriteria berbasis aliran kontrol. Mungkin cakupan yang paling sederhana

Kriteria adalah cakupan pernyataan, yang mensyaratkan bahwa setiap pernyataan dari

Program dilaksanakan setidaknya sekali selama pengujian. Dengan kata lain, itu membutuhkan

bahwa jalan dieksekusi selama pengujian mencakup semua node dalam grafik. Ini

juga disebut kriteria semua-node [73].

Kriteria cakupan ini tidak sangat kuat, dan dapat meninggalkan kesalahan terdeteksi.

Sebagai contoh, jika ada jika pernyataan dalam program tanpa memiliki lagi

klausa, kriteria cakupan pernyataan untuk pernyataan ini akan dipenuhi oleh kasus uji yang mengevaluasi kondisi true. Tidak ada kasus uji yang diperlukan yang memastikan

bahwa kondisi dalam laporan jika false. Ini adalah serius

kekurangan karena keputusan dalam program ini adalah potensi sumber kesalahan. Sebagai

contoh, pertimbangkan fungsi berikut untuk menghitung nilai absolut dari

jumlah:

int abs (x)

int x;

{

if (x >= 0) x = 0 - x;

return (x)

}Program ini jelas salah. Misalkan kita menjalankan fungsi dengan set uji kasus {x = 0} (yaitu, set hanya memiliki satu test case). Pernyataan

kriteria cakupan akan puas dengan menguji dengan set ini, tapi kesalahan akan

tidak terungkap.

Kriteria cakupan yang lebih umum adalah cakupan cabang, yang mengharuskan

setiap tepi dalam grafik kontrol aliran dilalui setidaknya sekali selama pengujian.

Dengan kata lain, cakupan cabang mensyaratkan bahwa setiap keputusan dalam program menjadi

dievaluasi untuk nilai-nilai benar dan salah setidaknya sekali selama pengujian. pengujian berdasarkan

pada cakupan cabang sering disebut pengujian cabang. Cakupan cabang 100%

Kriteria ini juga disebut kriteria all-tepi [73]. cakupan cabang menyiratkan pernyataan

cakupan, karena setiap pernyataan adalah bagian dari beberapa cabang. Dalam sebelumnya

Misalnya, satu set kasus uji memuaskan kriteria ini akan mendeteksi kesalahan.

Masalahnya dengan cakupan cabang datang jika keputusan memiliki banyak kondisi

di dalamnya (yang terdiri dari ekspresi Boolean dengan operator Boolean dan dan atau).

Dalam situasi seperti itu, keputusan dapat mengevaluasi untuk benar dan salah tanpa benar-benar

berolahraga semua kondisi. Sebagai contoh, perhatikan fungsi berikut yang

memeriksa validitas dari item data. Item data valid jika terletak antara 0

dan 100.

int check(x)

int x;

{

if ((x >= ) && (x <= 200))

check = True;

else check = False;

}

Modul ini tidak benar, seperti yang memeriksa x? 200 bukan 100 (mungkin

kesalahan pengetikan dibuat oleh programmer). Misalkan modul diuji dengan

set berikut kasus uji: {x = 5, x = -5}. Kriteria cakupan cabang

akan puas untuk modul ini dengan set ini. Namun, kesalahan tidak akan

mengungkapkan, dan perilaku modul konsisten dengan spesifikasinya

untuk semua kasus uji di set ini. Dengan demikian, kriteria cakupan puas, tetapi

Kesalahan tidak terdeteksi. Hal ini terjadi karena keputusan sedang mengevaluasi untuk benar dan

palsu karena kondisi (x? 0). Kondisi (x? 200) tidak pernah mengevaluasi

false selama tes ini, maka kesalahan dalam kondisi ini tidak terungkap.

Masalah ini dapat diatasi dengan mensyaratkan bahwa semua kondisi mengevaluasi

benar dan salah. Namun, situasi dapat terjadi di mana keputusan mungkin tidak mendapatkan

nilai-nilai baik benar dan salah bahkan jika setiap kondisi individu mengevaluasi untuk benar

dan palsu. Solusi yang jelas untuk masalah ini adalah dengan mewajibkan keputusan / kondisi

cakupan, di mana semua keputusan dan semua kondisi dalam keputusan mengambil

nilai-nilai benar dan salah selama pengujian.

Penelitian telah menunjukkan bahwa ada banyak kesalahan yang kehadirannya tidak terdeteksi

dengan pengujian cabang karena beberapa kesalahan terkait dengan beberapa kombinasi

cabang dan kehadiran mereka ini diungkapkan oleh sebuah eksekusi yang mengikuti jalan

yang meliputi cabang mereka. Oleh karena itu, kriteria cakupan yang lebih umum adalah salah satu

yang mengharuskan semua jalur yang mungkin dalam grafik kontrol aliran dilaksanakan selama

pengujian. Ini disebut kriteria cakupan jalur atau kriteria semua-jalan, dan

pengujian berdasarkan kriteria ini sering disebut pengujian jalan. kesulitan

dengan kriteria ini adalah bahwa program yang mengandung loop dapat memiliki tak terbatas

jumlah path yang mungkin. Selain itu, tidak semua jalur dalam grafik mungkin "layak"

dalam arti bahwa ada mungkin tidak ada masukan untuk jalan mana yang bisa

dieksekusi.

Sebagai kriteria cakupan jalur mengarah ke sejumlah berpotensi tak terbatas

jalur, beberapa upaya telah dilakukan untuk menunjukkan kriteria antara cabang

cakupan dan cakupan jalan. Tujuan dasar dari pendekatan ini adalah untuk memilih

mengatur jalur yang memastikan kriteria cakupan cabang dan mencoba beberapa jalur lain yang

dapat membantu mengungkapkan kesalahan. Salah satu metode untuk membatasi jumlah jalur adalah untuk mempertimbangkan

dua jalur yang sama jika mereka hanya berbeda dalam subpaths mereka yang disebabkan karena

untuk loop. Bahkan dengan pembatasan ini, jumlah jalur bisa sangat Ini harus menunjukkan bahwa tidak ada kriteria ini cukup untuk mendeteksi semua

jenis kesalahan dalam program. Misalnya, jika program yang hilang kendali

aliran jalur yang diperlukan untuk memeriksa nilai khusus (seperti pointer sama nil

dan pembagi sama dengan nol), kemudian bahkan mengeksekusi semua jalan belum tentu

mendeteksi kesalahan. Demikian pula, jika set jalur adalah seperti yang mereka memenuhi allpath yang

kriteria tapi latihan hanya satu bagian dari kondisi majemuk, maka

set tidak akan mengungkapkan kesalahan dalam bagian dari kondisi yang tidak dilaksanakan.

Oleh karena itu, bahkan kriteria cakupan jalur, yang merupakan terkuat kriteria

kita telah membahas, tidak cukup kuat untuk menjamin deteksi semua kesalahan.

8.4.2 Uji Generation Kasus dan Dukungan Perangkat

Setelah kriteria cakupan diputuskan, dua masalah harus dipecahkan untuk menggunakan

kriteria yang dipilih untuk pengujian. Yang pertama adalah untuk memutuskan apakah satu set kasus uji memuaskan

kriteria, dan yang kedua adalah untuk menghasilkan satu set kasus uji untuk kriteria tertentu.

Memutuskan apakah satu set kasus uji memenuhi kriteria tanpa bantuan apapun

alat adalah tugas yang rumit, meskipun secara teoritis mungkin untuk melakukan secara manual.

Untuk hampir semua teknik pengujian struktural, alat yang digunakan untuk menentukan

apakah kriteria tersebut telah puas. Umumnya, alat ini akan memberikan

umpan balik mengenai apa yang perlu diuji untuk sepenuhnya memenuhi kriteria.

Untuk menghasilkan uji kasus, alat-alat yang tidak mudah tersedia, dan karena

sifat dari masalah (yaitu, undecidability dari "kelayakan" dari jalan), sepenuhnya

alat otomatis untuk memilih uji kasus untuk memenuhi kriteria umumnya tidak

mungkin. Oleh karena itu, alat bisa, di terbaik, membantu tester. Salah satu metode untuk menghasilkan

uji kasus adalah untuk secara acak memilih data uji sampai kriteria yang diinginkan puas

(Yang ditentukan oleh alat). Hal ini dapat mengakibatkan banyak berlebihan uji kasus,

karena banyak kasus uji akan melaksanakan jalur yang sama.

Sebagai generasi uji kasus tidak dapat sepenuhnya otomatis, sering kasus uji

seleksi dilakukan secara manual oleh tester dengan melakukan pengujian struktural dalam

cara berulang, dimulai dengan kasus uji awal yang ditetapkan dan memilih lebih uji

kasus berdasarkan umpan balik yang diberikan oleh alat untuk evaluasi kasus uji. Itu

alat uji kasus evaluasi dapat membedakan mana jalan harus dieksekusi atau yang

mutan perlu dibunuh. Informasi ini dapat digunakan untuk memilih tes lebih lanjut

kasus.

Bahkan dengan bantuan alat, memilih uji kasus bukanlah proses yang sederhana.

Memilih uji kasus untuk mengeksekusi beberapa bagian kode yang belum unexecuted sering

sangat sulit. Karena ini, dan untuk alasan lain, kriteria seringkali

melemah. Misalnya, bukan membutuhkan cakupan 100% dari pernyataan dan

cabang, tujuannya mungkin untuk mencapai beberapa persentase diterima tinggi (tapi

kurang dari 100%). Ada banyak alat yang tersedia untuk pernyataan dan cakupan cabang, kriteria

yang paling sering digunakan. Kedua alat komersial dan freeware yang tersedia

untuk bahasa sumber yang berbeda. Alat-alat ini sering juga memberikan cakupan yang lebih tinggi tingkat

Data seperti cakupan fungsi, cakupan metode, dan cakupan kelas. Untuk mendapatkan

cakupan data, pelaksanaan program selama pengujian harus erat

dipantau. Hal ini membutuhkan bahwa program akan diinstrumentasi sehingga diperlukan

Data dapat dikumpulkan. Sebuah metode umum instrumenting adalah untuk memasukkan beberapa 

Laporan disebut probe dalam program ini. Satu-satunya tujuan dari probe adalah

untuk menghasilkan data tentang pelaksanaan program selama pengujian yang dapat digunakan untuk

menghitung cakupan. Dengan ini, kita dapat mengidentifikasi tiga fase dalam menghasilkan

Data cakupan:

1. Instrumen program dengan probe

2. Jalankan program dengan kasus uji

3. Menganalisis hasil data pemeriksaan

penyisipan Probe dapat dilakukan secara otomatis oleh preprocessor. Pelaksanaan

program ini dilakukan oleh tester. Setelah pengujian, data cakupan ditampilkan

dengan representasi alat-kadang grafis juga ditampilkan.

8.5 Metrik

Kita telah melihat bahwa selama pengujian perangkat lunak yang diuji dijalankan dengan set

kasus uji. Sebagai kualitas perangkat lunak yang dikirimkan tergantung substansial pada

kualitas pengujian, sebuah pertanyaan alami beberapa muncul saat uji coba:

- Seberapa baik adalah pengujian yang telah dilakukan?

- Bagaimana kualitas atau keandalan software setelah pengujian selesai?

Selama pengujian, tujuan utama dari metrik adalah mencoba untuk menjawab ini dan

pertanyaan terkait lainnya. Kita akan membahas beberapa metrik yang dapat digunakan untuk ini

tujuan.

 8.5.1 Analisis Cakupan

Salah satu pendekatan yang paling umum digunakan untuk mengevaluasi ketelitian yang

pengujian adalah dengan menggunakan beberapa langkah cakupan. Kami telah dibahas di atas beberapa

langkah-langkah cakupan umum yang digunakan dalam cakupan praktek-pernyataan

dan cakupan cabang. Untuk menggunakan langkah-langkah cakupan ini untuk mengevaluasi kualitas

pengujian, alat analisis cakupan yang tepat harus digunakan yang dapat

menginformasikan tidak hanya cakupan dicapai selama pengujian tetapi juga yang bagian

belum tercakup.

Seringkali, organisasi membangun pedoman untuk tingkat cakupan yang harus

dicapai selama pengujian. Umumnya, persyaratan cakupan akan lebih tinggi untuk

unit testing, tetapi lebih rendah untuk pengujian sistem seperti itu jauh lebih sulit untuk memastikan

pelaksanaan blok diidentifikasi ketika seluruh sistem sedang dieksekusi. Sering  persyaratan cakupan di tingkat unit dapat 90% sampai 100% (perlu diingat bahwa

100% mungkin tidak selalu mungkin karena mungkin ada kode unreachable).

Selain cakupan konstruksi Program, cakupan persyaratan juga

sering diperiksa. Hal ini untuk memfasilitasi evaluasi ini yang di uji kasus spesifikasi

persyaratan atau ketentuan yang diuji disebutkan. cakupan ini

umumnya didirikan dengan mengevaluasi set kasus uji untuk memastikan bahwa cukup

jumlah kasus uji dengan data yang sesuai disertakan untuk semua persyaratan.

Cakupan ukuran di sini adalah persentase persyaratan atau klausa mereka / -

kondisi yang setidaknya satu kasus uji ada. Seringkali cakupan penuh mungkin

diperlukan pada tingkat kebutuhan sebelum pengujian dianggap sebagai diterima.

8.5.2 Keandalan

Setelah pengujian dilakukan dan perangkat lunak disampaikan, pembangunan dianggap

lebih. Ini jelas akan diinginkan untuk tahu, dalam hal kuantitatif, yang

keandalan software yang disampaikan. Sebagai keandalan software tergantung

jauh pada kualitas pengujian, dengan menilai kehandalan kami juga dapat menilai

kualitas pengujian. Atau, estimasi reliabilitas dapat digunakan untuk memutuskan

apakah pengujian cukup telah dilakukan. Dengan kata lain, selain karakteristik

properti kualitas penting dari produk yang disampaikan, kehandalan estimasi

memiliki peran langsung dalam proyek manajemen-dapat digunakan oleh proyek

Manajer untuk memutuskan apakah pengujian cukup telah dilakukan dan kapan harus berhenti

pengujian.

Keandalan produk menentukan kemungkinan operasi kegagalan-bebas

bahwa produk untuk durasi waktu tertentu. Kebanyakan model kehandalan mengharuskan

terjadinya kegagalan menjadi fenomena acak. Dalam perangkat lunak meskipun

kegagalan terjadi karena bug yang sudah ada sebelumnya, asumsi ini umumnya akan terus untuk

besar sistem, tetapi mungkin tidak berlaku untuk program kecil yang memiliki bug (di mana

satu kasus mungkin dapat memprediksi kegagalan). Oleh karena itu, pemodelan keandalan

lebih berarti bagi sistem yang lebih besar.

Misalkan X variabel acak yang mewakili kehidupan sistem. Keandalan

sistem adalah probabilitas bahwa sistem tidak gagal pada saat t. di lain

kata-kata, Keandalan sistem yang juga dapat ditentukan sebagai waktu yang berarti kegagalan

(MTTF). MTTF mewakili hidup yang diharapkan dari sistem. Dari keandalan

Fungsi, dapat diperoleh sebagai [80].

Keandalan juga dapat didefinisikan dalam hal intensitas kegagalan yang kegagalan

tingkat (yaitu, jumlah kegagalan per satuan waktu) dari perangkat lunak pada waktu t.

Dari perspektif pengukuran, selama pengujian, pengukuran tingkat kegagalan

adalah yang paling mudah, jika cacat sedang login. Cara mudah untuk melakukan ini adalah untuk menghitung

jumlah kegagalan setiap minggu atau setiap hari selama tahap terakhir pengujian.

Dan jumlah kegagalan dapat didekati dengan jumlah cacat login.

(Meskipun kegagalan dan cacat yang berbeda, dalam tahap terakhir dari pengujian itu

diasumsikan bahwa cacat yang menyebabkan kegagalan yang segera diperbaiki cukup dan karena itu

tidak menyebabkan beberapa kegagalan.) Secara umum, tingkat kegagalan ini meningkat di awal

pengujian karena semakin banyak cacat yang ditemukan, puncak suatu tempat di tengah

pengujian, dan kemudian terus menurun sebagai cacat sedikit dilaporkan. Untuk sebuah

diberikan test suite, jika semua cacat tetap, maka harus ada hampir tidak ada kegagalan

menuju akhir. Dan yang bisa dianggap sebagai waktu yang tepat untuk rilis ini

perangkat lunak. Artinya, kriteria rilis dapat bahwa tingkat kegagalan di rilis

Waktu adalah nol kegagalan dalam beberapa durasi waktu, atau nol kegagalan saat mengeksekusi

test suite.

Meskipun pelacakan tingkat kegagalan memberikan rasa kasar dari kehandalan dalam hal

kegagalan per hari atau per minggu, untuk keandalan estimasi yang lebih akurat, lebih baik

model harus digunakan. model perangkat lunak keandalan adalah tugas yang kompleks, yang membutuhkan

model ketat dan analisis statistik canggih. Banyak model memiliki

telah diusulkan untuk penilaian keandalan software, dan survei dari banyak

model diberikan dalam [33, 67].

Perlu disebutkan bahwa kegagalan software juga sangat bergantung pada

lingkungan di mana ia mengeksekusi, tingkat kegagalan yang dialami dalam pengujian

akan mencerminkan keandalan tertinggi dialami oleh pengguna setelah rilis software

hanya jika pengujian erat meniru perilaku pengguna. Ini tidak mungkin terjadi,

terutama dengan tingkat yang lebih rendah dari pengujian. Namun, seringkali pada tingkat yang lebih tinggi, aktif

upaya dilakukan untuk memiliki ujian akhir Suite meniru penggunaan aktual. Jika ini adalah

kasus, maka estimasi reliabilitas dapat diterapkan dengan keyakinan yang lebih tinggi.

8.5.3 Cacat Removal Efficiency

Analisis lain yang menarik adalah efisiensi removal cacat, meskipun ini hanya dapat

ditentukan beberapa saat setelah perangkat lunak telah dirilis. Tujuan dari ini

analisis adalah untuk mengevaluasi efektivitas proses pengujian yang digunakan,

bukan kualitas pengujian untuk sebuah proyek. Analisis ini berguna untuk meningkatkan

proses pengujian di masa depan.

Biasanya, setelah perangkat lunak telah dirilis ke klien, klien akan

menemukan cacat, yang harus tetap (umumnya oleh pengembang asli, karena ini

sering menjadi bagian dari kontrak). Data cacat ini juga umumnya login. Dalam beberapa bulan, sebagian besar cacat akan ditemukan oleh klien (sering

"Garansi" periode 3 sampai 6 bulan).

Setelah total jumlah cacat (atau pendekatan dekat dengan total)

diketahui, efisiensi removal cacat (DRE) pengujian dapat dihitung.

Efisiensi removal cacat dari aktivitas pengendalian mutu didefinisikan sebagai

persentase penurunan jumlah cacat dengan menjalankan kegiatan [61].

Sebagai contoh, misalkan total jumlah cacat login adalah 500, dari yang

20 ditemukan setelah melahirkan, dan 200 ditemukan selama pengujian sistem.

Efisiensi removal cacat pengujian sistem adalah 200/220 (hanya sekitar 90%), sebagai

jumlah cacat hadir dalam sistem ketika pengujian dimulai adalah 220.

Efisiensi removal cacat dari proses kualitas secara keseluruhan 480/500, yang

adalah 96%. Kebetulan, tingkat DRE layak dan apa yang banyak komersial

organisasi mencapai.

Ini harus jelas bahwa DRE adalah konsep umum yang dapat diterapkan untuk

aktivitas penghapusan cacat. Sebagai contoh, kita dapat menghitung DRE desain

review, atau unit testing. Hal ini dapat dilakukan jika untuk setiap cacat, selain logging saat

dan di mana cacat ditemukan, fase di mana cacat diperkenalkan

juga dianalisis dan dicatat. Dengan informasi ini, ketika semua cacat yang

login, DRE tugas kontrol kualitas utama dapat ditentukan. Ini

Informasi ini sangat berguna dalam meningkatkan kualitas proses keseluruhan.

8.6 Ringkasan

- Pengujian adalah metode yang dinamis untuk verifikasi dan validasi, di mana perangkat lunak

untuk diuji dilaksanakan dengan hati-hati dirancang kasus uji dan

perilaku sistem software diamati. Sebuah test case adalah seperangkat input

dan kondisi pengujian bersama dengan hasil yang diharapkan dari pengujian. Sebuah test suite

adalah seperangkat kasus uji yang umumnya dijalankan bersama-sama untuk menguji beberapa spesifik

tingkah laku. Selama pengujian hanya kegagalan sistem yang diamati,

dari mana kehadiran kesalahan disimpulkan; kegiatan yang terpisah harus

dilakukan untuk mengidentifikasi kesalahan dan menghapus mereka.

- Tujuan dari pengujian adalah untuk meningkatkan kepercayaan dalam kebenaran perangkat lunak.

Untuk ini, himpunan kasus uji yang digunakan untuk pengujian harus sedemikian rupa sehingga untuk

cacat pada sistem, ada kemungkinan menjadi kasus uji yang akan mengungkapkannya.

Untuk memastikan hal ini, penting bahwa uji kasus secara hati-hati dirancang dengan

maksud mengungkapkan cacat.

- Karena keterbatasan metode verifikasi untuk tahap awal, desain

dan kesalahan persyaratan juga muncul dalam kode. Pengujian ini digunakan untuk mendeteksi

kesalahan ini juga, selain kesalahan diperkenalkan selama coding

tahap. Oleh karena itu, berbagai tingkat pengujian yang sering digunakan untuk mendeteksi cacat

disuntikkan selama tahap-tahap yang berbeda. Tingkat pengujian umum digunakan adalah

unit testing, pengujian integrasi, pengujian sistem, dan pengujian penerimaan.

- Untuk menguji produk software, pengujian secara keseluruhan harus direncanakan, dan untuk

menguji setiap unit diidentifikasi dalam rencana, uji kasus harus dirancang dengan hati-hati

untuk mengungkapkan kesalahan dan ditetapkan dalam dokumen atau naskah tes.

- Ada dua pendekatan untuk merancang uji kasus: kotak hitam dan putih-kotak.

Dalam pengujian black-box, logika internal dari sistem di bawah pengujian tidak dianggap

dan uji kasus diputuskan dari spesifikasi atau persyaratan.

Kesetaraan kelas partisi, analisis nilai batas, dan causeeffect

grafik adalah contoh dari metode untuk memilih kasus uji untuk kotak hitam

pengujian. pengujian berbasis negara adalah pendekatan lain di mana sistem dimodelkan

sebagai mesin negara dan kemudian model ini digunakan untuk memilih uji kasus menggunakan

beberapa transisi atau kriteria cakupan berbasis jalan. pengujian berbasis negara juga bisa

dipandang sebagai abu-abu kotak pengujian dalam yang sering membutuhkan informasi lebih dari

hanya persyaratan.

- Dalam pengujian white-box, uji kasus diputuskan berdasarkan logika internal

dari program yang sedang diuji. Seringkali kriteria yang ditentukan, tetapi prosedur

untuk memilih uji kasus untuk memenuhi kriteria yang tersisa untuk tester. Yang paling

Kriteria umum adalah cakupan pernyataan dan cakupan cabang.

- The metrik utama bunga selama pengujian adalah keandalan dari perangkat lunak

di bawah pengujian. Jika cacat sedang login, keandalan dapat dinilai dalam hal

dari tingkat kegagalan per minggu atau hari, meskipun model yang lebih baik untuk estimasi ada.

Cakupan dicapai selama pengujian, dan efisiensi removal cacat, yang lainnya

metrik bunga.