Mkpl Pertemuan5
-
Upload
mrirfan -
Category
Technology
-
view
1.488 -
download
2
description
Transcript of Mkpl Pertemuan5
![Page 1: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/1.jpg)
Pengujian, Validasi dan Verifikasi Perangkat Lunak
Pertemuan 5
![Page 2: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/2.jpg)
Definisi Pengujian Perangkat Lunak
Myers’1979 Proses menjalankan program dengan maksud
menemukan kesalahan IEEE’1990
Proses sistem operasi atau komponen menurut kondisi tertentu, pengamatan atau pencatatan hasil dan mengevaluasi beberapa aspek sistem atau komponen
Proses analisa item perangkat lunak untuk mendeteksi perbedaan antara kondisi yang ada dengan yang diinginkan dan mengevaluasi fiture item perangkat lunak
![Page 3: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/3.jpg)
Definisi Pengujian Perangkat Lunak
Proses formal yang ditentukan oleh tim pengujian yang meliputi unit perangkat lunak, beberapa unit terintegrasi atau seluruh paket yang ditentukan oleh program yang berjalan dikomputer. Seluruh test saling terkait dan adanya prosedur pengujian dan kasus pengujian
![Page 4: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/4.jpg)
Tujuan Pengujian PL
Tujuan Langsung Untuk identifikasi dan menemukan beberapa
kesalahan yang mungkin ada dalam perangkat lunak yang diuji
Setelah perangkat lunak dibetulkan, diidentifikasi lagi kesalahan dan ditest ulang untuk menjamin kualitas level penerimaan
Membentuk test yang efisien dan efektif dengan anggaran dan jadwal yang terbatas
Tujuan tidak langsung Mengumpulkan daftar kesalahan untuk digunakan
dalam daftar pencegahan kesalahan (tindakan corrective dan preventive)
![Page 5: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/5.jpg)
Apa yang bisa ditunjukkan oleh pengujian ?
errorserrors
requirements conformancerequirements conformance
performanceperformance
an indicationan indicationof qualityof quality
![Page 6: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/6.jpg)
Kategori Test
Unit unit testing dipakai pada modul single standalone module
atau unit dari code Integration
Testing pada group dari modul System
memeriksa/memvalidasi apakah sistem memenuhi persyaratan
Acceptance testing untuk memastikan bahwa sistem cocok dengan
kebutuhan dari organisasi dan end user Regression
testing setelah perubahan telah dibuat untuk memastikan bahwa tidak ada perubahan yang tidak diinginkan itu ada
![Page 7: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/7.jpg)
Strategi Pengujian Perangkat Lunak
Meskipun metodologi pengujian mungkin berubah, ada dua dasar strategi pengujian Menguji perangkat lunak secara keseluruhan,
sekali untuk semua package yang ada, “big bang testing”
Menguji perangkat lunak per bagian dalam modul (unit testing), dilanjutkan dengan menguji integrasi setiap modul (integration test), selanjutnya seluruh package di uji (system test) Strategi “Incremental Testing”
![Page 8: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/8.jpg)
Incremental Testing
Dibentuk dari dua dasar strategi Bottom-up Top-down
Kedua strategi incremental testing ini menganggap bahwa package perangkat lunak dibangun berdasarkan hirarki modul perangkat lunak
![Page 9: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/9.jpg)
Incremental Testing
Pengujian Top-down Modul pertama yang diuji adalah modul utama Level
modul tertinggi dalam struktur perangkat lunak Modul terakhir yang diuji adalah modul yang berada
pada level paling rendah Pengujian Bottom-up
Kebalikan dari Top-down Yang diuji pertama adalah modul yang terletak pada
level paling rendah Modul terakhir yang diuji adalah modul utama
![Page 10: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/10.jpg)
Bottom Up versus Top down strategies
Bottom Up Keuntungan
Relatif mendorong performance Kerugian
Menghambat program sebagai sebuah keseluruhan modul (yang diamati pertama modul dilevel paling rendah)
Top-down Keuntungan
Memperlihatkan keseluruhan fungsi program semua modul lengkap
Kerugian Sulit menyiapkan potongan program Sulit untuk menganalisa hasil test
![Page 11: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/11.jpg)
Langkah-lagkah membangun taktik pengujian
1. Memperoleh dan mempelajari strategi pengujian
2. Menentukan tipe proyek yang dibangun
3. Menentukan tipe dari sistem perangkat lunak
4. Menentukan ruang lingkup proyek
5. Mengidentifikasi resiko taktik
6. Menentukan kapan testing dilakukan
7. Membangun rencana sistem
8. Membangun rencana test unit
![Page 12: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/12.jpg)
1: Memperoleh dan mempelajari strategi pengujian Dala hal ini, tim harus menanyakan :
Apa hubungan dari kepentingan diantara faktor-faktor test ?
Mana resio level tinggi yang paling signifikan ? Kerusakan apa yang dapat terjadi pada bisnis
apabila perangkat lunak gagal untuk menampilkan dengan benar ataupun tidak lengkap pada waktunya?
Siapa orang yang paling tahu dalam memahami dampak dari resiko bisnis yag telah diidentifikasi?
![Page 13: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/13.jpg)
2: Menentukan tipe proyek yang dibangun
Pembangunan sistem tradisional Prototyping System Maintenance Pembelian atau penyewaan perangkat
lunak
![Page 14: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/14.jpg)
3. Menentukan tipe dari sistem perangkat lunak
Batch Even control Process control Procedure control Advanced mathematical
model Message processing Diagnostic software Sensor and signal
processing Simulation
Database management Data acquisition Data presentation Decision and planning aids Pattern and image
processing Computer system software Software development tools
![Page 15: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/15.jpg)
4. Menentukan ruang lingkup proyek
Pembangunan sistem baru Proses bisnis otomatis
atau manual ? Proses bisnis dan area
yang mana yang akan atau tidak akan terpengaruh ?
interfacing pada sistem yang ada ?
Sistem yang sudah ada akan atau tidak akan terpengaruh ?
Merubah yang sudah ada Hanya mengkoreksi ? Standar perawatan
rekayasa ulang ? Koreksi pada kerusakan
yang tersembunyi untuk ditambahkan pada perbaikan ?
Apakah sistem yang lain terpengaruh ?
Resiko atau regresi ?
![Page 16: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/16.jpg)
5. Mengidentifikasi resiko taktik
Ada tiga kategori dari resiko taktik Structural risks: berhubungan dengan aplikasi dan
metode yang digunakan untuk membangun aplikasi Technical risks: berhubungan dengan teknologi yang
digunakan dalam membangun dan mengoperasikan apikasi
Size risks: berhubungan dengan besarnya dalam segala aspek dari perangkat lunak
![Page 17: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/17.jpg)
6. Menentukan kapan testing dilakukan
Tahap persyaratan Menentukan strategi test Menentukan ketercukupan persyaratan Menjalankan kondisi test fungsional
Tahap Desain Menentukan konsistensi dari desain yang disyaratkan Menentukan ketercukupan desain Menjalankan konsistensi test struktural dan fungsional
Tahap coding Menentukan konsistensi dengan desain Menentukan ketercukupan dari implementasi Menjalankan kondisi test struktural dan fungsional Generate structural
dan functional test untuk program atau unit
![Page 18: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/18.jpg)
7. Membangun rencana sistem
Menetapkan background informasi Software yang di test Objektivitas Test and resiko Fungsi bisnis yang akan dit test Spesifik tests yang akan dilakukan
![Page 19: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/19.jpg)
8. Membangun rencana test unit
Setiap unit harus mempunyai testnya masing-masing
![Page 20: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/20.jpg)
Pengelompokkan berdasarkan konsep pengujian Black box (functionality) testing
Mengidentifikasi kesalahan yang berhubungan dengan kesalahan fungsionalitas perangkat lunak yang tampak dalam kesalahan output.
White box (structural) testing Memeriksa kalkulasi internal path untuk
mengidentifikasi kesalahan disebut juga glass box testing
![Page 21: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/21.jpg)
Definisi Black box dan white box IEEE Black box testing
Pengujian yang mengabaikan mekanisme internal sistem atau komponen dan fokus semata-mata pada output yang dihasilkan yang merespon input yang dipilih dan kondisi eksekusi
Pengujian dilakukan untuk mengevaluasi pemenuhan sistem atau komponen dengan kebutuhan fungsional tertentu
White box testing Pengujian yang memegang perhitungan mekanisme
internal sistem atau komponen
![Page 22: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/22.jpg)
Klasifikasi sesuai kebutuhan
Software Quality Assurance (Daniel Galin) Lihat Tabel 9.1
Mapping antara software quality factor, sub factor dengan klasifikasi test
Lihat Tabel 9.2 Mapping klasifikasi test dengan kategori
pengujian (white box dan black box)
![Page 23: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/23.jpg)
Black Box
Berusaha untuk menemukan Kesalahan atau hilangnya fungsi Kesalahan interface Kesalahan dalam struktur data atau akses eksternal basis data Kesalahan performance Kesalahan inisialisasi dan terminasi
Tes dirancang untuk menjawab pertanyaan berikut ini: Bagaimana validitas fungsi diuji? Kelas input apa yang membuat kasus uji berjalan dengan baik? Apakah sistem tertentu sensitif terhadap beberapa nilai input? Bagaimana batas kelas data dipisahkan? Apakah laju data dan volume data dapat dihadapi sistem? Apa ada dampak khusus jika data digabungkan dengan operasi
sistem?
![Page 24: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/24.jpg)
White box Testing
Ada 4 Kategori test pada white box testing Data processing dan calculations correctness
test Software qualification test Maintainability test Reusability test
![Page 25: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/25.jpg)
Data processing dan calculations correctness Test Melakukan pengecekan data processing
untuk setiap kasus test. Ada 2 pendekatan yang dilakukan:
Path Coverage Rencana test yang mencakup semua
kemungkinan path, dimana coverage diukur dengan berapa % path dicover
Line Coverage Rencana test yang mencakup semua baris kode
program, dimana coverage diukur dengan berapa % line dicover
![Page 26: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/26.jpg)
Correctness tests dan path coverage
Path yang berbeda dalam modul software akan dibentuk oleh pilihan kondisional statement seperti IF-THEN-ELSE atau DO WHILE atau DO UNTIL atau REPEAT-UNTIL
![Page 27: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/27.jpg)
Correctness tests dan line coverage
Untuk full line coverage maka setiap line sedikitnya dieksekusi minimal satu kali selama proses pengujian
![Page 28: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/28.jpg)
McCabe’s cyclomatic complexity metric Dikembangkan oleh McCabe (1976) untuk mengukur
kompleksitas program atau modul pada waktu yang sama sebagai jumlah maksimum independent path yang dibutuhkan untuk mencapai full line coverage pada program.
Dasar ukuran adalah teori graf dan dihitung berdasarkan kesesuaian ke sifat program yang dicapture oleh program flow graph
Independent path adalah setiap path pada program flow graph sedikitnya satu baris yang tidak dibentuk oleh independent path lain.
![Page 29: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/29.jpg)
Example
20 times
A
B
How many test cases ?
![Page 30: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/30.jpg)
Structural test - Control graph(Static point of view)
011123333444445677891011121213141415161617181819
void main (void) { int a, b, c; int min, med, max; if (a>b) { max=a; min=b; } else { max=b; min=a; } if (c>max) {max=c;} else if (c<min) {min=c;} med=a+b+c-min-max; if (max>min+med) {printf("impossible triangle \n");} else if (max==min) {printf("equilateral triangle \n");} else if (max==med || med==min) {printf("isoceles triangle \n");} else if ( max *max == min*min+med*med) {printf("rightangled triangle\n");} else {printf("any triangle\n");} }
v(G) = 25 - 19 + 2 = 8
1
10
1112
1314
3 4
5
6 7
8
9
17
1516
18
19
2
Example :if ( a > b and b > c) then
max=a;else
max = 100;end if ;
![Page 31: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/31.jpg)
RUMUS
V(G) = R V(G) = E – N +2 V(G) = P + 1
Keterangan V(G) = cyclometic complexity metric R = jumlah region dalam program flow graph
Setiap area yang melingkungi graph disebut sebuah region
E = Jumlah Edge (garis) N = Jumlah node P= Jumlah decision
![Page 32: Mkpl Pertemuan5](https://reader036.fdocuments.net/reader036/viewer/2022081412/545850c3af795998788b5402/html5/thumbnails/32.jpg)
Sekian