Aisyah Dian Rahmasari
43A87007150368
SI/S1/3B Pagi
8
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 perilaku dari 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 yang diberikan 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 memeriksa perilaku tersebut sebagaimana ditetapkan dalam uji kasus. Ini proses 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, kita membutuhkan 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 tingkat pengujian 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.
Figure 8.1: Level Pengujian
Tingkat berikutnya adalah pengujian sistem dan pengujian penerimaan. Berikut seluruh sistem perangkat lunak diuji. Dokumen acuan proses ini adalah dokumen persyaratan, dan tujuannya adalah untuk melihat apakah perangkat lunak memenuhi nya.
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 atau dokumen 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 tersebut dilanjutkan, 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 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 uji kasus dieksekusi. Jika kerangka uji yang digunakan, maka pengaturan lingkungan sebagai serta masukan untuk kasus uji dilakukan di skrip pengujian, dan eksekusi sangat mudah. Selama tes eksekusi kasus, cacat yang ditemukan. Cacat kemudian diperbaiki dan 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 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. Dalam pengujian black-box, tester hanya memasukan yang diberikan sistem kepada keluaran sistem. Dengan kata lain, dasar untuk memutuskan uji kasus adalah persyaratan atau spesifikasi dari sistem atau modul. 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 yang dekat optimal (yaitu, mendeteksi kesalahan maksimum dengan uji minimum kasus).
8.3.1 Equivalence Class Partisi
Pendekatan alami berikutnya adalah membagi domain input ke dalam satu set kelas kesetaraan, sehingga jika karya Program benar bernilai, maka akan benar bekerja untuk semua nilai-nilai lain dalam kelas. Jika memang mengidentifikasi kelas tersebut, maka pengujian program dengan satu nlai dari masing-masing kelas kesetaraan setara dengan melakukan tes lengkap program struktur.
Metode kesetaraan kelas partisi mencoba untuk ideal. 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 asumsi bahwa jika spesifikasi memerlukan perilaku sama 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.
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 dibatas 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, 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.
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 implisit pengaturan seperti 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. contoh sederhana kesalahan dari single-mode lunak tidak mampu mencetak jenis tertentu printer, sebuah perangkat lunak yang tidak dapat menghitung ongkos 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 tujuan untuk 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.
8.3.4 Kasus Khusus
Uji kasus yang ditulis untuk situasi ini. Misalnya, dalam masalah menemukan jumlah kata yang berbeda dalam file 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
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. 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.
8.4 Pengujian White-Box
Pengujian White-box, di sisi lain tangan, berkaitan dengan pengujian pelaksanaan program. Tujuannya pengujian ini bukan untuk melaksanakan semua input atau output kondisi yang berbeda (meskipun merupakan 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 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).
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.
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 untuk 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.
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 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.
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 diperkenalkan juga dianalisis dan dicatat. Dengan informasi ini, ketika semua cacat yang login, 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 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.
