Testing software terdiri dari dynamic verification dari behavior program pada uji kasus, sesuai yang dipilih dari domain eksekusi biasanya terbatas, terhadap perilaku yang diharapkan. Pengujian perangkat lunak terdiri dari subareas berikut:
1. Software Testing Fundamentals: Subarea ini mencakup definisi dasar di bidang software testing, masalah terminologi dan kunci dasar, dan hubungannya dengan kegiatan lain.
2. Test Levels: Subarea ini menjelaskan sasaran dari tes yang berisi daftar level di mana pengujian software besar secara tradisional dibagi dan tujuan pengujian yang mempertimbangkan pengujian untuk kondisi tertentu atau properti (sifat-sifat)
3. Test Techniques: Bagian ini menjelaskan berbagai teknik testing: didasarkan pada intuisi teknisi perangkat lunak dan pengalaman, teknik berbasis spesifikasi, teknik berbasis kode, teknik berbasis kesalahan pada fungsi, teknik berbasis penggunaan program, teknik didasarkan pada sifat dari aplikasi, kemudian memilih dan menggabungkan teknik
4. Test Related Measures: Uji-terkait evaluasi langkah-langkah dari program yang diuji dengan mengamati uji output, dituntut ketelitian dalam testing ini. Subarea ini menjelaskan tentang evaluasi program yang diuji, dan evaluasi tes performa.
5. Test Process: test proses mendukung kegiatan testing dan memberikan petunjuk untuk tim tester, dari perencanaan testing hingga evaluasi testing output, dilakukan beberapa hal untuk memberikan jaminan bahwa tujuan pengujian akan memenuhi efektifitas biaya. Hal-hal lain terhadap Test proses dibahas dalam subarea. Subarea ini menjelaskan tentang pertimbangan praktis dan gambaran singkat tentang kegiatan uji.
Tes yang berbeda dan saling melengkapi teknik statis, seperti yang dijelaskan dalam KA Kualitas Perangkat Lunak. Hingga: Bahkan dalam program yang sederhana, begitu banyak kasus uji secara teoritis mungkin bahwa pengujian mendalam bisa membutuhkan bulan atau tahun untuk mengeksekusi. Jadi dalam praktek set seluruh tes dapat dianggap sebagai tak terbatas. Pengujian selalu menyiratkan keseimbangan antara sumber daya yang terbatas dan jadwal di satu tangan dan persyaratan pengujian secara inheren terbatas pada yang lain. Terpilih: Teknik-teknik pengujian yang diusulkan banyak berbeda secara mendasar tentang cara untuk memilih test suite dan insinyur perangkat lunak harus menyadari bahwa kriteria seleksi yang berbeda dapat menghasilkan derajat yang sangat berbeda efektivitas. Bagaimana mengidentifikasi kriteria seleksi yang paling cocok dalam kondisi tertentu adalah masalah yang sangat kompleks, dalam prakteknya, menerapkan teknik analisis risiko dan menguji pengetahuan teknik. Diharapkan: Itu harus mungkin, meskipun tidak selalu mudah, untuk memutuskan apakah hasil yang diamati dari pelaksanaan program ini dapat diterima atau tidak, jika tidak upaya pengujian akan sia-sia. Perilaku yang diamati dapat diperiksa terhadap harapan pengguna (sering disebut sebagai pengujian untuk validasi), terhadap spesifikasi (pengujian untuk verifikasi), atau, akhirnya, dengan perilaku yang diantisipasi dari persyaratan implisit atau harapan yang wajar. Lihat, dalam Perangkat Lunak Persyaratan KA, topik Tes Penerimaan 6,4. Pandangan pengujian perangkat lunak telah berkembang menjadi lebih konstruktif. Pengujian tidak lagi dilihat sebagai suatu kegiatan yang dimulai setelah fase coding selesai, dengan tujuan terbatas kesalahan mendeteksi. Pengujian perangkat lunak adalah sekarang dilihat sebagai kegiatan yang harus mencakup pengembangan dan proses pemeliharaan dan merupakan bagian penting dari pembangunan yang sebenarnya dari produk itu sendiri. Bahkan, perencanaan tes harus dimulai sejak dini dalam proses persyaratan dan rencana uji dan prosedur harus dikembangkan secara sistematis dan terus menerus disempurnakan dan mungkin, sebagai akibat dari pembangunan. Ini perencanaan tes dan kegiatan desain sendiri merupakan masukan yang berguna bagi desainer untuk menyorot kelemahan potensial (seperti kelalaian desain atau kelalaian atau kontradiksi dan ambiguitas dalam dokumentasi). Saat ini dianggap sebagai sikap yang tepat terhadap kualitas adalah satu dari pencegahan: hal ini jelas jauh lebih baik untuk menghindari masalah untuk memperbaikinya. Pengujian Oleh karena itu harus dipertimbangkan terutama sebagai sarana untuk memeriksa tidak hanya jika pencegahan telah efektif, tetapi juga untuk mengidentifikasi kelemahan dalam kasus di mana, untuk beberapa alasan, tidak efektif. Hal ini mungkin jelas, tetapi layak mengakui, bahkan setelah selesainya kampanye ekstensif pengujian, perangkat lunak masih bisa mengandung kesalahan. Obat untuk kegagalan perangkat lunak yang berpengalaman setelah melahirkan disediakan oleh tindakan pemeliharaan korektif. Ini membahas masalah pemeliharaan software pada KA Pemeliharaan Software. Kualitas Perangkat Lunak Pada KA (lihat butir 3.3 Software manajemen kualitas teknik), teknik manajemen mutu di perangkat lunak tertentu diklasifikasikan menjadi teknik statis (tidak ada eksekusi kode) dan teknik dinamis (eksekusi kode). Kedua kategori berguna. KA ini difokuskan pada teknik dinamis. Software pengujian juga berkaitan dengan pembangunan perangkat lunak (lihat topik 3,4 Pengujian Konstruksi di KA itu). Unit dan pengujian integrasi sangat erat berkaitan dengan pembangunan perangkat lunak, jika tidak ada bagian dari itu. rincian topik 1. Software Testing Fundamentals 1.1. Testing-related terminology Sebuah pengantar yang komprehensif untuk pengujian perangkat lunak KA disediakan dalam referensi yang direkomendasikan. Banyak istilah yang digunakan dalam literatur rekayasa perangkat lunak untuk menggambarkan kerusakan, termasuk kesalahan, kelalaian, kesalahan, dan banyak lainnya. Terminologi ini tepat didefinisikan dalam IEEE 610,12-1.990, Standar Istilah Rekayasa Perangkat Lunak Terminologi (IEEE610-90) dan juga disebutkan dalam KA kualitas perangkat lunak. Hal ini penting untuk secara jelas membedakan penyebab kerusakan, yang kesalahan istilah atau cacat akan digunakan di sini, dan efek samping yang diamati dalam sistem pelayanan, yang akan disebut kegagalan. Pengujian dapat mengungkapkan kegagalan, tetapi kelemahan yang dapat dan harus dihapus. Namun, harus diakui bahwa penyebab kegagalan tidak selalu dapat diidentifikasi jelas. Tidak ada kriteria untuk menentukan teoritis pasti apa kesalahan yang disebabkan kerusakan yang diamati.
0 komentar:
Posting Komentar