Tahapan uji dalam fase pemrograman

Langkah 4. Rencana Bagaimana Menguji Modul (Plan How To Test The Module)

Programmer  harus  menyiapkan  rencana  pengujian  modul  dan  data  pengujian  sebelum dikodekan.  Rencana  pengujian  dilakukan  setelah  kode  ditetapkan.  Mereka  cenderung hanya  menguji  bagian  kode  yang  paling  ‘sulit’.  Pimpinan  proyek  bisa  saja  melakukan tuntutan  pada  penelusuran  rencana  pengujian  sepanjang  disain  modul  sedang dilaksanakan. Kerjakan penelusuran ini bersama-sama.

Langkah 6. Menguji Modul (Test The Module) 

Programmer  menguji  modul  dengan  menetapkan  lingkungan  yang  tepat,  menyediakan beberapa input, membiarkan modul langsung memproses secara logik dan mendapatkan hasilnya. Beberapa input mungkin tidak sebenarnya, terutama jika modul tersebut tidak menyediakan input yang sebenarnya.

Modul seharusnya diuji dalam dua tahap, yaitu :

•  Tahap Pertama disebut pengujian “ White Box”. Programmer harus mengetahui isi di  dalam  modul  dan  menyediakan  data  pengujian,  sehingga  masing-masing path logical dalam program dapat dieksekusi.

•  Tahap  Kedua  atau  pengujian  “Black  Box”  dapat  dilakukan.  Dalam  pengujian  ini, programmer mengabaikan bagian dalam dari modul – data disediakan secara berurut dan dianggap seperti pemakaian sebenarnya.

Langkah  7.  Menguji  Level  Terendah  dari  Integrasi  (Test  The  Lowest  Levels  Of Integration)

Jika modul utama memanggil sub-modul, programmer harus menggabungkan dan menguji semua  modul secara bersama-sama. Bahkan jika programmer  tidak bertanggung jawab untuk menulis sub-modul, programmer harus menguji perintah CALL dan RETURN dari seluruh modul.

 Metode  terbaik  untuk  melakukan  hal  ini  adalah  membuat  sebuah  “program  stub”  (potongan  program)  sebagai  pengganti  sub-modul.  Potongan  program  ini  dapat  terdiri dari empat baris program yang menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan  parameter  penerima,  jika  perlu  lakukan  pengontrolan  kembali  dengan beberapa parameter yang tidak sebenarnya.

Perbedaan dari uji secara black box dengan white box tahapan uji

Perbedaan White Box & Black Box:

White box (Struktural) 

White box adalah pengujian yang didasarkan pada pengecekan terhadap detail perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.

-Dilakukan oleh penguji yang mengetahui tentang QA.

-Melakukan testing pada software/program aplikasi menyangkut security dan performance program tersebut (meliputi tes code, desain implementasi, security, data flow, software failure).

-Dilakukan seiring dengan tahapan pengembangan software atau pada tahap testing. 

BlackBox  (Fungsional) 

Black box adalah pengujian yang dilakukan hanya mengamati hasil eksekusi melalui data uji dan memeriksa fungsional dari perangkat lunak. Jadi dianalogikan seperti kita melihat suatu koatak hitam, kit hanya bisa melihat penampilan luarnya saja, tanpa tau ada apa dibalik bungkus hitam nya. Sama seperti pengujian black box, mengevaluasi hanya dari tampilan luarnya(interface nya) , fungsionalitasnya.tanpa mengetahui apa sesungguhnya yang terjadi dalam proses detilnya (hanya mengetahui input dan output).

-Dilakukan oleh penguji Independent.

-Melakukan pengujian berdasarkan apa yang dilihat, hanya fokus terhadap fungsionalitas dan output. Pengujian lebih ditujukan pada desain software sesuai standar dan reaksi apabila terdapat celah-celah bug/vulnerabilitas pada program aplikasi tersebut setelah dilakukan white box testing. 

-Dilakukan setelah white box testing. 

Estimasi berdasarkan sejarah

Untuk estimasi berdasarkan sejarah, pertama harus mempelajari serta memahami sejarah berapa lama masing-masing tugas dapat diselesaikan dan siapa yang bertanggung jawab atas tugas tersebut. Kemudian dapat dibandingkan tugas yang akan diestimasikan dengan tugas yang sama yang dikerjakan jauh lebih dulu, setelah itu mulailah dengan melakukan estimasi. hal ini dimaksudkan agar sebelumnya menjabarkan suatu proyek ke dalam beberapa tugas yang biasanya diulang dan mudah untuk dibandingkan.

Secara garis bersar yang harus dilakukan adalah  membandingkan  tugas  yang  akan  diestimasik  dengan  tugas  yang sama yang  dikerjakan lebih awal, setelah itu mulailah dengan melakukan estimasi. 

3 jenis COCOMO

COCOMO merupakan singkatan dari Constructive Cost Model yaitu algortima model estimasi biaya perangkat lunak yang dikembangkan dan diterbitkan oleh Barry Boehm. Cocomo merupakan sebuah model – model untuk memperkirakan usaha, biaya dan jadwal untuk proyek-proyek perangkat lunak.

COCOMO pertama kali diterbitkan pada tahun 1981 Barry Boehm W. ‘s Book rekayasa ekonomi Perangkat Lunak sebagai model untuk memperkirakan usaha, biaya, dan jadwal untuk proyek-proyek perangkat lunak. Ini menarik pada studi dari 63 proyek di TRW Aerospace mana Barry Boehm adalah Direktur Riset dan Teknologi Perangkat Lunak pada tahun 1981. Penelitian ini memeriksa proyek-proyek ukuran mulai dari 2.000 sampai 100.000 baris kode , dan bahasa pemrograman mulai dari perakitan untuk PL / I . Proyek-proyek ini didasarkan pada model waterfall pengembangan perangkat lunak yang merupakan pengembangan software proses lazim pada tahun 1981.

Macam-macam COCOMO :

1. Basic COCOMO menghitung usaha pengembangan perangkat lunak (dan biaya) sebagai fungsi dari ukuran program. Ukuran Program dinyatakan dalam perkiraan ribuan baris kode sumber

COCOMO berlaku untuk tiga kelas proyek perangkat lunak:

§  Proyek Organik – “kecil” tim dengan “baik” pengalaman bekerja dengan “kurang kaku” persyaratan

§  Proyek semi-terpisah – “menengah” tim dengan pengalaman bekerja dicampur dengan campuran kaku dan kurang dari kebutuhan kaku

§  Proyek tertanam – dikembangkan dalam satu set “ketat” kendala. Hal ini juga kombinasi proyek organik dan semi-terpisah. ( Hardware, software, operasional ). 

2. Medium COCOMO menghitung usaha pengembangan perangkat lunak sebagai fungsi dari ukuran program yang dan satu set “driver biaya” yang mencakup penilaian subjektif dari produk, perangkat keras, personil dan atribut proyek. Ekstensi ini mempertimbangkan satu set empat “driver biaya”, masing-masing dengan sejumlah atribut anak.

3. Detail COCOMO menggabungkan semua karakteristik versi intermediate dengan penilaian dampak cost driver di setiap langkah (analisis, desain, dll) dari proses rekayasa perangkat lunak.

Model rinci menggunakan pengganda usaha yang berbeda untuk setiap cost driver atribut. Ini Tahap pengganda upaya Sensitif masing-masing untuk menentukan jumlah usaha yang diperlukan untuk menyelesaikan setiap tahap.

Dalam rinci COCOMO, upaya dihitung sebagai fungsi dari ukuran program yang dan satu set driver biaya yang diberikan sesuai dengan setiap fase siklus hidup perangkat lunak.

Sebuah jadwal proyek rinci tidak pernah statis.

Kelima fase rinci COCOMO adalah :

§  rencana dan kebutuhan.

§  desain sistem.

§  desain rinci.

§  kode modul dan uji.

§  integrasi dan pengujian.

Top-down Test

Strategi top-down test ini digunakan jika, modul level atas (high-level modules) dibuat (coding), di test, dan diintegrasikan sebelum modul level bawah (low-level modules). Keuntungannya adalah kesalahan pada modul level atas dapat teridentifikasi lebih dini, kerugiannya adalah pada saat uji coba program akan menemui kesulitan ketika modul level bawah menemukan kesalahan fungsi input-output yang sangat sulit.

Contoh intergration testing
Modul-modul diintegrasi dengan memindahkan downward melalui struktur kontrol. Modul subordinate ke modul kontrol utama digabung ke sistem dalam cara depth-first atau breadth-first.

Proses integrasi:
1. modul kontrol utama digunakan sebagai sebuah test driver, dan stubs disubstitusi untuk semua modul secara langsung ke modul kontrol utama.
2. stub subordinate digantikan sekali satu waktu dengan modul actual.
3. test terkonduksi sebagai tiap modul diintegrasi.
4. pada pelengkapan tiap kumpulan test, stub lainnya diganti dengan modul real.
5. pengujian regresi dapat dikonduksi.

Bottom-up Test

Strategi Bottom-up Test ini digunakan jika, modul level bawah di buat (coding), di test, dan diintegrasikan sebelum modul level atas di buat. Keuntungannya adalah modul level rendah yang merupakan operasi yang paling sulit di implementasikan dan diuji terlebih dahulu. Kerugiannya adalah pendekatan ini sangat sulit untuk di teliti seluruh operasinya, sebelum programnya selesai dibuat.

Contoh Menggunakan bottom-up test

Modul pada level terbawah diintegrasi pertama, kemudian dengan menggerakkan keatas melalui struktur kontrol.
Proses integration:
1. Modul low-level dikombinasikan ke cluster yang menunjukkan sebuah sub-function software spesifik.
2. sebuah driver ditulis untuk meng-coordinate input dan output test case.
3. Test cluster diuji.
4. Driver dipindah dan cluster digabungkan bergerak ke atas dalam struktur program.

Tools Untuk Audit IT

1. ACL (Audit Command Language)

Merupakan perangkat lunak dalam pelaksanaan audit yang di design khusus untuk melakukan analisa data elektronik suatu perusahaan dan membantu menyiapkan laporan audit secara mudah dan interaktif. ACL dapat digunakan untuk user biasa atau yang sudah ahli.

2. NMap (Network Mapper)

NMap bersifat open source yang digunakan untuk audit dalam hal keamanan. Sistem dan administrator menggunakan perangkat lunak ini sebagai persediaan jaringan, mengelola jadwal layanan untuk upgrade, jenis firewall apa yang sedang digunakan, dan lain-lain. NMap berjalan pada semua sistem operasi dan paket biner seperti Linux, serta dapat melakukan transfer data secara fleksibel.

3. Metasploit

Metasploit merupakan perangkat lunak yang dapat membanttu keamanan dan sifat profesionalisme teknologi informasi seperti melakukan identifikasi masalah keamanan, verifikasi kerentanan, dapat melakukan scanning aplikasi website, dan rekayasa sosial.