CHAPTER 18. TESTING CONVENTIONAL APPLICATION

Resume Mata Kuliah Rekayasa Perangkat Lunak 2018

CHAPTER 18. 

TESTING CONVENTIONAL APPLICATION
"Software Engineering 7th edition ROGER S.PRESSMAN"
Nama: Zuda Pradana Putra
Nim   : 04217044

Oke kali ini saya akan membahas chapter 18 tentang TESTING CONVENTIONAL APPLICATION dari buku karya Roger S. Pressman dengan judul SOFTWARE ENGINEERING A PRACTITIONER'S APPROACH. Jika kalian ingin mendapatkan buku secara gratis dapat klik link berikut!

Jika ingin download untuk versi PPT dapat download disini

Apa itu Testing Conventional Application? 

Pengujian menghadirkan anomali yang menarik bagi para insinyur perangkat lunak, yang menurut sifatnya adalah orang-orang yang konstruktif.Pengujian mengharuskan pengembang membuang praduga tentang "kebenaran" perangkat lunak yang baru saja dikembangkan dan kemudian bekerja keras untuk merancang uji coba untuk "merusak" perangkat lunak. Beizer [Bei90] menggambarkan situasi ini secara efektif ketika dia menyatakan.

MINDMAP

ABOUT Testing Conventional Application

What is it? Setelah kode sumber dibuat, perangkat lunak harus diuji untuk mengungkap (dan memperbaiki) sebanyak mungkin kesalahan sebelum pengiriman ke pelanggan Anda.

Who does it? Selama tahap awal pengujian, seorang software enginers melakukan semua tes. Namun, saat proses pengujian berlangsung, spesialis pengujian dapat terlibat. 

Why is it important? Program wajib di ujicoba dengan maksud software enginers harus menjalankan program sebelum sampai ke pelanggan dengan maksud khusus untuk menemukan dan menghapus semua kesalahan

What are the steps? Untuk aplikasi konvensional, perangkat lunak diuji dari dua perspektif yang berbeda: (1) logika program internal dilaksanakan menggunakan teknik desain “White Box” dan (2) persyaratan perangkat lunak dilakukan menggunakan teknik desain “Black Box”.

What is the work product? Serangkaian kasus uji yang dirancang untuk melatih logika internal, antarmuka, kolaborasi komponen, dan persyaratan eksternal dirancang dan didokumentasikan, hasil yang diharapkan ditetapkan, dan hasil aktual dicatat.

How do I ensure that I’ve done it right? Saat Anda memulai pengujian, ubah sudut pandang Anda. Berusaha keras untuk "merusak" perangkat lunak! Rancang uji kasus secara disiplin dan tinjau kembali kasus uji yang Anda buat untuk ketelitian. Selain itu, Anda dapat mengevaluasi cakupan pengujian dan melacak aktivitas deteksi kesalahan.

18.1 SOFTWARE TESTING FUNDAMENTAL

Tujuan pengujian adalah menemukan kesalahan, dan tes yang bagus adalah tes yang memiliki probabilitas tinggi untuk menemukan kesalahan. Oleh karena itu, Anda harus merancang dan mengimplementasikan sistem berbasis komputer atau produk dengan "testability" dalam pikiran. Testability. James Bach1 memberikan definisi berikut untuk testability: "Software testability adalah seberapa mudah [program komputer] dapat diuji." Karakteristik berikut mengarah ke perangkat lunak yang dapat diuji.

18.2 INTERNAL AND EXTERNAL VIEWS OF TESTING

Produk yang direkayasa (dan sebagian besar hal-hal lain) dapat diuji dengan salah satu dari dua cara: (1) Mengetahui fungsi yang ditentukan bahwa suatu produk telah dirancang untuk melakukan, tes dapat dilakukan yang menunjukkan setiap fungsi beroperasi penuh sementara pada saat yang sama mencari kesalahan di setiap fungsi. (2) Mengetahui cara kerja internal suatu produk, pengujian dapat dilakukan untuk memastikan bahwa “semua roda gigi mesh”, yaitu, operasi internal dilakukan sesuai dengan spesifikasi dan semua komponen internal telah dilaksanakan secara memadai.

18.3 WHITE-BOX TESTING

Pengujian white-box, kadang-kadang disebut pengujian glass-box, adalah filosofi desain pengujian yang menggunakan struktur kontrol yang digambarkan sebagai bagian dari desain tingkat komponen untuk menurunkan kasus uji. Dengan menggunakan metode pengujian white-box, Anda dapat menurunkan kasus uji yang 

menjamin bahwa semua jalur independen dalam modul telah dilakukan setidaknya sekali, 

menjalankan semua keputusan logis di sisi mereka yang benar dan salah, 

menjalankan semua loop pada batas-batas mereka dan dalam batas-batas operasional mereka, dan 

latihan struktur data internal untuk memastikan validitasnya.

18.4 BASIS PATH TESTING

Basis path testing adalah teknik pengujian white-box yang pertama kali diusulkan oleh Tom McCabe [McC76]. Metode jalur dasar memungkinkan perancang tes untuk memperoleh ukuran kompleksitas logis dari desain prosedural dan menggunakan ukuran ini sebagai panduan untuk menentukan kumpulan jalur eksekusi dasar. Uji kasus yang diturunkan untuk latihan dasar ditetapkan dijamin untuk mengeksekusi setiap pernyataan dalam program setidaknya satu kali selama pengujian.

18.4.1 FLOW GRAPH NOTATION

Sebelum kita mempertimbangkan metode path dasar, notasi sederhana untuk representasi aliran kontrol, disebut grafik aliran (atau grafik program) harus diperkenalkan. Grafik aliran menggambarkan aliran kontrol logis menggunakan notasi yang diilustrasikan pada Gambar 18.1. Setiap konstruk terstruktur (Bab 10) memiliki simbol grafik aliran yang sesuai.

18.4.2 INDEPENDENT PROGRAM PATH

Jalur independen adalah jalan mana pun melalui program yang memperkenalkan setidaknya satu set pernyataan pemrosesan baru atau kondisi baru. Ketika dinyatakan dalam bentuk grafik aliran, jalur independen harus bergerak sepanjang setidaknya satu sisi yang belum dilalui sebelum jalur didefinisikan.

18.4.3 DERIVING TEST CASES

Metode pengujian jalur dasar dapat diterapkan ke desain prosedural atau ke kode sumber. Pada bagian ini, saya menyajikan pengujian jalur dasar sebagai serangkaian langkah. Prosedur rata-rata, digambarkan dalam PDL pada Gambar 18.4, akan digunakan sebagai contoh untuk mengilustrasikan setiap langkah dalam metode desain uji kasus. Perhatikan bahwa rata-rata, meskipun algoritma yang sangat sederhana, mengandung kondisi dan loop yang kompleks. 

18.4.4 GRAPH MATRICES

Prosedur untuk mendapatkan grafik aliran dan bahkan menentukan satu set jalur dasar dapat diterima untuk mekanisasi. Struktur data, yang disebut matriks grafik, bisa sangat berguna untuk mengembangkan alat perangkat lunak yang membantu dalam pengujian jalur dasar. Matriks grafik adalah matriks persegi yang ukurannya (yaitu, jumlah baris dan kolom) sama dengan jumlah simpul pada grafik aliran. Setiap baris dan kolom sesuai dengan node yang diidentifikasi, dan entri matriks berhubungan dengan koneksi (sebuah edge) antar node.

18.5 CONTROL STRUCTURE TESTING

Teknik pengujian jalur dasar yang dijelaskan dalam Bagian 18.4 adalah salah satu dari sejumlah teknik untuk pengujian struktur kontrol. Meskipun pengujian jalur dasar sederhana dan sangat efektif, itu belum cukup untuk diuji coba. Pada bagian ini, variasi lain pada pengujian struktur kontrol dibahas. Ini memperluas cakupan pengujian dan meningkatkan kualitas pengujian kotak putih.

18.5.1 CONDITION TESTING

Pengujian kondisi [Tai89] adalah metode desain uji kasus yang melatih kondisi logis yang terdapat dalam modul program. Kondisi sederhana adalah variabel Boolean atau ekspresi relasional, mungkin didahului dengan satu operator TIDAK (¬). Ekspresi relasional mengambil bentuk.

Jika suatu kondisi salah, maka setidaknya satu komponen dari kondisi tidak benar. Oleh karena itu, jenis kesalahan dalam suatu kondisi termasuk kesalahan operator Boolean(operator keliru / hilang / ekstra Boolean), kesalahan variabel Boolean, kesalahan kurung Boolean, kesalahan operator relasional, dan kesalahan ekspresi aritmatika. Metode pengujian kondisi berfokus pada pengujian setiap kondisi dalam program untuk memastikan bahwa itu tidak mengandung kesalahan.

18.5.2 DATA FLOW TESTING

Metode pengujian aliran data [Fra93] memilih jalur uji program sesuai dengan lokasi definisi dan penggunaan variabel dalam program. Untuk mengilustrasikan pendekatan pengujian aliran data, asumsikan bahwa setiap pernyataan dalam program diberi nomor pernyataan unik dan bahwa setiap fungsi tidak mengubah parameter atau variabel globalnya.

18.5.3 LOOP TESTING

Loops adalah landasan bagi sebagian besar semua algoritma yang diimplementasikan dalam perangkat lunak. Namun, kita sering membayar mereka sedikit saat melakukan tes perangkat lunak. Pengujian loop adalah teknik pengujian white-box yang berfokus secara eksklusif pada validitas konstruksi loop. Empat kelas loop yang berbeda [Bei90] 

1. Simple Loop
2. Nested Loop
3. Concatenated Loop
4. Unstructure Loop

18.6 BLACK-BOX TESTING

Pengujian black-box, juga disebut pengujian perilaku, berfokus pada persyaratan fungsional perangkat lunak. Yaitu, teknik pengujian black-box memungkinkan Anda untuk menentukan set kondisi input yang akan sepenuhnya menjalankan semua persyaratan fungsional untuk suatu program. Pengujian black-box bukan merupakan alternatif teknik white-box. Sebaliknya, itu adalah pendekatan pelengkap yang kemungkinan akan mengungkap kelas kesalahan yang berbeda dari metode whitebox. Pengujian black-box mencoba menemukan kesalahan dalam kategori berikut: (1) fungsi yang salah atau yang hilang, (2) kesalahan antarmuka, (3) kesalahan dalam struktur data atau akses database eksternal, (4) kesalahan perilaku atau kinerja, dan (5) ) inisialisasi dan terminasi kesalahan.

18.6.1 GRAPH BASED TESTING METHODS

Langkah pertama dalam pengujian black-box adalah memahami objek5 yang dimodelkan dalam perangkat lunak dan hubungan yang menghubungkan objek-objek ini. Setelah ini selesai, langkah selanjutnya adalah menentukan serangkaian tes yang memverifikasi "semua objek memiliki hubungan yang diharapkan satu sama lain" [Bei95].

18.6.2 EQUIVALENCE PARTITIONING

Partisi kesetaraan adalah metode pengujian black-box yang membagi domain input dari suatu program ke dalam kelas-kelas data dari mana kasus-kasus pengujian dapat diturunkan. Sebuah kasus uji coba yang ideal dengan satu tangan mengungkap kelas kesalahan (mis., Pengolahan yang salah dari semua data karakter) yang mungkin membutuhkan banyak uji kasus untuk dieksekusi sebelum kesalahan umum diamati.