Komputer, Perangkat lunak
Metode pengujian perangkat lunak dan membandingkan mereka. Metode pengujian "kotak hitam" pengujian dan metode "kotak putih"
pengujian perangkat lunak (SW) mengidentifikasi kesenjangan, kekurangan dan kesalahan dalam kode yang perlu ditangani. Hal ini juga dapat didefinisikan sebagai proses mengevaluasi fungsi dan kebenaran dari perangkat lunak dengan bantuan analisis. metode dasar integrasi dan pengujian aplikasi perangkat lunak dan memastikan kualitas adalah untuk menguji spesifikasi, desain dan pengkodean, penilaian keandalan, validasi dan verifikasi.
metode
Tujuan utama dari pengujian perangkat lunak - konfirmasi kualitas sistem perangkat lunak melalui aplikasi debugging sistematis dalam kondisi yang terkendali dengan hati-hati untuk menentukan kelengkapan dan akurasi, serta deteksi kesalahan tersembunyi.
Metode verifikasi (pengujian) program dapat dibagi menjadi statis dan dinamis.
Mantan termasuk informal pemantauan dan kajian teknis, inspeksi, langkah demi langkah analisis, audit, serta analisis aliran data statis dan manajemen.
teknik dinamis adalah:
- pengujian kotak putih. Ini adalah studi rinci tentang logika internal dan struktur program. Hal ini diperlukan untuk pengetahuan tentang kode sumber.
- pengujian kotak hitam. Teknik ini tidak memerlukan pengetahuan tentang cara kerja bagian dalam aplikasi. Kita hanya mempertimbangkan aspek-aspek dasar dari sistem, tidak berhubungan dengan atau berhubungan dengan beberapa struktur logis internal.
- Metode kotak abu-abu. Ini menggabungkan dua pendekatan sebelumnya. Debugging dengan pengetahuan yang terbatas dari fungsi internal dari aplikasi dikombinasikan dengan pengetahuan tentang aspek-aspek dasar dari sistem.
pengujian transparan
Metode kotak menggunakan skrip pengujian putih mengontrol struktur dari desain prosedural. Teknik ini memungkinkan untuk mengungkapkan kesalahan implementasi, seperti sistem kode manajemen yang buruk dengan menganalisis bagian dari inner perangkat lunak. Metode uji ini berlaku untuk tingkat integrasi, modul dan sistem. tester harus memiliki akses ke kode sumber dan menggunakannya untuk mengetahui Unit berperilaku tidak tepat.
Pengujian program dengan kotak putih memiliki keuntungan sebagai berikut:
- Hal ini memungkinkan untuk mendeteksi kesalahan dalam kode tersembunyi dengan menghapus garis yang tidak perlu;
- penggunaan efek samping;
- cakupan maksimum dicapai dengan menulis naskah tes.
kelemahan:
- Proses biaya tinggi, membutuhkan debugger terampil;
- banyak jalan tetap belum diselidiki karena pemeriksaan menyeluruh dari semua kesalahan tersembunyi yang mungkin sangat kompleks;
- beberapa kode akan diteruskan tanpa disadari.
pengujian kotak putih kadang-kadang disebut dengan menguji kotak transparan atau terbuka, struktural, pengujian logis, berdasarkan kode sumber, dan arsitektur logika.
Varietas utama:
1) menguji kontrol aliran - strategi struktural menggunakan model aliran kontrol program dan memihak cara yang lebih sederhana untuk sedikit lebih kompleks;
2) Cabang ini dirancang untuk mempelajari debug setiap opsi (benar atau salah) dari masing-masing operator kontrol, yang juga termasuk solusi gabungan;
3) pengujian jalan utama, yang memungkinkan tester untuk membangun logis kompleksitas ukuran proyek prosedural untuk mengisolasi satu set dasar jalur eksekusi;
4) memeriksa aliran data - strategi kontrol aliran penelitian oleh penjelasan menghitung informasi tentang iklan dan menggunakan variabel program;
5) siklus pengujian - sepenuhnya fokus pada operasi yang benar dari proses siklik.
debugging perilaku
pengujian kotak hitam memperlakukan perangkat lunak sebagai "kotak hitam" - informasi tentang cara kerja bagian dalam program ini tidak dihitung, dan diperiksa hanya aspek-aspek dasar dari sistem. Dalam hal ini, tester perlu mengetahui arsitektur sistem tanpa akses ke kode sumber.
Keuntungan dari pendekatan ini:
- efisiensi untuk segmen kode besar;
- kemudahan persepsi tester;
- perspektif pengguna jelas dipisahkan dari perspektif pengembang (programmer dan tester independen satu sama lain);
- penciptaan lebih cepat dari tes.
software pengujian metode black box memiliki kelemahan sebagai berikut:
- memang dilakukan sejumlah pilih kasus uji, sehingga cakupan terbatas;
- kurangnya spesifikasi yang jelas sulit untuk mengembangkan skrip uji;
- efisiensi rendah.
Nama lain untuk teknologi ini - perilaku, non-transparan, uji fungsional dan metode debugging dari kotak tertutup.
Kategori ini mungkin termasuk teknik pengujian perangkat lunak berikut:
1) setara dengan partisi, yang dapat mengurangi set data uji sebagai data modul perangkat lunak input dipecah menjadi bagian yang terpisah;
2) analisis nilai batas berfokus pada verifikasi batas atau nilai-nilai batas ekstrim - minimum, maksimum, dan nilai-nilai khas kesalahan;
3) fuzzing - digunakan untuk melaksanakan pencarian dengan memasukkan kesalahan atau rusak poluiskazhennyh data dalam mode otomatis atau semi-otomatis;
4) jumlah kausalitas - teknik didasarkan pada penciptaan grafik dan menentukan hubungan antara tindakan dan alasan nya: identitas, negasi, logika OR dan logika AND - empat karakter utama, mengungkapkan hubungan antara sebab dan akibat;
5) Verifikasi array orthogonal diterapkan untuk masalah dengan area input relatif kecil melebihi kemungkinan penelitian mendalam;
6) menguji semua pasangan - teknik di mana satu set nilai tes terdiri dari semua kombinasi biner yang mungkin dari setiap pasangan parameter masukan;
7) negara debugging transisi - teknik yang berguna untuk memeriksa status mesin, serta untuk menavigasi melalui GUI pengguna.
Hitam pengujian kotak: Contoh
teknik black-box didasarkan pada spesifikasi, dokumentasi, dan deskripsi dari interface perangkat lunak atau sistem. Selain itu, Anda dapat menggunakan model (formal atau informal), yang mewakili perilaku yang diharapkan dari perangkat lunak.
Biasanya, metode ini digunakan untuk debugging antarmuka pengguna dan memerlukan interaksi dengan aplikasi dengan memperkenalkan koleksi data dan hasil - dari layar, dari laporan atau cetakan.
tester, oleh karena itu, berinteraksi dengan perangkat lunak dengan memasukkan, dengan bertindak pada switch, tombol atau antarmuka lainnya. Pilihan input data, urutan administrasi atau urutan tindakan dapat menyebabkan jumlah besar kombinasi, seperti yang ditunjukkan dalam contoh berikut.
Berapa banyak tes perlu membuat untuk memeriksa semua nilai yang mungkin untuk bendera 4 jendela dan satu-luar lapangan, mengatur waktu dalam hitungan detik? Pada perhitungan pandangan pertama adalah sederhana: 4 bidang dengan dua negara mungkin - 24 = 16, yang harus dikalikan dengan jumlah kemungkinan posisi 00-99, yaitu 1600 tes mungkin.
Namun, perhitungan ini adalah salah: kita dapat menentukan bahwa bidang dua titik juga dapat berisi spasi, yakni terdiri dari dua posisi alfanumerik dan dapat mencakup karakter alfanumerik, karakter khusus, spasi, dll Dengan demikian, jika .... sistem komputer 16-bit, giliran 216 = 65536 satu untuk setiap posisi dalam resultan 4294967296 kasus uji yang akan dikalikan dengan 16 kombinasi dari bendera yang memberikan total 68.719.476 736. Jika mereka melakukan pada 1 tes per detik, total cont pengujian olzhitelnost adalah 2 177,5 tahun. Untuk sistem 32 atau 64-bit, durasi bahkan lebih.
Oleh karena itu ada kebutuhan untuk mengurangi periode ini untuk tingkat yang dapat diterima. Dengan demikian, teknik harus diterapkan untuk mengurangi jumlah kasus uji tanpa mengurangi ruang lingkup pengujian.
kesetaraan partisi
Partisi setara adalah metode sederhana yang dapat diterapkan untuk setiap variabel yang hadir dalam perangkat lunak, apakah input atau output nilai-nilai, simbolik, numerik, dan lain-lain. Hal ini didasarkan pada prinsip bahwa semua data dari satu ekivalen partisi akan diperlakukan dengan cara yang sama dan dengan instruksi yang sama.
Selama pengujian, memilih satu wakil dari setiap partisi kesetaraan tertentu. Hal ini memungkinkan Anda untuk secara sistematis mengurangi jumlah kemungkinan kasus uji tanpa kehilangan cakupan perintah dan fungsi.
Konsekuensi lain dari partisi ini adalah untuk mengurangi ledakan kombinatorial antara variabel yang berbeda dan pengurangan terkait kasus uji.
Sebagai contoh, di (1 / x) 1/2 menggunakan tiga urutan data, tiga partisi setara:
1. nomor positif akan diperlakukan dengan cara yang sama dan harus memberikan hasil yang benar.
2. nomor negatif ditangani dengan cara yang sama dengan hasil yang sama. Ini tidak benar, karena akar dari angka negatif adalah imajiner.
3. Nol akan ditangani secara terpisah dan memberikan kesalahan "pembagian dengan nol". Ini adalah bagian dengan nilai tunggal.
Jadi, kita melihat tiga bagian yang berbeda, salah satunya adalah dikurangi menjadi nilai tunggal. Ada satu "benar" bagian, yang memberikan hasil yang dapat diandalkan, dan dua "salah" dengan hasil yang salah.
analisis nilai batas
Pengolahan di perbatasan setara partisi dapat dilakukan secara berbeda dari yang diharapkan. Investigasi nilai batas - metode terkenal menganalisis perilaku dari perangkat lunak di daerah tersebut. Teknik ini memungkinkan untuk mengidentifikasi kesalahan seperti:
- penyalahgunaan operator relasional (<,>, =, ≠, ≥, ≤);
- tunggal kesalahan;
- masalah dalam siklus dan iterasi,
- jenis yang salah atau ukuran variabel yang digunakan untuk menyimpan informasi;
- keterbatasan buatan terkait dengan tipe data dan variabel.
pengujian tembus
Metode kotak abu-abu meningkatkan cakupan tes, Anda dapat fokus pada semua tingkat kesulitan dari sistem melalui kombinasi teknik hitam dan putih.
Dengan menggunakan teknik ini, tester untuk pengembangan nilai-nilai tes harus memiliki pengetahuan tentang struktur data internal dan algoritma. Contoh metode pengujian abu-abu kotak adalah sebagai berikut:
- model arsitektur;
- Unified Modeling Language (UML);
- model negara (mesin negara yang terbatas).
Dalam metode kotak abu-abu untuk mengembangkan uji kasus belajar modul dalam kode rekayasa putih, dan tes yang sebenarnya dilakukan pada antarmuka dari program teknologi hitam.
Metode-metode pengujian memiliki keuntungan sebagai berikut:
- Kombinasi keuntungan kotak putih dan hitam teknisi;
- Tester didasarkan pada antarmuka dan spesifikasi fungsional, dan bukan kode sumber;
- debugger dapat membuat ujian besar kasus;
- cek dibuat dari sudut pandang pengguna, bukan perancang program;
- membuat pengembangan tes kustom;
- objektivitas.
kelemahan:
- cakupan tes terbatas karena tidak ada akses ke kode sumber;
- kompleksitas dari cacat pada aplikasi terdistribusi;
- banyak cara tetap belum diselidiki;
- jika pengembang perangkat lunak telah meluncurkan tes, maka penyelidikan lebih lanjut mungkin berlebihan.
Nama lain untuk teknik kotak abu-abu - tembus debugging.
Kategori ini termasuk metode seperti pengujian:
1) Array orthogonal - penggunaan subset dari semua kemungkinan kombinasi;
2) matriks debugging menggunakan keadaan data program;
3) pemeriksaan regresif dilakukan di perubahan baru untuk perangkat lunak;
4) Uji template yang menganalisis desain dan arsitektur aplikasi yang baik.
Perbandingan teknik pengujian perangkat lunak
Penggunaan metode dinamis menyebabkan ledakan kombinatorial dari jumlah tes yang perlu dikembangkan, dilaksanakan dan dilakukan. Setiap teknik harus digunakan secara pragmatis, mengambil keterbatasan ke rekening.
Satu-satunya metode yang benar tidak ada, hanya ada orang-orang yang lebih cocok untuk konteks tertentu. rekayasa struktural memungkinkan kita untuk menemukan kode yang tidak berguna atau berbahaya, tetapi mereka kompleks dan tidak berlaku untuk program besar. Metode berdasarkan spesifikasi - satu-satunya yang mampu mengidentifikasi kode yang hilang, tetapi mereka tidak dapat mengidentifikasi orang luar. Beberapa teknik yang lebih cocok untuk tingkat tes tertentu, jenis kesalahan atau konteks daripada yang lain.
Berikut adalah perbedaan utama antara tiga teknik pengujian dinamis - diberikan tabel perbandingan antara tiga bentuk debug software.
aspek | Metode kotak hitam | Metode kotak abu-abu | Metode putih-kotak |
Ketersediaan informasi tentang komposisi program | Memeriksa hanya aspek-aspek dasar | pengetahuan parsial tentang struktur internal program | Akses penuh ke kode sumber |
Tingkat fragmentasi program | rendah | pusat | tinggi |
Yang menghasilkan debugging? | Pengguna akhir, penguji dan pengembang | Pengguna akhir, pengembang dan debugger | Pengembang dan penguji |
dasar | Pengujian didasarkan pada situasi darurat eksternal. | Database diagram, data flow diagram, state pengetahuan internal algoritma dan arsitektur | Perangkat internal menyadari sepenuhnya |
Tingkat cakupan | Kurang komprehensif dan membutuhkan waktu minimum | pusat | Berpotensi paling komprehensif. Memakan waktu |
Data dan batas-batas internal | Debug hanya dengan trial and error |
Dapat diperiksa domain data dan batas-batas internal, jika mereka dikenal | Yang terbaik domain uji data dan batas-batas internal |
algoritma pengujian kesesuaian | tidak | tidak | ya |
otomatisasi
metode otomatis pengujian perangkat lunak jauh menyederhanakan proses pemeriksaan, terlepas dari lingkungan teknis dan konteks. Mereka digunakan dalam dua kasus:
1) untuk mengotomatisasi tugas-tugas yang membosankan, berulang atau teliti seperti file dibandingkan dengan beberapa ribu baris untuk melepaskan waktu untuk konsentrasi tester poin lebih penting;
2) untuk melakukan pelacakan atau tugas-tugas yang tidak dapat dengan mudah dilakukan oleh orang-orang seperti verifikasi kinerja atau analisis waktu respon yang dapat diukur dalam seratus detik.
alat uji dapat diklasifikasikan dalam berbagai cara. Pembagian selanjutnya didasarkan pada tugas-tugas mereka mendukung:
- manajemen tes, yang meliputi dukungan manajemen proyek, versi, konfigurasi, analisis risiko, pelacakan tes, kesalahan, cacat, dan alat pelaporan;
- manajemen persyaratan, yang meliputi persyaratan penyimpanan dan spesifikasi, memeriksa mereka untuk kelengkapan dan ambiguitas, prioritas mereka dan ketertelusuran setiap tes;
- tinjauan kritis dan analisis statis, termasuk pemantauan aliran, dan tugas-tugas, pencatatan dan penyimpanan komentar, deteksi cacat dan direncanakan manajemen koreksi link ke daftar periksa dan aturan, pelacakan dokumen sumber komunikasi dan kode analisis statis untuk mendeteksi cacat, memastikan kepatuhan dengan standar penulisan kode, analisis struktur dan dependensi, perhitungan metrik parameter kode dan arsitektur. Selain itu, menggunakan compiler, analisa, generator dan hubungan-referensi silang;
- modeling, yang mencakup perangkat untuk perilaku bisnis modeling dan menguji model;
- pengembangan tes memastikan generasi data yang diharapkan atas dasar kondisi dan model antarmuka pengguna dan kode, mengelola untuk membuat atau memodifikasi file dan database, messaging, validasi data atas dasar aturan manajemen, analisis statistik dari kondisi dan risiko;
- pandangan kritis dengan memasukkan data melalui antarmuka pengguna, API, baris perintah grafis menggunakan pembanding untuk membantu mengidentifikasi tes sukses dan berhasil;
- dukungan debugging lingkungan yang memungkinkan Anda untuk mengganti hardware yang hilang atau perangkat lunak, di Vol. h. peralatan Simulasi berdasarkan subset bertekad output, emulator terminal, ponsel dan peralatan jaringan, lingkungan untuk memeriksa bahasa, sistem operasi dan hardware dengan mengganti driver komponen yang hilang, fiktif modul, dll, serta alat-alat untuk menangkap dan memodifikasi OS meminta pembatasan simulasi CPU, RAM, ROM, atau jaringan .;
- .. Sebuah perbandingan file data, database, memeriksa hasil yang diharapkan selama dan setelah ujian selesai, termasuk dinamis dan bets perbandingan, Automatic "Oracle";
- lapisan pengukuran untuk lokalisasi kebocoran memori dan perilaku kontrol sistem memperkirakan tidak benar di bawah simulasi aplikasi beban pembangkit beban, database, jaringan atau server dalam skenario realistis pertumbuhan untuk pengukuran, analisis dan verifikasi laporan sumber daya sistem;
- keamanan;
- pengujian kinerja, beban dan analisis dinamis;
- alat-alat lain, di Vol. h. untuk memeriksa ejaan dan sintaksis, keamanan jaringan, ketersediaan semua halaman situs web dan lainnya.
perspektif
Dengan perubahan tren dalam industri perangkat lunak, proses debugging juga dapat berubah. Ada metode baru pengujian perangkat lunak, seperti arsitektur layanan-orientirovannae (SOA), teknologi nirkabel, layanan mobile, dan sebagainya. E., Apakah membuka cara baru perangkat lunak pengujian. Beberapa perubahan yang diharapkan dalam industri selama beberapa tahun ke depan tercantum di bawah ini:
- penguji akan memberikan model ringan bahwa pengembang akan dapat memeriksa kode Anda;
- pengembangan metode pengujian, termasuk melihat dan pemodelan program pada tahap awal, akan menghilangkan banyak kontradiksi;
- Kehadiran beberapa tes interceptions akan mempersingkat waktu deteksi kesalahan;
- analyzer statis dan deteksi berarti akan lebih banyak digunakan;
- penggunaan matriks mineral, seperti cakupan dari spesifikasi, ruang lingkup cakupan Model dan kode akan menentukan perkembangan proyek;
- alat kombinasi memungkinkan penguji untuk menentukan bidang prioritas untuk debugging;
- penguji akan memberikan layanan yang lebih intuitif dan berharga selama proses pengembangan perangkat lunak;
- debugger dapat menciptakan alat dan metode pengujian perangkat lunak yang ditulis dalam dan berinteraksi dengan berbagai bahasa pemrograman;
- ahli debugging akan lebih profesional terlatih.
Akan digantikan oleh metode pengujian perangkat lunak berorientasi bisnis baru, untuk mengubah cara interaksi dengan sistem dan informasi yang mereka berikan sekaligus mengurangi risiko dan meningkatkan manfaat dari perubahan bisnis.
Similar articles
Trending Now