Analisis Pengujian dan Dasar-Dasar Pengujian

Analisis Pengujian — juga dikenal sebagai Basis Pengujian — berada di awal siklus hidup pengujian. Setiap kondisi pengujian dan kasus uji pada akhirnya tracMari kita kembali ke topik tersebut. Bagian-bagian di bawah ini mendefinisikan istilah tersebut, menjelaskan sumbernya, menjabarkan alur kerja analisis, dan menempatkannya dalam Model V.

Apa itu Analisis Tes?

Analisis Uji Dalam pengujian perangkat lunak, proses ini mencakup peninjauan input yang digunakan untuk mendapatkan kondisi pengujian dan kasus uji. Input ini—spesifikasi, persyaratan, dokumen desain, cerita pengguna, dan hasil kerja serupa—secara kolektif disebut... artefak pengujianTujuan analisis tes adalah untuk...tracTujuan uji t harus cukup jelas sehingga masing-masing dapat diubah menjadi kondisi uji yang tidak ambigu. Karena materi yang dianalisis membentuk dasar dari mana semua uji diturunkan, maka materi tersebut juga disebut sebagai dasar. Dasar Tes.

Sumber-sumber umum yang digunakan penguji untuk memperoleh informasi pengujian meliputi:

• SRS — Spesifikasi Persyaratan Perangkat Lunak
• BRS — Spesifikasi Persyaratan Bisnis
• Dokumen Desain Fungsional
• Cerita pengguna, kriteria penerimaan, dan kerangka kerja (wireframe)

Penguji juga dapat menghasilkan kondisi pengujian dengan menjelajahi Aplikasi yang Sedang Diuji secara langsung atau dengan memanfaatkan pengalaman sebelumnya, tetapi sebagian besar kasus uji berasal dari artefak pengujian untuk pemeliharaan trackemampuan.

👉 Daftar untuk Proyek Pengujian Perangkat Lunak Langsung Gratis

Mengapa Basis Pengujian penting?

Basis pengujian adalah penentu terbesar apakah rangkaian pengujian menangkap cacat nyata atau hanya mengejar cacat semu. Menganggapnya sebagai hal opsional adalah penyebab paling umum dari bug yang lolos dan mencapai lingkungan produksi. Analisis pengujian yang solid memberikan empat manfaat nyata:

• Traceabilitas: Setiap kasus uji dapat dikaitkan kembali dengan persyaratan spesifik, yang membuat analisis dampak perubahan menjadi cepat dan tinjauan audit menjadi mudah.
• Kejelasan cakupan: RevMeninjau celah pada permukaan dasar — ​​status kesalahan yang tidak ditentukan, kasus batas yang hilang, ambang batas non-fungsional yang tidak terdefinisi — sebelum menjadi insiden produksi.
• Keselarasan pemangku kepentingan: Ketika tim penguji menentukan kondisi dari dokumen yang sama yang digunakan tim pengembang untuk membangun perangkat lunak, kedua belah pihak memiliki definisi "selesai" yang sama.
• Deteksi dini kerusakan: Banyak cacat persyaratan (ambiguitas, kontradiksi, kriteria penerimaan yang hilang) terdeteksi selama analisis pengujian itu sendiri, jauh sebelum kode apa pun ditulis — ini adalah tempat termurah untuk memperbaikinya.

Sumber Umum Dasar Pengujian

Artefak yang berbeda mendukung tingkat pengujian yang berbeda. Gunakan tabel di bawah ini sebagai referensi cepat saat memutuskan dokumen mana yang akan dikonsultasikan saat menulis kasus uji.

Artefak Sumber	Cocok Untuk	Apa yang Mantanmutract
Spesifikasi Persyaratan Bisnis (BRS)	Pengujian penerimaan dan sistem	Aturan bisnis ujung-ke-ujung, batasan regulasi, kriteria keberhasilan
Spesifikasi Persyaratan Perangkat Lunak (SRS)	Pengujian sistem	Persyaratan fungsional dan non-fungsional dengan ambang batas yang terukur.
Dokumen Desain Fungsional / Teknis	Tes integrasi	Antarmuka modul, alur data, spesifikasi penanganan kesalahan
Cerita pengguna & kriteria penerimaan	Pengujian sprint Agile	Ekspektasi perilaku dalam bentuk “Diberikan–Kapan–Maka”
Wireframe & mockup UI	Pengujian UI/kegunaan	Tata letak, navigasi, aturan validasi input
Aplikasi yang Sedang Diuji (eksplorasi)	Pengujian eksploratif dan regresi	Perilaku yang tidak terdokumentasi, alur kerja dunia nyata, kasus-kasus ekstrem.

Cara Melakukan Analisis Tes Langkah demi Langkah

Analisis pengujian yang efektif mengikuti alur kerja lima langkah yang dapat diulang, terlepas dari ukuran proyek atau metodologinya.

1. Kumpulkan dan inventarisasi dasar pengujian. Kumpulkan setiap artefak yang menjelaskan perilaku yang diinginkan — SRS, BRS, dokumen desain, user story, mockup. Catat dokumen mana yang bertanggung jawab atas setiap persyaratan sehingga tracKeandalan tetap terjaga.
2. RevTinjauan untuk kemudahan pengujian. Bacalah setiap artefak dengan tiga pertanyaan dalam pikiran: Apakah pernyataan ini terukur? Apakah pernyataan ini tidak ambigu? Apakah pernyataan ini lengkap? Tandai persyaratan apa pun yang gagal dalam salah satu pemeriksaan tersebut dan sampaikan kembali kepada penulis sebelum menulis pengujian terhadapnya.
3. Identifikasi kondisi pengujian. Untuk setiap pernyataan yang dapat diuji, cantumkan kondisi yang perlu diverifikasi (jalur positif, jalur negatif, nilai batas, penanganan kesalahan, keamanan, kinerja). Kondisi pengujian adalah hal yang mutlak.trac“apa” — misalnya, “Sistem menolak pesanan dengan kuantitas nol” — berbeda dari "bagaimana" konkret dalam sebuah kasus uji.
4. Prioritaskan dan kelompokkan kondisi-kondisi tersebut. Klasifikasikan setiap kondisi berdasarkan risiko dan frekuensi penggunaan. Kondisi berisiko tinggi dan frekuensi tinggi memerlukan cakupan yang detail; kondisi berisiko rendah dapat digabungkan atau diambil sampelnya. Di sinilah Anda juga memutuskan kondisi mana yang merupakan kandidat otomatisasi.
5. Ubah kondisi menjadi kasus uji. Setiap kondisi yang diprioritaskan menjadi satu atau lebih kasus uji dengan prasyarat, langkah-langkah, data uji, dan hasil yang diharapkan. Memelihara persyaratan. tracMatriks kelayakan yang menghubungkan setiap kasus uji dengan persyaratan asalnya.

Dengan mengikuti urutan ini, kesalahan analisis pengujian yang paling umum dapat dihindari: menulis kasus uji tanpa dasar yang jelas, melewatkan skenario negatif, dan menghasilkan pengujian yang tidak dapat dikaitkan kembali dengan persyaratan selama penapisan cacat.

Analisis Pengujian dalam Model V

Model V memasangkan setiap aktivitas pengembangan dengan aktivitas pengujian yang sesuai. Analisis pengujian dilakukan di setiap level menggunakan dokumen mana pun yang tersedia pada titik tersebut dalam siklus hidup.

Gambar 1: Analisis Pengujian di Seluruh Fase V-Model.

Studi Kasus: Mendapatkan Kasus Uji dari Persyaratan Klien

Pertimbangkan skenario di mana klien mengirimkan persyaratan satu baris berikut.

Client requirement: Add search functionality to an eCommerce Store

Meskipun aplikasi belum dibangun, seorang penguji sudah dapat menyimpulkan beberapa kondisi pengujian dengan menganalisis apa yang tersirat dalam persyaratan — baik perilaku skenario ideal maupun skenario kegagalan yang tidak dinyatakan secara eksplisit oleh klien. Beberapa contohnya meliputi:

• Verifikasi hasil pencarian jika tidak ada kata kunci yang dimasukkan.
• Verifikasi hasil pencarian jika tidak ada produk yang cocok untuk kata kunci yang dimasukkan.
• Verifikasi hasil pencarian jika terdapat beberapa produk yang cocok untuk kata kunci tersebut.
• Verifikasi perilaku dengan karakter khusus, spasi di awal/akhir, dan input yang sangat panjang.
• Verifikasi kepekaan huruf besar/kecil dan perilaku pencocokan sebagian.
• Verifikasi waktu respons pencarian di bawah beban pengguna yang diharapkan.

Penguji mengambil persyaratan klien (dasar pengujian), menganalisisnya, dan mengubahnya menjadi kondisi pengujian. Pola ini berulang di setiap fase Model V — rencana pengujian dan kasus uji dibuat menggunakan dokumen mana pun yang tersedia pada titik tersebut dalam siklus hidup.

Video: Penjelasan Analisis Tes

Jika video tidak dimuat, tonton langsung di YouTube.

Pertanyaan Umum Demo Slot