TESTING DAN IMPLEMENTASI

INDRA KURNIAWAN

NPM : 2013020077

Proses Testing

1. Unit testing => Pengujian masing-masing unit komponen program untuk meyakinkan bahwa program sudah beroperasi secara benar.

2. Module Testing => Pengujian terhadap koleksi unit-unit komponen yang saling berhubungan.

3. Sub-sistem Testing => Pengujian terhadap koleksi modul-modul yang membentuk suatu sub-sistem.

4. Sistem Testing => Pengujian terhadap keterhubungan antar sub-sistem.

1.      Penerimaan Testing

2.      Pengujian terakhir sebelum sistem dipakai oleh user.

3.      Melibatkan pengujian dengan data dari pengguna sistem.

4.      Biasa dikenal sebagai “alpha test”.

Proses Testing

1.      Component testing

2.      Pengujian komponen-komponen program

3.      Biasanya dilakukan oleh component developer

1.      Integration testing

Pengujian kelompok komponen-komponen yang terintegrasi untuk membentuk sub-sistem ataupun system dan dilakukan oleh tim penguji yang independent.

1.      Proses testing

Deskripsi fase-fase utama dalam pengujian.

1.      Pelacakan kebutuhan

Semua kebutuhan user diuji secara individu.

1.      Item yang diuji

Menspesifikasi komponen sistem yang diuji.

1.      Jadual testing

2.      Prosedur pencatatan hasil dan prosedur

3.      Kebutuhan akan hardware dan software

4.      Kendala-kendala

Failures, Faults

1.      Failure: output yang tidak benar/tidak sesuai ketika sistem dijalankan.

2.      Fault: kesalahan dalam source code yang mungkin menimbulkan failure ketika code yang fault tersebut dijalankan.

Prioritas Testing

1.  Hanya test yang lengkap yang dapat meyakinkan sistem terbebas dari kesalahan, tetapi hal ini sangat sulit dilakukan.

2.  Prioritas dilakukan terhadap pengujian kemampuan sistem, bukan masing-masing komponennya.

3.  Pengujian untuk situasi yang tipikal lebih penting dibandingkan pengujian terhadap nilai batas.

Test Data dan Kasus Test

-       Test data:  Input yang direncankan digunakan oleh sistem.

-       Test cases: Input yang digunakan untuk menguji sistem dan memprediksi output dari input jika sistem beroperasi sesuai dengan spesifikasi.

Integration Testing

Adalah pengujian keseluruhan sistem atau sub-sistem yang terdiri dari komponen yang terintegrasi. Beberapa pendekatan yang dilakukan yaitu :

1.      Top-down testing

Berawal dari level atas sistem dan terintegrasi dengan mengganti masing-masing komponen secara top-down dengan suatu stub (program pendek yang mengenerate input ke sub-sistem yang diuji).

1.      Bottom-up testing

Integrasi komponen dari level bawah hingga sistem lengkap sudah teruji.

Pada prakteknya, kebanyakan test integrasi menggunakan kombinasi kedua strategi pengujian tersebut.

Interface Testing

Dilakukan jika modul-modul dan sub-sistem terintegrasi dan membentuk sistem yang lebih besar. Tujuannya untuk medeteksi fault terhadap kesalahan interface atau asumsi yang tidak valid. Interface testing terdiri dari beberapa tipe, yaitu :

-       Parameter interfaces

-       Shared memory interfaces

-       Procedural interfaces

-       Message passing interfaces

Interface Errors

-       Interface misuse

Komponen pemanggil memanggil komponen lainnya dan membuat suatu kesalahan dalam penggunaan interfacenya.

-       Interface misunderstanding

Komponen pemanggil salah dalam mengasumsikan behaviour komponen yang dipanggil.

-       Timing errors

Komponen yang memanggil dan yang dipanggil beroperasi pada kecepatan yang berbeda.

Petunjuk Melakukan Interface Testing

-       Merancang test dimana parameter ke prosedur yang dipanggil berada pada nilai batas extrim

-       Test menggunakan null pointer

-       Perancangan test sehingga komponen yang di test akan fail.

-       Menggunakan stress testing pada message passing

-       Pada shared memory systems, variasikan urutan dimana komponen diaktifkan.

Stress testing => Menguji sistem dengan nilai yang melebihi maksimum load. Stressing suatu sistem menyebabkan tidak mudah kerusakan dengan mencek kehilangan service yang tidak diduga ataupun data yang hilang.

Object-oriented testing => Lebih besar dibandingkan pengujian sebuah function sehingga pendekatan  white-box testing perlu diperluas. Komponen yang diuji adalah class object yang di instantiate ke object.

Testing Levels

-       Testing operations pada objects

-       Testing object classes

-       Testing clusters cooperating objects

-       Testing OO system secara lengkap

Pengujian Class => Menguji terhadap semua operation yang ada dan perubahan atribut-atributnya.

Object Class Testing

1.    Complete test yang menguji class melibatkan

-        Testing semua operations suatu object

-       Setting dan interrogating semua attribute object

-       Menguji object untuk semua keadaan yang mungkin

2.    Inheritance akan mengakibatkan sulitnya perancangan object class tests seperti information yang diuji sulit dilokalisasi.

Cluster Testing

· Cluster testing digunakan untuk test integrasi and testing clusters terhadap cooperating objects.

· Identifikasi clusters menggunakan knowledge operation objects dan system features yang diimplementasikan oleh cluster tersebut

Scenario-based Testing

-       Identifikasi skenario dari use-cases dan menambahkannya dengan diagram interaksi yang menunjukkan object-object yang terlibat  dalam scenario.

-       Lihat contoh scenario berikut ini pada sistem weather station ketika suatu report dibuat.

Testing Workbenches

-       Testing merupakan suatu proses yang cukup mahal. Testing workbenches menyediakan tool-tool untuk mereduksi waktu yang dibutuhkan dan total cost pengujian.

-       Kebanyakan testing workbenches merupakan open systems karena kebutuhan testing tergantung dari spesifikasi organisasi.

Testing Workbench Adaptation

-       Scripts dibuat untuk user interface simulator dan model test data generator.

-       Test outputs harus disiapkan secara manual sebagai pembanding.

-       Special-purpose file comparators harus dibuat.

Prinsip Pemilihan Bahasa Pemrograman

Memiliki sintaks yang jelas

Memiliki semantik yang jelas

Precedence operator dalam expresi mudah dimengerti

Modular dan Information hiding

· § Model Integrasi sub-modul yang dapat di-link oleh beberapa sub-modul lain secara independent.

· § Setiap sub-modul yang di-link tersebut menjadikan suatu model abstraksi untuk information hiding.

· Ø Abstraksi

Tersedia fasilitas untuk mendefinisikan tipe data baru sbg abstraksi data, maupun abstraksi algoritma.

· Ø Orthogonal

Hanya ada satu cara dalam mengekspresikan suatu action, tidak bergantung tehadap komponen lain (tipe data composite dan return function sesuai tipe data yang diinginkan).

· Ø Portability

Dapat diinstal proses kompilasi pada beberapa jenis mesin dan OS.

· Ø Structure

· Control flow

· Name scope (bagaimana menggunakan referensi variable) -> pointer

· Typing (static, dynamic)

oØ Compiler dapat mendeteksi error melalui check yang konsisten.

oØ Efisiensi

oØ Seragam dalam penggunaan statement

oØ Dapat mengantisipasi kondisi exception

oØ Mampu menangani proses yang concurrent (bersamaan) -> multithread, parallel processing

Kategori Aplikasi

-       Paradigma pemrosesan data

-       Paradigma komputasi numeric

-       Paradigma berorientasi proses

-       Paradigma system-programming

-       Paradigma proses auto-adaptive

Pengujian Aplikasi Server

Volume Testing

· Ø Menemukan kelemahan sistem selama melakukan pemrosesan data dalam jumlah yang besar dalam periode waktu yang singkat.

· Ø Tujuan: meyakinkan bahwa sistem tetap melakukan pemrosesan data antar batasan fisik dan batasan logik.

Stress Testing

· Ø Tujuan:mengetahui kemampuan sistem dalam melakukan transaksi selama periode waktu puncak proses.

Performance Testing

· Ø Dilakukan secara paralel dengan Volume dan Stress testing untuk mengetahui unjuk kerja sistem (waktu respon, throughput rate) pada beberapa kondisi proses dan konfigurasi.

Data Recovery Testing

· Ø Investigasi akan dampak kehilangan data melalui proses recovery ketika terjadi kegagalan proses.

Data Backup and Restore Testing

· Ø Dilakukan untuk melihat prosedur back-up dan recovery.

· Ø Dilakukan dengan mensimulasikan beberapa kesalahan untuk menguji proses backup dan recovery.

Data Security Testing

· Ø Privilege access terhadap database diujikan pada beberapa user yang tidak memiliki privilege access ke database.

· Ø Shutdown database engine melalui operating system (dengan beberapa perintah OS) yang dapat mematikan aplikasi database.

Test Case

-       Untuk White-box testing

-       Pengujian struktur logik internal

-       Perintah spesifik yang diujikan:

-       SELECT

-       OPEN/CLOSE

-       COPY-REPLACE

-       IF statement

-       REPEAT UNTIL – DO-WHILE LOOP

-       CALL

-       Untuk Black-box testing

-       Pengujian fungsional sistem berdasarkan input – output

-       Membagi input – output ke dalam beberapa kelas (kelas ekuivalensi pada boundary input).

-       Menggunakan input yang tidak sesuai spesifikasi (negatif, di luar range)

Kegiatan Implementasi System

-       Menyiapkan Rencana Implementasi

-       Rencana Functional Test

-       Rencana Data Conversion

-       Rencana System Cutover

-       Rencana Training User

-       Membuat dan Test Networks

-       Install Hardware

-       Membuat Database Structures Production dan Test Databases

Sistem Acceptance Test

-       Bertujuan untuk menguji apakah sistem sudah sesuai dengan apa yang tertuang dalam spesifikasi fungisonal sistem (validation),

-       Terdiri dari dua tahapan: Sebelum pengiriman dan setelah instalasi,

-       Melibatkan semua aspek sistem: hardware, software aplikasi, environment software, tempat, dan operators.

-       Test dokumentasi terdiri dari tujuh bagian, diantaranya :

1.  Test Filosofi

Untuk meyakinkan bahwa sistem sudah memiliki:

–        Keamanan dan keselamatan dalam operasional,

–        Kehandalan,

–        Dapat dirawat secara cost-effective,

–        Dapat dimodifikasi untuk menyesuaikan dengan perubahan kebutuhan operasional.

2.    Test Plan

Merupakan dokumentasi yang menjelaskan jadwal untuk pre-delivery dan site acceptance test.

Jadwal test: urutan Test yang menyatakan kaitan antara test satu dengan yang lainnya dan masing-masing test tersebut sesuai dengan salah satu kebutuhan user.

3.    Spesifikasi Test

Setiap test yang akan dilakukan harus dispesifikasikan secara detail oleh pengembang dan disetujui oleh user. Spesfikasi tersebut terdiri dari:

–        Judul dan referensi tunggal

–        Tujuan yang secara spesifik sesuai dengan Functional Requirement

–        Lokasi pengujian

–        Syarat Pengujian: mis.: nilai marginal input, supplies, dan lingkungan yang digunakan

–        Konfiguasi Test: versi dan isu hardware, software, test dan bantuan simulasi

–        Spesifikasi input dan output

–        Detail prosedur operasional pengujian

–        Hasil yang dinginkan dan batasan untuk penerimaan

–        Format untuk merekam hasil, details kesalahan dan instruksi untuk melakukan test ulang, perekaman terhadap retensi dan analisis

4.    Pre-Delivery Test

Dilakukan melalui simulasi terhadap tempat yang implementasi sistem. Syarat utk memulai pengujian: konfiramsi terhadap kebenaran data, dokumen, software aplikasi dan test khusus atau software simulasi, dan ketersediaan lingkungan yang sesuai, pelayanan dan personal yang cocok,

5.    Test Log

Log semua operasi dan kejadian selama test (yang terencana maupun tidak) termasuk full detail insiden, error, failure, retest, restart.

6.    Test Summary

lsiting semua kegagalan test (termasuk pengulangan), kejadian yang tidak dapat dijelaskan dan non-conformances terhadap Functional test.

7.    Site Acceptance Test

Semua pengujian pada pre-delivery sudah dilakukan dan diterima. Hal tambahan yang dilakukan :

–        Delivery check: pengecekan terhadap kerusakan HW, SW dan dokumnetasi selama pengiriman,

–        Test Hardware: tidak terdapat kerusakan selama pengimpanan dan pengiriman, sudah install dengan baik, beroperasi dengan baik di lingkungan tempat yang akan diinstal (listrik, ruangan, dll).

–        Modifikasi pre-delivery test: semua modifikasi sebagai konsekuensi dari masalah yang akan muncul selama pre-delivery test harus dijadikan sebagai test tambahan.

–        Pengujian terhadap semua peralatan.

Automated test execution: meminimalkan jumlah kerja manual pada saat pengujiaan sehingga memperoleh nilai coverage yang lebih tinggi. Code coverage adalah metrik yang numerik yang mengukur elemen code (brach, statement, path dan data) yang sudah diujikan. Penggunaan tool pengujian code coverage dapat membantu mempercepat proses pengujian

Use case adalah visualisasi keinginan user yang dibuat dalam bentuk UML(Unified Modeling Language). Dalam pembentukan sebuah test case didasarkan oleh dua hal, yaitu basic flow (sistem berjalan dengan normal) dan alternate flow (alternatif jalannya sistem).

Contoh :

· Flow Normal : Logon -> Select “Create Schedule” -> Obtain Course Information -> Select Course -> Submit Schedule -> Display Completed Course.

· Alternate Flow: Unidentified Student; Quit at anytime; Unfulfilled Prerequisite, Course Full,  Schedule Conflict; Course Catalog Unavailable; Course Registration is Closed.

Proses yang dilakukan dalam pembuatan test case sebagai berikut :

1.      Generate Scenarios

2.      Identify Test Cases

3.      Identify Data Values to Test

Sistem Implementasi

·  Training Personal

·  Konversi Sistem

·  Review post-implementation

·  Dokumentasi

·  Dukungan lain

Training

Tipe Training disesuaikan dengan keadaan lingkungan implementasi system.

Eksternal Training: kursus dari vendor pelatihan

Internal Training: On the Job Training

Belajar Sendiri

Memilih Staf yang akan dilatih terdiri dari tiga kelompok user, yaitu :

1.      Teknisi & Administrator yang akan bertugas merawat sistem

2.      Application user (user pd umumnya)

3.      General Manager

Pelatihan untuk Administrator:

–        Set-up sistem awal

–        Rutinitas harian

–        Diagnosis kesalahan

–        Menulis sistem log

–        Trouble shooting

–        Penanganan Keamanan

–        Melakukan perubahan, penghapusan

–        Melakukan Backup

Aplikasi Training

–        Set up files

–        Proses transaksi

–        Validasi data

–        Update batch

–        Prosedur akhir-hari

–        Mencetak laporan

–        Pemahaman pesan kesalahan

Konversi Sistem Baru

1.    Konversi sistem secara langsung

Disebut juga sbg Cold Turkey yaitu langsung menghentikan sistem lama dan  menjalankan sistem baru.

2.    Konversi paralel

Sistem lama dan sistem baru beroperasi bersamaan untuk periode waktu tertentu.

3.    Konversi Phase- In

Sistem baru diimplementasikan secara gradual, sedikit demi sedikit -> memeberikan waktu lebih utk asimilasi prubahan.

4.    Konversi Pilot

Sistem diinstal hanya pada sebagian organisasi (mis. Kantor cabang atau pabrik).

Evaluasi Sistem Baru

Bertujuan untuk mendapatkan cara meningkatkan efisiensi dan efektifitas sistem baru, serta memberikan informasi untuk pengembangan sistem mendatang.

Dokumentasi

1.      Dokumentasi Proses

Merekam proses pengembangan dan perawatan. Isi dokumentasi proses adalah: perencanaan, jadwal, kualitas proses, standard proses.

1.      Dokumentasi Produk

Menggambarkan produk yang sedang dikembangkan dari sudut pandang engineer pengembang/perawatan. Yang termasuk dokumentasi produk adalah: user manual, help.

Penyebab error dalam software berbeda dengan hardware.

–      Hardware (manufacture, rusak/terlalu lama dipergunakan)

–      Software : tidak mendapatkan requirement yang benar; tidak mendapatkan requirement dengan benar, tidak menerjemahkan requirement dalam suatu cara yang jelas sehingga tidak dapat dipahami oleh programmer.

Maintainable Design

· Kunci untuk mengurangi kebutuhan maintenance adalah:

· Menetapkan user requirement lebih akurat selama sistem development

· Menyusun dokumentasi sistem yang lebih baik

· Menggunakan metoda yang lebih efektif untuk mendesign pemrosesan logic dan mengkomunikasikannya ke anggota project team

· Penggunaan tool dan teknik secara lebih baik

· Mengelola proses engineering system dengan efektif

Program Structure Charts

–        Design yang di strukturkan dengan baik akan meningkatkan maintainability system.

–        Struktur chart dikembangkan secara top down dan modular.

–        Hubungan antar modul bersifat terbatas dan interaksi datanya minimal, sehingga meningkatkan kualitas sistem dan mempermudah maintenance.

–        Tujuan struktur charts untuk identifikasi data yang dilewatkan antar masing-masing module yang saling berinteraksi.

Tingkat Testing

1. Unit testing:

–      Unit program adalah modules atau rutin yang digabung untuk melaksanakan fungsi tertentu.

–      Unit testing fokus pada masing-masing modul dan dilakukan secara independen untuk menemukan error.

· Bottom Up testing: dimulai dari modul yang paling rendah dan paling kecil dan menuju ke modul yang lebih besar

· Top Down testing: dimulai dari modul yang lebih tinggi dan turun ke modul yang lebih rendah

2.  System Testing

–      Pengujian atas integrasi setiap modul dalam sistem

–      Tujuan: menemukan kelemahan sistem dari sisi objektif, spesifikasi dan dokumentasi, termasuk kompatibilitas masing-masing modul.

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

Black Box

       

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:

· Fungsi-fungsi yang tidak benar atau hilang

· Kesalahan interface

· Kesalahan dalam struktur data atau akses database eksternal

· Kesalahan kinerja

· Inisialisasi dan kesalahan terminasi

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.
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

Strategi Black Box System, meliputi :
* 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

Perbedaan White Box & Black Box

  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. 

-       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 :
https://ceriamarcelina.wordpress.com/2012/12/25/rangkuman-mata-kuliah-testing-implementasi/
http://tkjpnup.blogspot.com/2013/12/black-box-testing-dan-white-box-testing.html