Software Testing dalam lingkup Software Engineering

Software Testing dibahas dalam buku Software Engineering Body of Knowledge Chapter 4. Bagan-bagan pembahasan dapat dilihat pada Gambar 1.

Rincian Topik pada Knowledge Area Software Testing

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.

China Airlines Flight 140

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 Pengujian

1.      Pengujian menunjukkan adanya cacat (defect)

2.      Pengujian menyeluruh tidak mungkin dilakukan

3.      Pengujian awal

4.      Defect clustering

5.      Pesticide paradox

6.      Pengujian tergantung pada konteks

7.      Tidak adanya kesalahan – kesalahan

 

Pengujian 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.

  • Dynamic (dinamis) : Istilah ini berarti bahwa pengujian selalu menyiratkan pelaksanaan program pada input yang dipilih. Tepatnya, nilai input saja tidak selalu cukup untuk menentukan sebuah tes, karena kompleks, sistem nondeterministik mungkin bereaksi terhadap input yang sama dengan perilaku yang berbeda, tergantung pada keadaan sistem. Dalam Knowledge Area Software Testing, bagaimanapun, istilah “input” akan dipertahankan, dengan konvensi tersirat bahwa maknanya juga mencakup keadaan input yang ditentukan dalam kasus-kasus yang menjadi hal penting. Teknik static (static techniques) berbeda dan saling melengkapi dengan pengujian dinamis (dynamic testing). Static techniques tercakup dalam Knowledge Area Software Quality. Perlu dicatat bahwa istilah itu tidak seragam di antara komunitas yang berbeda dan beberapa menggunakan istilah “testing” juga mengacu pada teknik statis (static techniques).
  • Finite (terbatas) : Bahkan dalam program sederhana, begitu banyak test case yang secara teoritis memungkinkan pengujian menyeluruh bisa memerlukan waktu berbulan-bulan atau bertahun-tahun untuk dieksekusi. Inilah sebabnya, dalam praktiknya, satu set tes yang lengkap umumnya dapat dianggap tidak tepat, dan pengujian dilakukan pada subset dari semua tes yang mungkin, yang ditentukan oleh kriteria risiko dan prioritas. Pengujian selalu menyiratkan antara sumber daya terbatas dan jadwal di satu sisi dan persyaratan pengujian yang tak terbatas secara inheren di sisi lain.
  • Selected (terpilih) : Banyak teknik pengujian yang diajukan berbeda secara mendasar dalam bagaimana rangkaian tes dipilih, dan software engineer harus sadar bahwa kriteria seleksi yang berbeda dapat menghasilkan tingkat efektivitas yang jauh berbeda. Bagaimana mengidentifikasi kriteria seleksi yang paling sesuai dengan kondisi yang ada adalah masalah yang kompleks. Dalam praktiknya, teknik analisis risiko dan keahlian rekayasa perangkat lunak diterapkan.
  • Expected (diharapkan) : Harus dimungkinkan, meski tidak selalu mudah, untuk memutuskan apakah hasil pengujian program yang teramati dapat diterima atau tidak. Jika tidak, upaya pengujian tidak ada gunanya. Perilaku yang diamati dapat diperiksa terhadap kebutuhan pengguna (biasanya disebut pengujian validasi), terhadap spesifikasi (pengujian verifcasi), atau, mungkin, terhadap perilaku yang diantisipasi dari persyaratan implisit atau harapan (dibahas dalam Knowledge Area Software Requirements bagian Acceptance Tests).

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:

  • Verifikasi dan validasi menemukan bug
  • Mendeteksi kesalahan (fault)
  • Membangun kepercayaan dalam perangkat lunak
  • Mengevaluasi sifat-sifat perangkat lunak (reliability, performance, memory usage, security, usability)

Fundamental Software Testing

Banyak 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:

  1. Test Selection Criteria / Test Adequacy Criteria (Stopping Rules)

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.

  1. Testing Effectiveness / Objectives for Testing

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.

  1. Testing for Defect Discovery

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.

  1. The Oracle Problem

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.

  1. Theoretical and Practical Limitations of Testing

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.

  1. The Problem of Infeasible Paths

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.

  1. Testability

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 Lainnya

Pengujian perangkat lunak juga berkaitan dengan kegiatan dan sudut pandang lainnya, diantaranya:

  • Testing vs. Static Software Quality Management Techniques (berkaitan dengan Knowledge Area Software Quality pada bagian Software Quality Management Techniques).
  • Testing vs. Correctness Proofs and Formal Verification (berkaitan dengan Knowledge Area Software Engineering Models and Methods).
  • Testing vs. Debugging (berkaitan dengan Knowledge Area Software Construction pada bagian Construction Testing dan Knowledge Area Computing Foundations pada bagian Debugging Tools and Techniques).
  • Testing vs. Program Construction (berkaitan dengan Knowledge Area Software Construction pada bagian Construction Testing).

Target Software Testing

Target 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 Testing

Unit 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 Testing

Integration 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 Testing

System 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 Pengujian

Pengujian 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:

  • Acceptance testing, berdasarkan requirement yang sudah disepakati di awal. Pengujian ini bertujuan menentukan kesepakatan dengan pengguna dalam menerima atau menolak perangkat lunak yang diberikan.
  • Installation testing, seringkali setelah menyelesaikan pengujian sistem dan penerimaan, perangkat lunak diverifikasi pada saat instalasi di lingkungan target. Installation testing dapat dilihat sebagai pengujian sistem yang dilakukan di lingkungan operasional konfigurasi perangkat keras dan kendala operasional lainnya. Prosedur instalasi juga bisa diverifikasi.
  • α / β testing, sebelum perangkat lunak rilis, kadang-kadang diberikan kepada sekelompok pengguna potensial yang dipilih untuk uji coba (alpha testing) dan / atau kumpulan perwakilan pengguna yang lebih besar (beta testing). Pengguna ini melaporkan masalah pada produk. Pengujian alfa dan beta seringkali tidak terkontrol dan tidak selalu disebut dalam rencana uji. Alpha (small groups), itu dilakukan oleh tim uji dalam organisasi yang mengembangkan perangkat lunak. Beta (larger groups), hal ini dilakukan oleh sekelompok pelanggan yang loyal terhadap perangkat lunak yang akan diujikan.
  • Reliability testing, pengujian meningkatkan reliability dengan mengidentifikasi dan memperbaiki fault. Selain itu, pengukuran statistik reliability dapat diturunkan dengan menghasilkan test case secara acak sesuai dengan profil operasional perangkat. Pendekatan terakhir disebut operational testing.
  • Regression testing, pengujian regresi adalah pengujian ulang selektif terhadap suatu sistem atau komponen untuk memverifikasi bahwa modifikasi tidak menimbulkan efek yang tidak diinginkan dan bahwa sistem atau komponennya masih sesuai dengan persyaratan yang ditentukannya. Dalam prakteknya, pendekatannya adalah untuk menunjukkan bahwa perangkat lunak masih melewati tes yang telah lulus sebelumnya dalam rangkaian uji (sebenarnya, ini juga kadang-kadang disebut pengujian non regresi). Untuk pengembangan inkremental, tujuan pengujian regresi adalah untuk menunjukkan bahwa perilaku perangkat lunak tidak berubah oleh perubahan bertahap pada perangkat lunak, kecuali sejauh yang seharusnya. Dalam beberapa kasus, harus dilakukan antara jaminan yang diberikan oleh pengujian regresi setiap kali terjadi perubahan dan sumber daya yang dibutuhkan untuk melakukan tes regresi, yang dapat memakan waktu yang cukup lama karena banyaknya tes yang mungkin dilakukan. Pengujian regresi melibatkan pemilihan, pengurangan, dan atau prioritas suatu subset dari test case di test suite yang ada. Pengujian regresi dapat dilakukan pada masing-masing tingkat pengujian yang serta mungkin berlaku untuk pengujian fungsional dan nonfungsional.
  • Performance testing, memverifikasi bahwa perangkat lunak memenuhi persyaratan kinerja yang ditentukan dan menilai karakteristik kinerja, misalnya kapasitas dan waktu respon. Pengujian ini juga mengetahui seberapa cepat perangkat lunak dilakukan untuk memeriksa apakah sistem memenuhi persyaratan nonfungsional yang diidentifikasi dalam dokumen SRS. Teknik check & fine tune waktu respon sistem. Tujuannya di sini adalah untuk mengurangi waktu respons.
  • Security testing, pengujian keamanan difokuskan pada verifikasi bahwa perangkat lunak terlindungi dari serangan eksternal. Secara khusus, pengujian keamanan memverifikasi kerahasiaan, integritas, dan ketersediaan sistem dan datanya. Biasanya, pengujian keamanan mencakup verifikasi terhadap penyalahgunaan dan penyalahgunaan perangkat lunak atau sistem (pengujian negatif).
  • Stress testing, menguji perangkat lunak pada beban desain maksimum, dan juga di luarnya, dengan tujuan menentukan batas perilaku, dan untuk menguji mekanisme pertahanan dalam sistem kritis. Pengujian ini mengeksekusi perangkat lunak hingga ekstrem. Contohnya, kinerja sistem pada beban yang berbeda, yaitu jumlah orang yang mengakses sistem.
  • Differential testing, juga disebut back to back testing. IEEE/ISO/IEC Standar 24765 mendefinisikan pengujian back-to-back sebagai pengujian di mana dua atau lebih varian program dieksekusi dengan input yang sama, hasilnya akan dibandingkan, dan kesalahan dianalisis jika terjadi perbedaan.
  • Recovery testing, ditujukan untuk memverifikasi kemampuan perangkat lunak ketika restart setelah terjadi crash sistem atau “bencana” lainnya.
  • Interface testing, Interface defects terjadi pada sistem yang kompleks. Interface testing bertujuan untuk memverifikasi apakah antarmuka komponen benar untuk memberikan pertukaran data dan informasi kontrol yang benar. Biasanya test cases dihasilkan dari spesifikasi interface. Tujuan spesifik interface testing adalah untuk mensimulasikan penggunaan API (Application Programming Interface) oleh aplikasi pengguna akhir. Kegiatan ini melibatkan pembuatan parameter panggilan API, pengaturan kondisi lingkungan eksternal, dan defnisi data internal yang mempengaruhi API.
  • Configuration testing, Dalam kasus di mana perangkat lunak dibuat untuk melayani pengguna yang berbeda, pengujian konfigurasi memverifikasi perangkat lunak dengan konfigurasi yang ditentukan berbeda.
  • HCI testing, tugas utama usability dan human computer interaction testing adalah untuk mengevaluasi seberapa mudah bagi pengguna akhir untuk belajar dan menggunakan perangkat lunak. Secara umum, ini mungkin melibatkan pengujian fungsi perangkat lunak yang mendukung tugas pengguna, dokumentasi yang membantu pengguna, dan kemampuan sistem untuk pulih dari kesalahan pengguna (berkaitan dengan Knowledge Area Software Design pada bagian User Interface Design).

Teknik Pengujian Perangkat Lunak

Salah 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 Experience

1.1.1         Ad Hoc

Mungkin 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 Testing

Exploratory 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 Techniques

1.2.1         Equivalence Partitioning

Equivalence 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 Testing

Test 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 Analysis

Test 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 Testing

Pengujian 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 Techniques

1.3.1         Control Flow-Based Criteria

Cakupan 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 Criteria

Dalam 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 Testing

Meskipun 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 Techniques

Dengan 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 Guessing

Dalam 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 Testing

Mutan 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 Techniques

1.5.1         Operational Profile

Dalam 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 Heuristics

Prinsip 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 Techniques

Model 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 Tables

Tabel 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 Machines

Dengan memodelkan sebuah program sebagai mesin negara yang terbatas, tes dapat dipilih untuk mencakup keadaan dan transisi.

1.6.3         Formal Specifcations

Menyatakan 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 Models

Workflow 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 Application

Teknik di atas berlaku untuk semua jenis perangkat lunak. Teknik tambahan untuk derivasi dan eksekusi tes didasarkan pada sifat perangkat lunak yang diuji; sebagai contoh,

  • object-oriented software
  • component-based software
  • web-based software
  • concurrent programs
  • protocol-based software
  • real-time systems
  • safety-critical systems
  • service-oriented software
  • open-source software
  • embedded software

1.8   Selecting and Combining Techniques

1.8.1         Combining Functional and Structural

Teknik 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. Random

Test 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 Testing

Tingkat 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:

  • Acceptance testing berada di level client.
  • System testing berhubungan dengan level SRS.
  • Integration testing berhubungan dengan level desain.
  • Unit testing berhubungan dengan level pengkodingan.

Blackbox Testing dan Whitebox Testing

Berikut adalah beberapa penjelasan perbedaan blackbox testing dan whitebox testing.

Blackbox Testing

Whitebox Testing

  • Berfokus pada input yang diambil dan output yang dihasilkan
  • Berfokus pada pengembangan internal perangkat lunak
  • Tidak memerlukan pengetahuan mendalam tentang bahasa atau detail teknis apa pun
  • Memerlukan pengetahuan mendalam tentang teknik dan platform untuk membangun perangkat lunak
  • Pengujian pada high level (system testing dan acceptance testing)
  • Pengujian pada lower level (unit testing dan integration testing)
  • Memerlukan dokumen SRS
  • Memerlukan dokumen detail
  • Tidak harus memiliki pengetahuan bahasa
  • Harus memiliki pengetahuan bahasa

 

 

 

Software Test Life Cycle

Berlawanan 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 Analysis

selama 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:

  • Mengidentifikasi jenis tes yang akan dilakukan.
  • Mengumpulkan secara detail tentang prioritas dan fokus pengujian.
  • Menyiapkan Requirement Traceability Matrix (RTM).
  • Mengidentifikasi rincian lingkungan pengujian di mana pengujian seharusnya dilakukan.
  • analisis kelayakan otomatisasi (jika diperlukan).

Tahap requirement analysis ini menghasilkan RTM dan dokumen analisis kelayakan otomatisasi.

2.      Test Planning

Fase 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:

  • Persiapan dokumen rencana uji / strategi untuk berbagai jenis pengujian
  • Pemilihan alat uji
  • Estimasi upaya pengujian
  • Perencanaan sumber daya dan menentukan peran dan tanggung jawab
  • Kebutuhan pelatihan

Tahap test planning ini menghasilkan dokumen rencana uji / strategi dan dokumen estimasi upaya pengujian.

3.      Test Case Development

Tahap 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:

  • Membuat test case, skrip otomatisasi (jika ada)
  • Meninjau tes case dan skrip
  • Membuat data uji (jika uji lingkungan tersedia)

Tahap test case development ini menghasilkan test case/script dan test data.

4.      Test Environment Setup

Lingkungan 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:

  • Memahami arsitektur yang diperlukan, pengaturan environtment, dan menyiapkan daftar requirement perangkat keras dan perangkat lunak untuk Test Environtment.
  • Pengaturan test environment dan test data.
  • Lakukan smoke test dalam pembangunan.

Tahap test environment ini menghasilkan environment yang siap dengan pengaturan test data dan hasil smoke test.

5.      Test Execution

Selama 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:

  • Jalankan tes sesuai rencana
  • Dokumentasikan hasil tes, dan log cacat untuk kasus yang gagal
  • Petakan defect ke test case dalam RTM
  • Tes ulang perbaikan defect
  • Lacak defect yang akan ditutup

6.      Test Cycle Closure

Tim 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.

Kesimpulan

Agar 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.

Posted in Artikel and tagged , , , , , , , , , .

Leave a Reply

Your email address will not be published. Required fields are marked *