CONTOH PAPER SISTEM TESTING DAN IMPLEMEN

TUGAS PAPER MATAKULIAH

SISTEM TESTING DAN IMPLEMENTASI

https://www.4shared.com/zip/YuMrNxJHba/TUGAS_PAPER_SISTEM_TESTING_DAN.html

Oleh :

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS ILMU KOMPUTER

UNIVERSITAS INDONESIA TIMUR MAKASSAR

2015/2016

SDLC (Software Development Life Cycle) berarti sebuah siklus hidup

pemngembangan perangkat lunak yang terdiri dari beberapa tahapan-tahapan yang sangat penting dalam keberadaan perangkat lunak yang dilihat dari segi pengembangannya, tahapan-tahapan pekerjaan yang dilakukan oleh analis sistem dan programmer dalam membangun sistem informasi. Langkah yang digunakan meliputi : 1. Melakukan survei dan menilai kelayakan proyek pengembangan sistem informasi 2. Mempelajari dan menganalisis sistem informasi yang sedan g berjalan 3. Menentukan permintaan pemakai sistem informasi

4. Memilih solusi atau pemecahan masalah yang paling baik

5. Menentukan perangkat keras (hardware) dan perangkat lunak (software) 6. Merancang sistem informasi baru

7. Membangun sistem informasi baru

8. Mengkomunikasikan dan mengimplementasikan sistem informasi baru

System Development Lyfe Cycle (SDLC) adalah keseluruhan proses dalam

membangun sistem melalui beberapa langkah. Ada beberapa model SDLC. Model yang cukup populer dan banyak digunakan adalah waterfall. Beberapa model lain SDLC misalnya fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize & stabilize.

Dengan siklus SDLC, proses membangun sistem dibagi menjadi beberapa langkah dan pada sistem yang besar, masing-masing langkah dikerjakan oleh tim yang berbeda.

o Kegunaan SDLC

Adapun kegunaan utama dari SDLC adalah mengakomodasi beberapa kebutuhan. Kebutuhan-kebutuhan itu biasanya berasal dari kebutuhan pengguna akhir dan juga pengadaan perbaikan sejumlah masalah yang terkait dengan pengembangan perangkat lunak. Kesemua itu dirangkum pada proses SDLC yang dapat berupa penambahan fitur baru (baca : kemampuan penggunaan) baik itu secara modular (baca : instalasi parsial atau update dan upgrade perangkat lunak) maupun dengan proses instalasi baru (baca : penggantian perangkat lunak menyeluruh atau software replacement). Dari proses SDLC juga berapa lama umur sebuah perangkat lunak dapat diperkirakan untuk dipergunakan yang dapat diukur atau disesuaikan dengan kebijakan dukungan (baca : software support) dari pengembang perangkat lunak terkait.

o Implementasi SDLC

Secara sederhana proses implementasi SDLC dapat dilihat dari penamaan sebuah perangkat lunak - sebagai contoh berikut :

Penerapan SDLC yang baik dan benar pada prinsipnya juga membutuhkan biaya baik itu finansial dan non-finansial, baik itu teknis maupun non-teknis yang tidak sedikit. Kesemua hal tersebut wajib diperhitungkan secara cermat agar proses pengembangan perangkat lunak itu sendiri (yang menjadi inti utama dari SDLC) tidak terhambat atau bahkan terbengkalai.

o Limitasi SDLC

Kadangkala, perkembangan dan penggunaan teknologi antara perangkat keras dan perangkat lunak, dan sesama perangkat lunak tidak sejalan (lebih cepat atau lebih lambat antara satu dengan lainnya, antara mendukung dan tidak mendukung satu dengan lainnya) - sehingga terkadang hasil proses SDLC yang membutuhkan aplikasi pendukung lainnya (software dependencies) maupun perangkat keras (hardware) yang benar-benar mendukung (perangkat keras baru) agak kesulitan dalam proses penyesuaian (serapan) sehingga dapat menyebabkan proses implementasi SDLC “terkesan” stagnan.

B. SIKLUS PENGEMBANGAN PERANGKAT LUNAK (SWDLC)

Pengembangan sistem (sistem development) dapat berarti menyusun sistem yang baru untuk menggantikan sistem yang lama secara keseluruhan atau memperbaiki sistem yang sudah ada. Sistem yang lama perlu diperbaiki atau diganti disebabkan karena beberapa hal, yaitu sebagai berikut :

1. Adanya permasalahan-permasalahan (problems) yang timbul di sistem yang lama. Permasalahan yang timbul dapat berupa :

Ketidakberesan dalam sistem yang lama yang menyebabkan sistem yang lama tidak dapat beroperasi sesuai dengan yang diharapkan.

Pertumbuhan organisasi, yang menyebabkan harus disusunnya sistem yang baru.

3. Adanya instruksi-instruksi (directives), penyusunan sistem yang baru dapat juga terjadi karena adanya instruksi-instruksi dari atas pimpinan ataupun dari luar organisasi. Karena adanya permasalahan, kesempatan atau instruksi, maka sistem yang baru perlu dikembangkan untuk emecahkan permasalahan-permasalahan yang timbul, meraih kesempatan-kesempatan yang ada atau memenuhi instruksi yang diberikan.

Gambar 1. Pengembangan Sistem Informasi

Sistem yang baik adalah sistem yang selalu menyesuaikan dengan perubahan lingkungan yang terjadi disekitarnya atau sistem tersebut harus dinamis menuju pada

Gambar 2. Tahapan Perancangan Sistem Informasi

Tahap awal, yaitu tahap perencanaan, menyangkut studi kebutuhan user, studi

kelayakan baik secara teknis maupun teknologi serta penjadwalan pengembangan suatu proyek sistem informasi.

Tahap berikutnya adalah tahap analisis, yaitu tahap dimana kita berusaha

mengenali segenap permasalahan yang muncul pada pengguna, mengenali komponen-komponen sistem, obyek-obyek, hubungan antar obyek dan sebagainya.

Kemudian tahap ketiga adalah tahap perancangan, yaitu tahap dimana kita

mencoba mencari solusi permasalahan yang didapat dari tahap analisis.

Tahap keempat adalah tahap implementasi dimana kita mengimplementasikan

keuntungan metodologi berorientasi obyek mulai terlihat, dimana mulai dari tahap analisis hingga tahap implementasi, kita bisa menggunakan tool yang sama sehingga proses iteratif itu dapat berjalan dengan lebih efektif serta efisien ditinjau dari segi uang dan waktu.

Kemudian tahap yang terakhir adalah tahap pemeliharaan / perawatan, dimana kita bisa mulai melakukan pengoperasian sistem dan jika diperlukan dapat melakukan perbaikan-perbaikan kecil. Kemudian jika waktu penggunaan sistem habis, maka kita akan masuk lagi pada tahap perencanaan.

Mengorganisasi Proyek Pengembangan Perangkat Lumak

Perancang dan analis sistem terlibat dalam tim pengembangan perangkat lunak dan harus mengetahui bagaimana program ini dikode dan bagaimana hasil akhirnya. Untuk itu diperlukan keterampilan pengorganisasian dalam tim proyek. Pengorganisasian proyek pengembangan perangkat lunak memerlukan komunikasi, integrasi dan koordinasi yang baik. Pengorganisasian tim pemrograman menggunakan pendekatan organisasional.

Pendekatan Organisasional

Tiga cara untuk mengorganisasi tim pemrograman, yaitu : Tim Pengembangan Program ( Program development team) Tim programmer kepala (chief programmer team)

Tim pemrograman bersama (Egoless programming team)

1. Tim Pengembangan Program ( Program development team)

2. Tim programmer kepala (chief programmer team)

Tim ini dibentuk dari programmer kepala atau senior yang banyak pengalaman dan pengetahuan pemrograman. Programmer kepala dapat berkomunikasi secara efektif dengan analis dan perancang sistem, pemakai, dan berbagai teknisi.

Programmer kepala didukung oleh asisten utama yang bertugas sebagai komunikator dengan orang lain pada tim atau penyampai informasi dari gagasan programmer kepala. Kedua orang tersebut didukung oleh Programmer pendukung/ yunior bertugas membantu programmer kepala dan asisten utama untuk proyek besar yang tidak dapat ditangani sendiri. Para programmer pendukung biasanya mengkode modul-modul tingkat rendah. Tim ini juga didukung oleh pustakawan, administrator, editor, dan klerk program.

3. Tim pemrograman bersama (Egoless programming team)

Tim ini terbentuk dari seluruh rekan yang bersama-sama bertanggung jawab atas pengembangan perangkat lunak tanpa supervisi langsung/pimpinan.

Perbedaan pendekatan-pendekatan tersebut :

 Tim pengembangan program mengembangkan aturan 40-20-40 yaitu menekankan pada perancangan dan pengujian.

 Tim programmer kepala dan tim pemrograman bersama menekankan pada fungsi pengkodean.

Jumlah interface dan lintasan komunikasi dari pendekatan di atas :

 Tim programmer kepala terdiri dari lima programmer pendukung mempunyai lima interface dan lintasan komunikasi, dan lebih mungkin memenuhi deadline yang ketat.

Tim pemrograman bersama terdiri dari lima programmer. Jumlah interface dan lintasan komunikasi = n(n-1)/2= 5(5-1)/2=10

Segala jenis pekerjaan pengembangan biasanya waktu restart (mulai lagi) setelah setiap interupsi besarnya 30 menit sehingga peluang pemrograman yang bisa dilakukan waktunya sedikit.

Oleh karena itu apabila terdapat lebih dari tiga programmer yang terlibat maka sebaiknya ditetapkan seorang supervisor atau pimpinan.

Didalam dunia perangkat lunak, penggunaan berulang merupakan hal yang biasa. Contohnya ide dan formula yang hampir sama digunakan berulang oleh programmer yang berbeda untuk mengembangkan aplikasi keuangan yang khusus diadaptasikan sesuai kebutuhan dan permintaan masing-masing klien. Oleh karena itu penggunaan berulang suatu obyek

merupakan hal yang seharusnya bisa dilakukan. Suatu obyek bisa diambil untuk dimodifikasi berupa penambahan atau pengulangan untuk memecahkan suatu masalah baru.

Ada empat prinsip dasar dari pemrograman berorientasi obyek, yaitu :abstraksi, enkapsulasi, modularitas dan hirarki.

Abstraksi :

Memfokuskan perhatian pada karakteristik obyek yang paling penting dan paling dominan yang bisa digunakan untuk membedakan obyek tersebut dari obyek lainnya. Dengan abstraksi ini developer bisa menerapkan konsep KIS (Keep It Simple) pada obyek didunia nyata yang memiliki tingkat kerumitan yang tinggi.

Enkapsulasi:

implementasinya dan untuk menuntaskan proses tersebut perlu berhubungan dengan obyek mana saja. Dengan demikian bila terjadi proses perubahan pada proses implementasi maka obyek pemanggil tidak akan terpengaruhi secara langsung.

Modularitas :

Membagi sistem yang rumit menjadi bagian-bagian yang lebih kecil yang bisa mempermudah developer memahami dan mengelola obyek tersebut. Contohnya adalah sistem akademis yang bisa dibagi menjdi kemahasiswaan, daftar mata kuliah, pembayaran uang kuliah, dan lain-lain.

Hirarki :

Hirarki berhubungan dengan abstraksi dan modularitas, yaitu pembagian berdasarkan urutan dan pengelompokkan tertentu. Misalnya untuk menentukan obyek mana yang berada pada kelompok yang sama, obyek mana yang merupakan komponen dari obyek yang memiliki hirarki lebih tinggi. Semakin rendah hirarki obyek berarti semakin jauh abstraksi dilakukan terhadap suatu obyek. Ke empat prinsip dasar ini merupakan hal yang mendasari teknologi obyek yang perlu ditanamkan dalam cara berpikir developer berorientasi obyek.

C. PENGUJIAN PERANGKAT LUNAK

Pengujian Perangkat Lunak adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean.

Dasar-dasar Pengujian Perangkat Lunak

Pengembang perangkat lunak sesuai dengan sifatnya dasar, mereka adalah manusia pembangun. Pengujian mengharuskan pengembang membuang pemikiran-pemikiran sebelumnya mengenai “kebenaran” perangkat lunak yang baru saja dikembangkan dan mengatasi konflik minat yang terjadi pada saat kesalahan ditemukan.

Sasaran Pengujian

menemukan dan mengungkapkan semua kesalahan yang belum pernah ditemukan atau diduga sebelumnya.

Prinsip Pengujian

1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan. 2. Pengujian harus direncanakan lama sebelum pengujian itu mulai.

3. Pengujian harus mulai “dari yang kecil” dan berkembang menjadi pengujian “yang besar”.

Karakteristik yang Membawa Perangkat Lunak Dapat Diuji

1. Operabilitas, yaitu : Semakin baik Dia bekerja, semakin efisien Dia dapat diuji. 2. Obsaikervabilitas, yaitu : “Apa yang Anda lihat adalah apa yang Anda uji”.

3. Kontralabilitas, yaitu : “Semakin baik kita dapat mengontrol perangkat lunak, semakin banyak pengujian yang dapat diotomasisasi dan dioptimalkan”.

4. Dekomposabilitas, yaitu : “Dengan mengontrol ruang lingkup pengujian, kita dapat dengan lebih cepat mengisolasi masalah dan melakukan pengujian kembali secara lebih halus”.

5. Kesederhanaan, yaitu : “Semakin sedikit yang kita uji, semakin cepat kita dapat mengujinya’.

6. Stabilitas, yaitu : “Semakin sedikit perubahan, semakin sedikit pula gangguan dalam pengujian’.

7. Kemampuan untuk dapat dipahami, yaitu : “Semakin banyak informasi yang kita miliki, semakin halus pengujian yang akan dilakukan’.

Atribut--atribut pengujian yang baik :

1. Pengujian yang baik memiliki probabilitas yang tinggi untuk menemukan kesalahan. 2. Pengujian yang baik tidak redudan.

3. Pengujian yang baik seharusnya “jenis terbaik”,

4. Pengujian yang baik tidak boleh terlalu sederhana atau terlalu kompleks.

Tujuan Pengujian :

Fase Pengujian

Ada 2 tingkat yang tersedia pada proses pegujian, yaitu :

1. Konfigurasi perangkat lunak yang mencakup spesifikasi keperluan perangkat lunak, spesifikaasi perancangan, test case dan program sumber

2. Konfigurasi uji coba yang mencakup rencana dan prosedur uji coba, test case dan hasil yang diharapkan

Condition Testing

Pengujian yang menjalankan kondisi logis yang terdapat pada modul program.

Data Flow Testing

Pengujian dengan metode yang menyeleksi jalur uji program menurut lokasi pendefinisian dan menggunakan variable-variabel program

Loop Testing

Pengujian yang berfokus pada validitas dari bentuk loop 1. simple loop

2. concatenated loop 3. nested loop 4. unstructured loop

D. STRATEGI DAN RENCANA PENGUJIAN

Isu-isu utama yang akan diangkat berkaitan dengan pelaksanaan pengujian adalah efektivitas dan efisiensi pengujian. Dengan kata lain, usaha yang terus menerus untuk diarahkan dalam pengurangan persentase kesalahan tidak terdeteksi yang tersisa di perangkat lunak atau sistem yang diuji pada satu sisi, dan untuk kinerja pengujian dengan mnghabiskan sumber daya lebih sedikit di sisi lain.

Isu utama bahwa metodologi pengujian harus bersaing adalah:  Standar kualitas perangkat lunak yang diperlukan,

 Strategi pengujian perangkat lunak. integrasi menghadapi tes dengan beberapa unit yang menggabungkan ke dalam sistem. Sistem tes merujuk ke paket perangkat lunak seluruh / sistem. Adalah tugas perencana untuk mempertimbangkan hal-hal berikut sebelum memulai rencana tes khusus:

 Apa yang akan diuji?

 Sumber-sumber apa yang digunakan untuk uji kasus?  Siapa yang melakukan pengujian?

 Dimana tempat melakukan pengujian?  Kapan harus mengakhiri pengujian?

Apa yang akan diuji?

Pendekatan langsung untuk pengujian yang sempurna akan merekomendasikan rencana pengujian perangkat lunak lengkap dan komprehensif yang melakukan uji unit untuk semua unit individu, uji integrasi untuk semua integrasi unit, dan uji sistem untuk menguji paket perangkat lunak secara keseluruhan. Menerapkan rencana secara “langsung” memang memastikan kualitas perangkat lunak yang tinggi tetapi juga memerlukan investasi sumber daya yang luas dan jadwal yang panjang.

Situasi yang berkaitan dengan manfaat dari pendekatan semacam itu. Sebagai contoh:  Apakah dibenarkan untuk melakukan pengujian unit untuk sebuah modul yang

terdiri dari 98% perangkat lunak yang reuse ?

 Apakah pengujian unit wajib dilakukan pada modul sederhana yang menampilkan modul versi 12 dari modul dasar yang digunakan berulang kali oleh tim pengembang selama tiga tahun terakhir?

Hanya dalam kasus yang jarang itu dibenarkan untuk menguji “segalanya”. Biasanya, kelayakan pengujian “segalanya” sangat terbatas. Terlepas dari kinerja dari daftar tes yang ditentukan dalam kontrak atau diperlukan oleh prosedur pengembang (misalnya beban tes untuk sistem secara keseluruhan), beberapa pertimbangan untuk tes yang akan diterapkan, antara lain :

 Unit modul mana yang harus diuji?  Integrasi mana yang harus diuji?

 Prioritas menentukan pengalokasian sumber daya pengujian kepada sistem aplikasi perangkat lunak individu. Akibatnya,aplikasi yang mendapat prioritas rendah diuji dengan hanya beberapa jenis tes atau tidak termasuk dalam pengujian sistem sama sekali.

Dalam menentukan apa yang harus dimasukkan dan apa yang dikecualikan dari uji sistem, uji unit dan uji integrasi yang sudah direncanakan harus dipertimbangkan. Untuk kualitas perangkat lunak dari aplikasi dan modul yang tidak dicakup oleh uji unit, integrasi dan sistem, kami mengandalkan cek kode yang dilakukan oleh programmer dan pemimpin timnya serta inspeksi kode dan walkthrough diprakarsai oleh tim pengembangan.

Siapa yang melakukan pengujian?

Siapa yang akan melakukan berbagai tes ditentukan pada tahap perencanaan :

pengujian tim konsultan eksternal).

E. PENGUJIAN WHITE BOX DAN METODENYA

White Box Testing

Merupakan metode perancangan test case yang menggunakan struktur kontrol dari perancangan prosedural untuk mendapatkan test case.

Dengan menggunakan metode white box, analis sistem akan dapat memperoleh test case yang:

 Menjamin seluruh independent path di dalam modul yang dikerjakan  sekurang-kurangnya sekali

 Mengerjakan seluruh keputusan logikal

 Mengerjakan seluruh loop yang sesuai dengan batasannya

 Mengerjakan seluruh struktur data internal yang menjamin validitas

A. Uji Coba Basis Path

Merupakan teknik uji coba white box yang diusulkan Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunakan ukuran ini sebagai petunjuk untuk mendefinisikan basis set dari jalur pengerjaan. Test case yang didapat digunakan untuk mengerjakan basis set yang menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.

Lingkaran (node), menggambarkan satu/lebih perintah prosedural. Urutan

proses dan keputusan dapat dipetakan dalam satu node. Tanda panah

(edge), menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan

Node dibuat terpisah untuk masing-masing kondisi A dan B dari pernyataan IF A OR B. Masing-masing node berisi kondisi yang disebut pridicate node dan mempunyai karakteristik dua atau lebih edge darinya.

Cyclomatic Complexity

Dari gambar: Path 1 = 1 - 11

Path 2 = 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11 Path 3 = 1 - 2 - 3 - 6 - 8 - 9 ...: 10 - 1 - 11 Path 4 = 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11

Path 1,2,3,4 yang telah didefinisikan diatas merupakan basis set untuk diagram alir.

Cyclomatic complexity digunakan untuk mencari jumlah path dalam satu flowgraph. Dapat dipergunakan rumusan sebagai berikut :

1. Jumlah region grafik alir sesuai dengan cyclomatic complexity.

2. Cyclomatix complexity V(G) untuk grafik alir dihitung dengan rumus: V(G) = E - N + 2

Dimana:

E = jumlah edge pada grafik alir N = jumlah node pada grafik alir

3. Cyclomatix complexity V(G) juga dapat dihitung dengan rumus: V(G) = P + 1

Dimana P = jumlah predicate node pada grafik alir

Pada Gambar dapat dihitung cyclomatic complexity: 1. Flowgraph mempunyai 4 region

3. V(G) = 3 predicate node + 1 = 4

Jadi cyclomatic complexity untuk flowgraph adalah 4

Melakukan Test Case

Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci atau program sumber. Prosedur rata-rata pada bagian berikut akan digunakan sebagai contoh dalam pembuatan test case.

Langkah-Iangkah pembuatan test case:

1. Dengan mempergunakan perancangan prosedural atau program sumber sebagai dasar, digambarkan diagram alirnya.

V(G) = 5 predicate node + 1 = 6

3. Tentukan independent path pada flowgraph

Dari hasil perhitungan cyclomatic complexity terdapat 6 independent path yaitu:

path 1 : 1-2-10-11-13 path 2 : 1-2-10-12-13 path 3 : 1-2-3-10-11-13 path 4 : 1-2-3-4-5-8-9-2-.. path 5 : 1-2-3-4-5-6-8-9-2-.. path 6 : 1-2-3-4-5-6-7-8-9-2-...

4. Buat test case yang akan mengerjakan masing-masing path pada basis set. Data yang dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan semua.

Graph Metrik

Graph metrik merupakan software yang dikembangkan untuk membantu uji coba basis path atau struktur data. Graph metrik adalah matrik empat persegi yang mempunyai ukuran yang sama dengan jumlah node pada flowgraph. Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah ditentukan dan pemasukan data matrik berhubungan dengan hubungan (edge) antar node.

Hubungan bobot menyediakan tambahan informasi tentang aliran kontrol.

Secara simpel hubungan bobot dapat diberi nilai 1 jika ada hubungan antara node atau nilai 0 jika tidak ada hubungan. Dapat juga hubungan bobot diberi tanda dengan:

 Kemungkinan link (edge) dikerjakan

 Waktu yang digunakan untuk proses selama traversal dari link  Memori yang diperlukan selama traversal link

 Sumber daya yang diperlukan selama traversal link

B. Pengujian Loop