43A87007150334
SI/S1/3B Pagi
PENGUJIAN
Ada dua jenis pendekatan untuk mengidentifikasi cacat pada statis dengan peranti lunak 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 dijalankan, dan eksekusi yang digunakan untuk menentukan cacat. Pengujian adalah teknik yang dinamis yang paling umum yang digunakan. Memang, pengujian adalah teknik yang paling umum digunakan untuk mendeteksi cacat, dan melakukan peran yang sangat penting untuk memastikan kualitas.
Dalam bab ini kita akan membahas:
- Konsep dasar dan definisi yang berkaitan dengan pengujian, seperti kesalahan, kesalahan, kegagalan, ujian, test suite, memanfaatkan uji, dll
- Pengujian proses pengujian-bagaimana direncanakan dan bagaimana pengujian unit 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-ing.
8.1 Konsep Pengujian
Pada bagian ini kita akan mendefinisikan beberapa istilah yang biasa digunakan ketika membahas pengujian. Kemudian kita akan membahas beberapa masalah dasar yang berkaitan dengan bagaimana pengujian dilakukan, dan pentingnya psikologi tester.
8.1.1 Eror, Kesalahan, dan Kegagalan
Kesalahan istilah digunakan dalam dua cara berbeda. Hal ini mengacu pada perbedaan antara nilai dihitung, mengamati, atau diukur dan nilai sebenarnya, ditentukan, atau secara
teoritis benar. Artinya, kesalahan mengacu pada selisih antara output aktual dari perangkat lunak dan output yang benar. Dalam penafsiran ini, kesalahan pada dasarnya adalah ukuran dari selisih antara aktual dan ideal. Kesalahan ini digunakan untuk merujuk pada tindakan manusia yang menghasilkan perangkat lunak yang mengandung cacat atau kesalahan. Definisi ini cukup umum dan mencakup semua tahap.
Kegagalan adalah ketidakmampuan sistem atau komponen untuk melakukan fungsi yang diperlukan sesuai dengan spesifikasinya. Sebuah kegagalan perangkat lunak terjadi jika perilakudari software ini di ff erent dari perilaku ditentukan. Kegagalan dapat disebabkan oleh faktor fungsional atau kinerja. Perhatikan bahwa definisi tidak berarti bahwa kegagalan harus diperhatikan. Ada kemungkinan bahwa kegagalan mungkin terjadi tetapi tidak terdeteksi.
Perlu dicatat bahwa selama proses pengujian, hanya kegagalan yang ob-dilayani, dimana kehadiran kesalahan disimpulkan. Artinya, pengujian hanya mengungkapkan adanya kesalahan. Kesalahan yang sebenarnya diidentifikasi oleh kegiatan terpisah, sering disebut sebagai "debugging." Dengan kata lain, untuk mengidentifikasi kesalahan, pengujian af-ter telah mengungkapkan adanya kesalahan, tugas mahal debugging harus dilakukan. Ini adalah salah satu alasan mengapa pengujian adalah metode mahal untuk identifikasi kesalahan.
8.1.2 Uji Kasus, Test Suite, dan Test Harness
Perhatikan bahwa dalam kasus uji, masukan uji dan kondisi eksekusi disebutkan secara terpisah. Uji input adalah nilai-nilai tertentu dari parameter atau input lain yangdiberikan kepada SUT baik oleh pengguna atau program lain. Kondisi eksekusi, di sisi lain, mencerminkan keadaan dari sistem dan lingkungan yang juga mempengaruhi perilaku SUT. Jadi, misalnya, saat uji coba fungsi untuk menambahkan catatan jika tidak ada dalam database, perilaku fungsi akan tergantung baik pada nilai catatan masukan serta keadaan database. Dan uji kasus perlu menentukan baik. Misalnya, kasus uji untuk fungsi ini mungkin menentukan rekor r sebagai masukan, dan mungkin menentukan bahwa keadaan database sedemikian rupa sehingga r sudah ada di dalamnya.
Pengujian dapat dilakukan secara manual dengan tester melaksanakan uji kasus dalam test suite dan kemudian memeriksaperilaku tersebut sebagaimana ditetapkan dalam uji kasus. Iniproses yang sangat rumit, terutama ketika test suite berisi sejumlah besar kasus uji. Itu menjadi lebih rumit karena test suite harus sering dijalankan setiap kali SUT berubah. Oleh karena itu, tren saat ini adalah untuk mengotomatisasi pengujian.
Untuk memiliki suite tes dieksekusi secara otomatis, kitamembutuhkan kerangka di mana masukan uji dapat didefinisikan, input didefinisikan dapat digunakan oleh fungsi mewakili uji kasus, tes script otomatis dapat ditulis, SUT dapat dieksekusi oleh script ini, dan hasil seluruh pengujian dilaporkan tester. Banyak kerangka pengujian sekarang ada yang izin semua ini harus dilakukan dengan cara yang sederhana. Sebuah kerangka pengujian juga kadang-kadang disebut memanfaatkan tes. Sebuah memanfaatkan tes atau kerangka tes membuat kehidupan seorang tester sederhana dengan menyediakan 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
Sebuah tujuan dasar pengujian adalah untuk mendeteksi kesalahan yang mungkin dalam program. Oleh karena itu, seseorang tidak harus memulai pengujian dengan maksud menunjukkan bahwa program bekerja, bukan maksud harus menunjukkan bahwa program tidak bekerja, untuk mengungkapkan cacat yang mungkin ada. Karena ini, pengujian juga telah didefinisikan sebagai proses eksekusi program dengan maksud menemukan kesalahan.
Jadi, tujuannya adalah untuk menunjukkan program kerjanya, kita secara sadar atau tidak sadar pilih uji kasus yang mencoba untuk menunjukkan tujuan itu dan yang mengalahkan tujuan dasar pengujian. Di sisi lain, jika tujuannya untuk menunjukkan bahwa program ini tidak bekerja, kami akan menantang akal kita untuk menemukan kasus uji untuk mencapai tujuan itu, dan kita cenderung untuk mendeteksi lebih banyak kesalahan. Pengujian pada dasarnya adalah sebuah proses yang merusak, 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 di mana pengujian dilakukan oleh tim yang tidak terlibat dalam membangun sistem.
8.1.4 Level Pengujian
Tingkat dasar unit testing, pengujian integrasi, pengujian sistem, dan pengujian penerimaan. tingkat di ff erent ini pengujian upaya untuk mendeteksi jenis di ff erent dari kesalahan. Hubungan antara kesalahan diperkenalkan secara bertahap, dan di tingkatpengujian ditunjukkan pada Gambar 8.1.
Unit pengujian pada dasarnya untuk verifikasi kode yang dihasilkan oleh programmer individu, dan biasanya dilakukan oleh programmer dari modul. Umumnya, modul programmer untuk integrasi dan digunakan orang lain setelah telah unit diuji memuaskan.
Tingkat berikutnya pengujian disebut pengujian integrasi. Dalam hal ini, banyak unit modul diuji digabungkan menjadi subsistem, yang kemudian diuji. Tujuannya adalah untuk melihat apakah modul dapat diintegrasikan dengan benar.
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 sistem yang ada.
Untuk pengujian regresi, beberapa kasus uji yang telah dijalankan pada sistem yang lama dipertahankan, bersama dengan output yang dihasilkan oleh sistem yang lama. uji kasus ini dijalankan lagi pada sistem dimodifikasi dan output dibandingkan dengan output sebelumnya untuk memastikan bahwa sistem ini bekerja seperti sebelumnya pada uji kasus ini. Hal ini sering merupakan tugas besar ketika modifikasi yang dibuat untuk sistem yang ada.
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 tingkat pengujian cacat disuntikkan untuk mendeteksi selama berbagai tugas dalam proyek.
8.2.1 Uji Rencana
Secara umum, dalam sebuah proyek, pengujian dimulai dengan rencana uji dan berakhir dengan keberhasilan pelaksanaan pengujian penerimaan. Sebuah uji rencana 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 pengujian. Rencana pengujian dapat dilakukan dengan baik sebelum pengujian yang sebenarnya dimulai dan dapat dilakukan di par-alel dengan kegiatan coding dan desain. Input untuk membentuk rencana uji adalah: (1) rencana proyek, (2) dokumen persyaratan, dan (3) arsitektur ataudokumen desain.
Dokumen persyaratan dan dokumen desain adalah dokumen-dokumen dasar yang digunakan untuk memilih unit tes dan decid-ing pendekatan yang akan digunakan selama pengujian. Sebuah rencana uji harus berisi sebagai berikut:
- Uji Spesifikasi Unit
- Fitur yang akan diuji
- Pendekatan untuk pengujian
- Kiriman Uji
- Jadwal dan tugas alokasi
Fitur yang akan diuji mencakup semua fitur perangkat lunak dan kombinasi yang harus diuji. Sebuah fitur software adalah karakteristik software tersirat oleh persyaratan atau dokumen desain. Termasuk fungsi, kinerja, kendala desain, dan atribut.
Rencana uji biasanya juga menentukan jadwal dan e ff ortir akan dihabiskan untuk di kegiatan ff erent pengujian, dan alat-alat yang akan digunakan. Jadwal ini harus konsisten dengan jadwal proyek secara keseluruhan. Rencana rinci dapat 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 karena rencana tes terpisah. Sebuah proyek yang lebih kecil mungkin termasuk rencana uji sebagai bagian dari rencana kualitas dalam rencana manajemen proyek.
8.2.2 Desain Kasus Uji
Rencana uji berfokus pada bagaimana proyek pengujian tersebutdilanjutkan, unit akan diuji, dan pendekatan (alat) yang 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.
8.2.3 Uji Kasus Eksekusi
Dengan spesifikasi kasus uji, langkah berikutnya dalam proses pengujian adalah untukmengeksekusi mereka. Langkah ini juga tidak mudah. Spesifikasi kasus ujihanya menentukan set kasus uji untuk unit yang akan diuji. Namun, mengeksekusiuji kasus mungkin memerlukan pembangunan modul driver atau bertopik. Mungkin jugamembutuhkan modul untuk mengatur lingkungan sebagaimana tercantum dalam rencana uji dan ujispesifikasi kasus.
Hanya setelah semua iniuji kasus dieksekusi. Jika kerangka uji yang digunakan, maka pengaturan lingkungan sebagaiserta masukan untuk kasus uji dilakukan di skrip pengujian, dan eksekusisangat mudah.Selama tes eksekusi kasus, cacat yang ditemukan. Cacat kemudian diperbaikidan tesing dilakukan lagi untuk memverifikasi perbaikan. Untuk memfasilitasi pelaporan dan pelacakan.
8.3 Pengujian Black-Box
Tujuannya 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 memilikiprobabilitas tinggi mendeteksi cacat, jika ada, dan juga yang eksekusiakan 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 dalampengujian: black-box dan white-box. Dalam kotak hitam pengujian strukturProgram tidak dianggap. Uji kasus diputuskan hanya berdasarkan daripersyaratan atau spesifikasi program atau modul, dan internalmodul atau program tidak dipertimbangkan untuk pemilihan kasus uji. Dalam pengujian black-box, tester hanya memasukan yangdiberikan sistem kepada keluaran sistem. Dengan kata lain, dasaruntuk memutuskan uji kasus adalah persyaratan atau spesifikasi dari sistem ataumodul. Bentuk pengujian juga disebut uji fungsional atau perilaku.Salah satu kriteria untuk menghasilkan uji kasus adalah untuk menghasilkan mereka secara acak.Strategi ini memiliki sedikit kesempatan untuk menghasilkan satu set kasus uji yangdekat optimal (yaitu, mendeteksi kesalahan maksimum dengan uji minimumkasus).
8.3.1 Equivalence Class Partisi
Pendekatan alami berikutnya adalah membagidomain input ke dalam satu set kelas kesetaraan, sehingga jika karya Programbenar bernilai, maka akanbenar bekerja untuk semua nilai-nilai lain dalamkelas. Jika memang mengidentifikasi kelas tersebut, maka pengujian program dengan satu nlai dari masing-masing kelas kesetaraan setara dengan melakukan tes lengkapprogramstruktur.
Metode kesetaraan kelas partisimencoba untuk ideal. Kelas kesetaraan terbentuk dari inputdimana perilaku sistem ditentukan atau diharapkan untuk menjadi serupa. Setiap
kelompok masukan yang perilaku tersebut diharapkan akan berbeda dari orang laindianggap sebagai kelas kesetaraan yang terpisah. Dasar pemikiran pembentukan kesetaraankelas seperti ini asumsi bahwa jika spesifikasi memerlukanperilaku sama untuk setiap elemen dalam kelas nilai-nilai, maka program akan cenderungdibangun sehingga baik berhasil atau gagal untuk masing-masing nilai di kelas itu.
Misalnya, spesifikasi modul yang menentukan nilai absolutuntuk bilangan bulat menentukan satu perilaku untuk bilangan bulat positif dan satu lagi untuk negatifbilangan bulat. Dalam hal ini, kita akan membentuk dua kesetaraan kelas-satu yang terdiri daribilangan bulat positif dan terdiri lainnya dari bilangan bulat negatif.Untuk perangkat lunak yang kuat, kita juga harus mempertimbangkan masukan tidak valid. Artinya, kita harusmendefinisikan kelas kesetaraan untuk input tidak valid juga. Kelas kesetaraan biasanya dibentuk dengan mempertimbangkan setiap kondisi yang ditentukanpada masukan sebagai menentukan kelas kesetaraan valid dan satu atau lebih validkelas kesetaraan.
8.3.2 Analisis Nilai Batas
Ia telah mengamati bahwa program yang bekerja dengan benar untuk satu set nilai-nilai dikelas kesetaraan gagal pada beberapa nilai khusus. Nilai-nilai ini sering berbaring dibatas dari kelas kesetaraan. Uji kasus yang memiliki nilai-nilai pada batas-bataskesetaraan kelas karena itu cenderung "-yield tinggi" uji kasus, danmemilih uji kasus tersebut adalah tujuan dari analisis nilai batas. dalam batasanalisis nilai, kita memilih masukan untuk kasus uji dari kesetaraan
kelas, sehingga input terletak di tepi kelas ekivalen. Batasnilai 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 yangterletak di tepi atau batas dari kelas data input atau yang menghasilkan keluaranyang terletak pada batas kelas data output.
8.3.3 Pengujian Pasangan
Ada banyak umumnya parameter yang menentukan perilaku perangkat lunak
sistem. Parameter ini bisa menjadi masukan langsung ke perangkat lunak atau implisitpengaturan seperti untuk perangkat. Parameter ini dapat mengambil nilai yang berbeda, danuntuk beberapa dari mereka perangkat lunak mungkin tidak bekerja dengan benar. Banyak cacat disoftware umumnya melibatkan satu syarat, yaitu, beberapa nilai khusus salah satu.
parameter. Cacat seperti ini disebut kesalahan single-mode. contoh sederhana kesalahan dari single-mode lunak tidak mampu mencetak jenis tertentuprinter, sebuah perangkat lunak yang tidak dapat menghitung ongkosminor, dan perangkat lunak penagihan telepon yang tidak menghitung tagihan dengan benaruntuk negara tertentu.
Kesalahan single-mode dapat dideteksi dengan menguji untuk nilai yang berbeda dari yang berbedaparameter. 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 kelasyang dianggap sebagai tujuan untuk pengujian seperti di kelas kesetaraan
partisi), maka dengan setiap kasus uji kita dapat menguji satu nilai yang berbeda dari masing-masingparameter. Dengan kata lain, kita dapat menguji untuk semua nilai yang berbeda di tes mkasus.
8.3.4 Kasus Khusus
Uji kasus yang ditulis untuk situasi ini. Misalnya, dalam masalah menemukan jumlah kata yang berbeda dalam filebeberapa kasus khusus dapat: file kosong,hanya satu kata dalam file, hanya satu kata dalam satu baris, beberapa baris kosong di inputFile, 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-diamdaripada 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
Namun demikian, banyaksistem yang perilakunya negara-berbasis di bahwa untuk masukan identik mereka berperilakuberbeda pada waktu yang berbeda dan dapat menghasilkan output yang berbeda. Alasannyauntuk perilaku yang berbeda adalah bahwa keadaan dari sistem mungkin berbeda. di lainkata-kata, perilaku dan output dari sistem tidak hanya tergantung pada inputtersedia, tetapi juga pada keadaan dari sistem. Keadaan dari sistem tergantungpada input terakhir sistem telah menerima.
Dengan kata lain, negara merupakandampak kumulatif dari semua input terakhir pada sistem. Dalam perangkat keras,sistem sekuensial jatuh dalam kategori ini. Dalam perangkat lunak, banyak sistem yang besar jatuhkategori ini sebagai negara terakhir yang ditangkap di database atau file dan digunakan untuk kontrolperilaku sistem. Untuk sistem seperti ini, pendekatan lain untuk memilihuji 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. Jika himpunan negara dari suatu sistem adalah dikelola,
model keadaan dari sistem dapat dibangun.
Sebuah model negara untuk sistem memilikiempat 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.
8.4 Pengujian White-Box
Pengujian White-box, di sisi lain tangan, berkaitan dengan pengujian pelaksanaan program. Tujuannyapengujian ini bukan untuk melaksanakan semua input atau output kondisi yang berbeda (meskipunmerupakan produk) tapi melaksanakan pemrograman yang berbeda
struktur dan struktur data yang digunakan dalam program ini. Pengujian kotak putih juga
disebut pengujian struktural.
8.4.1 Kriteria Basis Flow Kontrol
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 untuksebuah program.Biarkan grafik kontrol aliran (atau hanya mengalir grafik) dari program P G. Anode 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).
8.4.2 Uji Generation Kasus dan Dukungan Perangkat
Setelah kriteria cakupan diputuskan, dua masalah harus dipecahkan untuk menggunakankriteria yang dipilih untuk pengujian. Yang pertama adalah untuk memutuskan apakah satu set kasus uji memuaskankriteria, dan yang kedua adalah untuk menghasilkan satu set kasus uji untuk kriteria tertentu.Memutuskan apakah satu set kasus uji memenuhi kriteria
tanpa bantuan apapunalat adalah tugas yang rumit, meskipun secara teoritis mungkin untuk melakukan secara manual.Untuk hampir semua teknik pengujian struktural, alat yang digunakan untuk menentukanapakah kriteria tersebut telah puas. Umumnya, alat ini akan memberikanumpan 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 menghasilkanuji 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.
8.5 Metrik
Kita telah melihat bahwa selama pengujian perangkat lunak yang uji 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 untuktujuan.
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 beberapalangkah-langkah cakupan umum yang digunakan dalam cakupan praktek-pernyataan
dan cakupan cabang. Untuk menggunakan langkah-langkah cakupan ini untuk mengevaluasi kualitaspengujian, alat analisis cakupan yang tepat harus digunakan yang dapat
menginformasikan tidak hanya cakupan dicapai selama pengujian tetapi juga yang bagian
belum tercakup.
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
Sebagai keandalan software tergantungjauh pada kualitas pengujian, dengan menilai kehandalan kami juga dapat menilaikualitas pengujian. Atau, estimasi reliabilitas dapat digunakan untuk memutuskanapakah pengujian cukup telah dilakukan.
Dengan kata lain, selain karakteristikproperti kualitas penting dari produk yang disampaikan, kehandalan estimasimemiliki peran langsung dalam proyek manajemen-dapat digunakan oleh proyekManajer untuk memutuskan apakah pengujian cukup telah dilakukan dan kapan harus berhentipengujian.Keandalan produk menentukan kemungkinan operasi kegagalan-bebasbahwa produk untuk durasi waktu tertentu. Kebanyakan model kehandalan mengharuskanterjadinya kegagalan menjadi fenomena acak.
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.
Ini 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 setiap cacat, selain logging saat
dan di mana cacat ditemukan, fase di mana cacat diperkenalkanjuga dianalisis dan dicatat. Dengan informasi ini, ketika semua cacat yanglogin, DRE tugas kontrol kualitas utama dapat ditentukan. Informasi ini sangat berguna dalam meningkatkan kualitas proses keseluruhan.
8.6 Ringkasan
· Pengujian adalah metode yang dinamis untuk verifikasi dan validasi, di mana perangkat lunakuntuk diuji dilaksanakan dengan hati-hati dirancang kasus uji danperilaku sistem software diamati. Sebuah test case adalah seperangkat inputdan kondisi pengujian bersama dengan hasil yang diharapkan dari pengujian. Sebuah test suiteadalahseperangkat kasus uji yang umumnya dijalankan bersama-sama untuk menguji beberapa spesifiktingkah laku. Selama pengujian hanya kegagalan sistem yang diamati,dari mana kehadiran kesalahan disimpulkan; kegiatan yang terpisah harusdilakukan 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 untukcacat pada sistem, ada kemungkinan menjadi kasus uji yang akan mengungkapkannya.Untuk memastikan hal ini, penting bahwa uji kasus secara hati-hati dirancang denganmaksud mengungkapkan cacat.
· Karena keterbatasan metode verifikasi untuk tahap awal, desaindan kesalahan persyaratan juga muncul dalam kode. Pengujian ini digunakan untuk mendeteksikesalahan ini juga, selain kesalahan diperkenalkan selama codingtahap. Oleh karena itu, berbagai tingkat pengujian yang sering digunakan untuk mendeteksi cacatdisuntikkan selama tahap-tahap yang berbeda. Tingkat pengujian umum digunakan adalahunit testing, pengujian integrasi, pengujian sistem, dan pengujian penerimaan.
· Untuk menguji produk software, pengujian secara keseluruhan harus direncanakan, dan untukmenguji setiap unit diidentifikasi dalam rencana, uji kasus harus dirancang dengan hati-hatiuntuk 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 dianggapdan uji kasus diputuskan dari spesifikasi atau persyaratan.Kesetaraan kelas partisi, analisis nilai batas, dan causeeffectgrafik adalah contoh dari metode untuk memilih kasus uji untuk kotak hitampengujian. pengujian berbasis negara adalah pendekatan lain di mana sistem dimodelkansebagai mesin negara dan kemudian model ini digunakan untuk memilih uji kasus menggunakanbeberapa transisi atau kriteria cakupan berbasis jalan. pengujian berbasis negara juga bisadipandang sebagai abu-abu kotak pengujian dalam yang sering membutuhkan informasi lebih darihanya persyaratan.
· Dalam pengujian white-box, uji kasus diputuskan berdasarkan logika internaldari program yang sedang diuji. Seringkali kriteria yang ditentukan, tetapi proseduruntuk memilih uji kasus untuk memenuhi kriteria yang tersisa untuk tester. Yang palingKriteria umum adalah cakupan pernyataan dan cakupan cabang.
· Metrik utama bunga selama pengujian adalah keandalan dari perangkat lunak di bawah pengujian. Jika cacat sedang login, keandalan dapat dinilai dalam haldari tingkat kegagalan per minggu atau hari, meskipun model yang lebih baik untuk estimasi ada.Cakupan dicapai selama pengujian, dan efisiensi removal cacat, yang lainnyametrik bunga.
