Testing

Bab8 Testing

Dalam proyek pengembangan perangkat lunak, kesalahan dapat diperkenalkan pada setiap tahap pembangunan. Beberapa kesalahan tetap tidak terdeteksi. Pada akhirnya, tercermin dalam kode kesalahan. Oleh karena itu, kode akhir kemungkinan untuk memiliki beberapa requirements kesalahan dan kesalahan desain.

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. Dibahas dalam bab sebelumnya dalam analisis dinamis, kode adalah dieksekusi. Pengujian adalah teknik paling umum dinamis yang digunakan memang pengujian adalah yang paling umum digunakan. Selama pengujian, perangkat lunak yang diuji dijalankan dengan himpunan kasus uji dan perilaku sistem dievaluasi untuk uji kasus sistem ini.

Dalam bab ini kita akan membahas:

- Konsep dasar dan definisi yang berkaitan dengan pengujian, seperti kesalahan, kegagalan,
  uji kasus, test suite, memanfaatkan uji, dll
- Proses pengujian direncanakan pengujian-bagaimana dan bagaimana pengujian unit adalah
  dilakukan.
- Temukan Uji kasus menggunakan kotak hitam pendekatan pengujian.
- Seleksi kasus uji pendekatan menggunakan kotak putih.
- Beberapa cakupan dan kehandalan metrik seperti bekerja khi PPK Test

8.1 Konsep Pengujian

        Pada bagian ini pertama kami akan mendefinisikan beberapa istilah yang umum digunakan membahas pengujian. Kemudian beberapa dasar kami akan diskusikan masalah yang berhubungan dengan bagaimana dilakukan pengujian, dan pentingnya psikologi tester.

8.1.1 Kesalahan dan Kegagalan

        Ketika mendiskusikan biasanya menggunakan istilah-istilah seperti pengujian kesalahan,kegagalan dll mari kita mulai dengan mendefinisikan konsep digunakan dalam dua cara yang berbeda. Ini mengacu perbedaan tersebut antara nilai hitung, terpantau, atau diukur dan benar atau nilai teoritis yang benar. Artinya, kesalahan perbedaan mengacu untuk output aktual dari perangkat lunak dan output yang benar. Dalam interpretasi ini, kesalahan pada dasarnya adalah ukuran perbedaan antara aktual dan ideal. Kesalahan digunakan untuk merujuk pada hasil tindakan dalam perangkat lunak  atau kesalahan. Definisi ini cukup umum dan mencakup semua tahap dan kondisi penyebab kesalahan sistem. Sebuah kesalahan adalah alasan dasar untuk kerusakan perangkat lunak dan umumnya menggunakan istilah identik dengan bug, ataun lebih umum cacat jangka. Ada konsekuensi langsung pada pengujian,pengujian ini tidak mengamati kesalahan, kami tidak bisa mengatakan sesuatu tentang keberadaan atau kesalahan dalam sistem.

8.1.2 Uji Kasus, Test Suite, dan Test Harness

        Sejauh ini digunakan kasus uji istilah atau mengatur kasus uji informal. Mari kita mendefinisikan lebih tepatnya menambahkan. Sekelompok kasus uji terkait umumnya dilaksanakan bersama-sama untuk menguji beberapa perilaku tertentu atau aspek dari pengujian yang dimaksud dengan sering dilakukan adalah tes suite. Catatan dalam kasus uji, masukan uji dan eksekusi disebutkan secara terpisah. Uji input adalah nilai-nilai tertentu dari parameter atau masukan lainnya diberikan kepada pengguna atau program lain. Eksekusi mencerminkan keadaan dari sistem. Jadi, saat uji coba fungsi untuk menambahkan catatan dalam database sudah ada, perilaku fungsi tergantung pada nilai dari keduanya. Tampilan rekor sebagai masukan serta keadaan database. Misalnya, kasus uji untuk fungsi ini mungkin rekord sebagai masukan, dan mungkin dari database sudah ada. Pengujian dapat dilakukan secara manual dengan tester melaksanakan uji kasus ditest suite dan kemudian memeriksa apakah perilaku tersebut dalam kasus uji. Ini adalah proses yang sangat rumit, test suite berisi jumlah kasus uji. Ini menjadi lebih rumit sejak test suite telah akan dieksekusi. Oleh karena itu, saat ini tren adalah untuk otomatis pengujian. Dengan pengujian otomatis, kasus uji biasanya melakukan semua kegiatan uji kasus-set data uji. Hasil yang diharapkan, dan mendeklarasikan untuk tester yang gagal atau lulus. Sebuah test suite mengatur fungsi, masing-masing mewakili kasus uji. Untuk menguji dengan test suite, tes script otomatis umumnya meminta uji kasus dalam urutan yang diinginkan.

        Untuk memiliki suite tes dieksekusi secara otomatis, kami akan membutuhkan kerangka didefinisikan input, masukan dapat digunakan oleh fungsi yang didefinisikan mewakili uji kasus, tes script otomatis dapat dieksekusi oleh script. Dan hasil pengujian seluruh dilaporkan ketester. Banyak kerangka pengujian sekarang ada izin yang harus dilakukan semua dalam cara sederhana. Sebuah kerangka pengujian adalah tes harness juga kadang-kadang pemerintah Indonesia memanfaatkan uji atau kerangka uji tester untuk membuat kehidupan sederhana dengan mudah mendefinisikan test suite. 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 ada dalam program ini. Oleh karena itu, seseorang tidak harus memulai pengujian dengan maksud menunjukkan bahwa program bekerja melainkan ; untuk mengungkapkan cacat yang mungkin ada. Karena ini, pengujian juga telah didefinisikan sebagai proses eksekusi program dengan maksud menemukan kesalahan.

8.1.4 Tingkat Pengujian

        Pengujian biasanya diandalkan untuk mendeteksi kesalahan yang tersisa dari tahap awal, di samping kesalahan diperkenalkan selama coding sendiri. Karena ini, tingkat berbeda pengujian yang digunakan dalam proses pengujian; setiap tingkat pengujian bertujuan untuk menguji di aspek berbeda dari sistem.

      Tingkat pertama pengujian disebut unit testing, Unit pengujian pada dasarnya untuk verifikasi kode yang dihasilkan oleh programmer individu, dan biasanya dilakukan oleh programmer dari modul.

        Tingkat berikutnya pengujian sering disebut pengujian integrasi. Dalam hal ini, banyak unit diuji modul digabungkan menjadi subsistem, yang kemudian diuji. Tujuannya di sini adalah untuk melihat apakah modul dapat diintegrasikan dengan benar. Kegiatan pengujian ini dapat dianggap menguji desain.

        Tingkat berikutnya adalah pengujian sistem dan pengujian penerimaan. Berikut seluruh sistem perangkat lunak diuji.pengujian penerimaan sering dilakukan dengan data yang realistis dari klien untuk menunjukkan bahwa perangkat lunak bekerja memuaskan. pengujian penerimaan dasarnya menguji apakah sistem memuaskan memecahkan masalah bagi yang ditugaskan.

        Ada lagi tingkat pengujian, yang disebut pengujian regresi, yang dilakukan ketika beberapa perubahan yang dibuat untuk sistem yang ada. selain memastikan perilaku yang diinginkan dari layanan baru, pengujian harus memastikan bahwa perilaku yang diinginkan dari layanan lama dipertahankan. Ini adalah tugas dari pengujian regresi.

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). Proses pengujian untuk sebuah proyek terdiri dari perencanaan tiga tingkat tinggi tugas-test, desain uji kasus, dan pelaksanaan tes.

8.2.1 Perencanaan Pengujian

        Secara umum, dalam sebuah proyek, pengujian dimulai dengan rencana uji dan berakhir dengan keberhasilan pelaksanaan pengujian penerimaan. Sebuah rencana uji adalah dokumen-ment 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 berbeda  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.

        Rencana proyek diperlukan untuk memastikan bahwa rencana uji konsisten dengan rencana mutu secara keseluruhan untuk proyek dan jadwal pengujian cocok dengan rencana proyek. Sebuah rencana uji harus berisi sebagai berikut:

- Spesifikasi Unit Uji
- Fitur yang akan diuji
- Pendekatan untuk pengujian
- Kiriman Uji
- Jadwal dan tugas alokasi

        Merupakan faktor penting saat membentuk unit adalah "testability" dari unit. Sebuah unit harus sedemikian rupa sehingga dapat dengan mudah diuji. Misalnya, sebuah modul yang memanipulasi struktur data yang kompleks dibentuk dari input file dengan modul masukan mungkin tidak menjadi unit yang sesuai dari sudut pandang testability, sebagai pembentuk bermakna kasus uji untuk unit akan sulit, dan sopir rutinitas akan telah ditulis untuk mengkonversi masukan dari file atau terminal yang diberikan oleh tester ke dalam struktur data yang sesuai untuk modul. Sebuah fitur software adalah karakteristik software spesifik atau tersirat oleh persyaratan atau dokumen desain. Ini mungkin termasuk fungsi, kinerja, kendala desain, dan atribut.

        Pendekatan untuk pengujian menentukan pendekatan keseluruhan yang harus diikuti dalam proyek 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.

        Kiriman pengujian harus ditentukan dalam rencana uji sebelum pengujian yang sebenarnya dimulai. Kiriman bisa menjadi daftar kasus uji yang digunakan, hasil rinci dari pengujian termasuk daftar cacat yang ditemukan, ringkasan laporan tes, dan data tentang cakupan kode.

        Jadwal ini harus konsisten dengan jadwal proyek secara keseluruhan. Banyak produk besar memiliki tim pengujian terpisah dan karena rencana tes terpisah.

8.2.2 Uji Kasus Desain

        Rencana uji berfokus pada bagaimana pengujian untuk proyek tersebut akan dilanjutkan, yang mana unit akan diuji, dan apa pendekatan (alat) yang akan digunakan selama berbagai tahap pengujian. Namun, itu tidak berurusan dengan rincian pengujian unit, juga tidak menentukan uji kasus yang akan digunakan.

      Pengujian memiliki keterbatasan 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 kualitas tinggi. Evaluasi kasus uji sering dilakukan melalui review uji kasus. Adapun setiap review, dokumen atau pekerjaan produk formal diperlukan untuk meninjau kasus uji. Ini adalah alasan utama untuk mendokumentasikan kasus uji. Kasus uji dokumen spesifikasi ditinjau menggunakan proses formal, untuk memastikan bahwa uji kasus konsisten dengan kebijakan yang ditetapkan dalam rencana, memenuhi kriteria yang dipilih, dan mencakup berbagai aspek unit yang akan diuji.

8.2.3 Uji Eksekusi Kasus

        Dengan spesifikasi kasus uji, langkah berikutnya dalam proses pengujian adalah untuk 
mengeksekusi. Langkah ini juga tidak mudah. Test spesifikasi kasus hanya menentukan set 
kasus uji untuk unit yang akan diuji.Namun, melaksanakan uji kasus mungkin memerlukan 
pembangunan modul driver atau bertopik.
        Jika kerangka uji yang digunakan, maka pengaturan lingkungan serta masukan untuk 
kasus uji sudah dilakukan di naskah pengujian dan eksekusi langsung. Selama tes eksekusi 
kasus, ada cacat yang ditemukan. Cacat ini kemudian tetap dan pengujian dilakukan lagi 
untuk memverifikasi perbaikan. Cacat logging sangat penting dalam sebuah proyek software 
besar yang mungkin memiliki ratusan atau ribuan cacat yang ditemukan oleh orang yang 
berbeda pada berbagai tahap proyek. Penggunaan mekanisme informal dapat dengan mudah 
menyebabkan cacat yang ditemukan tetapi kemudian dilupakan, sehingga cacat tidak dapat 
dihapus. Oleh karena itu, cacat yang ditemukan harus dicatat dengan baik dalam sistem dan 
penutupan mereka dilacak. Cacat logging dan pelacakan dianggap sebagai salah satu praktik 
terbaik untuk mengelola proyek dan diikuti oleh organisasi perangkat lunak.
8.3 Pengujian Black-Box


        Sebagaimana telah kita lihat, desain kasus uji adalah kunci untuk pengujian sesuai 
SUT. Tujuan sementara pengujian SUT adalah untuk mendeteksi sebagian besar dari cacat 
melalui serangkaian uji kasus. Karena tujuan dasar ini, penting untuk memilih kasus uji 
dengan hati-hati, yang paling baik adalah uji kasus-kasus yang memiliki probabilitas tinggi.

        Ada dua pendekatan dasar untuk merancang uji kasus yang akan digunakan dalam pengujian, 
yaitu kotak hitam dan kotak putih. Dalam kotak hitam, pengujian program ini tidak dianggap. Uji 
kasus diputuskan hanya berdasarkan persyaratan atau spesifikasi program atau modul dan internal 
dari modul. Pengujian kotak putih akan dibahas pada bagian berikutnya. 
       
        Dalam pengujian black-box, tester hanya tahu masukan yang bisa diberikan ke sistem 
dan apa keluaran sistem. Bentuk pengujian juga disebut uji fungsional atau perilaku.

8.3.1 Kelas Kesetaraan Partisi

        Karena kita tidak dapat melakukan pengujian mendalam, pendekatan alami berikutnya 
adalah untuk membagi domain input ke dalam satu set kelas kesetaraan, sehingga jika 
program itu bekerja dengan benar untuk nilai, maka ia akan bekerja dengan benar untuk 
semua nilai-nilai lain di kelas itu. Jika kita memang bisa mengidentifikasi kelas 
tersebut, maka pengujian program dengan satu nilai dari masing-masing kelas kesetaraan 
setara dengan melakukan tes lengkap dari program.

        Kelas kesetaraan terbentuk dari input yang perilaku sistem ditentukan atau 
diharapkan untuk menjadi serupa. Dasar pemikiran pembentukan kelas kesetaraan 
seperti ini adalah asumsi bahwa jika spesifikasi memerlukan perilaku yang sama 
untuk setiap elemen dalam kelas nilai-nilai, maka program kemungkinan akan dibangun 
sehingga baik berhasil atau gagal untuk masing-masing nilai dalam kelas. Misalnya, 
spesifikasi modul yang menentukan nilai mutlak untuk bilangan bulat menentukan satu 
perilaku untuk bilangan bulat positif dan satu lagi untuk bilangan bulat negatif. 
Dalam hal ini, kita akan membentuk dua kelas kesetaraan salah satu yang terdiri dari 
bilangan bulat positif dan yang lain terdiri dari bilangan bulat negatif.

        Kelas kesetaraan biasanya dibentuk dengan mempertimbangkan kondisi masing-masing 
ditetapkan pada input sebagai menentukan kelas kesetaraan valid dan satu atau lebih 
valid kelas kesetaraan.


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 kelas kesetaraan, 
masing-masing terdiri dari nilai-nilai yang perilaku diharapkan untuk menjadi serupa. 
Misalnya, untuk input karakter, jika kita memiliki alasan untuk percaya bahwa program 
ini akan melakukan tindakan yang berbeda jika karakter adalah huruf, angka, atau 
karakter khusus, maka kita harus membagi masukan ke dalam tiga kelas kesetaraan valid.

        Pendekatan lain untuk membentuk kelas kesetaraan adalah untuk mempertimbangkan 
nilai khusus yang perilaku dapat berbeda sebagai kelas kesetaraan. Misalnya, nilai 0 bisa 
menjadi nilai khusus untuk input bilangan bulat. Juga, untuk setiap kelas kesetaraan valid, 
satu atau lebih valid kelas kesetaraan harus diidentifikasi.

8.3.2 Analisis Nilai Batas
        Uji kasus yang memiliki nilai-nilai pada batas-batas kelas kesetaraan karena 
itu cenderung "high-yield" uji kasus, dan memilih uji kasus tersebut adalah tujuan dari 
analisis nilai batas. Dalam analisis nilai batas [68], kita memilih masukan untuk kasus 
uji dari kelas kesetaraan, sehingga masukan terletak di tepi kelas ekivalen. nilai batas 
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 output yang terletak di batas kelas data keluaran.



8.3.3 Pengujian Berpasangan
        Pada umumnya banyak parameter yang menentukan perilaku sistem perangkat lunak. 
Parameter ini bisa menjadi masukan langsung ke perangkat lunak atau pengaturan implisit 
untuk perangkat. Parameter ini dapat mengambil nilai-nilai yang berbeda, dan untuk beberapa 
dari perangkat lunak mungkin tidak bekerja dengan baik. Ada banyak cacat dalam perangkat 
lunak, pada umumnya melibatkan satu syarat, yaitu, beberapa nilai khusus dari parameter. 
cacat seperti ini disebut kesalahan Single-Mode [70]. Contoh kesalahan sederhana dari 
Single-Mode adalah software tidak mampu mencetak untuk jenis tertentu dari printer, 
sebuah perangkat lunak yang tidak dapat menghitung nilai dengan benar ketika nilai 
tersebut bernilai kecil, dan software billing telepon yang tidak dapat menghitung 
tagihan tertentu dengan benar.