RANGKUMAN MATERI TESTING DAN IMPLEMENTASI

Nama : MUHAMMAD RIJAL
NPM : 2015020039
Tempat tgl/lahir : sekkang, 03 - Mei - 1998
Hobby : Makan
MAHASISWA STMIK HANDAYANI MAKASSAR

MATERI TESTING

Definisi Testing

• Menurut Hetzel 1973: proses pemantapan kepercayaan akan kinerja program atau sistem sebagaimana yang diharapkan.
• Menurut Myers 1979: proses eksekusi program atau sistem secara intens untuk menemukan error.
• Menurut Hetzel 1983 (Revisi): tiap aktivitas yang digunakan untuk dapat melakukan evaluasi suatu atribut atau kemampuan dari program atau sistem dan menentukan apakah telah memenuhi kebutuhan atau hasil yang diharapkan.
• Menurut Standar ANSI/IEEE 1059: proses menganalisa suatu entitas software untuk mendeteksi perbedaan antara kondisi yang ada dengan kondisi yang diinginkan ( defects / errors / bugs ) dan mengevaluasi fitur- fitur dari entitassoftware.

Definisi Testing Software

• Testing software adalah proses mengoperasikan software dalam suatu kondisi yang dikendalikan, untuk verifikasi apakah telah berlaku sebagaimana telah ditetapkan, validasi apakah spesifikasi yang telah ditetapkan sudah memenuhi keinginan atau kebutuhan dari pengguna yg sebenarnya.
• Verifikasi adalah pengecekan atau pengetesan entitas-entitas, termasuk software untuk pemenuhan dan konsistensi dengan melakukan evaluasi hasil terhadap kebutuhan yang telah ditetapkan. ( Are we building the system right?)
• Validasi melihat kebenaran system, apakah proses yang telah ditulis dalam spesifikasi adalah apa yang sebenarnya diinginkan atau dibutuhkan oleh pengguna.( Are we building the right system?)
• Deteksi error: Testing seharusnya berorientasi untuk membuat kesalahan secara intensif, untuk menentukan apakah suatu hal tersebut terjadi bilamana tidak seharusnya terjadi atau suatu hal tersebut tidak terjadi dimana seharusnya mereka ada.

Strategi Testing

• Strategi testing software mengintegrasikan metode – metode disain test cases software ke dalam suatu rangkaian tahapan yang terencana dengan baik sehingga pengembangan software dapat berhasil.
• Strategi menyediakan peta yang menjelaskan tahap – tahap yang harus dilakukan sebagai bagian dari testing, dan membutuhkan usaha, waktu, dan sumber daya bilamana tahap – tahap ini direncanakan dan dilaksanakan.
• Strategi testing harus menjadi satu kesatuan dengan perencanaan tes, disain test case , ekesekusi tes, dan pengumpulan serta evaluasi datahasil testing.
• Strategi testing software harus cukup fleksibel untuk dapat mengakomodasi kustomisasi pendekatan testing. Pada saat yang bersamaan, harus juga cukup konsisten dan tegas agar dapat melakukan perencanaan yang masuk akal dan dapat melakukan manajemen perkembangan kinerja proyek.

Pendekatan Strategi Testing

• Sejumlah strategi testing software diadakan untuk menyediakan kerangka testing bagi pengembang software dengan karekteristik umum sebagai berikut:

1. Testing dimulai dari tingkat komponen terkecil sampai pada integrasi antar komponen pada keseluruhan sistem komputer tercapai.
2. Teknik testing berbeda – beda sesuai dengan waktu penggunaannya.
3. Testing dilakukan oleh pengembang software dan (untuk proyek besar) dilakukan oleh suatu grup tes yang independen.
4. Testing dan debugging adalah aktifitas yang berlainan, tapi debugging harus diakomodasi disetiap strategi testing.

Unit Testing

• Unit testing berfokus pad usaha verifikasi pada unit terkecil dari disain software – komponen atau modul software.
• Penggunaan diskripsi disain tingkat komponen sebagai tuntunan, jalur kendali yang penting dites untuk menemukan errors , terbatas pada modul tersebut.
• Kompleksitas relatif terhadap tes dan errors yang dicakup dibatasi oleh batasan – batasan dari cakupan yang telah ditetapkan pada unit testing .
• Unit testing berorientasi white box , dan tahapan dapat dilakukansecara paralel pada banyak komponen.

Implementasi dari Unit testing
Untuk memastiakan kebenaran dari algoritma atau kode yang dibuat diperlukan proses testing dan pada kesempatan ini akan dibahas lebih lanjut implementasi unit testing menggunakan JUnit. JUnit ditulis oleh Erich Gamma dan Kent Beck sebagai sebuah open source. JUnit adalah standard tidak langsung sebagai pustaka pengujian untuk bahasa Bahasa. Dari pustaka ini pula, muncul komunitas-komunitas pengembang yang menurunkan JUnit untuk bahasa pemrograman lain, seperti untuk .NET yang disebut sebagai NUnit , PHPUnit untuk bahasa PHP dan JSUnit untuk bahasa JavaScript

Integration Testing adalah pengujian hasil dari pengabungan unit-unit / komponen yang berinteraksi di dalam software. Biasanya software tester menguji bagaimana unit-unit tersebut bekerja
sebagai suatu kombinasi, bukan lagi sebagai suatu unit yang individual.

Contoh nya di dalam test case dibawah:

ID	OBjective	Description	Expected Result
1	Check Login	Input Username dan Password yang benar lalu klik button login	Masuk ke dalam home
2	Check Logout	Klik Button Logout	Kembali ke halaman login dan Sesion Terputus

Pada tahapan integration testing seperti test case di atas, input berupa modul-modul yang telah diuji pada tahapan unit testing, diproses kedalam sub integration testing (interaction testing, UI testing, dll), dan kemudian output yang dihasilkan akan diproses lebih lanjut dalam system testing.

Dalam Integration Testing, Software Tester harus memastikan hasil dari beberapa fungsi tersebut berjalan sesuai yang di harapkan, dan juga Software Tester harus memastikan bahwa output yang di hasil sesuai dengan hasil yang di harapkan.

Teknik Integration Testing

Dalam melakukan Integration Testing terdapat 3 teknik yang sering digunakan oleh SOftware Tester, antara lain:

• Bigbang Integration Testing
• Top-down integration testing
• Bottom-up integration testing

Bigbang Integration Testing

Dalam Bigbang Integration Testing semua komponen atau modul yang terintegrasi secara bersamaan, setelah itu semuanya diuji secara keseluruhan. Sesuai gambar di bawah ini semua modul dari 'Modul 1' ke 'Modul 6' terintegrasi secara bersamaan selanjutnya pengujian akan bisa dilakukan.

Keuntungan: 

• Cocok untuk sistem yang kecil

Kerugian:

• Sulit Melacak Bug apabila terjadi kegagalan di sistem.
• Karena pengujian integrasi dapat dimulai hanya setelah "semua" modul dirancang, tim pengujian akan memiliki sedikit waktu untuk eksekusi dalam tahap uji coba.
• Sulit melacak bug pada interface

Top-down integration testing

Pengujian berlangsung dari atas ke bawah, mengikuti aliran kontrol atau struktur arsitektur (mis mulai dari GUI atau menu utama). Komponen atau sistem yang diganti oleh stub. Berikut adalah diagram dari 'Pendekatan Top down Integration Testing':

Kelebihan:

• Lebih mudah melacak bug apabila terjadi kegagalan di sistem.
• Kemungkinan untuk mendapatkan prototipe awal.
• Lebih mudah melacak Cacat desain utama 

Kerugian:

• Pengujian Fungsi dasar dilakukan di akhir integration testing
• Membutuhkan banyak versi design

Bottom-up integration testing

Pengujian berlangsung dari bawah kontrol mengalir ke atas. Komponen atau sistem yang diganti oleh driver. Berikut adalah gambar dari 'pendekatan Bottom-up integration testing':

Kelebihan:

• Pengujian bisa lebih teliti
• Lebih mudah melacak bug apabila terjadi kegagalan di sistem

Kerugian:

• modul tertinggi dites paling akhir
• Kerangka aplikasi belum bisa dilihat

Mengapa Harus melakukan Integration Testing?

• Sebuah Modul pada umumnya dirancang oleh pengembang perangkat lunak individu yang pengertian dan logika pemrograman mungkin berbeda dari programmer lain. Integration Testing menjadi perlu untuk memverifikasi perangkat lunak modul bekerja dalam kesatuan
• Pada saat pengembangan modul, ada kemungkinan macam perubahan persyaratan oleh klien. Persyaratan baru mungkin tidak bisa dilakukan unit testing  dan karenanya integration testing sangat diperlukan
• Interface dari modul software dengan database bisa terjadi kesalahan
• Supaya User Interface dari aplikasi atau website user friendly 

WHITE BOX TESTING DAN BLACK BOX TESTING

White Box

Pengertian White Box Testing
White box testing adalah pengujian yang didasarkan pada pengecekan terhadap detail perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.
Pengujian dilakukan berdasarkan bagaimana suatu software menghasilkan output dari input . Pengujian ini dilakukan berdasarkan kode program.
 Disebut juga struktural testing atau glass box testing
Teknik pengujian :
1.      Menggambarkan kode program ke dalam graph yaitu node & edge.
Jika berhubungan bernilai 1, bila tidak bernilai nol.
Dalam pengujian ini akan diperoleh hasil :
* Kemungkinan source code yang dieksekusi
* Waktu yang dibutuhkan
* Memori yang digunakan
* Sumber daya yang digunakan

2. Basic path, yaitu pengukuran kompleksitas kode program dan pendefinisian alur yang akan dieksekusi.
Digambarkan sequence, if, atau while nya
Uji coba basis path adalah teknik uji coba white box yg diusulkan Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunkan ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur pengerjaan. Test case yg didapat digunakan untuk mengerjakan basis set yg menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.
3. Data flow testing, untuk mendeteksi penyalahgunaan data dalam sebuah program.
4. Cyclomatic Complexity
Cyclomatic Complexity merupakan suatu sistem pengukuran yang menyediakan ukuran kuantitatif dari kompleksitas logika suatu program. Pada Basis Path Testing, hasil dari cyclomatic complexity digunakan untuk menentukan banyaknya independent paths. Independent path adalah sebuah kondisi pada program yang menghubungkan node awal dengan node akhir.
Terdapat 2 persamaan yang digunakan, yaitu:
V(G)= E - N + 2 atau V(G)= P + 1
Keterangan:
V(G)= cyclomatic complexity untuk flow graph G
E=Jumlah edge(panah)
N=Jumlah node(lingkaran)
P=Jumlah predicate node

• Kelebihan White Box Testing

• Kesalahan logika. Digunakan pada sintaks ‘if’ dan pengulangan. Dimana White Box Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan mendeteksi kapan proses pengulangan akan berhenti.

• Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai dengan kenyataan, untuk di analisa dan diperbaiki.

• Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat case sensitive.

• Kelemahan White Box Testing

• Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk melakukannya

• Fungsi-fungsi yang tidak benar atau hilang

• Kesalahan interface

• Kesalahan dalam struktur data atau akses database eksternal

• Kesalahan kinerja

• Inisialisasi dan kesalahan terminasi

Dokumentasi komponen software, mencangkup pemeriksaan dokumen dari software itu sendiri, yaitu :
* Flowchart yang dibuat
* Deskripsi input yang digunakan
* Deskripsi output yang digunakan
* Deskripsi output yang dihasilkan
* Kesesuaian penulisan (akurasi)
* Kontrol/kendali terhadap sistem yang dibuat
* Batasan nilai untuk testing, meliputi beberapa nilai, yaitu
   - Nilai minimum variabel input
   - Nilai di atas nilai minimum
   - Nilai normal
   - Nilai di bawah nilai maksimum
   - Nilai maksimum
* Equivalent Class Testing, yaitu mengelompokkan input yang direpresentasikan sebagai hasil yang valid atau invalid. Contoh :
Rekruitasi pegawai berdasarkan pengalaman kerja :
<1thn    : diterima, part time
1-3 thn  : diterima, sebagai tenaga kerja profesional
>4 thn  : diterima, sebagai pegawai tetap
Kesalahan yang dapat terdeteksi melalui testing ini ialah :
* kebenaran dokumentasi
* akses basis data
* hasil akhir program
Kelebihan black box testing :
* Spesifikasi program dapat ditentukan di awal
* Dapat digunakan untuk menilai konsistensi program
* Testing dilakukan berdasarkan spesifikasi
* Tidak perlu melihat kode program secara detail
Kekurangan black box testing :
* Bila spesifikasi program yang dibuat kurang jelas dan ringkas, maka akan sulit membuat dokumentasi setepat mungkin

Black Box

br/> 

Pengertian Black Box Testing

Black box testing adalah pengujian yang dilakukan hanya mengamati hasil eksekusi melalui data uji dan memeriksa fungsional dari perangkat lunak. Jadi dianalogikan seperti kita melihat suatu koatak hitam, kit hanya bisa melihat penampilan luarnya saja, tanpa tau ada apa dibalik bungkus hitam nya. Sama seperti pengujian black box, mengevaluasi hanya dari tampilan luarnya(interface nya) , fungsionalitasnya.tanpa mengetahui apa sesungguhnya yang terjadi dalam proses detilnya (hanya mengetahui input dan output).

Black Box pengujian adalah metode pengujian perangkat lunak yang menguji fungsionalitas aplikasi yang bertentangan dengan struktur internal atau kerja (lihat pengujian white-box). Pengetahuan khusus dari kode aplikasi / struktur internal dan pengetahuan pemrograman pada umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni, aplikasi apa yang seharusnya dilakukan. Menggunakan deskripsi eksternal perangkat lunak, termasuk spesifikasi, persyaratan, dan desain untuk menurunkan uji kasus. Tes ini dapat menjadi fungsional atau non-fungsional, meskipun biasanya fungsional. Perancang uji memilih input yang valid dan tidak valid dan menentukan output yang benar. Tidak ada pengetahuan tentang struktur internal benda uji itu.

Metode uji dapat diterapkan pada semua tingkat pengujian perangkat lunak: unit, integrasi, fungsional, sistem dan penerimaan. Ini biasanya terdiri dari kebanyakan jika tidak semua pengujian pada tingkat yang lebih tinggi, tetapi juga bisa mendominasi unit testing juga.

Pengujian pada Black Box berusaha menemukan kesalahan seperti:

Teknik khas Black Box Testing desain meliputi:

1. DECISION TABLE

Decision Tablel adalah cara yang tepat belum kompak untuk model logika rumit, seperti diagram alur dan jika-then-else dan switch-laporan kasus, kondisi mengaitkan dengan tindakan untuk melakukan, tetapi dalam banyak kasus melakukannya dengan cara yang lebih elegan.

Pada tahun 1960-an dan 1970-an berbagai “Decision Table Based“ bahasa seperti Filetab sangat populer untuk pemrograman bisnis.

2. ALL-PAIRS TESTING

All-pairs testing atau pairwise testing adalah metode pengujian perangkat lunak kombinatorial bahwa, untuk setiap pasangan parameter masukan ke sistem (biasanya, sebuah algoritma perangkat lunak), tes semua kombinasi yang mungkin diskrit parameter tersebut. Menggunakan vektor uji dipilih dengan cermat, hal ini dapat dilakukan jauh lebih cepat daripada pencarian lengkap semua kombinasi dari semua parameter, dengan “parallelizing“ pengujian pasangan parameter. Jumlah tes biasanya O (nm), dimana n dan m adalah jumlah kemungkinan untuk masing-masing dua parameter dengan pilihan yang paling.

Alasan di balik semua-All-pairs testing ini: yang sederhana dalam sebuah program umumnya dipicu oleh parameter masukan tunggal. Kategori paling sederhana berikutnya bug terdiri dari mereka bergantung pada interaksi antara pasangan parameter, yang bisa ditangkap dengan menguji semua-pasangan. yang melibatkan interaksi antara tiga atau lebih parameter secara progresif kurang umum [2], sementara pada saat yang sama waktu semakin lebih mahal untuk mencari oleh pengujian mendalam, yang sebagai batas pengujian lengkap semua input yang mungkin.

Banyak metode pengujian menganggap semua-pasang pengujian sistem atau subsistem sebagai kompromi biaya-manfaat yang wajar antara sering komputasi tidak layak tingkat tinggi metode pengujian kombinatorial, dan metode yang kurang lengkap yang gagal untuk menjalankan semua pasangan yang mungkin dari parameter. Karena tidak ada teknik pengujian dapat menemukan semua bug, semua-pasangan pengujian biasanya digunakan bersama dengan berbagai teknik jaminan mutu seperti unit testing, eksekusi simbolik, pengujian bulu halus, dan memeriksa kode.

3. STATE TRANSITION TABLE

Dalam teori automata dan logika sekuensial, state transition table adalah tabel yang menunjukkan apa yang negara (atau negara dalam kasus robot terbatas nondeterministic) suatu semiautomaton terbatas atau mesin finite state akan pindah ke, berdasarkan kondisi saat ini dan masukan lainnya. Sebuah tabel negara pada dasarnya adalah sebuah tabel kebenaran di mana beberapa input adalah kondisi saat ini, dan output termasuk negara berikutnya, bersama dengan keluaran lain.

state transition table adalah salah satu dari banyak cara untuk menentukan mesin negara, cara lain menjadi diagram negara, dan persamaan karakteristik.

4. EQUIVALENCE PARTITIONING

Equivalence partitioning adalah pengujian perangkat lunak teknik yang membagi data masukan dari unit perangkat lunak menjadi beberapa partisi data dari mana test case dapat diturunkan. Pada prinsipnya, uji kasus dirancang untuk menutupi setiap partisi minimal sekali. Teknik ini mencoba untuk mendefinisikan kasus uji yang mengungkap kelas kesalahan, sehingga mengurangi jumlah kasus uji yang harus dikembangkan.

Dalam kasus yang jarang Equivalence partitioning juga diterapkan pada output dari komponen perangkat lunak, biasanya itu diterapkan pada masukan dari komponen diuji. Partisi ekivalen biasanya berasal dari spesifikasi persyaratan untuk atribut masukan yang mempengaruhi pengolahan benda uji. Sebuah masukan telah rentang tertentu yang rentang sah dan lainnya yang tidak valid. Data yang tidak valid di sini tidak berarti bahwa data tidak benar, itu berarti bahwa data ini terletak diluar dari partisi tertentu. Hal ini mungkin lebih tepat dijelaskan oleh contoh fungsi yang mengambil sebuah parameter “bulan“. Jangkauan bulan adalah 1 sampai 12, mewakili Januari-Desember. Jangkauan ini disebut partisi. Dalam contoh ini ada dua partisi lebih lanjut rentang tidak valid. Partisi pertama akan menjadi tidak valid <= 0 dan partisi tidak valid kedua akan menjadi> = 13.

5. BOUNDRY VALUES ANALYSIS

Boundary value analysis merupakan suatu teknik pengujian perangkat lunak di mana tes dirancang untuk mencakup perwakilan dari nilai-nilai batas. Nilai-nilai di tepi sebuah partisi kesetaraan atau sebesar nilai terkecil di kedua sisi tepi. Nilai dapat berupa rentang masukan atau keluaran dari komponen perangkat lunak. Karena batas-batas tersebut adalah lokasi umum untuk kesalahan yang mengakibatkan kesalahan perangkat lunak mereka sering dilakukan dalam kasus-kasus uji.

Strategi Black Box System, meliputi :

Perbedaan White Box & Black Box

o    White box (Struktural) 

§  Dilakukan oleh penguji yang mengetahui tentang QA.

§  Melakukan testing pada software/program aplikasi menyangkut security dan performance program tersebut (meliputi tes code, desain implementasi, security, data flow, software failure).

§  Dilakukan seiring dengan tahapan pengembangan software atau pada tahap testing. 

o    Metode BlackBox  (Fungsional) 

§  Dilakukan oleh penguji Independent.

§  Melakukan pengujian berdasarkan apa yang dilihat, hanya fokus terhadap fungsionalitas dan output. Pengujian lebih ditujukan pada desain software sesuai standar dan reaksi apabila terdapat celah-celah bug/vulnerabilitas pada program aplikasi tersebut setelah dilakukan white box testing. 

§  Dilakukan setelah white box testing. 

Sumber : 
http://www.sistem-informasi.xyz/2017/03/pengertian-integration-testing.html
https://dimaswahab20.wordpress.com/2015/08/19/definisi-testing-dan-implementasi-sistem/
http://tkjpnup.blogspot.com/2013/12/black-box-testing-dan-white-box-testing.html

Read More