Rabu, 01 November 2017

Faktor Pengujian Perangkat Lunak

Dalam pengujian perangkat lunak terdapat 15 faktor pengujian, akan tetapi tidak semua faktor yang mungkin digunakan, tergantung pada sistem apa yang akan diuji. Berikut faktor-faktor dalam pengujian perangkar lunak :

1.        Reability
Menekankan bahwa aplikasi akan dilaksanakan dalam fungsi sesuai yang diminta dalam periode waktu tertentu.
Faktor yang diuji :
a.     Menentukan toleransi.
b.    Desain control dan integritas data.
c.     Implementasi control dan integritas data.
d.    Pengujian regresi, pengujian manual dan pengujian fungsional.
e.     Verifikasi dan ketetapan dan kelengkapan instalasi.
f.     Update ketepatan kebutuhan.

2.        Authorization
Menjamin data di proses sesuai dengan kebutuhan manajemen. Authorisasi menyangkut proses transaksi secara umum yaitu otoritas bisnis dan secara khusus otoritas pelaksanaan tindakan khusus.
Faktor yang diuji :
a.     Identifikasi aturan otorisasi.
b.    Desain aturan otorisasi.
c.     Implementasi aturan otorisasi.
d.    Pengujian kesesuain.
e.     Mencegah perubahan data selama instalasi.
f.     Menjaga aturan otorisasi.

3.        File Integrity
Menekankan pada data yang dimasukkan melalui aplikasi agar tidak dapat diubah serta prosedur yang akan memastikan bahwa file yang digunakan benar dan data dalam file tersebut akan disimpan sequensial dan benar.
Faktor yang diuji :
a.     Identifikasi kebutuhan integritas file.
b.    Desain control dan integritas file.
c.     Implementasi control dan integritas file.
d.    Pengujian fungsional.
e.     Verifikasi integritas dari produksi file.
f.     Menjaga integritas file.

4.        Audit Trail
Menekankan pada kemampuan untuk mendukung proses yang terjadi. Pemrosesan data secara keseluruhan berdasarkan retensi/jumlah dari kejadian yang cukup mendukung keakuratan, kelengkapan, batasan waktu dan otorisasi data.
Faktor yang diuji :
a.     Identifikasi kebutuhan rekontruksi.
b.    Desain audit trail
c.     Implementasi audit trail
d.    Pengujian fungsional.
e.     Menyimpan audit trail selama instalasi.
f.     Update audit trail.
  
5.        Continuity of processing
Menekankan kemampuan untuk meneruskan proses, ketika terjadi suatu permasalahan dengan menetapkan prosedur yang diperlukan dan back-up informasi untuk melindungi operasi mungkin hilang karena masalah tersebut.
Faktor yang diuji :
a.     Identifikasi akibat dari kegagalan.
b.    Desain contingency plan.
c.     Menyusun contingency plan dan prosedurnya.
d.    Pengujian pemulihan.
e.     Memastikan integritas dari pengujian sebelumnya.
f.     Update contingency plan.

6.        Service Level
Menekankan bahwa hasil yang diinginkan didapat dalam waktu yang diinginkan oleh  user. Untuk mencapai keinginan tersebut, harus dilakukan penyesuaian antara keinginan user dengan sumber daya yang ada.
Faktor yang diuji :
a.     Identifikasi tingkat layanan yang diinginkan.
b.    Desain metode untuk mencapai tingkat layanan.
c.     Desain sistem untuk mencapai tingkat layanan.
d.    Pengujian beban lebih.
e.     Implementasi rencana pencegahan kegagalan instalasi.
f.     Menjaga tingkat layanan.

7.        Access control
Menekankan sumberdaya sistem harus dilindungi dari kemungkinan modifikasi, pengrusakan, penyalahgunaan dan prosedur keamanan harus dijalankan secara penuh untuk menjamin integritas data dan program aplikasi.
Faktor yang diuji :
a.     Identifikasi hak akses.
b.    Desain Prosedur akses.
c.     Implementasi prosedur keamanan.
d.    Pengujian kesesuaian.
e.     Kontrol akses selama instalasi.
f.     Menjaga keamanan.

8.        Metodology
Menekankan bahwa aplikasi dirancang sesuai dengan strategi organisasi, kebijaksanaan, prosedur dan standar.
Faktor yang diuji :
a.     Penyesuaian kebutuhan dengan metodology.
b.    Penyesuaian desain dengan metodology.
c.     Penyesuaian program dengan metodology.
d.    Penyesuaian pengujian dengan metodology.
e.     Penyesuaian integrasi dengan metodology.
f.     Penyesuaian perawatan dengan metodology.

9.        Correctness
Menjamin pada data dmasukkan, proses dan output yang dihasilkan dari aplikasi harus akurat dan lengkap.
Faktor yang diuji :
a.     Identifikasi spesifikasi fungsional.
b.    Penyesuaian desain dengan requitment.
c.     Penyesuain program dengan desain.
d.    Pengujian fungsional.
e.     Ketepatan penempatan program dan data pada produksi.
f.     Update kebutuhan.

10.    Ease of use
Menekankan perluasan usaha yang diminta untuk belajar, mengoperasikan dan menyiapkan inputan dan menginterprestasikan output dari sistem.
Faktor yang diuji :
a.     Identifikasi spesifikasi kegunaan.
b.    Desain penggunaan fasilitas.
c.     Penyesuaian program dengan desain.
d.    Pengujian dukungan panduan.
e.     Penyebaran kegunaan instruksi.
f.     Menjaga kemudahan penggunaan.

11.    Maintainable
Usaha yang diminta untuk mengalokasi dan memperbaiki suatu eror dalam pengoperasian sistem.
Faktor yang diuji :
a.     Identifikasi spesifikasi kegunaan.
b.    Desain dapat dirawat.
c.     Program dapat dirawat.
d.    Inspeksi.
e.     Kelengkapan dokumentasi.
f.     Menjaga kerawatan.

12.    Portable
Usaha yang diminta untuk mengirimkan program dari satu konfigurasi hardware dan atau lingkungan sistem software ke lingkungan yang lain.
Faktor yang diuji :
a.     Identifikasi kebutuhan protabilitas.
b.    Desain protabilitas.
c.     Penyesuaian program dengan esain.
d.    Disaster testing.
e.     Kelengkapan dokumentasi.
f.     Menjaga protabilitas.

13.    Coupling
Usaha yang diminta untuk menghubungkan komponen di dalam sistem aplikasi dan dengan sistem aplikasi yang lain dalam lingkungan pemrosesan.
Faktor yang diuji :
a.     Identifikasi antar muka system.
b.    Kelengkapan desain antarmuka.
c.     Penyesuaian program dengan desain.
d.    Pengujian fungsional dan regresi.
e.     Koordinasi antarmuka.
f.     Memastikan antarmuka yang benar.

14.    Performance
Jumlah perhitungan sumberdaya dan kode yang diminta sistem untuk melakukan fungsinya, termasuk ke dalamnya kerja maual dan otomatis.
Faktor yang diuji :
a.     Identifikasi kriteria performance.
b.    Kriteria pencapaian desain.
c.     Kriteria pencapaian program.
d.    Pengujian kesesuaian.
e.     Mengawasi performa instalasi.
f.     Menjaga tingkat performance.

15.    Ease of operations
Sejumlah usaha yang diminta untuk mengintegrasikan sistem ke dalam lingkungan operasi dan lingkungan sistem aplikasi, berupa prosedur manual dan otomatisasi.
Faktor yang diuji :
a.     Identifikasi kebutuhan operasional.
b.    Mengkomunikasikan kebutuhan pada operasi.
c.     Mengembangkan prosedur operasi.
       d.   Pengujian operasi.

Teknik Pengujian Perangkat Lunak

Sebenarnya teknik untuk pengujian perangkat lunak terdiri dari 3 jenis, yaitu :
  1. Blackbox Testing
  2. Whitebox Testing
  3. Greybox Texting
Namun diblog ini, penulis akan menjabarkan dari 3 jenis diatas. Monggo disimak....

     Blackbox Testing

          Pengujian blackbox berfokus pada persyaratan fungsional perangkat lunak. Pengujian blackbox memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang sepernuhnya menggunakan semua persyaratan fungsional untuk suatu program.
Pengujian blackbox berusaha menemukan kesalahan dalam kategori sebagai berikut:
  1. Fungsi-fungsi yang tidak benar atau hilang
  2. Kesalahan interface
  3. Kesalahan dalam struktur data atau akses database eksternal
  4. Kesalahan kinerja
  5. Inisialisasi dan kesalahan terminasi
          Pengujian blackbox berbeda dengan pengujian whitebox yang dilakukan pada awal proses pengujian, pengujian blackbox cenderung diaplikasikan pada tahap akhir pengujian. Mengapa dilakukan pada tahap akhir ? Karena pengujian blackbox memperhatikan struktur kontrol, maka perhatian berfokus pada domain informasi.

Langkah pertama pada pengujian blackbox yaitu :
  1. Menggunakan Metode Pengujian Graph-based
      Dalam metode ini yang terpenting adalah "memahami objek" yang dimodelkan didalam perangkat lunak dan hubungan yang akan menghubungkan objek tersebut. Pengujian perangkat lunak dimulai dengan membuat grafik dari objek-objek yang penting dan hubungan objek-objek serta kemudian memikirkan sederetan pengujian yang akan mencakup grafik tersebut sehingga masing-masing objek dan hubungan serta kesalahan dapat ditemukan.

      2. Menggunakan Metode Partisi Ekivalensi

       Partisi Ekivalensi adalah metode pengujian blackbox yang membagi domain input dari suatu program ke dalam kelas data dari mana test case dapat dilakukan. Partisi Ekivalensi berusaha menentukan sebuat test case yang mengungkap kelas-kelas kesalahan, sehingga mengurangi jumlah total test case yang harus dikembangkan.

       3. Menganalisis Nilai Batas

         Analisis nilai batas adalah teknik desain proses yang melengkapi partisi ekivalensi. Daripada memilih sembarang elemen kelas ekivalensi, BVA lebih mengarah kepada pemilih test case pada “edge” dari kelas. Daripada hanya berfokus pada kondisi input, BVA melakukan test case dari domain output.
         
       4. Pengujian Perbandingan

        Ada banyak situasi (seperti avionik pesawat udara) dimana reliabilitas perangkat lunaknya sangat kritis. Dalam aplikasi semacam itu, perangkat lunak dan perangkat keras redundan sering digunakan untuk meminimalkan kemungkinan kesalahan. Pada saat perangkat lunak redundan dikembangkan, tim rekayasa perangkat lunak yang terpisah mengembangkan versi-versi independen dari suatu aplikasi dengan menggunakan spesifikasi yang sama. Dalam situasi semacam itu, setiap versi dapat diuji dengan data uji yang sama untuk memastikan bahwa semua versi memberikan output yang identik. Kemudian semua versi dieksekusi secara paralel dnegan perbandingan real time hasil untuk memastikan konsistensi.

     Pengujian perbandingan tidaklah mudah. Bila spesifikasi dari mana semua fungsi telah dikembangkan mengandung kesalahan, maka semua versi kemungkinan besar merefleksikan kesalahan. Lagi pula jika masing-masing versi independen identik tetapi tidak benar, maka pengujian kondisi akan gagal mendeteksi kesalahan.

Berikut Keunggulan dan kekurangan Blackbox Testing :

Keunggulan
  • Black box testing dapat menguji keseluruhan fungsionalitas perangkat lunak.
  • Black box testing dapat memilih subset test yang secara efektif dan efisien dapat menemukan cacat. Dengan cara ini black box testing dapat membantu memaksimalkan testing investment.
Kekurangan
  • Ketika tester melakukan black box testing, tester tidak akan pernah yakin apakah perangkat lunak yang diuji telah benar-benar lolos pengujian.


     Whitebox Testing
     Pengujian white box, kadang-kadang disebut pengujian glass box, adalah metode desaintest case yang menggunakan struktur kontrol desain prosedural untuk memperoleh test case. Dengan menggunakan metode pengujian white box, perekayasa sistem dapat melakukan test case yang : 
  1. memberikan jaminan bahwa semua jalur independen pada suatu modal telah digunakan, paling tidak satu kali.
  2. Menggunakan semua keputusan logis pada sisi true dan false 
  3. Mengeksekusi semua loop pada batasan mereka dan baas operasional mereka 
  4. Menggunakan struktur data internal untuk menjamin validitasnya 
     Pada titik ini, dapat diajukan pertanyaan yang beralasan, yaitu “Mengapa menghabiskan waktu dan energi untuk menguji logika jika kita dapat dengan lebih baik memperluas kerja yang dapat memastikan bahwa persyaratan program telah dipenuhi ?” Bila dinyatakan dengan cara lain, mengapa kita tidak menggunakan semua energi kita untuk melakukan pengujian black box ? 

      Jawabannya ada pada sifat cacat perangkat lunak : 
  • Kesalahan logis dan asumsi yang tidak benar berbanding terbalik dengan probabilitas jalur program yang akan dieksekusi. Kesalahan cenderung muncul dalam kerja kita pada saat kita mendesain dan mengimplementasi fungsi, kondisi atau kontrol yang berada di luar mainstraim. Pemrosesan setiap hari cenderung dipahami dengan baik sementara pemrosesan “kasus khusus” cenderung berantakan.
  • Kita sering percaya bahwa jalur logis mungkin tidak akan diseksekusi bila pada kenyataannya akan diseksekusi pada basis reguler. Aliran logika dari suatu program kadangkadang bersifat konterintuitif yang berarti asumsi kita yang tidak kita sasari mengenai aliran dan data kontrol dapat menyebabkan kita membuat kesalahan desai yang akan terungkap hanya setelah pengujian jalur mulai.
  • Kesalahan tipografis adalah random. Bila sebuah program diterjemahkan ke dalam kode sumber bahasa pemrograman maka dimungkinkan akan terjadi banyak kesalahan pengetikan. Beberapa akan ditemukan dengan mekanisme pengecekan sintaks, tetapi yang lainnya akan tetap tidak terdeteksi sampai pengujian mulai.]
Masing-masing alasan tersebut memberikan suatu argurmen untuk melakukan pengujian white box. Pengujian black box, tidak peduli seberapa cermat dilakukan, dapat menangkap bentuk kesalahan tersebut. 

Berikut Keunggulan dan kekurangan Whitebox Testing:

Keunggulan
  • Kebenaran program dalam mendefinisikan algoritma dapat diketahui secara langsung dengan pengolahan path.
  • Menentukan kualitas pekerjaan coding dan pengaruhnya untuk standar coding.

Kekurangan
  • Jumlah biaya untuk white box testing lebih besar daripada biaya yang dibutuhkan untuk black box, untuk ukuran software yang sama.
  • Belum mampu melakukan tes ketersediaan, kehandalan, daya tahan beban dan testing – testing lain yang berhubungan dengan kebutuhan faktor – faktor untuk operasi, revisi dan transisi.

     Greybox Testing

    Adalah metode pengujian perangkat lunak yang adalah kombinasi dari Black box testing dan White box testing. Dalam Black box testing, struktur internal dari item yang sedang diuji tidak diketahui tester dan White box testing struktur internal di dikenal. Dalam pengujian Gray box testing, struktur internal sebagian dikenal. Ini melibatkan memiliki akses ke internal data struktur dan algoritma untuk tujuan merancang uji kasus, tetapi pengujian pada pengguna, atau tingkat Black box. Grey-box, berusaha menggabungkan kedua metode diatas, mengambil kelebihan keduanya, mengurangi kekurangan keduanya. Teknik verifikasi modern menerapkan combine-method ini.