Mkpl Pertemuan5

1,364 views
1,189 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,364
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • sensibilier les stagiaires au test des conditions élémentaires pour les structures de coontrôle (pas prise en charge par les outils aujourd'hui) if ( a>b and b>c) then max=a; else max = 100; end if ; il faut examiner les cas ou a>b b>c combinaison V V V V F F F V F F F F et ne pas se contenter des 2 premiers cas qui conduisent à une couverture de CDD En fait, le dernier cas n’est pas utile car on peut ecrire les choses de la facon suivante : if ( a>b) then if (b > c) then max=a; end if else max = 100; end if ;
  • Mkpl Pertemuan5

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

    ×