TUGAS

REKAYASA PERANGKAT LUNAK

Strategi Pengujian Perangkat Lunak

OLEH :

I Wayan Widarma Eka Putra (1204505054)

I Putu Joddy Wira Ananta (1204505074)

I Made Mertha Prayuda (1204505079)

Kadek Aris Andhika Prahaditama (1204505086)

Hagi Semara Putra (1204505094)

TEKNOLOGI INFORMASI FAKULTAS TEKNIK

UNIVERSITAS UDAYANA

TH. AJARAN 2013 / 2014

BAB I

Pendahuluan

1.1 Latar Belakang

Pengujian adalah serangkaian aktivitas yang dapat di rencanakan dan di

lakukan secara sistemmatis. sejumlah strategi pengujian perangkat lunak setelah di

usulkan di dalam literatur.

Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada

kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan

aktivitas produksi di mana peluang terjadinya kesalahan manusia sangat besar dan

arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan

sempurna maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan

kualitas.

Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen

sistem dan biaya yang muncul akibat kegagalan perangkat lunak, memotivasi

dilakukannya perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya,

pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang dapat

dianggap sebagai hal yang merusak daripada membangun.

1.2 Rumusan Masalah

Dari latar belakang diatas dapat diambil rumusan masalah sebagai berikut :

1. Apa itu pendekatan strategis pengujian perangkat lunak ?

2. Apa itu pengujian validasi perangkat lunak ?

3. Apa itu pengujian system perangkat lunak ?

4. Apa itu debugging perangkat lunak

1.3 Tujuan

Tujuan kami membuat makalah tentang Strategi Pengujian Perangkat Lunak

adalah :

1. Mampu menjelaskan tentang strategi startegi pengujian perangkat lunak

2. Mampu menjelaskan tentang pengujian validasi perangkat lunak

3. Mampu menjelaskan tentang pengujian perangkat lunak

4. Mampu menjelaskan tentang pengertian dari debugging dan jenis-jenis dari

debugging perangkat linak

1.4 Manfaat

Manfaat yang didapatkan dari makalah ini adalah sebagi berikut :

1. Mampu menerapkan strategi-strategi yang digunakan dalam pengujian

perangkat lunak

2. Menambah wawasan tentang strategi pengujian perangkat lunak

3. Menjadikan bahan referensi bagi pembaca khususnya tentang rekayasa

perangkat lunak

BAB II

Pembahasan

2.1 Strategi Pengujian Perangkat Lunak

Dalam strategi pengujian perangkat lunak dapat digambarkan dengan ilustrasi

berikut: Sebuah perangkat lunak dimulai dari penentuan kebutuhan perangkat lunak,

kemudian prose dilanjutkan ke dalam bentuk rancangan, dan akhirnya ke

pengkodean. Strategi pengujian serupa dengan hal tersebut, dimulai dengan unit

testing di pusat spiral di mana masing-masing modul / unit dari perangkat lunak yang

diimplementasikan dalam source code menjadi sasaran pengujian. Kemudian

dilakukan integration testing dengan focus pengujian adalah desain dan kontruksi

arsitektur perangkat lunak. Selanjutnya dilakukan validation testing dengan sasaran

pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang telah ditentukan

di awal. Terakhir pada lingkaran terluar spiral sampai pada sistem testing, di mana

perangkat lunak dan keseluruhan sistem diuji.

2.1.1 Pendekatan Strategis ke Pengujian Perangkat lunak

Pengujian merupakan rangkaian aktivitas yang dapat direncanakan

sebelumnya dan dilakukan secara sistematis. Strategi uji coba perangkat lunak

memudahkan para perancang untuk menentukan keberhasilan sistem yang telah

dikerjakan. Hal yang harus diperhatikan adalah langkah-langkah perencanaan dan

pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan

sumber daya yang diperlukan. Strategi uji coba mempunyai karakteristik sebagai

berikut:

a) Pengujian mulai pada tingkat modul yang paling bawah, dilanjutkan dengan

modul di atasnya kemudian hasilnya dipadukan.

b) Teknik pengujian yang berbeda mungkin menghasilkan sedikit perbedaan

(dalam hal waktu).

c) Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang

besar) suatu kelompok pengujian yang independen.

d) Pengujian dan Debugging merupakan aktivitas yang berbeda, tetapi debugging

termasuk dalam strategi pengujian.

1.1.1 Macam-Macam Strategi Pengujian PL

a) Big bang testing

menguji PL keseluruhan, sekali untuk semua package yang ada.

b) Incremental testing

menguji PL per bagian dalam modul (unit testing), dilanjutkan dengan menguji

integrasi tiap modul (integration test), selanjutnya seluruh package diuji (system

testing).

2.2 Pengujian Validasi

Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi

testing. Pengujian validasi dikatakan berhasil bila fungsi yang ada pada perangkat

lunak sesuai dengan yang diharapkan pemakai. Validasi perangkat lunak merupakan

kumpulan seri uji coba black box yang menunjukkan sesuai dengan yang diperlukan.

Kemungkinan kondisi setelah pengujian:

a) Karakteristik performansi fungsi sesuai dgn spesifikasi dan dapat diterima.

b) Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.

2.2.1 Pengujian BETA dan ALPHA

Apabila perangkat lunak dibuat untuk pelanggan maka dapat dilakukan

aceeptance test sehingga memungkinkan pelanggan untuk memvalidasi seluruh

keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan

kesalahan yg lebih rinci dan membiasakan pelanggan memahami perangkat lunak yg

telah dibuat.

1. Pengujian Alpha

Dilakukan pada sisi pengembang oleh seorang pelanggan. Perangkat Lunak

digunakan pada setting yg natural dgn pengembang yang memandangmelalui bahu

pemakai dan merekam semua kesalahan dan masalah pemakaian

2. Pengujian Beta

Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir perangkat lunak dalam

lingkungan yg sebenarnya. Pengembang biasanya tidak ada pada pengujian ini.

Pelanggan merekam semua masaladi h (real atau imajiner) yang ditemui selama

pengujian dan melaporkan pada pengembang pada interval waktu tertentu.

2.3 Pengujian Sistem

Pada akhirnya perangkat lunak digabungkan dengan elemen sistem lainnya

dan rentetan perpaduan sistem dan validasi tes dilakukan. Jika uji coba gagal atau di

luar skope dari proses daur siklus pengembangan sistem, langkah yg diambil selama

perancangan dan pengujian dapat diperbaiki. Keberhasilan perpaduan perangkat

lunak dan sistem yg besar merupakan kuncinya.

Pengujian Sistem (System Testing) merupakan rentetan pengujian yang

berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen sistem yang

dikembangkan.

a) Volume Testing

Adalah pengujian system yang menemukan kelemahan sistem selama

melakukan pemrosesan data dalam jumlah yang besar dalam periode waktu yang

singkat. Tujuannya adalah meyakinkan bahwa sistem tetap melakukan pemrosesan

data antar batasan fisik dan batasan logik.

b) Recovery Testing

Adalah system testing yg memaksa perangkat lunak mengalami kegagalan

dalam bermacam-macam cara dan apakah perbaikan dilakukan dengan tepat.

c) Security Testing

Adalah pengujian yang akan melalukan verifikasi dari mekanisme

perlindungan yg akan dibuat oleh system, melindungi dari hal-hal yang mungkin

terjadi.

d) Strees Testing

Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji.

Testing ini dilakukan oleh system untuk kondisi seperti volume data yg tidak normal

(melebihi atau kurang dari batasan) atau frekuensi.

e) Performance Testing

Pengujian untuk menguji kinerja run-time (saat berjalan) dari PL didalam

konteks sistem yang terintegrasi. Tes kinerja sering digunakan bersamaan dengan

stress testing, dimana kita bisa melihat bagaimana kinerja sistem dalam keadaan

abnormal. Dilakukan secara paralel dengan Volume dan Stress Testing untuk

mengetahui unjuk kerja sistem (waktu respon, throughput rate) pada beberapa kondisi

proses dan konfigurasi.Dilakukan pada semua konfigurasi sistem perangkat keras dan

lunak. Misalnya: pada aplikasi Client-Server diujikan pd kondisi korporate ataupun

lingkungan sendiri (LAN vs. WAN, Laptop vs. Desktop)

2.4 Debugging

Debugging bukan merupakan pengujian, namun merupakan konsekuensi dari

pengujian yang berhasil. Jika sebuah kasus uji berhasil menemukan kesalahan, maka

proses debugging bertujuan untuk menghilangkan kesalahan tersebut.

Debugging merupakan proses yang sulit untuk dilakukan karena adanya

beberapa karakteristik bug seperti:

a. Gejala dan penyebab dari bug bisa sajasangat jauh, gejala dapat muncul pada

bagian tertentu dari program dan penyebabnya bisa saja berada pada bagian

lain yang sangat jauh dari tempatmunculnya gejala.

b. Gejala dapat hilang ketika kesalahan yang lain diperbaiki.

c. Gejala dapat ditimbulkan oleh sesuatu yang tidak salah(misalnya pembulatan

yang tidak akurat).

d. Gejala dapat disebabkan oleh masalah timing.

e. Kemungkinan sulit untuk memproduksi kondisi onput secara akurat.

f. Gejala dapat terjadi tiba-tiba.

g. Gejala dapat disebabkan oleh sesuatu yang didistribusikan melewati sejumlah

tugas yang bekerja pada prosesor yang berbeda-beda.

Terdapat 3 jenis pendekatan debugging, antara lain:

1. Brute Force

Merupakan teknik yang paling sering digunakan dan paling tidak efisien

dalam mengisolasi penyebab kesalahan. Dengan prinsip biarkan komputer

menemukan kesalahan, maka seluruh sumber daya komputer digunakan dengan

tujuan untuk menemukan penyebab kesalahan.

2. Backtracking

Merupakan pendekatan yang dimulai dari penemuan gejala kemudian

menelusuri balik hingga ke penyebab.

3. Cause Elimination

Dimanifestasikan oleh induksi atau deduksi dan menggunakan konsep partisi

biner. Data yang berhubungan dengan kesalahan yang muncul dikumpulkan untuk

mengisolasi penyebab. Kemudian dibuat sebuah hipotesis dan data digunakan untuk

membuktikan hipotesis tersebut. Daftar rangkaian penyebab yang mungkin dibuat

dan dilakukan pengujian untuk mengeliminasi penyebab-penyebab tersebut. Jika

pengujian menunjukkan kebenaran hipotesis untuk suatu penyebab, maka data

diperbaiki untuk mengisolasi bug. Sekali bug ditemukan, bug harus diperbaiki.

2.5 Pertanyaan dan Jawaban

I Putu Joddy Wira Ananta

1204505073

1. Apa saja karakteristik-karakteristik strategi uji coba perangkat lunak!

Jawaban:

a) Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan dgn modul

di atasnya kemudian hasilnya dipadukan.

b) Teknik pengujian yang berbeda mungkin menghasilkan sedikit perbedaan

(dalam hal waktu).

c) Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek

yang besar) suatu kelompok pengujian yang independen.

d) Pengujian dan Debugging merupakan aktivitas yang berbeda, tetapi

debugging termasuk dalam strategi pengujian.

I Made Mertha Prayuda

1204505079

2. Sebutkan dan Jelaskan macam-macam strategi pengujian perangkat lunak!

a. Big bang testing

Menguji PL keseluruhan, sekali untuk semua package yang ada.

b. Incremental testing

Menguji PL per bagian dalam modul (unit testing), dilanjutkan dengan

menguji integrasi tiap modul (integration test), selanjutnya seluruh package diuji

(system testing).

Hagi Semara Putra

1204505094

3. Apa saja jenis pendekatan pada debugging? Dari pendekatan itu mana yang

kurang efektif?

Terdapat 3 jenis pendekatan debugging, antara lain:

1. Brute Force

Merupakan teknik yang paling sering digunakan dan paling tidak efisien

dalam mengisolasi penyebab kesalahan. Dengan prinsip biarkan komputer

menemukan kesalahan, maka seluruh sumber daya komputer digunakan dengan

tujuan untuk menemukan penyebab kesalahan.

2. Backtracking

Merupakan pendekatan yang dimulai dari penemuan gejala kemudian

menelusuri balik hingga ke penyebab.

3. Cause Elimination

Dimanifestasikan oleh induksi atau deduksi dan menggunakan konsep partisi

biner. Data yang berhubungan dengan kesalahan yang muncul dikumpulkan untuk

mengisolasi penyebab. Kemudian dibuat sebuah hipotesis dan data digunakan untuk

membuktikan hipotesis tersebut. Daftar rangkaian penyebab yang mungkin dibuat

dan dilakukan pengujian untuk mengeliminasi penyebab-penyebab tersebut. Jika

pengujian menunjukkan kebenaran hipotesis untuk suatu penyebab, maka data

diperbaiki untuk mengisolasi bug. Sekali bug ditemukan, bug harus diperbaiki.

Pendekatan yang kurang efisien yaitu:

Brute Force karena pendekatan ini tidak efisien dalam mengisolasi penyebab

kesalahan. Pendekatan ini memiliki prinsip biarkan komputer menemukan

kesalahan, maka seluruh sumber daya komputer digunakan dengan tujuan untuk

menemukan penyebab kesalahan.

I Wayan Widarma Eka Putra

1204505054

4. Apa manfaat dari pengujian BETA dan ALPHA?

Manfaatnya yaitu untuk pelanggan melakukan aceeptance test sehingga

memungkinkan pelanggan untuk memvalidasi seluruh keperluan. Test ini dilakukan

karena memungkinkan pelanggan menemukan kesalahan yang lebih rinci dan

membiasakan pelanggan memahami perangkat lunak yang telah dibuat.

Kadek Aris Andhika Prahaditama

1204505086

5. Jelaskan tujuan pengujian sistem dan bagaimana pengujian tersebut sukses !

Pengujian Sistem (System Testing) merupakan rentetan pengujian yang

berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen sistem yang

dikembangkan.

a) Volume Testing

Adalah pengujian system yang menemukan kelemahan sistem selama

melakukan pemrosesan data dalam jumlah yang besar dalam periode waktu

yang singkat. Tujuannya adalah meyakinkan bahwa sistem tetap melakukan

pemrosesan data antar batasan fisik dan batasan logik.

b) Recovery Testing

Adalah system testing yg memaksa perangkat lunak mengalami kegagalan

dalam bermacam-macam cara dan apakah perbaikan dilakukan dengan tepat.

c) Security Testing

Adalah pengujian yang akan melalukan verifikasi dari mekanisme

perlindungan yg akan dibuat oleh system, melindungi dari hal-hal yang

mungkin terjadi.

d) Strees Testing

Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji.

Testing ini dilakukan oleh system untuk kondisi seperti volume data yg tidak

normal (melebihi atau kurang dari batasan) atau frekuensi.

e) Performance Testing

Pengujian untuk menguji kinerja run-time (saat berjalan) dari PL didalam

konteks sistem yang terintegrasi. Tes kinerja sering digunakan bersamaan

dengan stress testing, dimana kita bisa melihat bagaimana kinerja sistem

dalam keadaan abnormal. Dilakukan secara paralel dengan Volume dan Stress

Testing untuk mengetahui unjuk kerja sistem (waktu respon, throughput rate)

pada beberapa kondisi proses dan konfigurasi.Dilakukan pada semua

konfigurasi sistem perangkat keras dan lunak.

Pengujian dianggap sukses jika berhasil, menemukan error yang tidak

diketahui.

BAB III

STUDI KASUS

The Bugs Will Always Show Themselves, But Often Too Late

Programer dengan skala aplikasi software organisasi yang besar mempunyai

tangggung jawab yang besar juga. Jutaan baris dari kode program yang dihasilkan

oleh tim pemrograman tidak hanya mampu melakukan tugas yang dimaksudkan

tetapi harus melakukannya dengan 100 persen bebas dari kesalahan akurasi. Sebuah

tanda hubung tunggal tidak pada tempatnya dapat memberikan bencana bagi

pengguna akhir yang menerima manfaat dari perangkat lunak tersebut sama halnya

seperti pengembangnya. Kegagalan menunjukkan bahwa satu kesalahan kecil pada

kode ketika kesalahan itu terjadi dapat menghasilkan biaya jutaan, bahkan miliaran,

yang terakhir ditelusuri ketika akhirnya kesalahan tersebut mengungkapkan dirinya

sendiri. Pertimbangkan contoh ini:

Pada 15 Januari, 1990, sekitar 60.000 AT&T pelanggan jarak jauh mencoba untuk

menempatkan sambungan langsung jarak jauh menghubungi kami seperti biasa-

namun tidak diperoleh apapun (error). Di belakang layar, perusahaan switch jarak

jauh, semua 114 dari mereka, dijaga untuk melakukan reboot di squence. AT&T

mengasumsikan itu terjadi akibat hack, dan selama sembilan jam, perusahaan dan

penegakan hukum berusaha mencari tahu apa yang terjadi. Pada akhirnya, AT&T

mengungkap pelakunya : sebuah kesalahan tidak jelas yang terjadi didalam perangkat

lunak baru.

Bulan sebelum kecelakaan itu, AT&T memperbaiki kode tersebut untuk

mempercepat proses. Masalahnya, hal itu terlalu cepat. Server pertama yang dicoba

untuk overload dan memberikan dua pesan, salah satunya menghantam server kedua

sama seperti yang telah diatur ulang. Server kedua diasumsikan bahwa ada kesalahan

dalam logika internalnya dan diatur ulang sendiri. Server kedua menempatkan sendiri

tanda "tidak mengganggu" dan melewati masalah pada ke switch ketiga dan sehingga

masalah mengalir melalui seluruh sistem. Semua 114 switch dalam sistem dijaga

untuk diatur ulang sendiri, sampai teknisi dapat mengurangi beban pesan pada

seluruh sistem dan gelombang dari mengatur ulang sampai akhirnya berhasil.

Sementara itu, AT&T kehilangan sekitar $60 juta biaya jarak jauh dari panggilan

yang tidak diproses. Perusahaan mengambil langkah sukses keuangan lebih lanjut

beberapa minggu kemudian ketika dilakukan penurunan sepertiga tarif dari

sambungan reguler langsung jarak jauh pada hari valetine untuk menebus kesalahan

dengan pelanggan. Hal yang dapat dipelajari: menguji "perbaikan kode" terlebih

dahulu sebelum merilisnya.

Diperkenalkan pada tahun 2006, Windows Genuine Advantage (WGA) adalah

sebuah inisiatif yang tidak pernah populer dengan pelanggan microsoft itu. WGA

tidak melakukan apapun untuk membantu keamanan atau stabilitas dari instalasi

windows yang sah. Semua yang terjadi telah membantu microsoft memberantas

pembajakan dari perangkat lunak di mana-mana pemberantasan tersebut tampak-

bahkan di antara ribuan pelanggan windows yang sah.

Seseorang di tim WGA secara tidak sengaja memasang bug untuk mengisi perangkat

lunak praproduksi pada server WGA tim dengan cepat memutar kembali untuk

menguji peluncuran dari perangkat lunak, tetapi mereka tidak memeriksa bahwa yang

meraka perbaiki benar-benar membahas masalah yang ada. Ternyata tidak. sehingga

selama 19 jam server menandai ribuan dari klien WGA di seluruh dunia sebagai

ilegal. Pelanggan windows XP diberitahu bahwa mereka menjalankan perangkat

lunak bajakan. pelanggan windows vista mendapatkan fitur telah dimatikan, termasuk

tema eye candy aero dan dukungan untuk ReadyBost RAM virtual drive.

Official pertama menanggapi bahwa mengeluh tidak membantu banyak: pelanggan

yang tidak puas disarankan untuk mencoba memvalidasi ulang pada hari Selasa, tapi

bahkan ketika masalah telah diperbaiki, klien vista masih harus memvalidasi ulang

instalasi windows mereka sebelum mereka bisa menjalankan ReadyBoost mereka

kembali ke aero.

Ok, jadi ini adalah masalah yang relatif ringan dalam hal teknik, dan sesungguhnya,

itu disebabkan oleh kesalahan manusia. Namun kesalahan dalam pertanyaan itu

menyebarkan buggy, perangkat lunak yang belum teruji, dan ketika anda menjadi

salah satu faktor dari beberapa orang yang terkena, tingkat kemarahan diinduksi, dan

dampak yang muncul adalah publisitas yang buruk, itu lebih parah daripada

penglihatan pada pandangan pertama.

Tidak semua bug dalam perangkat lunak dianggap masalah sederhana, namun.

Beberapa dari mereka adalah fatal. Perangkat lunak medis dan militer dapat sangat

berbahaya jika tidak benar diuji. Selama perang teluk persia pertama, irak-

menembakkan rudal dengan gerakan cepat adalah serangan udara yang paling

mengancam bagi pasukan AS. Setelah salah satu roket cepat yang mematian

diluncurkan, pertahanan AS yang terbaik adalah untuk mencegah serangan tersebut

dengan rudal patriot antibalistik. Patriot bekerja hampir sama seperti senapan,

mendapatkan dalam jangkauan rudal yang mendekat sebelum menembakkan keluar

sebuah awan dengan 1.000 pelet untuk meledakkan serangan roket.

Sebuah patriot diperlukan untuk menyebarkan peletnya antara 5 dan 10 meter dari

sebuah rudal yang mendekat untuk hasil terbaik. Ini membutuhkan waktu sepersekian

detik, yang selalu rumit dengan dua benda yang bergerak sangat cepat terhadap satu

sama lain. Sekalipun booster patriot yang paling menonjol, maka presiden george

H.W.Bush, mengakui bahwa salah satu gerakan cepat (dari 42 tembakkan) berhasil

melewati patriot. Kegagalan tunggal diakui presiden berada di pangkalan AS di

Dhahran, Arab Saudi, pada tanggal 25 februari 1991, dan kegagalan tersebut

menewaskan 28 tentara mereka. Kesalahan ini terlacak pada kesalahan perangkat

lunak.

Perhitungan lintasan patriot berkisar seputar waktu dari pulsa radar, dan mereka harus

dimodifikasi untuk menangani kecepatan tinggi dari rudal modern. Sebuah subroutine

diperkenalkan untuk mengubah waktu jam lebih akurat ke titik mengambang angka

untuk perhitungan. Itu telah diperbaiki sedikit rapi, tapi programmer tidak

menempatkan panggilan ke subroutine di mana saja itu dibutuhkan.

Nampak secara kasat masalah ini telah diketahui, dan diperbaiki sementara berada di

tempatnya: reboot sistem sering sekali dilakukan untuk me-reset jam. Sayangnya,

istilah "sering sekali" tidak diartikan, dan itulah masalah yang terjadi dalam Februari

dahulu di Dhahran. Sistem ini telah berjalan selama 100 jam, dan jam berangkat

sekitar sepertiga dari satu detik. sebuah gerakan perjalanan cepat setengah kilometer

dalam waktu itu, jadi tidak ada kesempatan patriot bisa untuk disadap. Hal yang

dapat dipelajari: definisi yang tepat dari instruksi untuk penggunaan aplikasi adalah

sangat penting.

Terapi radiasi adalah alat yang berguna dalam memerangi berbagai bentuk kanker

yang terkandung: sinar elektron membinasakan hal yang buruk, dan tubuh membuang

benda mati. Sinar elektron memiliki fokus. Hal tersebut yang menyebabkan dunia

medis beralih dari mesin. Ketidak beruntungan terjadi pada enam pasien antara tahun

1985 dan 1986, Therac-25 merupakan mesin dalam pertanyaan.

Therac 25 menangani dua jenis terapi: sebuah low-poweres direct electron beam dan

sebuah mode sinar-X megavolt, yang dipersyaratkan melindungi dan menyaring dan

ruang ion untuk menjaga sinar berbahaya dengan aman pada target. Masalahnya

adalah bahwa perangkat lunak yang mendukung unit ini dimodif dari model

sebelumnya, dan itu tidak cukup untuk diuji.

Jika operator mengubah modus perangkat dengan cepat, kondisi persaingan terjadi:

dua set instruksi yang dikirim, dan yang pertama tiba mengatur mode. Dalam enam

kasus didokumentasikan, ini berarti bahwa megavolt sinar-X dikirim, tanpa filter dan

tanpa saringan, terhadap pasien yang memerlukan theraphy langsung elektron.

Setidaknya dua dari mereka menjerit kesakitan dan berusaha lari dari ruangan. Semua

dari mereka menderita keracunan radiasi, yang diklaim beberapa kehidupan.

Therac-25, yang telah mengingatkan kembali pada tahun 1987, telah menjadi

pelajaran mengenai apa yang bisa salah dari mesin medis yang hebat. Kode tidak

menyebabkan overdosis di vented mereka. Hal yang dapat dipelajari: menggunakan

kembali kode pada sistem baru tanpa melalui pengujian adalah pemrograman yang

buruk, dengan alasan yang baik.

Proses pengujian perangkat lunak membutuhkan waktu dan uang dan umumnya

terjadi dalam lingkungan hidup dimana mendapatkan aplikasi yang dilakukan dan di

tangan mereka yang membutuhkannya adalah tekanan konstan. Mengingat bahwa

bug pada akhirnya akan, dan selalu, menemukan diri mereka harus memiliki cukup

motivasi untuk mendapatkan yang benar pertama kalinya. Tapi, sering kali tidak.

BAB IV

Penutup

3.1 Kesimpulan

Kesimpulan yang bisa kita ambil adalah :

1. Pengujian merupakan rangkaian aktivitas yang dapat direncanakan

sebelumnya dan dilakukan secara sistematis. Strategi uji coba perangkat lunak

memudahkan para perancang untuk menentukan keberhasilan sistem yg telah

dikerjakan.

2. Validasi perangkat lunak merupakan kumpulan seri uji coba black box yg

menunjukkan sesuai dengan yang diperlukan.

3. Pengujian Sistem (System Testing) merupakan rentetan pengujian yang

berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen sistem

yang dikembangkan.

4. Debugging bukan merupakan pengujian, namun merupakan konsekuensi dari

pengujian yang berhasil.

3.2 Saran

Mampu menjadikan strategi pengujaian perangkat lunak sebagai pedoman

untuk menunjang pengujian pengujian yang lain seperti penjian validasi, pengujian

system dan proses debugging.

Daftar Pustaka

http://agusnurkhomarudin.blogspot.com/2012/07/strategi-pengujian-perangkat-

lunak.html

http://wsilfi.staff.gunadarma.ac.id/Downloads/files/2205/Strategi+Pengujian+Perangk

at+Lunak+mg+ke+8LANJ.pdf

http://bagusalfiyanto.blogspot.com/2010/06/pengujian-perangkat-lunak.html

http://kur2003.if.itb.ac.id/file/TESTING.pdf

http://amethyst070188.files.wordpress.com/2010/09/rpl-8.pdf

http://suryagsc.files.wordpress.com/2012/05/meeting-13.ppt