Black Box Testing
Klasifikasi black box testing mencangkup beberapa pengujian,
diantaranya sebagai berikut :
1. Pengujian fungsional (Functional
testing)
Pada jenis pengujian ini,
perangkat lunak di uji untuk persyaratan fungsiolanal. Pengujian di lakukan
dalam bentuksi tertulis untuk memeriksa apakah aplikasi berjalan seperti yang
di harapkan. Walaupun pengujian fungsional sudah sering di lakukan di bagian akhir
dari siklus pngem angan , masing – masing komponen dan proses dapat di uji pada
awal pengem bangan, bahkan sebelum sistem berpungsu. Pengujian ini sudah dapat
di lakukan pada seluruh sistem. Pengujian pungsional meliputi seberapa baik
sistem melaksanakan fungsinya, termasuk perintah – perintah pengguna,
manipulasi data, pencarian dan feroses bisnis, penggunalayar dan integrasi.
Pengujian juga meliputi permukaan yang jelas dari jenis fungsi-fungsi, serta
operasi back end (seperti ,keamanan dan bagaimana meningkatkan sistem ).
2. Pengujian tegangan (stress
testing)
Pengujian tegangan berkaitan
dengan kualitas aplikasi di dalam lingkungan.
Idenya adalah untuk menciptakan sebuah lingkungan yang lebih menuntut
aplikasi, tidak seperti saat aplikasi dijalankan pada beban kerja normal. Pengujian
ini adalah yang paling sulit, cukup kompleks di lakukan, dan memerlukan upaya
bersama dari semua tim.
3. Pengujian beban (load
testing)
Pada pengujian beban aplikasi
akan di uji dengan beban berat atau masukan, seperti yang terjadi pada
pengujian situs web, Untuk mengetahui apakah aplikasi atau situs gagal atau
kinerjannya menurun. Pengujian beban ber oprasi pada tingkat beban standar, biasanya
beban tertinggi akan diberikan ketika sistem dapat menerima dan tetap berpungsi
dengan baik. Perlu di ketahui bahwa pengujian beban tidak bertujuan untuk
merusak sistem dengan banyak hal, namun
mencoba untuk menjaga agar sistem selalu kuat dan berjalan dengan lancar.
4. Pengjian khusus (ad-hoc
testing)
Jenis pengujian ini di lakukan tanpa penciptaan
rencana pengujian (test plan ) atau kasus pengujian (test case ). Pengujian kasus membantu dalam menentukanlingkungan dan durasi
dari sebagai pengujian lainnya dan juga membantu para penguji dalam mempelajari
aplikasi sebelum memulai pengujian ini merupakan metode pengujian forma yang
paling sedikit. Salah satu penggunaan terbaik daripengujian khusus adalah untuk
penemuan. Membaca persyaratan atau sfesikasi (jika ada) jarang memberikan
panduan yang jelasmengenai bagaimana sebuah program benar-benar bertindak
bahkan dokumentasi penggunaan tida menangkap’’look
and feel’’dari sebuah program. Pengujian khusus dapat menemukan lubang-lubang
dalam pengujian strategi dan dapat mengekspos hubungan di antara sub sistem
lain yang tidak jelas. Dengan cara ini, pengujian khusus berfungsi sebagai alat
untuk memeriksa kelengkapan yang anda uji.
5. Pengujian penyelidikan (exploratory
testing)
Pengujian penyelidikan mirip
dengan pengujian khusus dan dilakukan untuk mempelajari / mencari aplikasi.
Pengujian penyelidikan perangkat lunak ini merupakan pendekatan yang
menyenangkan untuk pengujian.
6. Pengujian usabilitas (usability
testing)
Pengujian ini di sebut juga
sebagai pengujian untuk keakraban pengguna (testing
for user-friendliness). Pengujian ini di lakukan jika antarmuka penguna
dari aplikasinya penting dan harus spesifik untuk jenis penguna tertentu.
Pengujian usabilitas adalah proses yang bekerja dengan penguna akhir secara
langsung maupun tidak langsung untuk menilai bagaimana pengguna merasakan paket
perangkat lunak dan bagai mereka berinteraksi dengannya. Proses ini akan
membongkar area kesulitan pengguna seperti halnya area kekuatan. Tujuan dari
pengujian usabilitis harus membatasi dan menghilangkan kesulitan bagi pengguna
dan untuk memengaruhi area yang kuat untuk usabilitas maksimum. Pengujian ini
idealnya melibatkan masukan dari pengguna secara langsung maupun tidak langsung
(mengamati prilaku) dan bila memungkikan melibatkan komputer yang di dukung
umpan balik. Komputer yang di dukung umpan balik sering kali (jika tidak
selalu) dihilangkan untuk proses ini. Komputer yang di dukung dengan umpan
balik dapat berperan sebagai pengatur waktu (timer) pada dialog untuk monitoring
(memonitor) berapa lama waktu yang di perlukan pengguna untuk
menggunakan dialog dan alat menghitung (counter)
untuk menentukan seberapa sering kondisi tertentu terjadi (misalnya, pesan error, bantuan pesan, dan lain – lain).
Biasanya, proses tersebut melibatkan modivikasi sepele (trivial) dari perangkat lunak yang sudah ada, namun dapat berakibat
besar terhadap laba atas investasi. Akhirnya, pengujian usabilitas
mengakibatkan perubahan pada produk yang diberikan sesuai dengan penemuan yang
di buat mengenai kegunaan. Perubahan ini harus secara langsung berkaitan dengan
fungsinya di dunia nyata dengan pengguna pada umumnya. Dokumen ini harus di
tulis semaksimal mungkin untuk mendukung perubahan sehingga mempermudah penanganan
situasi yang sama di masa yang akan datang.
7. Pengujian asap (smoke
testing)
Jenis pengujian ini di sebut
juga pengujian kenormalan (sanity testing).
Pengujian ini dilakukan untuk memeriksa apakah aplikasi tersebut sudah siap
untuk pengujian yang lebih besar dan bekerja dengan baik tanpa cela sampai
tingkat yang paling diharapkan. Pada sebuah pengujian baru atau perbaikan
peralatan yang terpasang, jika aplikasi “berasap”, aplikasi tersebut tidak
bekerja ! istilah ini juga merujuk langsung kepada pengujian perangkat lunak (software) dasar. Istilah ini awalnya
tercipta pada manufaktur kontainer dan pipa, ketika smoke telah di perkenalkan untuk menentukan apakah ada kebocoran.
Praktik umum di Microsoft dan beberapa perusahaan perangkat lunak shrini-wrap lainnya adalah proses “daily build and smoke test”. Setiap file
di kompilasi, dihubungkan, dan digabungkan menjadi sebuah perogram yang dapat
di eksekusi setiap hari, dan program ini kemudian di masukan melalui “pengujian asap ” (smoke test) yang relatif sederhana untuk memeriksa apakah
produk “berasap” ketika produk
dijalankan.
8. Pengujian pemulihan (recovery
testing)
Pengujian pemulihan (recovery testing ) pada dasarnya
dilakukan untuk memeriksa seberapa cepat dan baiknya aplikasi bisa pulih
terhadap semua jenis crash atau
kegagalan hardware, masalah bencana dan lain lain. Jenis atau taraf pemulihan
di tetapkan dalam persyaratan spesifikasi.
9. Pengujian volume (volume
testing)
Pengujian volume dilakukan terhadap efisiensi dan aplikasi.
Jumlah data yang besar di proses melalui aplikasi (yang sedang di uji) untuk
memeriksa keterbasan ekstrem dari sistem. Seperti namanya, pengertian volume
adalah pengujian sebuah sistem (baik perangkat keras dan perangkat lunak) untuk
serangkaian pengujian dengan volume data yang di proses adalah subjek dari
pengujian, seperti sistem yang mendapat menangkap sistem pengolahan trasaksi penjualan
real-time atau dapat memperbaharui
basis data atau pengembalian data (data
retrieval).
Pengujian volume akan berusaha memastikan batas – batas
fisik dan logis untuk sebuah kapasitas sistem dan memastikan apakah batasan
dapat di terima untuk memenuhi proyeksi kapasitas dari pengolahan bisnis
organisasi.
10. Pengujian Domain (domain
testing)
Pengujian domain ini sering
kali menjelaskan teknik pengujian. Beberapa penulis biasanya hanya menulis
tentang pengujian domain ketika mereka menulis desain pengujian. Dugaan dasarnya
adalah bahwa nada mengambil ruang pengujian yang memungkinkan dari variabel
indvidu dan membaginya lagi kedalam subset (dalam beberapa cara) yang sama. Kemudian,
anda menguji perwakilan dari masing masing subset.
11. Pengujian skenario (Scenario
testing)
Pengujian ini adalah sebuah pengujian
yang realitas, kredibel dan memotivasi stakeholder, tantangan untuk program dan
mempermudah penguji untuk melakukan evaluasi. Pengujian ini menyediakan kombinasi
variabel – variabel dan fungsinya yang sangat berarti daripada kombinasi buatan
yang anda dapatkan dengan pengujian domain atau desain pengujian kombinasi.
12. Pengujian regresi (regression
testing)
Pengujian ini adalah gaya
pengujian yang berfokus pada pengujian ulang (retesting) setelah ada perubahan. Pada pengujian regresi
berorientasi resiko (risk-oriented
regression testing), daerah yang sama yang sudah di uji, akan kita uji lagi
dengan pengujian yang berbeda (semakin komplek). Usaha dari pengujian ini bertujuan
untuk mengurangi resiko sebagai berikut :
a. Perubahan untuk memperbaiki bug yang gagal
b. Beberapa perubahan memiliki efek samping, tidak memperbaiki
bug lama atau memperkenalkan bug baru.
13. Penerimaan pengguna (user
acceptance)
Dalam pengujian ini perangkat
lunak akan di serahkan kepada pengguna
dan bekerja seperti yang diharapkan. Pada pengembangan perangkat lunak, user acceptance testing (UAT), juga di
sebut pengujian beta (beta testing), pengujian
aplikasi (application testing), dan
pengujian penggunaan akhir (end user
testing) adalah tahapan pengembangan perangkat lunak ketika perangkat lunak
di uji pada “dunia nyata” yang dimaksud oleh pengguna. UAT dapat dilakukan
dengan in-house testing dengan
membayar relawan atau subjek penguji perangkat lunak atau biasanya mendistribusikan
perangkat lunak secara luas dengan melakukan pengujian versi yang tersedia
secara gratis untuk di unduh melalui web. Pengalaman awal pengguna akan di
teruskan kembali kepada para pengembang yang membuat perubahan sebelum akhirnya
melepaskan perangkat lunak komersial.
14. Pengujian alfa (alpha
testing)
Pada pengujian ini akan di
undang ke pusat pengembangan dengan maksud pengguna akan mengunakan aplikasi
dan pengembang mencatat setiap masukan atau tindakan yang di lakukan oleh pengguna.
Semua jenis perilaku yang tidak normal atau tidak sesuai dari sistem di catat
dan di koreksi oleh pengembang.
15. Pengujian beta (beta testing)
Pada tahap penguian ini
perangkat lunak di distribusikan sebagai sebuah versi beta dengan pengguna yang
menguji di situs mereka. Kesalahan atau cacat akan di laporkan kepada
pengembang. Pengujina beta ini dilakukan setelah pengujian alfa. Versi beta ini
di rilis untuk pengguna yang terbatas di luar perusahaan. Perangkat lunak di
lepaskan ke kelompok masyarakat agar dapat memastikan bahwa perangkat lunak
tersebut memiliki beberapa kesalahan atau bug.
Itulah sekilas tentang klasifikasi Black box testing dalam RPL, semoga bermanfaat, untuk info lebih lanjut anda dapat membuka website resminya. Terimakasih..!
Sumber referensi :
Simarmata janner,"Rekayasa Perangkat Lunak", ANDI
0 comments:
Post a Comment