Metodologi dan praktik pengujian perangkat lunak. Jenis Pengujian Perangkat Lunak. Daftar Lengkap

Perkenalan

Metode pengujian perangkat lunak saat ini tidak memungkinkan kami untuk mengidentifikasi semua cacat secara jelas dan lengkap dan menetapkan fungsi yang benar dari program yang dianalisis, oleh karena itu semua metode pengujian yang ada beroperasi dalam kerangka proses verifikasi formal untuk perangkat lunak yang sedang diteliti atau dikembangkan.

Proses verifikasi formal atau pembuktian ini dapat membuktikan bahwa tidak ada cacat dalam hal metode yang digunakan. (Artinya, tidak ada cara untuk secara akurat menetapkan atau menjamin tidak adanya cacat pada produk perangkat lunak, dengan mempertimbangkan faktor manusia yang ada di semua tahap siklus hidup perangkat lunak).

Ada banyak pendekatan untuk memecahkan masalah pengujian dan verifikasi perangkat lunak, namun pengujian yang efektif terhadap produk perangkat lunak yang kompleks adalah proses yang sangat kreatif yang tidak terbatas pada mengikuti atau menciptakan prosedur yang ketat dan tepat.

Pengujian statis juga mencakup pengujian persyaratan, spesifikasi, dan dokumentasi.

Pengujian regresi

Artikel utama: Pengujian regresi

Setelah melakukan perubahan pada versi program berikutnya, uji regresi mengonfirmasi bahwa perubahan yang dilakukan tidak memengaruhi kinerja fungsionalitas aplikasi lainnya. Pengujian regresi dapat dilakukan secara manual atau menggunakan alat otomatisasi pengujian.

Skrip pengujian

Penguji menggunakan skrip pengujian pada tingkat yang berbeda: baik dalam pengujian unit maupun dalam pengujian integrasi dan sistem. Skrip pengujian biasanya ditulis untuk menguji komponen yang kemungkinan besar akan gagal atau jika bug yang tidak ditemukan tepat waktu dapat memakan biaya yang besar.

Pengujian kotak putih dan kotak hitam

Dalam terminologi profesional pengujian, frasa "pengujian kotak putih" dan "pengujian kotak hitam" mengacu pada apakah pengembang pengujian memiliki akses ke kode sumber perangkat lunak yang diuji, atau apakah pengujian dilakukan melalui antarmuka pengguna atau pemrograman aplikasi. antarmuka yang disediakan oleh unit yang diuji.

Saat menguji kotak hitam, penguji memiliki akses ke perangkat lunak hanya melalui antarmuka yang sama dengan pelanggan atau pengguna, atau melalui antarmuka eksternal yang memungkinkan komputer lain atau proses lain terhubung ke sistem untuk pengujian. Misalnya, modul pengujian dapat secara virtual menekan tombol atau tombol mouse dalam program yang diuji menggunakan mekanisme komunikasi proses, dengan keyakinan bahwa semuanya berjalan dengan benar dan kejadian ini menghasilkan respons yang sama seperti penekanan tombol dan tombol mouse sebenarnya. Biasanya, pengujian black box dilakukan dengan menggunakan spesifikasi atau dokumen lain yang menjelaskan persyaratan sistem. Biasanya, dalam jenis pengujian ini, kriteria cakupan terdiri dari cakupan struktur data masukan, cakupan persyaratan, dan cakupan model (dalam pengujian berbasis model).

Dalam pengujian kotak abu-abu, pengembang pengujian memiliki akses ke kode sumber, namun saat menjalankan pengujian secara langsung, akses ke kode umumnya tidak diperlukan.

Meskipun pengujian "alfa" dan "beta" mengacu pada tahapan sebelum suatu produk dirilis (dan juga, secara implisit, pada ukuran komunitas pengujian dan batasan metode pengujian), pengujian kotak putih dan kotak hitam mengacu pada cara-cara pengujian. di mana penguji mencapai tujuan.

Pengujian beta secara umum terbatas pada pengujian kotak hitam (meskipun sebagian penguji permanen biasanya melanjutkan pengujian kotak putih secara paralel dengan pengujian beta). Jadi, istilah "pengujian beta" dapat menunjukkan keadaan program (mendekati rilis daripada "alfa"), atau dapat menunjukkan beberapa kelompok penguji dan proses yang dilakukan oleh kelompok tersebut. Jadi, seorang tester dapat terus mengerjakan white box pengujian meskipun perangkat lunaknya sudah “dalam tahap beta” (tahap), namun dalam hal ini dia bukan bagian dari “beta pengujian” (grup/proses).

Cakupan Kode

Artikel utama: Cakupan kode

Cakupan kode, pada intinya, adalah pengujian kotak putih. Perangkat lunak yang diuji dibangun dengan pengaturan atau perpustakaan khusus dan/atau dijalankan di lingkungan khusus, sebagai akibatnya untuk setiap fungsi program yang digunakan (dieksekusi), lokasi fungsi ini dalam kode sumber ditentukan. Proses ini memungkinkan pengembang dan spesialis jaminan kualitas untuk mengidentifikasi bagian sistem yang, selama pengoperasian normal, jarang atau tidak pernah digunakan (seperti kode penanganan kesalahan, dll.). Hal ini memungkinkan penguji untuk fokus pada pengujian mode yang paling penting.

Penguji dapat menggunakan hasil pengujian cakupan kode untuk mengembangkan pengujian atau data pengujian yang memperluas cakupan kode ke fitur-fitur penting.

Biasanya, alat dan pustaka yang digunakan untuk memperoleh cakupan kode memerlukan kinerja dan/atau biaya memori yang signifikan yang tidak dapat diterima untuk pengoperasian perangkat lunak normal. Oleh karena itu, mereka hanya dapat digunakan dalam kondisi laboratorium.

Kutipan

“Pengujian program dapat digunakan untuk menunjukkan adanya kesalahan, namun tidak akan pernah menunjukkan ketidakhadirannya.”— Dijkstra, 1970

Lihat juga

Penelusuran semantik mundur adalah metode universal untuk menguji artefak desain apa pun

Catatan

Literatur

Glenford Myers, Tom Badgett, Corey Sandler Seni Pengujian Perangkat Lunak, Edisi ke-3. - M.: “Dialektika”, 2012. - 272 hal. - ISBN 978-5-8459-1796-6
Lisa Crispin, Janet Gregory Pengujian Agile: Panduan Praktis untuk Penguji dan Tim Agile. - M.: “Williams”, 2010. - 464 hal. - (Seri Tanda Tangan Addison-Wesley). - 1000 eksemplar.
- ISBN 978-5-8459-1625-9 Kaner Khem, Folk Jack, Nguyen Yong Kek
Pengujian perangkat lunak. Konsep dasar manajemen aplikasi bisnis. - Kyiv: DiaSoft, 2001. - 544 hal. - ISBN 9667393879 Culbertson Robert, Brown Chris, Cobb Gary
Pengujian cepat. - M.: “Williams”, 2002. - 374 hal. - ISBN 5-8459-0336-X Sinitsyn S.V., Nalyutin N.Yu.
Verifikasi perangkat lunak. - M.: BINOM, 2008. - 368 hal. - ISBN 978-5-94774-825-3 Beiser B.

Pengujian kotak hitam. Teknologi untuk pengujian fungsional perangkat lunak dan sistem. - Sankt Peterburg. : Petrus, 2004. - 320 hal. - ISBN 5-94723-698-2

Tautan
Portal tentang pengujian perangkat lunak otomatis (Rusia)
Kualitas perangkat lunak (Rusia)

Saat membangun proyek perangkat lunak pada umumnya, sekitar 50% dari total waktu dan lebih dari 50% total biaya dihabiskan untuk pengujian. Angka-angka ini dapat menimbulkan diskusi yang menyeluruh, namun pertanyaan utamanya adalah: bagaimana cara mengurangi biaya dan meningkatkan kualitas perangkat lunak?

Pengujian manual adalah bagian dari proses pengujian selama fase kendali mutu dari proses pengembangan perangkat lunak. Hal ini dilakukan oleh penguji atau pengguna biasa dengan mensimulasikan kemungkinan skenario tindakan pengguna.

Tugas penguji adalah menemukan jumlah kesalahan terbesar. Dia harus mengetahui dengan baik kesalahan yang paling umum dan dapat menemukannya dalam waktu sesingkat mungkin. Kesalahan lain yang tidak umum hanya terdeteksi oleh rangkaian pengujian yang dibuat dengan cermat. Namun, ini tidak berarti bahwa tidak perlu menulis tes untuk kesalahan umum.

Pengujian manual terdiri dari pelaksanaan prosedur terdokumentasi yang menjelaskan cara melakukan pengujian. Teknik ini menentukan urutan pengujian dan, untuk setiap pengujian, daftar nilai parameter, yang diberikan sebagai masukan dengan daftar hasil sebagai keluaran. Karena prosedur ini dimaksudkan untuk dilakukan oleh manusia, uraiannya mungkin menggunakan beberapa standar akal sehat atau referensi ke informasi yang disimpan dalam dokumen lain agar singkatnya.

Contoh fragmen prosedur

Berikan tiga bilangan bulat berbeda sebagai masukan;
Jalankan eksekusi tes;
Periksa apakah hasil yang diperoleh sesuai dengan tabel [tautan ke dokumen1] dengan mempertimbangkan perubahan [tautan ke dokumen2];
Pastikan informasi terlampir yang diberikan dapat dimengerti dan benar.

Dalam prosedur ini, penguji menggunakan dokumen tambahan dan pemahamannya sendiri tentang informasi apa yang dianggap “dapat dipahami dan benar”. Keberhasilan penggunaan pendekatan prosedural dicapai jika penguji memahami dengan jelas semua poin prosedur. Misalnya, paragraf 1 dari prosedur di atas tidak menentukan dari rentang mana tiga bilangan bulat harus ditentukan, dan tidak menjelaskan lebih lanjut bilangan mana yang dianggap “berbeda”.

Upaya untuk mengotomatiskan hasil pengujian di atas dalam pembuatan skrip yang menetapkan produk yang diuji ke tiga angka tertentu dan mengarahkan keluaran produk ke file untuk tujuan analisis, dan juga berisi nilai tertentu dari hasil yang diinginkan , yang dengannya nilai yang diperoleh saat menjalankan pengujian diperiksa. Oleh karena itu, semua informasi yang diperlukan harus ditempatkan secara eksplisit dalam teks (skrip) tes, yang memerlukan upaya tambahan dibandingkan dengan pendekatan manual. Selain itu, upaya dan waktu tambahan diperlukan untuk membuat parser keluaran (program untuk mengoordinasikan format untuk mewakili nilai referensi dari pengujian dan hasil yang dihitung selama proses) dan, mungkin, membuat database untuk menyimpan status data referensi.

Metode pengujian manual cukup efektif dalam menemukan kesalahan. Mereka pasti harus digunakan di setiap produk perangkat lunak. Metode yang dijelaskan dimaksudkan untuk periode pengembangan, ketika program telah diberi kode, namun tahap pengujian aktif belum dimulai. Teknik serupa dapat diterapkan pada awal proses pembuatan perangkat lunak, pada akhir setiap tahap desain.

Metode-metode ini berkontribusi terhadap peningkatan produktivitas yang signifikan dan meningkatkan keandalan program. Pertama, mereka biasanya memungkinkan Anda mendeteksi kesalahan lebih awal, mengurangi biaya koreksi, dan meningkatkan kemungkinan koreksi dilakukan dengan benar. Kedua, psikologi programmer tampaknya berubah ketika pengujian pra-rilis dimulai. Ketegangan internal meningkat dan ada kecenderungan untuk “memperbaiki kesalahan secepat mungkin.” Akibatnya, pemrogram membuat lebih banyak kesalahan ketika memperbaiki kesalahan yang sudah ditemukan selama pengujian dibandingkan ketika memperbaiki kesalahan yang ditemukan pada tahap sebelumnya. Selain itu, skeptisisme berasal dari fakta bahwa ini adalah “metode primitif”. Sekarang biaya waktu komputer sangat rendah, dan biaya tenaga kerja untuk penguji tinggi, dan sejumlah manajer akan melakukan apa saja untuk mengurangi biaya. Namun, ada sisi lain dari pengujian manual - saat pengujian di komputer, penyebab kesalahan hanya diidentifikasi dalam program, dan penyebab terdalamnya - pemikiran pemrogram, sebagai suatu peraturan, tidak mengalami perubahan, sedangkan selama pengujian manual, pemrogram menganalisis kodenya secara mendalam, sekaligus mengidentifikasi kemungkinan cara pengoptimalannya, dan mengubah gaya berpikirnya sendiri, meningkatkan keterampilannya. Dengan demikian, kita dapat menyimpulkan bahwa pengujian manual dapat dan harus dilakukan pada tahap awal, terutama jika tidak ada tekanan waktu dan anggaran.

Perbandingan pendekatan pengujian manual dan otomatis

Perbandingan tersebut menunjukkan tren pengujian modern, yang berfokus pada otomatisasi maksimum proses pengujian dan pembuatan kode pengujian, yang memungkinkan untuk mengatasi sejumlah besar data dan pengujian yang diperlukan untuk memastikan kualitas dalam produksi produk perangkat lunak.

	petunjuk	Otomatis
Menetapkan nilai masukan	Fleksibilitas dalam menentukan data. Memungkinkan Anda menggunakan nilai yang berbeda dalam siklus uji coba yang berbeda, memperluas cakupan	Nilai masukan ditentukan secara ketat
Memeriksa hasilnya	Fleksibel, memungkinkan penguji mengevaluasi kriteria yang dirumuskan secara samar-samar	Ketat. Kriteria yang dirumuskan secara samar-samar hanya dapat diverifikasi melalui perbandingan dengan suatu standar
Pengulangan	Rendah. Faktor manusia dan definisi data yang tidak jelas menyebabkan pengujian tidak dapat diulang	Tinggi
Keandalan	Rendah. Siklus pengujian yang panjang menyebabkan berkurangnya perhatian penguji	Tinggi, tidak bergantung pada lamanya siklus pengujian
Sensitivitas terhadap perubahan kecil pada produk	Tergantung pada detail deskripsi prosedur. Biasanya penguji dapat melakukan pengujian jika tampilan produk dan teks pesan sedikit berubah	Tinggi. Perubahan kecil pada antarmuka sering kali menyebabkan koreksi standar
Kecepatan eksekusi rangkaian pengujian	Rendah	Tinggi
Kemampuan untuk menghasilkan tes	Absen. Kecepatan eksekusi yang rendah biasanya mencegah rangkaian pengujian yang dihasilkan untuk dijalankan	Didukung

Inspeksi dan penelusuran

Inspeksi dan penelusuran sumber adalah metode utama pengujian manual. Karena kedua metode ini memiliki banyak kesamaan, maka keduanya dibahas di sini bersama-sama. Inspeksi dan penelusuran melibatkan pembacaan atau pemeriksaan visual suatu program oleh sekelompok orang. Kedua metode tersebut memerlukan pekerjaan persiapan. Tahap terakhir adalah “pertukaran pandangan” - pertemuan yang diadakan oleh peserta inspeksi. Tujuan dari pertemuan tersebut adalah untuk menemukan kesalahan, tetapi bukan untuk memperbaikinya (yaitu, pengujian, bukan debugging). Program ini diuji bukan oleh penulisnya, tetapi oleh orang lain, dan sebenarnya, “inspeksi” dan “melalui tinjauan” hanyalah nama baru untuk metode lama “memeriksa di meja”, tetapi lebih efektif karena tidak hanya penulis program, tetapi juga orang lain yang terlibat dalam proses tersebut. Hasil dari penggunaan metode ini biasanya berupa penentuan sifat kesalahan secara akurat. Selain itu, metode ini dapat mendeteksi kelompok kesalahan, yang memungkinkan Anda memperbaiki beberapa kesalahan sekaligus.

Inspeksi teks sumber adalah seperangkat prosedur dan teknik untuk mendeteksi kesalahan ketika mempelajari teks oleh sekelompok penguji. Selama pemeriksaan teks sumber, perhatian difokuskan pada metode, prosedur, bentuk pelaksanaan, dll. Kelompok biasanya beranggotakan empat orang, salah satunya menjabat sebagai ketua. Ketuanya harus seorang programmer yang kompeten, tetapi bukan pembuat program; dia seharusnya tidak mengetahui detailnya. Tanggung jawab ketua antara lain menyiapkan bahan rapat kelompok inspeksi dan menjadwalkannya, menyelenggarakan rapat, mencatat semua kesalahan yang ditemukan dan mengambil tindakan untuk memperbaikinya selanjutnya.

Rapat inspeksi dibagi menjadi dua bagian:

Pemrogram diminta menjelaskan logika programnya. Selama percakapan, pertanyaan muncul dengan tujuan mengidentifikasi kesalahan. Praktek telah menunjukkan bahwa membacakan program Anda kepada siswa tampaknya merupakan metode yang efektif untuk mendeteksi kesalahan, dan banyak kesalahan ditemukan oleh pemrogram itu sendiri, dan bukan oleh anggota kelompok lainnya.
Program ini dianalisis berdasarkan daftar pertanyaan untuk mengidentifikasi kesalahan pemrograman yang umum terjadi secara historis. Pesertanya harus memusatkan perhatian mereka untuk menemukan kesalahan, bukan mengoreksinya. Koreksi kesalahan dilakukan oleh programmer setelah rapat inspeksi. Daftar kesalahan dianalisis dan dikategorikan, sehingga dapat diperbaiki guna meningkatkan efisiensi inspeksi di masa mendatang. Anda dapat mencatat jenis kesalahan yang menjadi dasar pelatihan programmer tambahan di area lemah. Proses inspeksi, selain tujuan utamanya, menjalankan sejumlah fungsi yang berguna. Hasil inspeksi memungkinkan pemrogram untuk melihat kesalahan yang dibuatnya dan mendorongnya untuk belajar dari kesalahannya sendiri, biasanya memberinya kesempatan untuk mengevaluasi gaya pemrogramannya dan pilihan algoritma serta metode pengujiannya. Peserta yang tersisa mendapatkan pengalaman dengan mengamati kesalahan dan gaya pemrograman programmer lain. Inspeksi adalah cara untuk mengidentifikasi secara dini bagian program yang paling rawan kesalahan, sehingga Anda dapat fokus pada bagian tersebut selama pengujian.

Tampilan ujung ke ujung adalah serangkaian prosedur dan metode untuk mendeteksi kesalahan yang dilakukan oleh sekelompok orang yang melihat teks program. Metode ini memiliki banyak kesamaan dengan proses inspeksi, namun prosedurnya sedikit berbeda dan menggunakan metode deteksi kesalahan yang berbeda. Walk-through dilakukan secara pertemuan berkesinambungan, kelompok terdiri dari 3-5 orang. Prosedurnya berbeda dengan rapat inspeksi karena pesertanya “berperan sebagai komputer”. Dewan mengusulkan sejumlah kecil tes tertulis yang mewakili serangkaian masukan dan keluaran yang diharapkan untuk suatu program atau modul. Data pengujian diproses sesuai dengan logika program, keadaan program dan nilai variabel dilacak di atas kertas atau papan pemahaman awal tentang program dan dasar pertanyaan kepada pemrogram tentang logika desain dan asumsi yang diterima.

Pemeriksaan tabel dapat dianggap sebagai pemeriksaan atau penelusuran kode sumber, yang dilakukan oleh satu orang yang membaca teks program, memeriksanya terhadap daftar kesalahan, atau menjalankan data pengujian melalui program. Pada umumnya, pengecekan di meja relatif tidak produktif karena merupakan proses yang tidak terorganisir. Selain itu, pengujian meja berbeda dengan salah satu prinsip pengujian, yang menyatakan bahwa pemrogram biasanya menguji program mereka sendiri secara tidak efektif. Oleh karena itu, pemeriksaan tabel paling baik dilakukan oleh orang lain selain pembuat program, misalnya, dua pemrogram dapat bertukar program daripada memeriksa tabel program mereka sendiri. Namun, bahkan dalam kasus ini, verifikasi tersebut kurang efektif dibandingkan tinjauan langsung atau inspeksi. Alasan inilah yang menjadi alasan utama dibentuknya kelompok pada saat review atau pemeriksaan end-to-end terhadap teks sumber. Pertemuan kelompok mendorong terciptanya suasana kompetisi yang sehat: peserta ingin menunjukkan sisi terbaiknya ketika menemukan kesalahan. Saat memeriksa di meja, efek berharga ini tentu saja tidak ada. Singkatnya, inspeksi meja tentu berguna, namun kurang efektif dibandingkan inspeksi atau penelusuran kode sumber.

Pengujian perangkat lunak adalah proses penelitian perangkat lunak (software) guna memperoleh informasi mengenai kualitas produk.

Perkenalan

Proses pemeriksaan atau verifikasi formal ini dapat membuktikan bahwa tidak ada cacat dalam hal metode yang digunakan. (Artinya, tidak ada cara untuk secara akurat menetapkan atau menjamin tidak adanya cacat pada produk perangkat lunak, dengan mempertimbangkan faktor manusia yang ada di semua tahap siklus hidup perangkat lunak).

Dari sudut pandang ISO 9126, Kualitas (perangkat lunak) dapat didefinisikan sebagai karakteristik keseluruhan perangkat lunak yang diteliti, dengan mempertimbangkan komponen-komponen berikut:

· Keandalan

· Pemeliharaan

· Kepraktisan

· Efisiensi

· Mobilitas

· Fungsionalitas

Daftar atribut dan kriteria yang lebih lengkap dapat ditemukan dalam standar ISO 9126 Organisasi Internasional untuk Standardisasi. Komposisi dan isi dokumentasi yang menyertai proses pengujian ditentukan oleh Standar IEEE 829-1998 untuk Dokumentasi Pengujian Perangkat Lunak.

Sejarah pengembangan pengujian perangkat lunak

Pengujian perangkat lunak

Ada beberapa kriteria yang biasa digunakan untuk mengklasifikasikan jenis pengujian. Biasanya yang berikut ini dibedakan:

Dengan menguji objek:

Pengujian fungsional

· Pengujian beban

· Pengujian kinerja (uji kinerja/stres)

· Pengujian stabilitas/beban

· Pengujian kegunaan

· Pengujian antarmuka pengguna (pengujian UI)

Pengujian keamanan

· Pengujian lokalisasi

· Pengujian kompatibilitas

Berdasarkan pengetahuan tentang sistem:

· Pengujian kotak hitam

Pengujian kotak putih

Pengujian kotak abu-abu

Berdasarkan tingkat otomatisasi:

· Pengujian manual

Pengujian otomatis

Pengujian semi-otomatis

Menurut tingkat isolasi komponen:

· Pengujian komponen/unit

· Pengujian integrasi

· Pengujian sistem (pengujian sistem/end-to-end)

Berdasarkan waktu pengujian:

Pengujian alfa

· Pengujian asap

· Menguji fungsionalitas baru (pengujian fitur baru)

Pengujian regresi

· Pengujian penerimaan

· Pengujian beta

Berdasarkan skenario positif:

Pengujian positif

· Pengujian negatif

Menurut tingkat kesiapan pengujian:

· Pengujian dokumentasi (pengujian formal)

· Pengujian Ed Hock (intuitif) (pengujian ad hoc)

Tingkat tes

Pengujian unit (pengujian unit) - komponen minimum yang mungkin untuk pengujian diuji, misalnya, kelas atau fungsi terpisah. Pengujian unit sering dilakukan oleh pengembang perangkat lunak.

Pengujian integrasi - antarmuka antara komponen dan subsistem diuji. Jika ada cadangan waktu pada tahap ini, pengujian dilakukan secara iteratif, dengan penyertaan subsistem berikutnya secara bertahap.

Pengujian sistem - sistem terintegrasi diuji untuk memastikan memenuhi persyaratan.

Pengujian alfa adalah tiruan dari pekerjaan nyata dengan sistem yang dilakukan oleh pengembang penuh waktu, atau pekerjaan nyata dengan sistem oleh calon pengguna/pelanggan. Paling sering, pengujian alfa dilakukan pada awal pengembangan suatu produk, namun dalam beberapa kasus dapat digunakan untuk produk jadi sebagai pengujian penerimaan internal. Terkadang pengujian alfa dilakukan di bawah debugger atau menggunakan lingkungan yang membantu mengidentifikasi kesalahan yang ditemukan dengan cepat. Kesalahan yang ditemukan dapat diteruskan ke penguji untuk diselidiki lebih lanjut dalam lingkungan yang serupa dengan lingkungan tempat perangkat lunak akan digunakan.

Pengujian beta - dalam beberapa kasus, versi terbatas (dalam hal fungsionalitas atau waktu proses) didistribusikan ke sekelompok orang tertentu untuk memastikan bahwa produk mengandung sedikit kesalahan. Terkadang pengujian beta dilakukan untuk mendapatkan masukan tentang suatu produk dari pengguna masa depan.

Seringkali untuk perangkat lunak gratis/sumber terbuka, tahap pengujian Alfa mencirikan konten fungsional kode, dan pengujian Beta mencirikan tahap perbaikan bug. Selain itu, sebagai suatu peraturan, pada setiap tahap pengembangan, hasil antara pekerjaan tersedia bagi pengguna akhir.

Pengujian kotak putih dan kotak hitam

Dalam terminologi profesional pengujian (perangkat lunak dan beberapa perangkat keras), frasa "pengujian kotak putih" dan "pengujian kotak hitam" mengacu pada apakah pengembang pengujian memiliki akses ke kode sumber perangkat lunak yang diuji, atau apakah pengujian dilakukan melalui antarmuka pengguna atau antarmuka pemrograman aplikasi, yang disediakan oleh modul yang diuji.

Saat menguji pengujian white-box, pengembang pengujian memiliki akses ke kode sumber program dan dapat menulis kode yang terhubung ke perpustakaan perangkat lunak yang diuji. Hal ini biasa terjadi pada pengujian unit, yang hanya menguji bagian individual dari sistem. Ini memastikan bahwa komponen struktur berfungsi dan stabil sampai batas tertentu. Pengujian kotak putih menggunakan metrik cakupan kode.

Pengujian statis dan dinamis

Teknik yang dijelaskan di atas - pengujian kotak putih dan pengujian kotak hitam - mengasumsikan bahwa kode dieksekusi, dan perbedaannya hanya pada informasi yang dimiliki penguji. Dalam kedua kasus ini adalah pengujian dinamis.

Selama pengujian statis, kode program tidak dijalankan - program dianalisis berdasarkan kode sumber, yang dibaca secara manual atau dianalisis dengan alat khusus. Dalam beberapa kasus, bukan kode sumber yang dianalisis, namun kode perantara (seperti kode bytecode atau MSIL).

Pengujian statis juga mencakup pengujian persyaratan, spesifikasi, dan dokumentasi.

Pengujian regresi

Pengujian regresi (pengujian regresi bahasa Inggris, dari bahasa Latin regressio - bergerak mundur) adalah nama kolektif untuk semua jenis pengujian perangkat lunak yang bertujuan untuk mendeteksi kesalahan di area kode sumber yang sudah diuji. Kesalahan seperti itu - ketika, setelah melakukan perubahan pada program, sesuatu yang seharusnya terus berfungsi berhenti berfungsi - disebut bug regresi.

Metode pengujian regresi yang umum digunakan mencakup menjalankan kembali pengujian sebelumnya, serta memeriksa apakah bug regresi muncul di versi berikutnya sebagai hasil penggabungan kode.

Dari pengalaman pengembangan perangkat lunak, kita mengetahui bahwa kemunculan kesalahan yang sama secara berulang-ulang merupakan kejadian yang cukup umum. Terkadang hal ini terjadi karena teknik kontrol versi yang buruk atau kesalahan manusia saat bekerja dengan sistem kontrol versi. Namun sering kali, solusi terhadap suatu masalah bersifat “berumur pendek”: setelah perubahan berikutnya dalam program, solusi tersebut berhenti bekerja. Dan terakhir, ketika Anda menulis ulang bagian mana pun dari kode, kesalahan yang sama sering muncul pada implementasi sebelumnya.

Oleh karena itu, ketika memperbaiki bug, dianggap sebagai praktik yang baik untuk membuat pengujian untuk bug tersebut dan menjalankannya secara teratur selama perubahan program berikutnya. Meskipun pengujian regresi dapat dilakukan secara manual, pengujian ini paling sering dilakukan dengan menggunakan program khusus yang memungkinkan Anda melakukan semua pengujian regresi secara otomatis. Beberapa proyek bahkan menggunakan alat untuk menjalankan pengujian regresi secara otomatis pada interval waktu tertentu. Biasanya hal ini dilakukan setelah setiap kompilasi berhasil (dalam proyek kecil) atau setiap malam atau setiap minggu.

Pengujian regresi merupakan bagian integral dari Pemrograman Ekstrim. Metodologi ini menggantikan dokumentasi desain dengan pengujian yang dapat diperluas, berulang, dan otomatis terhadap seluruh paket perangkat lunak pada setiap tahap siklus pengembangan perangkat lunak.

Pengujian regresi tidak hanya dapat digunakan untuk memeriksa kebenaran suatu program; sering juga digunakan untuk mengevaluasi kualitas hasil yang diperoleh. Jadi, saat mengembangkan kompiler, saat menjalankan pengujian regresi, ukuran kode yang dihasilkan, kecepatan eksekusi, dan waktu kompilasi setiap contoh pengujian dipertimbangkan.

“Masalah mendasar dalam pemeliharaan perangkat lunak adalah memperbaiki satu kesalahan memiliki kemungkinan besar (20-50%) menyebabkan kesalahan baru. Oleh karena itu, keseluruhan proses mengikuti prinsip “dua langkah maju, satu langkah mundur.”

Mengapa kami tidak dapat memperbaiki kesalahan dengan lebih akurat? Pertama, bahkan cacat tersembunyi pun memanifestasikan dirinya sebagai kegagalan di satu tempat. Pada kenyataannya, hal ini sering kali mempunyai dampak pada seluruh sistem, dan biasanya tidak terlihat jelas. Setiap upaya untuk memperbaikinya dengan sedikit usaha akan memperbaiki masalah lokal dan jelas, tetapi kecuali jika strukturnya sangat jelas atau dokumentasinya sangat baik, konsekuensi jangka panjang dari perbaikan ini tidak akan diperhatikan. Kedua, kesalahan biasanya diperbaiki bukan oleh pembuat program, tetapi sering kali oleh programmer junior atau peserta pelatihan.

Karena munculnya kesalahan baru, pemeliharaan program memerlukan lebih banyak proses debug sistem per pernyataan dibandingkan dengan jenis pemrograman lainnya. Secara teoritis, setelah setiap perbaikan, Anda perlu menjalankan seluruh rangkaian kasus pengujian yang telah diuji sebelumnya oleh sistem untuk memastikan bahwa sistem tidak rusak dengan cara yang tidak diketahui. Dalam praktiknya, pengujian kemunduran (regresi) tersebut harus benar-benar mendekati ideal teoretis ini, dan biayanya sangat mahal.”

Skrip pengujian

Cakupan Kode

Cakupan kode adalah ukuran yang digunakan dalam pengujian perangkat lunak. Ini menunjukkan persentase kode sumber program yang telah diuji. Teknik cakupan kode adalah salah satu teknik pertama yang ditemukan untuk pengujian perangkat lunak sistematis. Penyebutan cakupan kode pertama kali dalam publikasi muncul pada tahun 1963.

Kriteria

Ada beberapa cara berbeda untuk mengukur cakupan, yang utama adalah:

· Cakupan pernyataan - apakah setiap baris kode sumber telah dieksekusi dan diuji?

· Cakupan kondisi - apakah setiap titik keputusan (mengevaluasi apakah suatu ekspresi benar atau salah) telah dieksekusi dan diuji?

· Cakupan jalur - apakah semua jalur yang mungkin melalui potongan kode tertentu telah diikuti dan diuji?

· Cakupan fungsi - apakah setiap fungsi program dijalankan

· Cakupan input/output - apakah semua pemanggilan fungsi dan pengembalian telah dijalankan

Untuk program dengan persyaratan keamanan khusus, seringkali perlu untuk menunjukkan bahwa pengujian mencapai cakupan 100% untuk salah satu kriteria. Beberapa kriteria cakupan yang diberikan saling berkaitan; misalnya, cakupan jalur mencakup cakupan kondisi dan cakupan pernyataan. Cakupan pernyataan tidak termasuk cakupan kondisi, seperti yang ditunjukkan oleh kode C ini:

printf("Ini adalah ");

printf("Bilangan Bulat Positif");

Jika di sini bar = −1, maka cakupan operator akan lengkap, tetapi cakupan kondisi tidak akan lengkap, karena kasus ketidakpatuhan terhadap kondisi dalam pernyataan if tidak tercakup. Cakupan jalur yang lengkap biasanya tidak memungkinkan. Fragmen kode dengan n kondisi berisi 2n jalur; desain loop menghasilkan jumlah jalur yang tak terbatas. Beberapa jalur dalam program mungkin tidak dapat dijangkau karena tidak ada jalur dalam data pengujian yang dapat mengarah ke eksekusi jalur tersebut. Tidak ada algoritma universal yang memecahkan masalah jalur yang tidak dapat dijangkau (algoritma ini dapat digunakan untuk menyelesaikan masalah stalling). Dalam praktiknya, untuk mencapai cakupan jalur, pendekatan berikut digunakan: kelas jalur diidentifikasi (misalnya, jalur yang hanya berbeda dalam jumlah iterasi dalam loop yang sama dapat diklasifikasikan sebagai satu kelas), cakupan 100% tercapai jika semua kelas jalur tercakup (suatu kelas dianggap tercakup jika setidaknya satu jalur darinya tercakup).

Penerapan Praktis

Biasanya, kode sumber dilengkapi dengan pengujian yang dijalankan secara berkala. Laporan yang dihasilkan dianalisis untuk mengidentifikasi area kode yang tidak dieksekusi, rangkaian pengujian diperbarui, dan pengujian ditulis untuk area yang tidak tercakup. Tujuannya adalah untuk memiliki serangkaian tes regresi yang memeriksa seluruh kode sumber secara menyeluruh.

Cakupan kode biasanya dinyatakan dalam persentase. Misalnya, “kami menguji 67% kode”. Arti ungkapan ini tergantung pada kriteria apa yang digunakan. Misalnya, cakupan jalur 67% adalah hasil yang lebih baik daripada cakupan pernyataan 67%. Masalah hubungan antara nilai cakupan kode dan kualitas rangkaian pengujian belum sepenuhnya terselesaikan.

Penguji dapat menggunakan hasil pengujian cakupan kode untuk mengembangkan pengujian atau data pengujian yang memperluas cakupan kode ke fitur-fitur penting.

Perkenalan

Rata-rata, pengujian memakan 50% waktu dan 50% biaya total perkiraan proyek (pastikan untuk mempertimbangkan hal ini saat menetapkan anggaran Anda). Di perusahaan besar (Intel, IBM, Microsoft) setiap pengembang ditugaskan seorang penguji pribadi. Waktu telah berlalu ketika pekerjaan ini dilakukan oleh programmer kelas dua yang belum diperbolehkan membuat kode secara mandiri (kata mereka, sebelum membuat kesalahan sendiri, biarkan mereka belajar dari orang lain terlebih dahulu). Saat ini, seorang penguji adalah spesialis berkualifikasi tinggi dan bergaji tinggi yang layanannya dibutuhkan oleh ribuan perusahaan dan tidak pernah kehilangan pekerjaan.

Ketika mereka memberi tahu Anda bahwa siklus hidup produk terdiri dari desain, implementasi, pengujian, dan dukungan - jangan percaya! Pengujian menyertai proyek sepanjang hidupnya - dari lahir hingga mati. Perancang menetapkan mekanisme untuk diagnosis mandiri dan keluaran informasi “telemetri”. Pengembang menguji setiap fungsi yang diprogramnya (pengujian tingkat mikro). Penguji beta memeriksa kinerja keseluruhan produk secara keseluruhan. Masing-masing dari mereka harus memiliki rencana tindakan yang jelas, jika tidak pengujian akan gagal bahkan sebelum dimulai.

Idealnya, untuk setiap fungsi kode sumber, serangkaian pengujian otomatis dikembangkan untuk memverifikasi fungsionalitasnya. Yang terbaik adalah mempercayakan pekerjaan ini kepada kelompok pemrogram yang terpisah, memberi mereka tugas untuk mengembangkan contoh di mana fungsi tersebut akan gagal. Misalnya, fungsi pengurutan. Tes paling sederhana terlihat seperti ini. Kami menghasilkan data arbitrer, menjalankannya, dan jika untuk setiap elemen N kondisinya N<= N + 1 (N >= N + 1 untuk mengurutkan dalam urutan menurun) benar, kami yakin pengujian akan lulus dengan benar. Tapi tes ini salah! Anda perlu memastikan bahwa keluaran fungsi berisi semua data asli dan tidak ada yang berlebihan! Banyak fungsi yang mengurutkan sepuluh atau bahkan seribu elemen dengan baik, tetapi gagal pada satu atau dua (ini biasanya terjadi ketika mengurutkan berdasarkan separuh). Bagaimana jika tidak ada elemen yang dapat diurutkan? Dan jika salah satu fungsi yang dipanggil (misalnya malloc) menghasilkan kesalahan, apakah fungsi yang diuji akan mampu menanganinya dengan benar? Berapa banyak waktu (sumber daya sistem) yang diperlukan untuk mengurutkan item sebanyak mungkin? Performa yang terlalu rendah juga merupakan sebuah kesalahan!

Ada dua pendekatan utama dalam pengujian - kotak hitam dan kotak putih. Sebuah “kotak hitam” adalah fungsi sumber tertutup, yang verifikasinya bermuara pada penghitungan semua kombinasi argumen yang membosankan. Jelasnya, sebagian besar fungsi tidak dapat diuji dalam waktu yang wajar (jumlah kombinasinya terlalu banyak). Kode kotak putih diketahui dan penguji dapat fokus pada area tepi. Katakanlah suatu fungsi memiliki batas panjang garis maksimum yang diizinkan yaitu MAX_LEN karakter. Maka Anda harus hati-hati memeriksa baris karakter MAX_LEN - 1, MAX_LEN dan MAX_LEN + 1, karena kesalahan "plus atau minus satu byte" adalah salah satu yang paling populer.

Pengujian harus melibatkan seluruh cabang program sehingga setelah dijalankan tidak ada satu baris kode pun yang tersisa. Rasio kode yang telah dieksekusi setidaknya sekali terhadap total kode program disebut cakupan, dan banyak alat telah ditemukan untuk mengukurnya - mulai dari profiler yang disertakan dalam paket kompiler standar hingga paket yang berdiri sendiri, yang terbaik adalah Cakupan Sejati NuMega.

Mengembangkan kasus uji merupakan tugas rekayasa yang serius, seringkali bahkan lebih sulit daripada mengembangkan fungsi pengujian itu sendiri. Tidaklah mengherankan bahwa dalam kehidupan nyata mereka hanya menggunakannya pada kasus-kasus yang paling kritis. Fungsi dengan logika sederhana diuji "secara visual". Itu sebabnya semuanya bermasalah dan mogok.

Selalu siarkan program Anda dengan tingkat peringatan maksimum (untuk Microsoft Visual C++ ini adalah tombol /W4), perhatikan semua pesan kompiler. Beberapa kesalahan yang paling jelas sudah terdeteksi pada tahap ini. Pemverifikasi kode pihak ketiga (lint, smatch) bahkan lebih canggih dan mengenali kesalahan yang tidak lagi dapat diatasi oleh penerjemah.

Pencatatan Kesalahan

Kegagalan program adalah cara termudah. Mendokumentasikan kondisi kegagalan jauh lebih sulit. Situasi yang umum: seorang penguji menjalankan program melalui serangkaian pengujian. Tes yang gagal dikirim ke pengembang sehingga ia dapat melokalisasi kesalahan dan memperbaiki bug. Namun pengembang berhasil melewati tes yang sama! Oh, dia sudah mengulang semuanya, mengkompilasi ulang dengan kunci lain, dll. Untuk mencegah hal ini terjadi, gunakan sistem kontrol versi - Microsoft Source Safe atau CVS.

Pertama, versi debug program diuji, dan kemudian versi final diuji dengan cara yang sama. Pengoptimalan adalah hal yang rumit dan cacat dapat muncul di tempat yang paling tidak terduga, terutama saat bekerja dengan aritmatika nyata. Terkadang penerjemahlah yang harus disalahkan dalam hal ini, tetapi lebih sering lagi programmernya sendiri.

Yang paling berbahaya adalah kesalahan "mengambang", yang muncul dengan berbagai tingkat kemungkinan - program berjalan dengan baik selama sembilan ratus kali berjalan, dan kemudian tiba-tiba macet tanpa alasan yang jelas. Hei, siapa yang berteriak bahwa ini tidak terjadi? Mesinnya, kata mereka, bersifat deterministik, dan jika perangkat kerasnya berfungsi dengan baik, maka ada bug atau tidak. Ya, mereka melarikan diri! Aplikasi multi-thread dan kode yang mengontrol perangkat I/O menimbulkan kelas khusus bug yang tidak dapat direproduksi, beberapa di antaranya mungkin hanya muncul setiap beberapa tahun sekali! Berikut ini contoh tipikal:

f1() (int x = strlen(s); s[x] = "*"; s = 0;) // thread 1

f2() (printf("%s\n", s);) // rangkaian pesan 2

Listing 1. Contoh kesalahan mengambang.

Satu thread memodifikasi string, dan thread lainnya mencetaknya ke layar. Program akan bekerja secara normal untuk beberapa waktu hingga thread 1 terputus pada saat tanda bintang telah menghancurkan karakter nol di belakangnya, dan nol baru belum ditambahkan. Sangat mudah untuk membuktikan bahwa ada konfigurasi perangkat keras di mana kesalahan ini tidak akan pernah muncul (untuk melakukan ini, cukup mengambil mesin prosesor tunggal yang dijamin dapat menjalankan seluruh kode fungsi f1 dalam satu kuantum) . Menurut hukum kekejaman, mesin ini biasanya menjadi komputer penguji dan semuanya berfungsi untuknya. Dan bagi pengguna, itu turun.

Untuk melokalisasi kesalahan, pengembang tidak cukup hanya mengetahui bahwa “program tersebut mogok”; ia perlu menyimpan dan kemudian menganalisis dengan cermat statusnya pada saat program tersebut mogok. Sebagai aturan, untuk tujuan ini, dump memori crash digunakan, dibuat oleh utilitas seperti Doctor Watson (termasuk dalam paket pengiriman standar sistem operasi) atau, paling buruk, nilai register prosesor dan isi tumpukan . Karena tidak semua kesalahan menyebabkan penghentian darurat program, pengembang harus menyediakan terlebih dahulu kemungkinan membuat dump sendiri - dengan menekan kombinasi tombol khusus atau ketika sistem kontrol internal dipicu.

Inilah yang menyebabkan kesalahan desain saat memuat sistem dengan data nyata

Gambar 1. Inilah yang menyebabkan kesalahan desain saat memuat sistem dengan data nyata.

Pengujian beta

Dengan menggabungkan semua modul yang diuji, kami mendapatkan produk dengan fungsi minimal. Jika dimulai dan tidak crash, itu bagus. Mereka berkata: letakkan orang yang buta huruf di depan komputer dan biarkan dia menekan semua tombol sampai programnya mogok. Ya, tentu saja! Menguji suatu program adalah operasi yang serius dan pendekatan perintis seperti itu tidak tepat di sini. Penting untuk menguji setiap tindakan, setiap item menu, pada semua jenis data dan operasi. Seorang penguji beta mungkin bukan seorang programmer, tetapi ia harus memiliki kualifikasi sebagai pengguna tingkat lanjut.

Setelah program mogok (atau menyebabkannya menghasilkan data yang salah), penguji beta harus dapat mereproduksi kegagalan tersebut, yaitu. mengidentifikasi urutan operasi terpendek yang menyebabkan kesalahan. Dan betapa sulitnya melakukan ini! Coba ingat tombol mana yang ditekan! Apa? Itu tidak berhasil?! Su... Gunakan keylogger. Ada banyak sekali di situs peretas mana pun. Biarkan mereka bekerja demi kepentingan masyarakat (mereka tidak bisa mencuri kata sandi selamanya). Memata-matai mouse jauh lebih sulit - Anda tidak hanya harus menyimpan posisi kursor, tetapi juga koordinat semua jendela atau menggunakan alat makro bawaan (seperti Visual Basic di Word). Secara umum, mouse adalah saksofon dan harus diberikan. Penguji beta normal puas dengan satu keyboard. Log klik yang lengkap mempersempit pencarian kesalahan, namun tidak selalu dan tidak semua orang berhasil mereproduksi kegagalan untuk pertama kalinya.

Selama pengujian, Anda harus melakukan operasi yang sama berulang kali. Itu menjengkelkan, tidak dapat diandalkan, dan tidak produktif. Pengiriman standar Windows 3.x menyertakan pemutar keyboard yang memungkinkan Anda mengotomatiskan operasi tersebut. Sekarang harus dibeli secara terpisah. Namun, Anda dapat menulis sendiri utilitas tersebut. Fungsi FindWindow dan SendMessage akan membantu dalam hal ini.

Uji program di seluruh lini sistem operasi: Windows 98, Windows 2000, Windows 2003, dll. Perbedaan di antara keduanya sangat signifikan. Apa yang bekerja secara stabil pada satu sumbu mungkin gagal pada sumbu lainnya, terutama jika ia kelebihan beban dengan banyak aplikasi yang saling bertentangan. Oke, jika ini adalah program jahat dari Vasya Pupkin (di sini Anda dapat menyerang pengguna), tetapi jika program Anda tidak cocok dengan MS Office atau produk perusahaan besar lainnya, mereka akan mengalahkan Anda. Jangan pernah mengubah konfigurasi sistem selama pengujian! Maka akan sulit untuk menentukan bug siapa itu. Hal yang baik adalah mesin virtual (VM Ware, Microsoft Virtual PC). Di satu komputer Anda dapat menyimpan banyak versi sistem operasi dengan kombinasi aplikasi terinstal yang berbeda - dari yang steril hingga yang benar-benar berantakan. Jika terjadi kesalahan, status sistem dapat dengan mudah disimpan ke hard drive, kemudian mengaksesnya sebanyak yang diperlukan.

Pada bagian ini, kami akan menjelaskan berbagai jenis pengujian perangkat lunak. Berbagai jenis pengujian perangkat lunak dilakukan untuk mencapai tujuan berbeda saat menguji aplikasi perangkat lunak. Anda juga dapat membaca tentang berbagai teknik pengujian perangkat lunak yang dapat dikaitkan dengan berbagai jenis pengujian perangkat lunak. Kami akan membantu Anda menjadi ahli di bidang ini.

Pengujian ad-hoc

Jenis pengujian ini OLEH bersifat informal dan tidak terstruktur dan dapat dilakukan oleh pihak mana pun yang berkepentingan, tanpa mengacu pada kasus uji atau dokumen pengujian apa pun.

Orang yang melakukan pengujian Ad-hoc memiliki pemahaman yang baik tentang alur kerja aplikasi ketika mencoba menemukan cacat dan peretasan OLEH. Pengujian khusus dirancang untuk mendeteksi cacat yang tidak terdeteksi pada kasus pengujian yang ada.

Pengujian penerimaan

Pengujian penerimaan adalah jenis pengujian perangkat lunak formal yang dilakukan oleh pengguna akhir setelah pengembang menyediakan layanan yang diminta. Tujuan dari pengujian ini adalah untuk memverifikasi kepatuhan OLEH persyaratan bisnis pelanggan dan persyaratan yang disajikan sebelumnya. Pengujian penerimaan biasanya didokumentasikan pada awal pekerjaan (dalam agile) dan membantu penguji dan pengembang meningkatkan pengetahuan dan keterampilan mereka di bidang ini.

Apa itu Pengujian Penerimaan di Agile?

Pengujian Aksesibilitas

Pada pengujian aksesibilitas, tujuan pengujian adalah untuk mengetahui apakah konten suatu website dapat diakses dengan mudah oleh penyandang disabilitas. Meliputi berbagai pemeriksaan seperti pengecekan warna dan kontras (bagi penderita buta warna), ukuran font untuk tunanetra, teks jelas dan ringkas sehingga mudah dibaca dan dipahami.

Pengujian tangkas

Agile Testing adalah jenis pengujian perangkat lunak yang memperhitungkan pendekatan tangkas dan metode pengembangan perangkat lunak. Dalam lingkungan pengembangan Agile, pengujian merupakan bagian integral dari pengembangan. OLEH dan dieksekusi secara paralel dengan penulisan kode. Pengujian tangkas memungkinkan Anda menulis kode secara bertahap dan mengujinya.

pengujian API

Pengujian API adalah jenis pengujian yang mirip dengan pengujian unit. Setiap API diuji sesuai dengan spesifikasi API. Pengujian API terutama dilakukan oleh tim penguji. Memerlukan pemahaman tentang fungsionalitas API dan keterampilan pemrograman yang baik.

Pengujian Otomatis

Ini adalah pendekatan pengujian yang menggunakan alat pengujian dan/atau pemrograman untuk menjalankan kasus pengujian menggunakan perangkat lunak atau utilitas pengujian yang dirancang khusus. Sebagian besar alat otomatis adalah alat perekaman dan pemutaran, namun ada beberapa alat yang memerlukan skrip atau pemrograman ekstensif untuk mengotomatiskan skrip pengujian.

Pengujian berpasangan

Dengan kata lain, Pengujian Berpasangan adalah metode pengujian dan pengujian kotak hitam di mana sepasang masukan diuji untuk setiap masukan, yang membantu menguji perangkat lunak agar berfungsi seperti yang diharapkan dengan semua kemungkinan kombinasi masukan.

Pengujian beta

Ini adalah jenis pengujian perangkat lunak formal yang dilakukan oleh pengguna akhir sebelum perangkat lunak dirilis atau didistribusikan kepada pengguna. Keberhasilan menyelesaikan pengujian beta merupakan penerimaan pengguna terhadap perangkat lunak.

Pengujian Kotak Hitam

Pengujian black box adalah jenis pengujian perangkat lunak di mana penguji tidak diharuskan mengetahui pengkodean atau struktur internal perangkat lunak. Metode pengujian black box didasarkan pada pengujian OLEH dengan masukan yang berbeda dan membandingkan hasilnya dengan yang diharapkan.

Pengujian Kompatibilitas Mundur

Jenis pengujian perangkat lunak yang dilakukan untuk memverifikasi bahwa versi perangkat lunak yang lebih baru dapat berhasil dijalankan di atas perangkat lunak versi sebelumnya dan bahwa perangkat lunak versi baru berfungsi dengan baik dengan struktur tabel, struktur data, dan file yang dibuat oleh versi perangkat lunak sebelumnya.

Batasi pengujian

Pengujian batas adalah jenis pengujian yang didasarkan pada konsep “agregasi kesalahan pada batas”. Pengujian dilakukan dengan menguji cacat secara menyeluruh pada nilai batas. Jika bidang menerima nilai dari 1 hingga 100, maka pengujian dilakukan untuk nilai 0, 1, 2, 99, 100, dan 101.

Metode Uji Big Bang

Ini adalah salah satu pendekatan pengujian integrasi. Metode pengujian Big Bang didasarkan pada fakta bahwa semua atau sebagian besar modul dikembangkan dan kemudian dihubungkan bersama.

Pengujian integrasi Bottom-up (pengujian bottom-up)

Pengujian Integrasi Pengujian bottom-up adalah metode pengujian integrasi di mana pengujian dimulai dengan bagian atau subsistem yang lebih kecil dari suatu sistem dan diakhiri dengan cakupan keseluruhan sistem perangkat lunak secara keseluruhan. Pengujian integrasi bottom-up dimulai dengan perangkat lunak kecil dan akhirnya berskala dalam hal ukuran, kompleksitas, dan kelengkapan.

Menguji cabang

Merupakan teknik pengujian white box untuk mengembangkan kasus uji untuk menguji kode pada setiap kondisi cabang. Digunakan selama pengujian unit.

Pengujian Kompatibilitas Peramban

Ini adalah subtipe pengujian kompatibilitas yang dilakukan oleh tim penguji. Pengujian kompatibilitas browser dilakukan pada aplikasi web yang dikombinasikan dengan browser dan sistem operasi yang berbeda.

Pengujian kompatibilitas

Pengujian kompatibilitas adalah jenis pengujian yang dilakukan oleh sekelompok penguji. Pengujian kompatibilitas memeriksa apakah perangkat lunak dapat dijalankan pada perangkat keras yang berbeda, sistem operasi, database, server web, server aplikasi, periferal perangkat keras, emulator, konfigurasi berbeda, prosesor, browser berbeda dan versi browser berbeda, dll.

Pengujian komponen

Jenis pengujian perangkat lunak ini dilakukan oleh pengembang. Pengujian komponen dilakukan setelah pengujian unit selesai. Pengujian komponen melibatkan pengujian sekelompok unit sebagai kode bersama-sama secara keseluruhan, daripada menguji fungsi dan metode individual.

Pengujian cakupan kondisi

Pengujian cakupan kondisi adalah teknik pengujian yang digunakan selama pengujian unit, di mana pengembang menguji semua kondisi seperti if, if-else, case, dll pada modul kode yang diuji.

Pengujian dinamis

Pengujian dapat dilakukan dengan pengujian statis dan pengujian dinamis. Pengujian dinamis merupakan pendekatan pengujian dimana pengujian hanya dapat dilakukan ketika kode diambil.

Pengujian cakupan solusi

Ini adalah teknik pengujian yang digunakan dalam pengujian unit. Tujuan dari pengujian cakupan keputusan adalah untuk mengimplementasikan dan menguji setiap blok keputusan dalam kode, misalnya. Jika, jika-lain, kasus.

Pengujian Ujung-ke-Ujung

Pengujian ujung ke ujung dilakukan oleh tim penguji dan fokusnya adalah pada pengujian aliran ujung ke ujung. Mulai dari pembuatan pesanan hingga pelaporan atau pembuatan pesanan hingga pengembalian produk, dll. dan verifikasi. Pengujian end-to-end biasanya bertujuan untuk mensimulasikan skenario kehidupan nyata dan implementasinya. Pengujian ujung ke ujung melibatkan pengujian aliran informasi antar aplikasi.

Pengujian eksplorasi

Pengujian eksplorasi adalah jenis pengujian informal yang dilakukan untuk mempelajari perangkat lunak sambil mencari bug atau perilaku dalam aplikasi yang tidak terlihat jelas. Pengujian biasanya dilakukan oleh penguji, namun dapat dilakukan oleh pemangku kepentingan lainnya, serta analis bisnis, pengembang, pengguna akhir, dll., yang tertarik untuk mempelajari fitur perangkat lunak sekaligus mencari bug atau perilaku yang tampaknya tidak sesuai. -jelas.

Partisi yang setara

Partisi ekivalensi disebut juga partisi ekivalensi. Klasifikasi adalah teknik pengujian perangkat lunak, bukan jenis pengujian itu sendiri. Pengujian partisi yang setara digunakan dalam pengujian kotak hitam dan kotak abu-abu. Partisi ekivalen mengklasifikasikan data pengujian ke dalam kelas kesetaraan sebagai kelas kesetaraan positif dan kelas kesetaraan negatif—klasifikasi ini memastikan bahwa kondisi positif dan negatif diuji.

Pengujian fungsional

Pengujian fungsional adalah jenis pengujian formal yang dilakukan oleh penguji. Pengujian fungsional berfokus pada pengujian perangkat lunak berdasarkan dokumen status, kasus, dan persyaratan. Pengujian fungsional adalah jenis pengujian kotak hitam dan tidak memerlukan pengetahuan tentang cara kerja internal perangkat lunak, tidak seperti pengujian kotak putih.

Pengujian bulu halus

Pengujian fuzz atau fuzzing adalah teknik pengujian perangkat lunak yang melibatkan pengujian dengan masukan yang tidak terduga atau acak. Perangkat lunak diuji terhadap kesalahan atau pesan kesalahan yang muncul karena kesalahan entri data.

Menguji GUI

Jenis pengujian perangkat lunak ini ditujukan untuk menguji antarmuka pengguna grafis perangkat lunak, yang harus memenuhi persyaratan yang ditentukan dalam mockup GUI dan dokumen terperinci. Misalnya, memeriksa panjang dan kapasitas kolom input yang ditentukan dalam formulir terhadap jenis kolom input yang disediakan. Beberapa bidang formulir mungkin muncul sebagai daftar drop-down atau serangkaian tombol radio. Dengan demikian, pengujian GUI memastikan bahwa elemen antarmuka grafis perangkat lunak sesuai dengan mockup GUI yang disetujui, dokumen desain rinci, dan persyaratan fungsional. Sebagian besar alat otomatisasi pengujian fungsional bekerja dengan kemampuan perekaman dan pemutaran GUI. Ini mempercepat penulisan skrip dan meningkatkan biaya pemeliharaan skrip.

Pengujian kotak kaca

Pengujian kotak kaca adalah nama lain dari pengujian kotak putih. Pengujian kotak kaca adalah metode pengujian yang melibatkan pengujian pernyataan individual, fungsi, dll. Pengujian unit adalah salah satu metode pengujian kotak kaca.

Pengujian gorila (pengujian kacau)

Jenis pengujian perangkat lunak ini dilakukan oleh sekelompok penguji perangkat lunak. Tujuan pengujian Gorilla adalah untuk menggunakan satu atau lebih fungsi secara lengkap atau menyeluruh jika banyak orang menguji fungsi yang sama.

Menguji jalur yang menguntungkan

Juga dikenal sebagai pengujian Jalur Emas, jenis pengujian ini berfokus pada kelulusan pengujian tanpa menimbulkan kesalahan.

Pengujian integrasi

Pengujian integrasi adalah salah satu jenis pengujian perangkat lunak yang paling umum dan penting. Setelah masing-masing unit atau komponen diverifikasi berfungsi oleh pengembang, pengujian akan dilakukan oleh tim penguji yang akan menguji komunikasi antara unit/komponen tersebut atau beberapa unit/komponen. Ada pendekatan yang berbeda untuk pengujian integrasi yaitu pengujian integrasi top down, pengujian integrasi bottom up dan kombinasi dari kedua pengujian Sand witch ini.

Pengujian antarmuka

Pengujian antarmuka diperlukan ketika perangkat lunak menyediakan dukungan untuk satu atau lebih antarmuka seperti "Antarmuka Pengguna Grafis", "Antarmuka Baris Perintah" atau "Antarmuka Pemrograman Aplikasi" untuk berinteraksi dengan penggunanya atau perangkat lunak lain. Antarmuka menyediakan media bagi perangkat lunak untuk menerima masukan dari pengguna dan memberikan keluaran kepada pengguna. Pendekatan pengujian antarmuka bergantung pada jenis antarmuka yang diuji, seperti GUI atau API atau CLI.

Pengujian internasionalisasi

Pengujian internasionalisasi adalah jenis pengujian yang dilakukan oleh sekelompok penguji perangkat lunak untuk memeriksa seberapa besar perangkat lunak tersebut dapat mendukung internasionalisasi, yaitu. menggunakan bahasa berbeda, kumpulan karakter berbeda, karakter bita ganda, dll. Misalnya: Gmail adalah aplikasi web yang digunakan orang untuk bekerja dengan bahasa berbeda, kumpulan karakter bita tunggal atau multibita.

Pengujian berbasis kata kunci

Pengujian berbasis kata kunci adalah pendekatan otomatis terhadap pengujian perangkat lunak dan bukan jenis pengujian itu sendiri. Pengujian berbasis kata kunci dikenal sebagai pengujian berbasis aktivitas atau pengujian berbasis tabel.

Pengujian beban

Pengujian beban adalah jenis pengujian non-fungsional. Pengujian beban dilakukan untuk memeriksa perilaku perangkat lunak dalam kondisi beban normal dan super puncak. Pengujian beban biasanya dilakukan menggunakan alat pengujian otomatis. Pengujian beban dirancang untuk menemukan kerentanan atau masalah yang menghalangi perangkat lunak menjalankan tugasnya pada beban kerja maksimal.

Pengujian lokalisasi

Pengujian lokalisasi adalah jenis pengujian perangkat lunak yang dilakukan oleh penguji perangkat lunak, dalam pengujian jenis ini perangkat lunak diharapkan dapat beradaptasi dengan bahasa tertentu, harus mendukung bahasa tertentu, menerima input dalam lokal tertentu, menampilkan font, waktu, tanggal, mata uang, dll. . dll. terkait dengan bahasa tertentu. Misalnya, banyak aplikasi web yang memungkinkan Anda memilih bahasa, seperti Inggris, Prancis, Jerman, atau Jepang. Oleh karena itu, jika suatu lokal ditentukan atau dikonfigurasikan dalam konfigurasi perangkat lunak, perangkat lunak diharapkan berfungsi seperti yang diharapkan dalam bahasa/lokal tersebut.

Pengujian negatif

Jenis pendekatan pengujian perangkat lunak ini menunjukkan bagaimana perangkat lunak berperilaku ketika diretas. Dengan kata lain, ini adalah pengujian fungsional dan non-fungsional yang dirancang untuk memecahkan perangkat lunak dengan memasukkan data yang salah seperti tanggal, waktu atau string yang salah, atau dengan memuat file biner padahal seharusnya memuat file teks. atau dengan memasukkan string teks besar untuk kolom input, dll. Ini juga merupakan tes positif untuk bug.

Pengujian non-fungsional

Sebagian besar produk perangkat lunak dirancang untuk memenuhi persyaratan fungsional dan non-fungsional. Persyaratan non-fungsional: Kinerja, kegunaan, lokalisasi, dll. Ada banyak jenis pengujian seperti kompatibilitas, lokalisasi, pengujian kegunaan yang dilakukan untuk memeriksa persyaratan non-fungsional.

Pengujian berpasangan

adalah teknik pengujian perangkat lunak yang dapat dilakukan oleh penguji perangkat lunak, pengembang, atau analis bisnis. Seperti namanya, dua orang bekerja sama, yang satu melakukan pengujian dan yang lainnya memantau dan mencatat hasil pengujian. Pengujian berpasangan juga dapat dilakukan dalam kombinasi penguji-pengembang, kombinasi penguji-analis bisnis, atau kombinasi analis-pengembang bisnis. Menyatukan penguji dan pengembang dalam pengujian berpasangan membantu menemukan cacat lebih cepat, menentukan akar permasalahan, memperbaiki, dan menguji perbaikan.

Pengujian kinerja

Ini adalah jenis pengujian perangkat lunak dan bagian dari aktivitas rekayasa yang dilakukan untuk memeriksa atribut tertentu dari kualitas perangkat lunak, seperti stabilitas, keandalan, ketersediaan. Pengujian kinerja dilakukan oleh tim pengembangan. Berbeda dengan pengujian fungsional, pengujian kinerja dilakukan untuk memverifikasi persyaratan non-fungsional. Pengujian kinerja menguji seberapa baik kinerja perangkat lunak pada beban kerja yang diharapkan dan maksimum. Ada variasi atau subtipe kinerja yang berbeda seperti pengujian beban, pengujian tegangan, pengujian volume, pengujian ketahanan, dan pengujian konfigurasi.

Pengujian keamanan

Ini adalah salah satu jenis pengujian keamanan. Pengujian penetrasi digunakan untuk menguji bagaimana perangkat lunak yang dilindungi dan lingkungannya (perangkat keras, sistem operasi, dan jaringan) diserang oleh penyerang eksternal atau internal. Penyusup dapat berupa manusia/hacker atau malware. Pentest menggunakan intrusi kekerasan (serangan brute force) atau teknik eksploitasi kerentanan untuk mendapatkan akses ke perangkat lunak atau data atau perangkat keras untuk mengungkap metode pencurian, manipulasi atau kerusakan data, file perangkat lunak atau konfigurasi. Pengujian keamanan adalah cara peretasan etis: penguji keamanan berpengalaman akan menggunakan teknik dan alat yang sama seperti peretas, namun tujuan penguji adalah mengidentifikasi kerentanan dan memperbaikinya sebelum peretas atau malware sungguhan mengeksploitasi kerentanan untuk tujuan mereka sendiri.

Pengujian regresi

adalah jenis pengujian perangkat lunak yang dilakukan oleh penguji perangkat lunak sebagai pengujian regresi fungsional dan oleh pengembang sebagai pengujian regresi unit. Tujuan dari uji regresi adalah untuk mengidentifikasi cacat yang telah diperkenalkan untuk memperbaiki cacat atau memperkenalkan fitur baru. Tes regresi adalah pilihan ideal untuk otomatisasi pengujian.

Pengujian ulang

Ini adalah jenis pengujian ulang yang dilakukan oleh penguji perangkat lunak sebagai bagian dari pengujian untuk memperbaiki kerusakan. Misalnya, seorang penguji memeriksa perbaikan untuk mengetahui adanya cacat. Setelah penguji memverifikasi perbaikan cacat berhasil, penguji kemudian akan menguji ulang atau memverifikasi fitur yang sama dengan menjalankan kasus pengujian yang gagal sebelumnya.

Pengujian Berbasis Risiko

Ini adalah jenis pengujian perangkat lunak dan pendekatan lain terhadap pengujian perangkat lunak. Dalam pengujian berbasis risiko, persyaratan dan fungsionalitas perangkat lunak yang diuji diprioritaskan sebagai kritis, tinggi, sedang, dan rendah. Dalam pendekatan ini, semua kasus kritis dan berprioritas tinggi diuji, diikuti dengan kasus-kasus menengah. Fungsi prioritas rendah atau risiko rendah terlambat diuji atau mungkin tidak diuji sama sekali, bergantung pada jangka waktu.

Pengujian asap (pengujian asap)

Ini adalah jenis pengujian yang dilakukan oleh penguji perangkat lunak untuk memeriksa apakah build baru yang disediakan oleh tim pengembangan cukup stabil, yaitu apakah fungsionalitas inti berfungsi seperti yang diharapkan, untuk memungkinkan pengujian lebih lanjut atau mendetail. Pengujian asap dirancang untuk mendeteksi cacat "show stopper" yang mungkin menghalangi pengujian aplikasi secara detail. Pengujian asap juga dikenal sebagai pengujian verifikasi build.

Pengujian keamanan

Ini adalah salah satu jenis pengujian perangkat lunak yang dilakukan oleh sekelompok penguji perangkat lunak khusus. Tujuan pengujian keamanan adalah untuk memastikan bahwa perangkat lunak terlindungi dari ancaman eksternal atau internal dari manusia dan malware. Pengujian keamanan pada dasarnya memeriksa seberapa baik mekanisme otorisasi perangkat lunak, seberapa kuat otentikasi, bagaimana perangkat lunak menjaga kerahasiaan data, bagaimana perangkat lunak menjaga integritas data, bagaimana ketersediaan perangkat lunak jika perangkat lunak diserang oleh hacker dan perangkat lunak perusak. Pengujian keamanan memerlukan pengetahuan yang baik tentang aplikasi, teknologi, jaringan, alat pengujian keamanan. Dengan bertambahnya jumlah aplikasi web, pengujian keamanan menjadi lebih penting dari sebelumnya.

Pengujian Kinerja

Ini adalah jenis pengujian yang dilakukan terutama oleh penguji dan juga di beberapa proyek oleh pengembang. Pengujian kinerja adalah penilaian cepat terhadap perangkat lunak, lingkungan, jaringan, sistem eksternal, dan pemeriksaan stabilitas lingkungan perangkat lunak yang cukup untuk memulai pengujian komprehensif. Tes kinerja bersifat sempit dan dalam banyak kasus tidak didokumentasikan.

Pengujian skalabilitas

Ini adalah pengujian non-fungsional yang dirancang untuk menguji salah satu atribut kualitas perangkat lunak, yaitu “Skalabilitas”. Uji skalabilitas tidak berfokus pada satu atau beberapa fitur perangkat lunak saja, melainkan kinerja perangkat lunak secara keseluruhan. Pengujian skalabilitas biasanya dilakukan oleh tim pengembangan. Tujuan pengujian skalabilitas adalah untuk menguji kemampuan perangkat lunak untuk tumbuh dengan lebih banyak pengguna, meningkatkan transaksi, meningkatkan ukuran database, dll. Kinerja perangkat lunak tidak perlu meningkat seiring dengan peningkatan konfigurasi perangkat keras. Tes skalabilitas membantu menentukan seberapa besar beban kerja yang dapat didukung oleh perangkat lunak seiring dengan perluasan basis pengguna, transaksi, penyimpanan data, dll.

Pengujian stabilitas

Ini adalah pengujian non-fungsional yang dirancang untuk menguji salah satu atribut kualitas perangkat lunak, yaitu “Stabilitas”. Pengujian stabilitas berfokus pada pengujian perangkat lunak yang stabil ketika terkena beban pada tingkat yang dapat diterima, beban puncak, beban yang dihasilkan secara lonjakan dengan sejumlah besar data yang sedang diproses. Pengujian skalabilitas akan melibatkan pelaksanaan berbagai jenis pengujian kinerja seperti pengujian beban, pengujian tegangan, pengujian lonjakan, pengujian ketahanan.

Pengujian statis

adalah suatu bentuk pengujian yang menggunakan panduan langkah demi langkah untuk mengevaluasi keakuratan hasil. Dalam pengujian statis, kode program tidak dieksekusi tetapi ditinjau untuk sintaksis, komentar, konvensi penamaan, ukuran fungsi/metode, dll. Pengujian statis biasanya memiliki daftar periksa yang hasilnya akan dievaluasi. Pengujian statis dapat digunakan untuk menguji persyaratan, desain, dan kasus pengujian menggunakan pendekatan seperti tinjauan atau penelusuran.

Tes stres

Merupakan jenis pengujian kinerja di mana perangkat lunak dikenakan beban puncak untuk mengamati bagaimana perangkat lunak akan berperilaku pada beban puncak. Pengujian stres juga memeriksa perilaku perangkat lunak ketika sumber daya seperti prosesor, memori, bandwidth jaringan, ruang disk, dll tidak mencukupi. Pengujian stres memungkinkan Anda memeriksa atribut kualitas seperti keandalan.

Pengujian sistem

Mencakup beberapa jenis pengujian perangkat lunak yang akan menguji perangkat lunak secara keseluruhan (perangkat lunak, perangkat keras, dan jaringan) sesuai dengan kebutuhan pembuatannya. Untuk menyelesaikan pengujian sistem, berbagai jenis pengujian dilakukan (pengujian GUI, pengujian fungsional, pengujian regresi, pengujian asap, pengujian beban, pengujian stres, pengujian keamanan, pengujian stres, pengujian ad-hoc, dll.).

Pengujian beban

Suatu jenis pengujian kinerja dimana perangkat lunak dikenakan beban untuk jangka waktu yang signifikan, pengujian ketahanan dapat berlangsung selama beberapa hari atau bahkan beberapa minggu. Pengujian ketahanan adalah jenis pengujian yang dilakukan untuk mengidentifikasi kesalahan yang menyebabkan penurunan kinerja perangkat lunak jika digunakan terus-menerus. Pengujian ketahanan banyak digunakan untuk perangkat elektronik yang diharapkan dapat beroperasi terus menerus selama berhari-hari, berbulan-bulan, atau bertahun-tahun tanpa perlu melakukan boot ulang. Dengan meningkatnya jumlah aplikasi web, pengujian ketahanan menjadi penting karena ketersediaan aplikasi web sangat penting untuk mendukung dan keberhasilan bisnis.

Pengujian integrasi sistem

Dikenal sebagai SIT (singkatnya), ini adalah jenis pengujian yang dilakukan oleh tim penguji perangkat lunak. Seperti namanya, fokus pengujian integrasi sistem adalah untuk memeriksa kesalahan terkait integrasi antara berbagai aplikasi, layanan, aplikasi pihak ketiga, dll. SIT menguji skenario ujung ke ujung yang memerlukan perangkat lunak untuk berkomunikasi (Mengirim atau menerima data) dengan aplikasi lain atas, bawah, dengan aplikasi pihak ketiga.

Pengujian satuan

Ini adalah jenis pengujian yang dilakukan oleh pengembang perangkat lunak. Pengujian unit mengikuti metode pengujian white box dimana pengembang akan menguji modul kode sumber seperti pernyataan, cabang, fungsi, metode, antarmuka dalam OOP (Object Oriented Programming). Pengujian unit biasanya melibatkan pengembangan driver. Tes unit adalah pilihan ideal untuk otomatisasi. Pengujian otomatis dapat dijalankan sebagai pengujian regresi tunggal terhadap rilis baru atau rilis perangkat lunak baru. Ada banyak kerangka kerja berguna seperti Junit, Nunit, dll. yang dapat membuat pengujian unit lebih efisien.

Pengujian kegunaan

Ini adalah jenis pengujian perangkat lunak yang dilakukan untuk memahami seberapa ramah pengguna perangkat lunak tersebut. Tujuan dari pengujian kegunaan adalah untuk memungkinkan pengguna akhir menggunakan perangkat lunak, mengamati perilaku mereka, respons emosional (apakah pengguna menikmati menggunakan perangkat lunak atau menekankan penggunaannya, dll.) dan mengumpulkan umpan balik mereka tentang bagaimana perangkat lunak dapat lebih ramah pengguna.

Pengujian Penerimaan Pengguna

Pengujian penerimaan pengguna adalah suatu keharusan untuk proyek apa pun. Ini dilakukan oleh klien/pengguna akhir perangkat lunak. Pengujian penerimaan memungkinkan teknisi klien menguji perangkat lunak terhadap skenario bisnis nyata atau skenario dunia nyata dan memverifikasi bahwa perangkat lunak memenuhi persyaratan bisnis mereka.

Pengujian volume

Merupakan jenis pengujian non-fungsional yang dilakukan oleh tim insinyur kinerja. Pengujian volume adalah jenis pengujian kinerja. Pengujian volume dilakukan untuk menguji keandalan perangkat lunak ketika menangani berbagai ukuran data yang diterima dan diproses oleh perangkat lunak. Misalnya, jika Anda akan menguji Microsoft Word, maka pengujian ukurannya adalah untuk melihat apakah MS Word dapat membuka, menyimpan, dan bekerja dengan file dengan ukuran berbeda (dari 10 hingga 100 MB).

Pengujian kerentanan

Melibatkan identifikasi kerentanan perangkat lunak, perangkat keras, atau jaringan yang dapat dieksploitasi oleh peretas dan program jahat lainnya yang serupa dengan virus atau worm. Pengujian kerentanan adalah kunci untuk memastikan keamanan dan ketersediaan perangkat lunak. Dengan meningkatnya peretas dan malware, pengujian kerentanan sangat penting untuk kesuksesan bisnis.

Pengujian kotak putih

Pengujian kotak putih juga dikenal sebagai pengujian kotak bening atau kaca. Pengujian kotak putih adalah metode pengujian perangkat lunak yang dirancang untuk menguji perangkat lunak dengan pengetahuan tentang cara kerja internal perangkat lunak. Teknik ini digunakan dalam pengujian unit, yang biasanya dilakukan oleh pengembang perangkat lunak. Pengujian white box adalah untuk menguji kode, pengujian, cabang, jalur, keputusan dan aliran data pada program yang diuji. Pengujian white box dan pengujian black box saling melengkapi karena setiap pendekatan pengujian dapat mengidentifikasi kategori kesalahan tertentu.

Saya ingin mencatat bahwa metode kami akan membantu Anda mengenal metode pengujian ini.

Daftar sekarang atau minta panggilan dengan konsultasi gratis!

Pengujian perangkat lunak mengidentifikasi kekurangan, kekurangan dan kesalahan dalam kode yang perlu dihilangkan. Ini juga dapat didefinisikan sebagai proses mengevaluasi fungsionalitas dan kebenaran perangkat lunak melalui analisis. Metode utama integrasi dan pengujian produk perangkat lunak memastikan kualitas aplikasi dan terdiri dari pemeriksaan spesifikasi, desain dan kode, penilaian keandalan, validasi dan verifikasi.

Metode

Tujuan utama pengujian perangkat lunak adalah untuk memastikan kualitas paket perangkat lunak dengan men-debug aplikasi secara sistematis dalam kondisi yang dikontrol dengan cermat, menentukan kelengkapan dan kebenarannya, serta mendeteksi kesalahan tersembunyi.

Metode dapat dibagi menjadi statis dan dinamis.

Yang pertama mencakup tinjauan informal, pengendalian dan teknis, inspeksi, penelusuran, audit, dan analisis statis aliran data dan pengendalian.

Teknik dinamisnya adalah sebagai berikut:

Pengujian kotak putih. Ini adalah studi rinci tentang logika internal dan struktur suatu program. Ini membutuhkan pengetahuan tentang kode sumber.
Pengujian kotak hitam. Teknik ini tidak memerlukan pengetahuan apa pun tentang cara kerja internal aplikasi. Hanya aspek utama dari sistem yang tidak terkait atau memiliki sedikit hubungan dengan struktur logis internalnya yang dipertimbangkan.
Metode kotak abu-abu. Menggabungkan dua pendekatan sebelumnya. Debugging dengan pengetahuan terbatas tentang fungsi internal aplikasi digabungkan dengan pengetahuan tentang aspek dasar sistem.

Pengujian transparan

Metode kotak putih menggunakan skrip pengujian untuk mengontrol struktur desain prosedural. Teknik ini memungkinkan Anda mengidentifikasi kesalahan implementasi, seperti manajemen kode yang buruk, dengan menganalisis cara kerja internal suatu perangkat lunak. Metode pengujian ini dapat diterapkan pada tingkat integrasi, modul, dan sistem. Penguji harus memiliki akses ke kode sumber dan, dengan menggunakannya, mencari tahu blok mana yang berperilaku tidak tepat.

Pengujian program kotak putih memiliki keuntungan sebagai berikut:

memungkinkan Anda mengidentifikasi kesalahan dalam kode tersembunyi saat menghapus baris tambahan;
kemungkinan efek samping;
cakupan maksimum dicapai dengan menulis naskah tes.

Kekurangan:

proses yang sangat mahal yang memerlukan debugger yang berkualifikasi;
banyak jalur yang masih belum dijelajahi, karena pemeriksaan menyeluruh terhadap semua kemungkinan kesalahan tersembunyi sangat sulit;
beberapa kode yang hilang akan luput dari perhatian.

Pengujian kotak putih terkadang juga disebut pengujian kotak transparan atau terbuka, pengujian struktural, pengujian logis, pengujian sumber, pengujian arsitektur, dan pengujian logika.

Varietas utama:

1) pengujian aliran kendali - strategi terstruktur yang menggunakan aliran kendali program sebagai model dan lebih mengutamakan sejumlah besar jalur sederhana daripada sejumlah kecil jalur yang lebih kompleks;

2) debugging cabang bertujuan untuk memeriksa setiap opsi (benar atau salah) dari setiap pernyataan kontrol, yang juga mencakup keputusan gabungan;

3) pengujian jalur dasar, yang memungkinkan penguji menetapkan ukuran kompleksitas logis dari desain prosedural untuk mengidentifikasi serangkaian jalur eksekusi dasar;

4) pemeriksaan aliran data - strategi untuk memeriksa aliran kontrol dengan memberi anotasi pada grafik dengan informasi tentang deklarasi dan penggunaan variabel program;

5) pengujian siklus - sepenuhnya fokus pada pelaksanaan prosedur siklus yang benar.

Debug Perilaku

Pengujian kotak hitam memperlakukan perangkat lunak sebagai "kotak hitam" - informasi tentang cara kerja internal program tidak diperhitungkan, dan hanya aspek utama dari sistem yang diuji. Dalam hal ini, penguji perlu mengetahui arsitektur sistem tanpa akses ke kode sumber.

Keuntungan dari pendekatan ini:

efisiensi untuk segmen kode yang besar;
kemudahan persepsi oleh penguji;
Perspektif pengguna jelas terpisah dari perspektif pengembang (programmer dan penguji tidak bergantung satu sama lain);
pembuatan tes lebih cepat.

Pengujian program dengan menggunakan metode black box memiliki kelemahan sebagai berikut:

pada kenyataannya, sejumlah kasus uji coba dilaksanakan, sehingga cakupannya terbatas;
kurangnya spesifikasi yang jelas mempersulit pengembangan kasus uji;
efisiensi rendah.

Nama lain untuk teknik ini adalah pengujian perilaku, pengujian buram, pengujian fungsional, dan debugging kotak tertutup.

1) partisi yang setara, yang dapat mengurangi kumpulan data pengujian, karena data masukan modul perangkat lunak dibagi menjadi beberapa bagian terpisah;

2) analisis tepi berfokus pada pengujian batas atau nilai batas ekstrem - nilai minimum, maksimum, kesalahan, dan tipikal;

3) fuzzing - digunakan untuk mencari kesalahan implementasi dengan memasukkan data yang terdistorsi atau semi-terdistorsi dalam mode otomatis atau semi-otomatis;

4) grafik hubungan sebab-akibat - suatu teknik yang didasarkan pada pembuatan grafik dan membangun hubungan antara suatu tindakan dan penyebabnya: identitas, negasi, logika OR dan logika AND - empat simbol dasar yang mengungkapkan saling ketergantungan antara sebab dan akibat;

5) pengujian susunan ortogonal, diterapkan pada masalah dengan area masukan yang relatif kecil yang melebihi kemampuan studi mendalam;

6) pengujian semua pasangan - suatu teknik yang kumpulan nilai pengujiannya mencakup semua kemungkinan kombinasi diskrit dari setiap pasangan parameter masukan;

Pengujian Kotak Hitam: Contoh

Teknik ini didasarkan pada spesifikasi, dokumentasi, dan deskripsi perangkat lunak atau antarmuka sistem. Selain itu, dimungkinkan untuk menggunakan model (formal atau informal) yang mewakili perilaku yang diharapkan dari perangkat lunak.

Metode debugging ini biasanya digunakan untuk antarmuka pengguna dan memerlukan interaksi dengan aplikasi dengan memasukkan data dan mengumpulkan hasil - dari layar, dari laporan, atau cetakan.

Penguji kemudian berinteraksi dengan perangkat lunak melalui input, sakelar operasi, tombol, atau antarmuka lainnya. Pilihan data masukan, urutan pemasukannya, atau urutan tindakan dapat menghasilkan jumlah kombinasi yang sangat besar, seperti dapat dilihat pada contoh berikut.

Berapa banyak tes yang diperlukan untuk memeriksa semua nilai yang mungkin untuk 4 kotak centang dan satu bidang dua posisi yang menentukan waktu dalam hitungan detik? Sekilas, penghitungannya sederhana: 4 bidang dengan dua kemungkinan status - 24 = 16, yang harus dikalikan dengan jumlah kemungkinan posisi dari 00 hingga 99, yaitu 1600 kemungkinan pengujian.

Namun perhitungan ini memiliki kelemahan: kita dapat mendefinisikan bahwa bidang dua posisi juga dapat berisi spasi, yaitu terdiri dari dua posisi alfanumerik dan dapat berisi karakter alfabet, karakter khusus, spasi, dll. Jadi, jika sistemnya adalah 16 -bit komputer, terdapat 216 = 65.536 opsi untuk setiap posisi, sehingga menghasilkan 4.294.967.296 kasus pengujian, yang harus dikalikan dengan 16 kombinasi untuk flag, menghasilkan total 68.719.476.736 dengan kecepatan 1 pengujian per detik, total durasi pengujian akan menjadi 2.177,5 tahun. Untuk sistem 32 atau 64-bit, durasinya lebih lama lagi.

Oleh karena itu, ada kebutuhan untuk mengurangi periode ini ke nilai yang dapat diterima. Oleh karena itu, teknik harus diterapkan untuk mengurangi jumlah kasus uji tanpa mengurangi cakupan pengujian.

Partisi yang setara

Partisi ekuivalen adalah teknik sederhana yang dapat diterapkan pada variabel apa pun yang ada dalam perangkat lunak, baik itu nilai masukan atau keluaran, simbolik, numerik, dll. Hal ini didasarkan pada prinsip bahwa semua data dari partisi ekuivalen yang sama akan diproses dengan cara yang sama dan dengan instruksi yang sama.

Selama pengujian, satu perwakilan dipilih dari setiap partisi setara yang ditentukan. Hal ini memungkinkan Anda secara sistematis mengurangi jumlah kemungkinan kasus pengujian tanpa kehilangan cakupan perintah dan fitur.

Konsekuensi lain dari partisi ini adalah pengurangan ledakan kombinatorial antara variabel yang berbeda dan pengurangan kasus uji yang terkait.

Misalnya, dalam (1/x)1/2 tiga urutan data digunakan, tiga partisi setara:

1. Semua bilangan positif akan diproses dengan cara yang sama dan akan memberikan hasil yang benar.

2. Semua bilangan negatif akan diproses dengan cara yang sama, dengan hasil yang sama. Hal ini tidak benar karena akar suatu bilangan negatif adalah bilangan imajiner.

3. Nol akan diproses secara terpisah dan akan memberikan kesalahan pembagian dengan nol. Ini adalah bagian makna tunggal.

Jadi kita melihat tiga bagian berbeda, yang salah satunya bermuara pada satu makna. Ada satu bagian yang “benar”, yang memberikan hasil yang dapat diandalkan, dan dua bagian yang “salah”, dengan hasil yang salah.

Analisis wilayah

Pemrosesan data pada batas partisi yang setara mungkin dilakukan secara berbeda dari yang diharapkan. Studi nilai batas adalah cara yang terkenal untuk menganalisis perilaku perangkat lunak di area tersebut. Teknik ini memungkinkan Anda mengidentifikasi kesalahan berikut:

penggunaan operator relasional yang salah (<,>, =, ≠, ≥, ≤);
kesalahan tunggal;
masalah dengan loop dan iterasi,
jenis atau ukuran variabel yang digunakan untuk menyimpan informasi salah;
pembatasan buatan yang terkait dengan tipe data dan variabel.

Pengujian tembus pandang

Metode kotak abu-abu meningkatkan cakupan audit dengan memungkinkan Anda fokus pada semua tingkat sistem yang kompleks dengan menggabungkan metode kotak putih dan hitam.

Saat menggunakan teknik ini, penguji harus memiliki pengetahuan tentang struktur data internal dan algoritma untuk mengembangkan nilai pengujian. Contoh teknik pengujian kotak abu-abu adalah:

model arsitektur;
Bahasa Pemodelan Terpadu (UML);
model negara (mesin negara terbatas).

Dalam metode kotak abu-abu, kode modul dipelajari menggunakan teknik putih untuk mengembangkan kasus uji, dan pengujian sebenarnya dilakukan pada antarmuka program menggunakan teknik hitam.

Metode pengujian tersebut memiliki keuntungan sebagai berikut:

menggabungkan keunggulan teknik kotak putih dan hitam;
penguji mengandalkan antarmuka dan spesifikasi fungsional daripada kode sumber;
debugger dapat membuat skrip pengujian yang sangat baik;
verifikasi dilakukan dari sudut pandang pengguna, bukan perancang program;
pembuatan pengembangan pengujian khusus;
objektivitas.

Kekurangan:

cakupan pengujian terbatas karena kurangnya akses terhadap kode sumber;
kesulitan mendeteksi cacat pada aplikasi terdistribusi;
banyak jalan yang masih belum dijelajahi;
jika pengembang perangkat lunak telah menjalankan pengujian, penyelidikan lebih lanjut mungkin tidak diperlukan.

Nama lain dari teknik kotak abu-abu adalah debugging tembus cahaya.

1) susunan ortogonal - menggunakan subset dari semua kemungkinan kombinasi;

2) debugging matriks menggunakan data status program;

3) dilakukan pada saat dilakukan perubahan baru pada perangkat lunak;

4) pengujian template yang menganalisis desain dan arsitektur aplikasi yang baik.

pengujian perangkat lunak

Penggunaan semua metode dinamis menyebabkan ledakan kombinatorial dalam jumlah pengujian yang harus dirancang, diimplementasikan, dan dilaksanakan. Setiap teknik harus digunakan secara pragmatis, dengan mempertimbangkan keterbatasannya.

Tidak ada satu metode yang benar, yang ada hanyalah metode yang lebih sesuai dengan konteks tertentu. Teknik struktural dapat menemukan kode yang tidak berguna atau berbahaya, namun rumit dan tidak dapat diterapkan pada program besar. Metode berbasis spesifikasi adalah satu-satunya metode yang mampu mengidentifikasi kode yang hilang, namun tidak dapat mengidentifikasi outlier. Beberapa teknik lebih cocok untuk tingkat pengujian, jenis bug, atau konteks tertentu dibandingkan yang lain.

Di bawah ini adalah perbedaan utama antara ketiga teknik pengujian dinamis - tabel perbandingan antara ketiga bentuk debugging perangkat lunak diberikan.

Aspek	Metode kotak hitam	Metode kotak abu-abu	Metode kotak putih
Ketersediaan informasi tentang komposisi program	Hanya aspek dasar yang dianalisis	Pengetahuan parsial tentang struktur internal program	Akses penuh ke kode sumber
Tingkat fragmentasi program
Siapa yang melakukan debugging?	Pengguna akhir, penguji, dan pengembang	Pengguna akhir, debugger, dan pengembang	Pengembang dan penguji
	Pengujian didasarkan pada situasi darurat eksternal.	Diagram basis data, diagram aliran data, keadaan internal, pengetahuan tentang algoritma dan arsitektur	Struktur internalnya diketahui sepenuhnya
Cakupan	Kurang komprehensif dan membutuhkan waktu minimal		Mungkin yang paling komprehensif. Membutuhkan banyak waktu
Data dan batasan internal	Debugging hanya dilakukan dengan coba-coba	Domain data dan batasan internal dapat diperiksa jika diketahui	Pengujian domain data dan batasan internal yang lebih baik
Kesesuaian untuk menguji algoritma

Otomatisasi

Metode pengujian perangkat lunak otomatis sangat menyederhanakan proses verifikasi, terlepas dari lingkungan teknis atau konteks perangkat lunak. Mereka digunakan dalam dua kasus:

1) untuk mengotomatisasi tugas-tugas yang membosankan, berulang-ulang atau teliti, seperti membandingkan file beberapa ribu baris, untuk membebaskan waktu penguji untuk berkonsentrasi pada poin-poin yang lebih penting;

2) untuk melakukan atau melacak tugas-tugas yang tidak dapat dilakukan dengan mudah oleh manusia, seperti pengujian kinerja atau analisis waktu respons, yang dapat diukur dalam seperseratus detik.

Instrumen tes dapat diklasifikasikan dengan berbagai cara. Berikut pembagiannya berdasarkan tugas yang didukungnya:

manajemen pengujian, yang mencakup dukungan untuk manajemen proyek, manajemen versi, manajemen konfigurasi, analisis risiko, pelacakan pengujian, bug, cacat, dan alat pelaporan;
manajemen persyaratan, yang mencakup penyimpanan persyaratan dan spesifikasi, pemeriksaan kelengkapan dan ambiguitas, prioritasnya, dan ketertelusuran setiap pengujian;
tinjauan kritis dan analisis statis, termasuk memantau aliran dan tugas, mencatat dan menyimpan komentar, mendeteksi cacat dan koreksi yang direncanakan, mengelola referensi ke daftar periksa dan aturan, melacak hubungan dokumen sumber dan kode, analisis statis dengan mendeteksi cacat, memastikan kepatuhan terhadap standar pengkodean , analisis struktur dan ketergantungannya, perhitungan parameter metrik kode dan arsitektur. Selain itu, kompiler, penganalisis tautan, dan generator referensi silang digunakan;
pemodelan, yang mencakup alat untuk memodelkan perilaku bisnis dan menguji model yang dibuat;
pengembangan pengujian memastikan pembuatan data yang diharapkan berdasarkan kondisi dan antarmuka pengguna, model dan kode, manajemennya untuk membuat atau mengubah file dan database, pesan, verifikasi data berdasarkan aturan manajemen, analisis statistik kondisi dan risiko;
tinjauan kritis dengan memasukkan data melalui GUI, API, baris perintah menggunakan pembanding untuk membantu mengidentifikasi pengujian yang berhasil dan gagal;
dukungan untuk lingkungan debugging yang memungkinkan Anda mengganti perangkat keras atau perangkat lunak yang hilang, termasuk simulator perangkat keras berdasarkan subset keluaran deterministik, emulator terminal, ponsel atau peralatan jaringan, lingkungan untuk menguji bahasa, OS dan perangkat keras dengan mengganti komponen yang hilang dengan modul driver tiruan , dll., serta alat untuk mencegat dan memodifikasi permintaan OS, mensimulasikan batasan CPU, RAM, ROM atau jaringan;
perbandingan file data, database, pemeriksaan hasil yang diharapkan selama dan setelah pengujian, termasuk perbandingan dinamis dan batch, “oracle” otomatis;
pengukuran cakupan untuk melokalisasi kebocoran memori dan manajemen memori yang salah, mengevaluasi perilaku sistem dalam kondisi beban simulasi, menghasilkan beban aplikasi, database, jaringan atau server dalam skenario pertumbuhan yang realistis, untuk mengukur, menganalisis, memeriksa dan melaporkan sumber daya sistem;
memastikan keamanan;
pengujian kinerja, pengujian beban dan analisis dinamis;
alat lainnya, termasuk untuk memeriksa ejaan dan sintaksis, keamanan jaringan, ketersediaan semua halaman situs web, dll.

Perspektif

Seiring dengan perubahan tren dalam industri perangkat lunak, proses debugging juga dapat berubah. Metode pengujian perangkat lunak baru yang ada seperti Arsitektur Berorientasi Layanan (SOA), teknologi nirkabel, layanan seluler, dll. telah membuka cara baru dalam pengujian perangkat lunak. Beberapa perubahan yang diharapkan terjadi dalam industri ini selama beberapa tahun ke depan adalah sebagai berikut:

penguji akan menyediakan model ringan yang dapat digunakan pengembang untuk memeriksa kode mereka;
pengembangan metode pengujian yang mencakup melihat dan mensimulasikan program pada tahap awal akan menghilangkan banyak inkonsistensi;
kehadiran banyak intersepsi pengujian akan mengurangi waktu untuk mendeteksi kesalahan;
alat analisa dan deteksi statis akan digunakan secara lebih luas;
penerapan matriks yang berguna seperti cakupan spesifikasi, cakupan model, dan cakupan kode akan memandu pengembangan proyek;
alat kombinatorial akan memungkinkan penguji menentukan area prioritas untuk debugging;
penguji akan memberikan layanan yang lebih terlihat dan berharga sepanjang proses pengembangan perangkat lunak;
Debugger akan mampu membuat alat dan metode pengujian perangkat lunak yang ditulis dan dapat dioperasikan dengan berbagai bahasa pemrograman;
Spesialis debugging akan menjadi lebih terlatih secara profesional.

Metode baru yang berorientasi bisnis dalam program pengujian akan menggantikannya, mengubah cara kita berinteraksi dengan sistem dan informasi yang disediakan, sekaligus mengurangi risiko dan meningkatkan manfaat dari perubahan bisnis.

OTOMATIS

Perkenalan

Pengujian regresi

Skrip pengujian

Pengujian kotak putih dan kotak hitam

Cakupan Kode

Kutipan

Lihat juga

Catatan

Literatur

Pengujian kotak hitam. Teknologi untuk pengujian fungsional perangkat lunak dan sistem. - Sankt Peterburg. : Petrus, 2004. - 320 hal. - ISBN 5-94723-698-2

Perbandingan pendekatan pengujian manual dan otomatis

Inspeksi dan penelusuran

Pengujian ad-hoc

Pengujian penerimaan

Apa itu Pengujian Penerimaan di Agile?

Pengujian Aksesibilitas

Pengujian tangkas

pengujian API

Pengujian Otomatis

Pengujian berpasangan

Pengujian beta

Pengujian Kotak Hitam

Pengujian Kompatibilitas Mundur

Batasi pengujian

Metode Uji Big Bang

Pengujian integrasi Bottom-up (pengujian bottom-up)

Menguji cabang

Pengujian Kompatibilitas Peramban

Pengujian kompatibilitas

Pengujian komponen

Pengujian cakupan kondisi

Pengujian dinamis

Pengujian cakupan solusi

Pengujian Ujung-ke-Ujung

Pengujian eksplorasi

Partisi yang setara

Pengujian fungsional

Pengujian bulu halus

Menguji GUI

Pengujian kotak kaca

Pengujian gorila (pengujian kacau)

Menguji jalur yang menguntungkan

Pengujian integrasi

Pengujian antarmuka

Pengujian internasionalisasi

Pengujian berbasis kata kunci

Pengujian beban

Pengujian lokalisasi

Pengujian negatif

Pengujian non-fungsional

Pengujian berpasangan

Pengujian kinerja

Pengujian keamanan

Pengujian regresi

Pengujian ulang

Pengujian Berbasis Risiko

Pengujian asap (pengujian asap)

Pengujian keamanan

Pengujian Kinerja

Pengujian skalabilitas

Pengujian stabilitas

Pengujian statis

Tes stres

Pengujian sistem

Pengujian beban

Pengujian integrasi sistem

Pengujian satuan

Pengujian kegunaan

Pengujian Penerimaan Pengguna

Pengujian volume

Pengujian kerentanan

Pengujian kotak putih

Metode

Pengujian transparan

Debug Perilaku

Pengujian Kotak Hitam: Contoh

Partisi yang setara

Analisis wilayah

Pengujian tembus pandang