REKAYASA PERANGKAT LUNAK - PowerPoint

Document Sample
REKAYASA PERANGKAT LUNAK - PowerPoint Powered By Docstoc
					REKAYASA PERANGKAT
LUNAK

   STRATEGI PENGUJIAN
   PERANGKAT LUNAK
Pendekatan strategis ke pengujian perangkat lunak


   Sejumlah energi pengujian perangkat lunak telah diusulkan
   didalam literatur. Semua memberi pengembang perangkat
   lunak sebuah template untuk pengujian, dan semua memiliki
   karakteristik generik sebagai berikut:
1. Pengujian mulai pada tingkat-tingkat modul dan kerja
   “keluar” ke arah integrasi dari sistem yang berbasis komputer
2. Teknik pengujian yang berbeda sesuai pada titik waktu yang
   berbeda.
3. Pengujian dilakukan oleh pengembang perangkat lunak dan
   (untuk proyek yang besar) suatu kelompok independen.
4. Pengujian dan debugging merupakan aktifitas yang berbeda,
   tetapi debugging harus diakomodasi pada banyak strategi
   pengujian.
Validasi mengacu pada serangkaian aktivitas yang
berbeda yang memastikan bahwa perangkat lunak
yang dibangun dapat ditelusuri ke persyaratan
pelanggan.
Pencapaian Kualitas Perangkat Lunak


                     Kajian Teknik
                         Format


  Metode Rekayasa
                                      Pengukuran
   perangkat lunak

                       Kualitas

    Standar dan
      prosedur                        Pengujian

                         SCM
                          &
                         SQA
 Pengorganisasian Pengujian Perangkat Lunak

1. Sering ada sejumlah kesalahan konsepsi yang secara ironis dapat diduga berasal
dari Bahwa pengembang perangkat lunak tidak boleh melakukan pengujian sama
sekali;
Bahwa perangkat lunak harus “dilempar ke dinding” bagi orang asing yang akan
mengujinya habis-habisan.
Bahwa penguji terlibat dengan proyek hanya ketika langkah pengujian baru akan
dimulai.
Masing-masing dari pernyataan tersebut adalah salah.

2. ITG merupakan bagian dari tim proyek pengembang perangkat lunak dimana ia
terlibat selama spesifikasi proses dan tetap terlibat (merencanakan dan menentukan
prosedur pengujian) pada keseluruhan proyek besar.
Peran Kelompok Pengujian Independen (ITG) adalah untuk menghilangkan masalah
yang melekat sehubungan dengan diperbolehkannya pengembang menguji semua
yang telah dibangun.
ITG melapor kepada organisasi jaminan kualitas, sehingga tercapai tingkat
independensi yang tidak mungkin didapatkan bila dia menjadi bagian dari organisasi
pengembangan perangkat lunak.
1. ITG merupakan bagian dari tim proyek pengembang perangkat lunak
dimana ia terlibat selama spesifikasi proses dan tetap terlibat
(merencanakan dan menentukan prosedur pengujian) pada keseluruhan
proyek besar.

2. Peran Kelompok Pengujian Independen (ITG) adalah untuk
menghilangkan masalah yang melekat sehubungan dengan
diperbolehkannya pengembang menguji semua yang telah dibangun.

3. ITG melapor kepada organisasi jaminan kualitas, sehingga tercapai
tingkat independensi yang tidak mungkin didapatkan bila dia menjadi
bagian dari organisasi pengembangan perangkat lunak.
 Strategi Pengujian Perangkat Lunak




Rekayasa sistem
   Persyaratan
        Desain
         Kode
                                      Tes Unit
                                      Tes Integrasi

                                      Tes Validasi
                                      Tes sistem
Kriteria Pelengkapan Pengujian

         Dengan menggunakan pemodelan statistik dan teori realibilitas
perangkat lunak sebagai sebuah fungsi dari waktu eksekusi dapat
dikembangkan. Versi dari model kegagalan, yang disebut Logarithmic
Poisson execution-time model, memiliki bentuk:
                                      F(t) = (l/p) ln (l0pt+1)
  Dimana F(t) = jumlah komulatif kegagalan yang diharapkan terjadi
sekali perangkat lunak diuji pada suatu jumlah waktu eksekusi,t,
                     l0 = intensitas kegagalan yang diharapkan terjadi
sekali perangkat lunak diuji pada awal pengujian.
                     P  = reduksi eksponensial didalam intensitas
kegagalan karena kesalahan ditemukan perbaikan dilakukan.
   Intensitas kegagalan sesaat, l(t) dapat ditarik dengan mengambil
derivatif dari f(t),
                                      l(t) = l0/(l0pt+1)
                     Masalah-masalah Strategis

    Tom Gilb [GIL 95] menyatakan bahwa masalah-masalah berikut harus
    diselesaikan bila strategi pengujian perangkat lunakyang sukses akan
    diimplementasikan:
   Tentukan persyaratan produk dalam suatu cara yang dapat dikuantifikasi lebih
    jauh sebelum pengujian dimulai.
   Nyatakan sasaran pengujian secara eksplisit.
   Pahami para pemakai perangkat lunak dan kembangkan profil bagi masing-
    masing kategori pemakai.
   Kembangkan rencana pengujian yang menekankan “pengujian siklus cepat”
   Bangun perangkat lunak “robusi” yang didesain untuk menguji dirinya
    sendiri.
   Gunakan kajian teknis formal sebagai sebuah filter sebelum pengujian.
   Lakukan kajian teknis formal untuk memperkirakan strategi pengujian dan
    melakukan test case terhadap dirinya sendiri.
   Kembangkan pendekatan pengembangan yang kontinyu untuk proses
    pengujian.
Pengujian Unit
    Pertimbangan Pengujian Unit
Gambar 17.5 “pengujian unit”
                                 Ineterface
                            Struktur data lokal
       MODUL                   Kondisi batas
                             Jalur independen
                        Jalur penganan kesalahan




                                           Test case
                                            Test case
                                             Test case
                                              Test case
     Dibutuhkan pengujian aliran data pada interface modul sebelum
     beberapa pengujian lain diawali.


     Test case harus didesain untuk mengungkap
     kesalahan dengan kategori:

1.   Pengetikan yang tidak teratur dan tidak
     konsisten
2.   Inisialisasi yang salah atau niali-nilai default
3.   Nama variabel yang tidak benar
4.   Ttipe data yang tidak konsisten
5.   Underflow,overflow,dan pengecualian
     pengalmata
Kesalahan yang harus diungkap test case:
1.   Perbandingan tipe data yang berbeda
2.   Presedent atau operator logiak yang tidak benar
3.   Pengharapan akan persamaan bila precition error
     memuat persamaan yang tidak mungkin
4.   Perbandingan atau variabel yang tidak benar
5.   Penghentian loop yang tidak ada atau tidak teratur
6.   Kegagalan untuk keluar pada saat terjadi interasi
     divergen
7.   Variabel loop yang di modifikasi secara tidak
     teratur
Kesalahan potensial yang harus diuji bila
penanganan kesalahan dievaluasi:
1.   Deskripsi kesalahan tidak dapat dipahami
2.   Kesalahan yang dicatat tidak sesuai dengan
     kesalahan yang terjadi
3.   Kondisi kesalahan menyebabkan intevensi
     sistem sebelum penangan kesalahan
4.   Pemrosesan kondisi pengecualian yang tidak
     benar
5.   Defskripsi kesalahan tidak memberi cukup
     informasi untuk membantu penempatan
     penyebab kesalahan tersebut
Prosedur pengujian kesatuan

Gambar 17.6 “lingkungan pengujian unit”


                         Driver                   Interface;6
                                              Struktur data lokal
                                                 Kondisi batas
                                               Jalur independen
                                          Jalur penangan kesalahan
        Modul
        untuk
         di uji


                                          Test case
 Stub             Stub
  Pengujian Validasi
  Definisi yang sederhana : bahwa Validasi berhasil bila
  perangkat lunak berfugsi dengan cara yang dapat diharapkan
  secara bertanggung jawab oleh pelanggan

1. Kriteria pengujian Validasi:
 Kevalidan perangkat lunak dicapai melalui pengujian Black
    box yang memperlihatkan konformitas,dengan persyaratan:
 1. Rencana pengujian menguraikan kelas-kelas pengujian yang
    akan dilakukan.
 2. Prosedur pengujian menentukan test case (yang digunakan
    untuk mengungkap kesalahan dalam konformitas)
2. Kajian konfigurasi

   Tujuan kajian ini adalah untuk memastikan apakah semua
   elemen konfigurasi perangkat lunak telah di kembangkan
   dengan tepat ,dikatalog dan memiliki detail yang perlu untuk
   mendukung fase pemeliharaan dari siklus hidup perangkat
   lunak.


3. Pengujian alpha beta
  pengujian ini digunakan “untuk mengungkap kesalahan yang
  hanya ditemukan oleh pemakai akhir”
Pengujian Integrasi

   DEFINISI
    Pengujian integrasi adalah teknik sistematis
    untuk mengkonstruksi struktur program sambil
    melakukan pengujian untuk mengungkap
    kesalahan sehubungan dengan interfacing
   SASARAN
    Untuk mengambil modul yang dikenai
    pengujian unit dan membangun struktur
    program yang telah ditentukan oleh desain
Integrasi Top-Down

   Definisi
    pendekatan inkremental terhadap struktur
    program.
   Dalam integrasi Top-Down subordinat
    program terhadap modul kontrol utama
    digabungkan kedalam struktur dengan cara
    depth-first atau breadth-first
               M1




     M2        M3           M4




M5        M6   M7




M8

                    Integrasi Top-Down
Integrasi Botom-Up

 Pengujian integrasi botom-up memulai
 konstruksi dan pengujian dengan modul
 atomik (modul pada tingkat paling rendah
 pada struktur program)
Langkah-langkahb strategi Integrasi
bottom-up
   Modul tingkat rendah digabgkan kedalam
    cluster
   Driver (program kontrol untuk pengujian)
    ditulis untuk mengkoordinasi input dan output
    test case.
   Cluster diuji
   Driver diganti dengan cluster digabungkan
    dengan menggerakannya keatas didalam
    struktur program
     Integrasi Bottom-Up
             Mc


      Ma            Mb


D1          D2             D3
 PENGUJIAN REGRESI
DEFINISI :
•   Dalam konteks strategi pengujian integrasi adalah Eksekusi ulang dari
    beberapasubset yang telah dilakukan untuk memasyikan bahwa perubahan tidak
    menimbulkan efek samping yang tidak diharapkan.
•   Dalama konteks yang lebih luas adalah akivitas yang membantu memastikan
    bahwa perubahan (sehubungan dengan pengujian atau alasan-alasan lainnya)
    tidak menimbulkan tingkah laku yang tidak diharapkan atau kesalahan tambahan.

    Dalam pengujian regresi terdapat 3 kelas test case yang berbeda:
1.   Sampel representatif dari penngujian yang akan mengunakan semua fungsi
     perangkat lunak
2.   Pengujian tambahan yang berfokus pada fungsi-fungsi perangkat lunak yang
     mungkin dipengaruhi oleh perubahan tersebut.
3.   Pengujian yang berfokus pada komponen perangkat lunak yang telah diubah.
Tanggapan mengenai pengujian integrasi:

    Kerugian utama dari pendekatan Top-Down : kebutuhan akan stub dan sulitnya
     pengujian yang dapat berkaitan dengan stub (BE 184)
    Kerugian dari integrasi Botton up adalah : program dari sebuah entitas tidak ada
     sampai modul terakhir ditambah (MYE79)

     Pada saat pengujian integrasi dilakukan, penguji harus mengidentifikasi modul
     kritis. Dengan karakteristik sebagai berikut:
1.   Menekankan beberapa persyaratan perangkat lunak.
2.   Memilih tingkat kontrol yang tinggi
3.   Kompleks atau error prone (kompleksitas siklomatis dapat digunakan sebagai
     indikator)
4.   Memiliki persyaratan kinerja yang terbatas
Dokumentasi pengujian integrasi
  Rencana keseluruhan perangkat lunak dan deskripsi pengujian spesifik didokumn tasikan dalam spesifikasi
  pengujian, yang memilki komponen-komponen sbb:
  I.     Lingkup pengujian
  II.     Rencana pengujian
      A. Phase dan build pengujian
      B. Jadwal
      C. Perangkat lunak overhead
      D. Lingkungan dan Sumber daya
  III.    n Prosedur pengujian (deskripsi pengujian untuk n build pengujian)
      A. Urutan integrasi
        1. ujuan
        2. modul untuk di uji
      B. Pengujian unit untuk modul-modul dalam buld.
        1. deskripsi pengujian untuk n modul
        2. deskripsi perangkat lunak overhead
        3. hasil yang diharapkan
      C. Lingkungan pengujian
        1. peranti atau teknik khusus
        2. deskripsi perangkat lunak overhead
      D. Data test case
       E. Hasil yang diharapkan untuk n build
  IV.     Hasil pengujian sesungguhnya
  V.      Referensi
  VI.     Lampiran
Kriteria dan pengujian yang di implementasikan kedalam
spesifikasi pengujian:

   Integritas interface
    Dimana antarmuka internal dan eksternal diuji pada saat masing-masing
    modul (atau kluster) ditambahkan kedalam struktur.
   Validitas fungsional
    Pegujian yang didisain untuk mengungkap kesalahan fungsional yang
    dilakukan
   Isi informasi
    pengujian yang didesain untuk mengungkap kesalahan yang berhubungan
    dengan struktur data global atau lokal yang dilakukan
   Kinerja
    Pengujian yang didesain untuk memeriksa batasan kinerja yang dibangun selama
    desain perangkat lunak dilakukan.
              Pengujian Sistem

   Pengujian Perbaikan
   Pengujian Keamanan
   Pengujian Stress
   Pengujian kinerja
       Pengujian perbaikan


Pengujian yang memaksa perangkat lunak
untuk gagal dalam berbagai cara dan
memaksa perbaikan itu dilakukan dengan
tepat
         Pengujian keamanan

Pengujian keamanan berusaha
membuktikan, apakah mekanisme
perlindungan yang dibangun pada sebuah
sistem dapat melindungi sisem dari penetrasi
yang tidak benar
           Pengujian stress

Pengujian stress didisain untuk melawan
program dalam keadaan abnormal
           Pengujian kinerja

Pengujian kinerja dilakukan untuk menguji
kinerja runtime dari perangkat lunak dalam
sistem yang terintegrasi
                Debugging

   Proses debugging
   Perkembangan Psikologis
   Pendekatan Debugging
                Proses debugging
   Gejala dan penyebab dapat jauh secara geografis
   Gejala dapat hilang ketika kesalahan yang lain
    dibetulkan
   Gejala dapat benar-benar disebabkan oleh suatu
    yang tidak salah
   Simton dapat disebabkan oleh kesalahan manusia
    yang tidak dapat dengan mudah ditelusuri
   Gejala dapat merupakan hasil dari masalah timing
   Kesulitan untuk memproduksi kondisi input secara
    akurat
   Gejala dapat berhubungan dengan penyabab yang
    didistribusikan melewati sejumlah tugas yang
    bekerja pada prosesor yang berbeda
        Pertimbangan psikologis
Menurut shneiderman
Debugging merupakan salah satu dari berbagai
pemrograman yang membuat lebih frustasi.
Debugging memiliki elemen pemecahan
masalah atau gangguan otak, yang bersama
dengan penghindaran kesadaran bahwa anda
melakukan kesalahan.
          Pendekatan Debugging


   Gaya yang kasar (brute force)
   Penelurusan balik (backtracking)
   Eliminasi penyebab

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1579
posted:4/22/2010
language:Indonesian
pages:35