Berikan penjelasan pemilihan software yang akan anda gunakan dalam melakukan simulasi komputer!
Software Testing dibahas dalam buku Software Engineering Body of Knowledge Chapter 4. Bagan-bagan pembahasan dapat dilihat pada Gambar 1. Show
Gambar 1 Rincian Topik pada Knowledge Area Software Testing Pengujian adalah proses yang digunakan untuk membantu mengidentifikasi kebenaran, kelengkapan dan kualitas perangkat lunak komputer yang dikembangkan. Pengujian perangkat lunak adalah menjalankan perangkat lunak dalam lingkungan simulasi atau nyata, menggunakan input yang dipilih dengan cara yang ditentukan. Dengan kata sederhana, pengujian perangkat lunak adalah kegiatan untuk memeriksa apakah sistem perangkat lunak bebas cacat. Pengujian pada perangkat lunak ini dimaksudkan untuk mendeteksi kesalahan sehingga produk dapat diperbaiki sebelum rilis ke pengguna akhir. Dalam istilah sederhana, pengujian perangkat lunak adalah kegiatan untuk melihat bahwa sistem perangkat lunak bebas dari cacat. Kasus perangkat lunak pada dasarnya terdiri dari tiga komponen, yaitu persyaratan masukan, persyaratan keluaran, dan sistem yang bersangkutan. Pengujian perangkat lunak sangatlah penting. Hal ini untuk menghindari resiko kegagalan yang ditimbulkan oleh perangkat lunak. Contoh kasus pada peristiwa kecelakaan pesawat. Penerbangan China Airlines Flight 140 pada 26 April 1994 yang lalu ini menjadi kecelekaan paling mematikan dalam sejarah penerbangan di China. Awalnya, pesawat berada dalam kondisi normal saat penerbangan sedang berlangsung, namun tak lama setelah take off, petugas mengalami kesalahan saat mengaktifkan tombol take off atau go around sebelum pesawat ini akan mendarat di Nagoya, Jepang. Akhirnya, pesawat ini jatuh dan setidaknya menelan 264 korban tewas dan 7 orang selamat dalam kecelakaan tragis ini. Contoh lain dari pentingnya pengujian perangkat lunak adalah pada mesin Therac-25 medical accelerator. Pengujian ini berkaitan dengan user interface dan human computer interaction. User interface yang jelek juga dapat mengakibatkan hilangnya nyawa manusia. Therac-25 merupakan mesin terapi radiasi untuk menghancurkan kanker pasien. Mesin ini mempunyai pemancar elektron dengan dua settingan: mode energi rendah, untuk pancaran elektron langsung ke pasien, dan mode energi tinggi yang pancarannya dihalangi oleh filter pembangkit X-ray. Masalahnya, rancangan sistem Therac-25 mempunyai race condition antara user interface dan kontroler pemancar. Jika operator memilih suatu mode, dan mesin memulai untuk mengatur ulang sistemnya, kemudian operator kembali memilih mode yang berbeda dalam interval 8 detik –yang sebenarnya digunakan oleh mesin untuk memindahkan magnet ketempat asalnya–, sehingga sistem akhirnya tidak dapat menerima settingan yang baru. Hasilnya, karena ingin cepat operator yang berpengalaman pun dapat dengan tidak berhati-hati memberikan overdosis kepada pasien dan beberapa pasien meninggal dunia. Selain itu, perangkat lunak yang digunakan pada alat ini mengalami bug yang serius. Bug merupakan kesalahan pada saat pelaksanaan perangkat lunak. Alat tersebut gagal berfungsi, bug pada software ini menyebabkan dosis radiasi yang meningkat hingga 10 kali lebih tinggi. Sehingga menyebabkan pasien keracunan radiasi. Tak hanya itu, beberapa pasien juga akhirnya kehilangan nyawa. Peristiwa lain juga dialami dalam dunia militer. Selama Operasi Desert Shield, militer AS menggunakan Sistem Rudal Patriot sebagai pertahanan terhadap pesawat terbang dan rudal, dalam hal ini rudal Irak Al Hussein (SCUD). Perangkat lunak pelacak untuk rudal Patriot menggunakan kecepatan targetnya dan waktu saat ini untuk memprediksi dari mana targetnya berasal dari satu instan ke instan lainnya. Karena berbagai target dapat berjalan dengan kecepatan hingga MACH 5, perhitungan ini harus sangat akurat. Pada saat itu, ada bug dalam perangkat lunak penargetan, artinya bahwa seiring berjalannya waktu, jam internal akan melayang lebih jauh dari waktu yang akurat, semakin lama sistem dibiarkan berjalan. Bug ini sebenarnya sudah diketahui dan hanya diperbaiki dengan reboot sistem secara teratur, dan dengan demikian mengatur ulang jam sistem. Sayangnya, mereka yang bertanggung jawab tidak mengerti dengan jelas bagaimana secara teratur mereka harus melakukan reboot sistem dan dibiarkan berjalan selama 100 jam. Ketika sebuah rudal Irak diluncurkan, yang ditargetkan ke sebuah lapangan terbang AS di Dhahran, Arab Saudi terdeteksi oleh sistem rudal Patriot. Namun, pada titik ini, jam internal melayang keluar sekira 0,34 detik, jadi ketika mencoba menghitung di mana rudal akan berada di depan, ia melihat area di langit lebih dari setengah kilometer dari lokasi rudal sebenarnya. Rudal tersebut akhirnya dibawa ke tempat tujuan, di mana ia telah membunuh 28 tentara dan melukai 98 tentara lainnya. Contoh lain lagi dari pentingnya pengujian perangkat lunak untuk menghindari bug yang muncul, dapat dilihat pada video berikut. Seperti yang Anda lihat, pengujian itu penting karena bug perangkat lunak bisa mahal atau bahkan berbahaya. Bug perangkat lunak berpotensi menyebabkan kerugian moneter dan manusia, sejarah penuh dengan contoh-contoh tersebut. Tujuh Prinsip PengujianPengujian perangkat lunak terdiri dari verifikasi dinamis bahwa sebuah program memberikan perilaku yang diharapkan pada sekumpulan test cases yang sesuai, yang dipilih secara sesuai dari domain eksekusi yang biasanya tidak terbatas.
Dalam beberapa tahun terakhir, pandangan pengujian perangkat lunak telah matang menjadi pendekatan yang konstruktif. Pengujian tidak lagi dilihat sebagai aktivitas yang dimulai hanya setelah tahap pengkodean selesai dengan tujuan terbatas mendeteksi kegagalan. Pengujian perangkat lunak, atau semestinya, meresap sepanjang siklus pengembangan dan maintenance keseluruhan. Memang, perencanaan untuk pengujian perangkat lunak harus dimulai dengan tahap awal dari proses persyaratan perangkat lunak, dan rencana dan prosedur pengujian harus secara sistematis dan terus dikembangkan– dan mungkin disempurnakan — Seiring pengembangan perangkat lunak. Kegiatan test planning dan tes designing ini memberikan masukan yang berguna bagi perancang perangkat lunak dan membantu menyoroti kelemahan potensial, seperti perbedaan / kontradiksi desain, atau kelalaian / ambiguitas dalam dokumentasi. Tujuan dari adanya software testing, antara lain:
Fundamental Software TestingBanyak istilah digunakan dalam literatur rekayasa perangkat lunak untuk menggambarkan malfungsi, terutama fault, failure, error, dan lainnya. Ada berbagai nama untuk kesalahan di tingkat yang berbeda. Error ditemukan pada level programmer/developer. Fault/bug ditemukan pada level testing. Failure (baik pada software maupun hardware) ditemukan pada level user/client. Defect adalah kecacatan dari spesifikasi produk yang dibangun. Defect ini ditimbulkan dari adanya kekeliruan (fault). Fault merupakan kesalahan pada sebuah baris kode atau lebih. Fault merupakan keadaan perangkat lunak yang disebabkan oleh kesalahan (error). Kesalahan bisa saja tidak tampak pada program dengan indikasi perangkat lunak bekerja sebagaimana harapan developer. Bahkan mungkin untuk waktu yang lama, sebuah baris program bisa saja tidak tersentuh oleh eksekusi sehingga tidak tampak sebagai kekeliruan. Hal yang akan muncul pada saat terjadi kekeliruan adalah kesalahan. Ini adalah tindakan manusia yang menghasilkan hasil yang salah yang menghasilkan kesalahan. Bila kekeliruan dalam baris dieksekusi, perangkat lunak akan melakukan operasi yang tidak sesuai dengan keinginan pengembang sehingga menghasilkan respons yang salah. Kesalahan (error) ini dapat mengakibatkan kegagalan (failure). Failure merupakan penyimpangan perangkat lunak dari hasil yang diharapkan. Hal tersebut merupakan sebuah kejadian. Dalam beberapa kasus, kekeliruan akan muncul sebagai kegagalan. Kegagalan perangkat lunak merupakan sederetan ketidakmampuan perangkat lunak untuk menjalankan fungsinya. Misalnya kesalahan keluaran perangkat lunak, proses eksekusi yang tidak normal, waktu eksekusi dan kapasitas penyimpanan yang membengkak, dan lain sebagainya. Masalah kunci dalam software testing, antara lain:
Test selection criterion adalah alat untuk memilih test case atau menentukan bahwa satu set test case cukup untuk tujuan yang ditentukan. Test adequacy criteria dapat digunakan untuk menentukan kapan pengujian yang cukup akan dilakukan, atau telah selesai.
Testing effectiveness ditentukan dengan menganalisis serangkaian eksekusi program. Pemilihan pengujian yang akan dijalankan dapat dipandu oleh tujuan yang berbeda, hanya berdasarkan tujuan yang ingin dicapai bahwa keefektifan rangkaian pengujian dapat dievaluasi.
Dalam pengujian untuk penemuan defect, pengujian yang berhasil adalah salah satu yang menyebabkan sistem gagal. Ini sangat berbeda dari pengujian untuk menunjukkan bahwa perangkat lunak tersebut memenuhi spesifikasi atau sifat yang diinginkan lainnya, dalam hal ini pengujian berhasil jika tidak ada kegagalan yang diamati pada uji kasus yang realistis dan lingkungan uji. Oracle adalah agen manusia atau mekanik yang menentukan apakah suatu program berperilaku benar dalam suatu pengujian dan karenanya menghasilkan sebuah keputusan “pass” atau “fail”. Ada banyak jenis oracle, misalnya, spesifikasi persyaratan yang tidak jelas, model perilaku, dan anotasi kode. Otomatisasi oracle mekanis bisa sulit dan mahal.
Teori pengujian memperingatkan untuk tidak memasukkan tingkat kepercayaan yang tidak dapat dibenarkan ke serangkaian pengujian. Sayangnya, hasil pengujian teori yang paling mapan adalah yang negatif, karena mereka menyatakan pengujian apa yang tidak dapat dicapai dibandingkan dengan apa yang sebenarnya dicapai. Kutipan yang paling terkenal dalam hal ini adalah pepatah Dijkstra bahwa “pengujian program dapat digunakan untuk menunjukkan adanya bug, namun tidak pernah menunjukkan ketidakhadiran mereka”. Alasan yang jelas untuk ini adalah bahwa pengujian yang lengkap tidak layak dilakukan dalam perangkat lunak yang realistis. Karena itu, pengujian harus didorong berdasarkan risiko dan dapat dilihat sebagai strategi manajemen risiko.
Infeasible paths adalah control flow paths yang tidak dapat dilakukan dengan data masukan apapun. Hal ini adalah masalah yang signifikan dalam pengujian berbasis path, terutama dalam derivasi otomatis input uji untuk mengendalikan jalur aliran kontrol. Istilah ” software testability ” memiliki dua arti yang saling terkait namun berbeda, yakni di satu sisi, ini mengacu pada kemudahan kriteria cakupan yang diberikan dapat memuaskan. Di sisi lain, ia dikalahkan sebagai kemungkinan, mungkin diukur secara statistik, bahwa satu set kasus uji akan menunjukkan kegagalan jika perangkat lunak tersebut rusak. Kedua arti itu penting. Keterkaitan Pengujian dengan Kegiatan LainnyaPengujian perangkat lunak juga berkaitan dengan kegiatan dan sudut pandang lainnya, diantaranya:
Target Software TestingTarget pengujian dapat bervariasi: modul tunggal, sekelompok modul (terkait dengan tujuan, penggunaan, perilaku, atau struktur), atau keseluruhan sistem. Tiga tahap uji dapat dibedakan: unit, integrasi, dan sistem. Ketiga tahap uji ini tidak menyiratkan model proses apapun, dan juga salah satu dari mereka dianggap lebih penting daripada dua lainnya. Unit TestingUnit testing memverifikasi fungsi dalam isolasi elemen perangkat lunak yang dapat diuji secara terpisah. Bergantung pada konteksnya, ini bisa menjadi subprogram individu atau komponen yang lebih besar yang terbuat dari unit yang sangat kohesif. Biasanya, unit testing terjadi dengan mengakses ke kode yang sedang diuji dan dengan dukungan alat debugging. Unit testing dilakukan oleh developer sebelum ditangani oleh software tester. Integration TestingIntegration testing adalah proses verifikasi interaksi antar komponen perangkat lunak. Strategi integration testing klasik, seperti topdown dan bottom-up, sering digunakan dengan perangkat lunak terstruktur secara hierarkis. Saat ini, systematic integration strategies biasanya berbasis arsitektur, yang melibatkan integrasi komponen perangkat lunak atau subsistem secara bertahap berdasarkan benang fungsional yang dapat dikenali. Integration testing sering merupakan kegiatan yang sedang berlangsung pada setiap tahap pengembangan selama software engineering menghapus sudut pandang tingkat rendah dan berkonsentrasi pada perspektif tingkat di mana mereka mengintegrasikan. Untuk perangkat lunak kecil dan sederhana, strategi pengujian integrasi tambahan biasanya lebih disukai untuk meletakkan semua komponen sekaligus– Yang sering disebut “big bang” testing. System TestingSystem testing berkaitan dengan pengujian perilaku keseluruhan sistem. Pengujian unit dan integrasi yang efektif akan mengidentifikasi banyak defect perangkat lunak. System testing biasanya dianggap tepat untuk menilai persyaratan sistem nonfungsional—seperti security, speed, accuracy, dan reliability (berkaitan dengan Knowledge Area Software Requirement pada bagian Functional and Non-Functional Requirements dan Knowledge Area Software Quality pada bagian Software Quality Requirements). Antarmuka eksternal ke aplikasi lain, utilitas, perangkat keras, atau lingkungan operasi juga biasanya dievaluasi pada tingkat ini. Contoh jenis system testing antara lain alpha testing, beta testing, acceptance testing, performance testing. Tujuan PengujianPengujian bertujuan untuk menemukan sebanyak mungkin kesalahan (atau bug) dalam produk yang diberikan. Peragakan produk perangkat lunak yang diberikan yang cocok dengan spesifikasi kebutuhannya. Validasi kualitas pengujian perangkat lunak menggunakan biaya dan upaya minimum. Buat kasus uji kualitas tinggi, lakukan tes efektif, dan keluarkan laporan masalah yang benar dan bermanfaat. Jenis-jenis software testing antara lain:
Teknik Pengujian Perangkat LunakSalah satu tujuan pengujian adalah mendeteksi sebanyak mungkin kegagalan. Banyak teknik telah dikembangkan untuk melakukan ini. Teknik-teknik ini berusaha untuk “memecahkan” sebuah program dengan bersikap seakurat mungkin dalam mengidentifikasi masukan yang akan menghasilkan perilaku program yang representative. Misalnya, dengan mempertimbangkan subclass dari domain input, skenario, keadaan, dan aliran data. Klasifikasi teknik pengujian yang dipaparkan di sini didasarkan pada bagaimana tes dihasilkan: dari intuisi dan pengalaman software engineer, spesifikasi, struktur kode, kesalahan nyata atau bayangan yang dapat ditemukan, prediksi penggunaan, model, atau sifat dari aplikasi. Satu kategori berhubungan dengan penggunaan gabungan dua teknik atau lebih. Terkadang teknik ini digolongkan sebagai white-box (disebut juga glass-box), jika tes didasarkan pada informasi tentang bagaimana perangkat lunak telah dirancang atau dikodekan, atau sebagai black-box jika kasus uji hanya bergantung pada input / output perilaku perangkat lunak. Daftar berikut mencakup teknik pengujian yang umum digunakan, namun beberapa praktisi mengandalkan beberapa teknik lebih banyak daripada yang lain. 1.1 Based on the Software Engineer’s Intuition and Experience1.1.1 Ad HocMungkin teknik yang paling banyak dipraktikkan adalah pengujian ad hoc: pengujian diturunkan bergantung pada keahlian, intuisi, dan pengalaman software engineer dengan program serupa. Pengujian ad hoc dapat berguna untuk mengidentifikasi test case yang tidak mudah dihasilkan dengan teknik yang lebih formal. 1.1.2 Exploratory TestingExploratory testing didefinisikan sebagai simultaneous learning, test design, dan test execution. Artinya, tes tidak didefinisikan sebelumnya dalam test plan yang telah ditetapkan, namun secara dinamis ditetapkan, dijalankan, dan dimodifikasi. Efektivitas exploratory testing bergantung pada pengetahuan software engineer, yang dapat diturunkan dari berbagai sumber: perilaku produk yang diamati selama pengujian, keakraban dengan aplikasi, platform, proses kegagalan, jenis kemungkinan kesalahan dan kegagalan, risiko yang terkait dengan produk tertentu, dan sebagainya. 1.2 Input Domain-Based Techniques1.2.1 Equivalence PartitioningEquivalence partitioning melibatkan pembagian domain input ke dalam kumpulan himpunan bagian (atau setara kelas) berdasarkan kriteria atau relasi yang ditentukan. Kriteria atau relasi ini mungkin merupakan hasil komputasi yang berbeda, sebuah relasi yang didasarkan pada control flow atau data flow, atau perbedaan yang dibuat antara input yang valid yang diterima dan diproses oleh sistem dan masukan yang tidak benar, seperti nilai di luar jangkauan, yang tidak diterima dan harus menghasilkan pesan kesalahan atau melakukan pemrosesan kesalahan. Satu set tes perwakilan (kadang-kadang hanya satu) biasanya diambil dari masing-masing kelas kesetaraan. 1.2.2 Pairwise TestingTest case diturunkan dengan menggabungkan nilai menarik untuk setiap pasangan seperangkat variabel masukan alih-alih mempertimbangkan semua kemungkinan kombinasi. Pairwise testing termasuk pengujian kombinatorial, yang pada umumnya juga mencakup kombinasi tingkat yang lebih tinggi daripada pasangan: teknik ini disebut sebagai t-wise, di mana setiap kemungkinan kombinasi dari variabel input t dipertimbangkan. 1.2.3 Boundary-Value AnalysisTest case dipilih pada atau di dekat batas domain masukan variabel, dengan dasar pemikiran bahwa banyak kesalahan cenderung berkonsentrasi di dekat nilai input yang ekstrem. Perpanjangan teknik ini adalah robustness testing, dimana test case juga dipilih di luar domain input variabel untuk menguji ketahanan program dalam memproses input yang tidak diharapkan atau salah. 1.2.4 Random TestingPengujian dilakukan secara acak (jangan sampai bingung dengan statistical testing dari kalangan operasional). Bentuk pengujian ini berada di bawah judul pengujian domain masukan karena domain masukan harus diketahui agar dapat memilih titik acak di dalamnya. Random testing memberikan pendekatan yang relatif sederhana untuk otomasi uji. Baru-baru ini, bentuk random testing yang disempurnakan telah diajukan di mana pengambilan sampel acak diarahkan oleh kriteria seleksi masukan lainnya. Fuzz testing atau fuzzing adalah bentuk khusus dari random testing yang bertujuan untuk memecahkan perangkat lunak. Hal ini paling sering digunakan untuk pengujian keamanan. 1.3 Code-Based Techniques1.3.1 Control Flow-Based CriteriaCakupan kriteria Control flow-based ditujukan untuk mencakup semua pernyataan, blok pernyataan, atau kombinasi pernyataan yang ditentukan dalam sebuah program. Kriteria terkuat dari control flowbased didasarkan pada path testing, yang bertujuan untuk melaksanakan semua entry-to-exit control flow paths ke dalam aliran grafik kontrol program. Karena path testing yang meluas umumnya tidak memungkinkan karena adanya loop, kriteria yang kurang ketat lainnya difokuskan pada cakupan jalur yang membatasi iterasi loop seperti cakupan pernyataan, cakupan cabang, dan pengujian kondisi / keputusan. Kecukupan tes semacam itu diukur dalam persentase; Sebagai contoh, ketika semua cabang telah dieksekusi setidaknya sekali oleh tes, cakupan cabang 100% telah tercapai. 1.3.2 Data Flow-Based CriteriaDalam data flow-based testing, grafik control flow diberi catatan dengan informasi tentang bagaimana variabel program didefinisikan, digunakan, dan dibunuh (tanpa didefinisikan). Kriteria terkuat, semua jalur penggunaan definisi, mensyaratkan bahwa, untuk setiap variabel, setiap segmen jalan aliran kontrol dari defnisi variabel tersebut sampai penggunaan defnisi tersebut dijalankan. Untuk mengurangi jumlah jalur yang dibutuhkan, strategi yang lebih lemah seperti semua definisi dan penggunaan semua digunakan. 1.3.3 Reference Models for Code-Based TestingMeskipun bukan teknik tersendiri, struktur kontrol suatu program dapat digambarkan secara grafis menggunakan grafik aliran untuk memvisualisasikan teknik pengujian berbasis kode. Grafik arus adalah grafik yang diarahkan, simpul dan busur yang sesuai dengan elemen program (berkaitan dengan Knowledge Area Mathematical Foundations pada bagian Graphs and Trees). Misalnya, node dapat mewakili pernyataan atau urutan pernyataan yang tidak terputus, dan busur dapat mewakili transfer kontrol antar node. 1.4 Fault-Based TechniquesDengan tingkat formalisasi yang berbeda, teknik fault-based testing merancang test case yang secara khusus ditujukan untuk mengungkapkan kategori kesalahan yang mungkin atau telah ditentukan sebelumnya. Untuk lebih memfokuskan pada generasi test case atau seleksi, model kesalahan dapat dikenalkan yang mengklasifikasikan berbagai jenis kesalahan. 1.4.1 Error GuessingDalam error guessing, test case secara khusus dirancang oleh software engineer yang mencoba mengantisipasi kesalahan yang paling masuk akal dalam program tertentu. Sumber informasi yang baik adalah sejarah kesalahan yang ditemukan pada proyek sebelumnya, serta keahlian software engineer. 1.4.2 Mutation TestingMutan adalah versi modifikasi sedikit dari program yang diuji, berbeda dengan perubahan sintaksis kecil. Setiap test case melakukan latihan baik program asli maupun semua mutan yang dihasilkan: Jika test case berhasil mengidentifikasi perbedaan antara program dan mutan, yang terakhir dikatakan “dibunuh”. Awalnya dipahami sebagai teknik untuk mengevaluasi set tes, mutation testing juga merupakan kriteria pengujian tersendiri, baik tes secara acak dihasilkan sampai cukup mutan telah dibunuh, atau tes secara khusus dirancang untuk membunuh mutan yang masih hidup. Dalam kasus terakhir, mutation testing juga dapat dikategorikan sebagai teknik berbasis kode. Asumsi yang mendasari pengujian mutasi, efek kopling adalah bahwa dengan mencari kesalahan sintaksis sederhana, kesalahan yang lebih kompleks namun nyata akan ditemukan. Agar teknik ini efektif, sejumlah besar mutan harus secara otomatis dihasilkan dan dieksekusi secara sistematis. 1.5 Usage-Based Techniques1.5.1 Operational ProfileDalam pengujian untuk evaluasi keandalan (juga disebut operational testing), lingkungan uji mereproduksi lingkungan operasional perangkat lunak, atau profil operasional, semaksimal mungkin. Tujuannya untuk menyimpulkan dari hasil uji yang teramati keandalan masa depan perangkat lunak saat di gunakan sebenarnya. Untuk melakukan ini, masukan diberikan probabilitas, atau profile, sesuai dengan frekuensi kejadiannya dalam operasi sebenarnya. Profil operasional dapat digunakan selama pengujian sistem untuk memandu derivasi kasus uji yang akan menilai pencapaian tujuan keandalan dan penggunaan relatif latihan dan kekritisan fungsi yang berbeda yang serupa dengan yang akan dihadapi di lingkungan operasional. 1.5.2 User Observation HeuristicsPrinsip usability dapat memberikan panduan untuk menemukan masalah dalam perancangan antarmuka pengguna (berkaitan dengan Knowledge Area Software Design pada bagian User Interface Design). Heuristik khusus, juga disebut metode usability inspection, diterapkan untuk pengamatan sistematis terhadap penggunaan sistem dalam kondisi terkendali untuk menentukan seberapa baik orang dapat menggunakan sistem dan antarmukanya. Usability heuristics meliputi walkthrough kognitif, analisis klaim, observasi field, berpikir keras, dan bahkan pendekatan tidak langsung seperti kuesioner pengguna dan wawancara. 1.6 Model-Based Testing TechniquesModel dalam konteks ini adalah representasi abstrak (formal) dari perangkat lunak yang diuji atau persyaratan perangkat lunaknya (berkaitan dengan Knowledge Area Software Engineering Models and Methods pada bagian Modeling). Model-based testing digunakan untuk memvalidasi persyaratan, memeriksa konsistensi mereka, dan menghasilkan test case yang berfokus pada aspek perilaku perangkat lunak. Komponen kunci dari model-based testing adalah: Notasi yang digunakan untuk mewakili model perangkat lunak atau persyaratannya; Model workflow atau model serupa; Strategi tes atau algoritma yang digunakan untuk pembuatan test case; Infrastruktur pendukung untuk eksekusi tes; Dan evaluasi hasil test dibandingkan dengan hasil yang diharapkan. Karena kompleksitas teknik, pendekatan model-based testing sering digunakan bersamaan dengan penggunaan uji otomasi. Teknik Model-based testing meliputi hal-hal berikut. 1.6.1 Decision TablesTabel keputusan mewakili hubungan logis antara kondisi (kira-kira, input) dan aksi (kira-kira, keluaran). Test case secara sistematis diturunkan dengan mempertimbangkan setiap kemungkinan kombinasi kondisi dan tindakan resultannya yang sesuai. Teknik yang terkait adalah cause-effect graphing. 1.6.2 Finite-State MachinesDengan memodelkan sebuah program sebagai mesin negara yang terbatas, tes dapat dipilih untuk mencakup keadaan dan transisi. 1.6.3 Formal SpecifcationsMenyatakan spesifikasi dalam bahasa formal (berkaitan dengan Knowledge Area Software Engineering Models and Methods pada bagian Formal Methods) memungkinkan derivasi otomatis test case fungsional, dan pada saat bersamaan, menyediakan nubuat untuk memeriksa hasil tes. TTCN3 (Testing and Test Control Notation version 3) adalah sebuah bahasa yang dikembangkan untuk menulis test case. Notasi tersebut disusun untuk kebutuhan spesifik dalam menguji sistem telekomunikasi, sehingga sangat sesuai untuk menguji protokol komunikasi yang kompleks. 1.6.4 Workflow ModelsWorkflow models menentukan urutan aktivitas yang dilakukan oleh manusia dan atau aplikasi perangkat lunak, biasanya diwakili melalui notasi grafis. Setiap urutan aksi merupakan satu worksflow (juga disebut skenario). tipe dan alternative workflow harus diuji. Fokus khusus pada peran dalam spesifikasi workflow ditargetkan dalam business process testing. 1.7 Techniques Based on the Nature of the ApplicationTeknik di atas berlaku untuk semua jenis perangkat lunak. Teknik tambahan untuk derivasi dan eksekusi tes didasarkan pada sifat perangkat lunak yang diuji; sebagai contoh,
1.8 Selecting and Combining Techniques1.8.1 Combining Functional and StructuralTeknik tes Model-based dan code-based sering dikontraskan sebagai pengujian fungsional vs. structural. Kedua pendekatan untuk menguji seleksi ini tidak dipandang sebagai alternatif, melainkan sebagai pelengkap; Sebenarnya, mereka menggunakan sumber informasi yang berbeda dan telah terbukti menyoroti berbagai jenis masalah. Mereka bisa digunakan dalam kombinasi, tergantung pada pertimbangan anggaran. 1.8.2 Deterministic vs. RandomTest case dapat dipilih secara deterministik, sesuai dengan salah satu dari banyak teknik, atau secara acak ditarik dari beberapa distribusi input, seperti biasanya dilakukan dalam pengujian reliabilitas. Beberapa perbandingan analitis dan empiris telah dilakukan untuk menganalisis kondisi yang membuat pendekatan lebih efektif daripada yang lain. Level Software TestingTingkat pengujian perangkat lunak pada dasarnya melibatkan berbagai tingkat perangkat lunak yang memerlukan pengujian untuk menemukan kesalahan pada tingkat yang dituju, sebagai contoh functional testing berikut:
Blackbox Testing dan Whitebox TestingBerikut adalah beberapa penjelasan perbedaan blackbox testing dan whitebox testing.
Software Test Life CycleBerlawanan dengan kepercayaan populer, Pengujian Perangkat Lunak bukan hanya aktivitas tunggal. Kegiatan ini terdiri dari serangkaian kegiatan yang dilakukan secara metodologis untuk membantu mengesahkan produk perangkat lunak Anda. Kegiatan-kegiatan ini (tahapan) merupakan Software Test Life Cycle (STLC). Gambar 2 menunjukkan contoh model pengujian yaitu V-Model of Testing. Model pengujian yang lainnya pun banyak, menyesuaikan pada model pengembangan perangkat lunak yang digunakan. Gambar 2 Flow V-Model of Testing 1. Requirement Analysisselama fase ini, tim uji mempelajari requirement dari sudut pandang pengujian untuk mengidentifikasi requirement yang dapat diuji. Tim QA dapat berinteraksi dengan berbagai pemangku kepentingan (Client, Business Analyst, Technical Leads, System Architects, dll) untuk memahami requirement secara terperinci. Requirement dapat berupa Fungsional (menentukan apa yang harus dilakukan perangkat lunak) atau Non Fungsional (mendefinisikan kinerja sistem / ketersediaan keamanan). Kelayakan otomatisasi untuk proyek pengujian yang diberikan juga dilakukan pada tahap ini. Aktivitas yang dilakukan pada tahap requirement analysis antara lain:
Tahap requirement analysis ini menghasilkan RTM dan dokumen analisis kelayakan otomatisasi. 2. Test PlanningFase ini juga disebut fase Strategi Tes. Biasanya, dalam tahap ini, seorang manajer senior QA akan menentukan perkiraan upaya dan biaya untuk proyek dan akan menyiapkan dan menyelesaikan Rencana Tes. Aktivitas yang dilakukan pada tahap requirement analysis antara lain:
Tahap test planning ini menghasilkan dokumen rencana uji / strategi dan dokumen estimasi upaya pengujian. 3. Test Case DevelopmentTahap ini melibatkan pembuatan, verifikasi, dan pengerjaan ulang kasus uji dan skrip pengujian. Data uji, diidentifikasi / dibuat dan ditinjau dan kemudian dikerjakan ulang juga. Aktivitas yang dilakukan pada tahap test case development antara lain:
Tahap test case development ini menghasilkan test case/script dan test data. 4. Test Environment SetupLingkungan pengujian menentukan kondisi perangkat lunak dan perangkat keras tempat work product diuji. Pengaturan lingkungan pengujian adalah salah satu aspek penting dari proses pengujian dan dapat dilakukan secara paralel dengan Tahap Pengembangan Test Case. Tim uji mungkin tidak terlibat dalam kegiatan ini jika pelanggan / tim pengembangan menyediakan lingkungan pengujian, dalam hal ini tim uji diminta untuk melakukan pemeriksaan kesiapan (smoke testing) dari lingkungan yang diberikan. Aktivitas yang dilakukan pada tahap test environment setup antara lain:
Tahap test environment ini menghasilkan environment yang siap dengan pengaturan test data dan hasil smoke test. 5. Test ExecutionSelama fase ini tim uji akan melakukan pengujian berdasarkan rencana pengujian dan kasus uji yang disiapkan. Bug akan dilaporkan kembali ke tim pengembangan untuk koreksi dan pengujian ulang akan dilakukan. Aktivitas yang dilakukan pada tahap test execution antara lain:
6. Test Cycle ClosureTim pengujian akan bertemu, membahas dan menganalisis artefak pengujian untuk mengidentifikasi strategi yang harus diterapkan di masa depan, mengambil pelajaran dari siklus pengujian saat ini. Idenya adalah untuk menghilangkan hambatan proses untuk siklus pengujian di masa depan. KesimpulanAgar hemat biaya, pengujian harus dikonsentrasikan pada area yang paling efektif. Tidak adanya kebijakan pengujian organisasi dapat mengakibatkan terlalu banyak usaha dan uang yang akan dihabiskan untuk pengujian, sehingga berusaha untuk mencapai tingkat kualitas yang tidak mungkin atau tidak perlu. Testing juga dipengaruhi oleh people, cost, organization, dan measure. office 365 kaufen |