TUGAS
TUGAS
REKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Strategi Pengujian Perangkat Lunak
Strategi Pengujian Perangkat Lunak
OLEH : OLEH :
I
I Wayan Wayan Widarma Widarma Eka Eka Putra Putra (1204505054)(1204505054)
I
I Putu Putu Joddy Joddy Wira Wira Ananta Ananta (1204505074)(1204505074)
I
I Made Made Mertha Mertha Prayuda Prayuda (1204505079)(1204505079)
Kadek
Kadek Aris Aris Andhika Andhika Prahaditama Prahaditama (1204505086)(1204505086)
Hagi
Hagi Semara Semara Putra Putra (1204505094)(1204505094)
TEKNOLOGI INFORMASI FAKULTAS TEKNIK TEKNOLOGI INFORMASI FAKULTAS TEKNIK
UNIVERSITAS UDAYANA UNIVERSITAS UDAYANA
TH. AJARAN 2013 / 2014 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 memandang”melalui 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 k omputer 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 k esempatan 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
