Software pengujian merupakan investigasi dilakukan untuk memberikan stakeholder dengan informasi tentang kualitas produk atau jasa sedang diuji. Software pengujian juga menyediakan independen, objektif perangkat lunak untuk memungkinkan bisnis untuk menghargai dan memahami risiko pada pelaksanaan perangkat lunak. teknik uji meliputi, tetapi tidak terbatas, proses eksekusi sebuah program atau aplikasi dengan tujuan menemukan bug perangkat lunak .

Software pengujian juga dapat dinyatakan sebagai proses untuk memvalidasi dan memverifikasi bahwa program software / aplikasi / produk:

1. memenuhi persyaratan bisnis dan teknis bahwa desain yang dibimbing dan pengembangan;
2. bekerja seperti yang diharapkan, dan
3. dapat diimplementasikan dengan karakteristik yang sama.

Software pengujian, tergantung pada metode pengujian yang digunakan, dapat diterapkan pada setiap saat dalam proses pembangunan. Namun, sebagian besar upaya uji terjadi setelah persyaratan yang telah dibuat dan proses pengkodean telah selesai. Dengan demikian, metodologi tes diatur oleh metodologi pengembangan perangkat lunak diadopsi.

model pengembangan perangkat lunak yang berbeda-beda akan memfokuskan upaya uji pada titik-titik yang berbeda dalam proses pembangunan. model-model pembangunan yang lebih baru, seperti Agile , sering menggunakan didorong pengembangan tes dan menempatkan porsi peningkatan pengujian di tangan pengembang, sebelum mencapai sebuah tim penguji formal. Dalam model yang lebih tradisional, sebagian besar terjadi setelah pelaksanaan tes persyaratan yang telah dibuat dan proses pengkodean telah selesai.

Sejarah

Pemisahan debugging dari pengujian pada awalnya diperkenalkan oleh Glenford J. Myers pada tahun 1979. Meskipun perhatiannya adalah pada pengujian kerusakan (“tes yang sukses adalah salah satu yang menemukan bug”) itu diilustrasikan keinginan komunitas rekayasa perangkat lunak untuk memisahkan kegiatan pembangunan mendasar, seperti debug, dari verifikasi. Dave Gelperin dan William C. Hetzel diklasifikasikan pada tahun 1988 tahapan dan tujuan dalam pengujian perangkat lunak dalam tahap berikut:

* Sampai 1956 – Debugging berorientasi
*1957-1978 – Peragaan berorientasi
*1979-1982 – Pemusnahan berorientasi
*1983-1987 – Evaluasi berorientasi
* 1988-2000 – Pencegahan berorientasi

Software Pengujian Topik

Ruang Lingkup

Tujuan utama pengujian adalah untuk mendeteksi kegagalan perangkat lunak sehingga cacat dapat ditemukan dan diperbaiki. Pengujian tidak dapat menetapkan bahwa fungsi produk dengan benar dalam semua kondisi namun hanya dapat menetapkan bahwa hal itu tidak berfungsi sebagaimana mestinya dalam kondisi tertentu. Ruang lingkup pengujian perangkat lunak sering kali berisi pemeriksaan kode serta pelaksanaan kode dalam berbagai lingkungan dan kondisi serta memeriksa aspek kode: melakukannya melakukan apa yang seharusnya dilakukan dan melakukan apa yang perlu dilakukan. Dalam budaya saat ini pengembangan perangkat lunak, sebuah organisasi pengujian mungkin terpisah dari tim pengembangan. Ada berbagai peran untuk menguji anggota tim. Informasi yang diperoleh dari pengujian perangkat lunak yang dapat digunakan untuk memperbaiki proses dimana perangkat lunak dikembangkan.

Fungsional vs non-fungsional pengujian

pengujian Fungsional mengacu pada tes yang memverifikasi tindakan spesifik atau fungsi dari kode. Ini biasanya ditemukan dalam dokumentasi kode persyaratan, meskipun beberapa metodologi pengembangan kerja dari kasus penggunaan atau cerita-cerita pengguna. tes Fungsional cenderung menjawab pertanyaan “bisa pengguna melakukan ini” atau “apakah ini bekerja fitur tertentu”.

Pengujian non-fungsional mengacu pada aspek perangkat lunak yang mungkin tidak terkait dengan fungsi tertentu atau tindakan pengguna, seperti skalabilitas atau keamanan . pengujian non-fungsional cenderung untuk menjawab pertanyaan seperti “berapa banyak orang bisa login sekaligus”, atau “bagaimana mudah adalah untuk hack software ini”.

Cacat dan Kegagalan

Tidak semua cacat software disebabkan oleh kesalahan coding Salah satu sumber umum dari cacat mahal disebabkan oleh kesenjangan kebutuhan, misalnya, persyaratan yang belum diakui, yang mengakibatkan kesalahan dari kelalaian oleh perancang program. Sebuah sumber umum persyaratan kesenjangan adalah persyaratan non-fungsional seperti testability , skalabilitas , rawatan , kegunaan , kinerja , dan keamanan .

Software kesalahan terjadi melalui proses berikut. Seorang pemrogram membuat kesalahan (kesalahan), yang menghasilkan cacat (salah, bug) dalam perangkat lunak kode sumber . Jika cacat ini dijalankan, dalam situasi tertentu sistem akan menghasilkan hasil yang salah, menyebabkan kegagalan . Tidak semua cacat tentu akan menghasilkan kegagalan. Misalnya, cacat kode mati tidak akan mengakibatkan kegagalan. cacat A dapat berubah menjadi kegagalan ketika lingkungan berubah. Contoh dari perubahan lingkungan termasuk perangkat lunak yang berjalan di sebuah baru hardware platform, perubahan dalam sumber data atau berinteraksi dengan perangkat lunak yang berbeda.Sebuah cacat tunggal dapat mengakibatkan berbagai gejala kegagalan.

Kesalahan Pencarian Awal

Hal ini umumnya percaya bahwa cacat sebelumnya ditemukan lebih murah itu adalah untuk memperbaikinya. Tabel berikut menunjukkan biaya memperbaiki cacat tergantung di atas panggung itu ditemukan. Sebagai contoh, jika masalah di persyaratan hanya ditemukan pasca-release, maka akan biaya 1-10 kali lebih untuk memperbaiki daripada jika itu sudah ditemukan oleh review persyaratan.

Kompatibilitas

Penyebab umum kegagalan perangkat lunak (nyata atau dianggap) adalah kurangnya kompatibilitas dengan lain perangkat lunak aplikasi , sistem operasi (atau sistem operasi versi , lama atau baru), atau lingkungan target yang berbeda jauh dari aslinya (seperti terminal atau GUI aplikasi ditujukan untuk berjalan di desktop sekarang sedang dibutuhkan untuk menjadi aplikasi web , yang harus membuat dalam browser web ). Misalnya, dalam kasus kurangnya kompatibilitas ke belakang , ini dapat terjadi karena programmer mengembangkan dan menguji perangkat lunak hanya pada versi terbaru dari lingkungan target, yang tidak semua pengguna dapat berjalan. Hal ini menghasilkan konsekuensi yang tidak diinginkan bahwa pekerjaan terbaru mungkin tidak berfungsi pada versi sebelumnya dari lingkungan target, atau pada perangkat keras lama bahwa versi sebelumnya dari lingkungan target mampu menggunakan. Kadang-kadang isu-isu tersebut dapat diperbaiki dengan proaktif abstrak fungsi sistem operasi ke dalam program yang terpisah modul atau perpustakaan .

Input kombinasi dan Prasyarat

Sebuah masalah yang sangat mendasar dengan pengujian perangkat lunak adalah bahwa pengujian di bawah semua kombinasi input dan prasyarat (keadaan awal) tidak layak, bahkan dengan produk yang sederhana. Ini berarti bahwa jumlah cacat pada produk perangkat lunak dapat sangat besar dan cacat yang jarang terjadi sulit ditemukan dalam pengujian. Lebih penting lagi, fungsional non- dimensi kualitas (bagaimana seharusnya versus apa yang seharusnya dilakukan) – kegunaan , skalabilitas , kinerja , kompatibilitas , reliabilitas -bisa sangat subjektif, sesuatu yang merupakan nilai yang cukup untuk satu orang mungkin tak tertahankan lain.

Pengujian Statis VS Dinamis

Ada banyak pendekatan untuk pengujian perangkat lunak. Ulasan , penelusuran , atau inspeksi dianggap sebagai pengujian statis , sedangkan benar-benar melaksanakan kode diprogram dengan himpunan uji kasus disebut sebagai pengujian dinamis . Pengujian statis dapat (dan sayangnya dalam praktek sering) diabaikan. pengujian dinamis terjadi ketika program itu sendiri digunakan untuk kali pertama (yang umumnya dianggap sebagai awal tahap pengujian). pengujian dinamis dapat dimulai sebelum program 100% selesai untuk menguji bagian tertentu dari kode (modul atau diskrit fungsi ). Khas teknik untuk hal ini adalah baik menggunakan Rintisan bertopik / driver atau eksekusi dari sebuah debugger lingkungan. Sebagai contoh, spreadsheet program ini, dengan sifatnya, diuji untuk sebagian besar interaktif (” on the fly “), dengan hasil yang ditampilkan segera setelah setiap perhitungan atau manipulasi teks.

Perangkat Lunak Verifikasi dan Validasi

Software pengujian yang digunakan dalam hubungan dengan verifikasi dan validasi :

* Apakah kita membangun perangkat lunak yang tepat? (Yaitu, bukan sesuai spesifikasi).
* Validasi: Apakah kita membangun perangkat lunak yang tepat? (Yakni, apakah ini yang diinginkan oleh pelanggan).

Istilah verifikasi dan validasi yang umum digunakan bergantian dalam industri, melainkan juga umum untuk melihat kedua istilah ini tidak benar didefinisikan. Menurut Standar IEEE Istilah Istilah Rekayasa Perangkat Lunak:

Verifikasi adalah proses mengevaluasi suatu sistem atau komponen untuk menentukan apakah produk dari tahap pengembangan yang diberikan memenuhi kondisi yang dikenakan pada awal fase itu.
Validasi adalah proses mengevaluasi suatu sistem atau komponen selama atau pada akhir proses pembangunan untuk menentukan apakah memenuhi persyaratan yang ditentukan.

Tim Pengujian perangkat lunak

Software pengujian dapat dilakukan oleh perangkat lunak penguji . Sampai tahun 1980-an istilah “software tester” digunakan secara umum, tetapi kemudian juga dilihat sebagai profesi yang terpisah. Mengenai periode dan tujuan yang berbeda dalam pengujian perangkat lunak, peran yang berbeda telah ditetapkan: manajer, memimpin, uji desainer, tester, pengembang otomasi, dan pengawas tes.

Software Quality Assurance (SQA)

Meskipun kontroversial, pengujian perangkat lunak dapat dilihat sebagai bagian penting dari jaminan kualitas perangkat lunak (SQA) proses. Dalam SQA, spesialis proses software dan auditor mengambil pandangan yang lebih luas pada perangkat lunak dan pengembangannya. Mereka memeriksa dan mengubah proses rekayasa perangkat lunak itu sendiri untuk mengurangi jumlah kesalahan yang berakhir di perangkat lunak yang dikirimkan: cacat yang disebut tingkat-begitu.

Apa yang merupakan tingkat kecacatan “diterima” tergantung pada sifat dari perangkat lunak. Sebagai contoh, sebuah video game arcade dirancang untuk mensimulasikan pesawat terbang mungkin akan memiliki toleransi lebih tinggi banyak cacat daripada misi kritis perangkat lunak seperti yang digunakan untuk mengontrol fungsi sebuah pesawat itu benar-benar terbang!

Meskipun ada hubungan yang erat dengan SQA, pengujian departemen sering ada secara independen, dan mungkin tidak ada fungsi SQA di beberapa perusahaan.

Software pengujian adalah tugas dimaksudkan untuk mendeteksi cacat pada piranti lunak oleh kontras hasil program komputer yang diharapkan dengan hasil aktual untuk satu set input. Sebaliknya, QA (jaminan mutu) adalah implementasi kebijakan dan prosedur yang dimaksudkan untuk mencegah kerusakan dari yang terjadi di tempat pertama.

Dalam melakukan analisa kebutuhan yang sesungguhnya di lapangan, kita akan sering menemukan hal-hal yang kurang diharapkan. Misalnya, klien yang meminta pembuatan perangkat lunak tidak memiliki pengetahuan yang cukup tentang hal yang berkaitan dengan komputer, pemrograman, dan yang berhubungan dengan teknologi informasi. Ini cukup merepotkan, karena akan memerlukan usaha yang banyak untuk menggali apa keinginan mereka sesungguhnya.

Persoalan lain yang juga cukup kerap ditemui adalah cara klien dalam mengungkapkan keinginan mereka. Banyak kasus memperlihatkan bahwa informasi yang disampaikan sangat tidak terstruktur, sehingga cukup merepotkan dalam memahami maksud dari keinginan mereka. Bahkan ada informasi yang semestinya dijelaskan tidak diberikan, dan informasi yang tak berguna malah dipaparkan.

Masalah waktu juga menjadi penghalang lainnya. Banyak klien tidak memberi waktu yang cukup. Waktu yang kurang dalam proses analisa kebutuhan perangkat lunak, jelas akan menyebabkan tidak terkumpulnya dengan lengkap apa yang diinginkan oleh klien. Masalah penyediaan waktu ini bisa terjadi pada kedua belah pihak.

Beberapa langkah yang akan digambarkan berikut ini, dapat dilakukan ketika melakukan analisa kebutuhan. Cara-cara tersebut bisa memberikan bantuan yang cukup berarti untuk memperoleh analisa kebutuhan yang baik, dan diharapkan dapat memenuhi tiga faktor utama yang mesti dipenuhi dalam membuat analisa kebutuhan.

3.1 Komunikasi yang Baik

Salah satu hal yang diperlukan adalah membangun hubungan yang baik dengan klien. Kemampuan seorang analis dalam menciptakan hubungan sosial dengan pihak lain, dalam situasi ini adalah dengan klien, menjadi bantuan yang signifikan. Hubungan sosial yang baik dengan klien akan menjadikan komunikasi yang terbuka dan lancar. Dan ini sudah mengurangi banyak masalah, ketika berada dalam proses mendapatkan informasi dari klien.

Mengenal lebih dekat klien anda, artinya akan bisa menciptakan komunikasi yang lebih lancar dan tidak terlalu formal. Dengan keadaan yang bisa dibuat seperti ini, maka banyak hal yang bisa diketahui dengan baik, sehingga kemungkinan kesalahan dalam berkomunikasi bisa direduksi.

Apabila ada informasi yang disampaikan oleh klien yang kurang terstruktur, atau sulit dipahami, bisa ditanyakan lebih lanjut lagi, tanpa harus kesulitan karena masalah komunikasi yang kurang lancar. Biasanya analis akan malas bertanya lebih jauh, jika komunikasi yang terbangun kurang baik. Ini pasti mejadi salah satu penyebab kegagalan dalam mengetahui apa yang dibutuhkan klien.

3.2 Mengetahui "Apa"

Yang perlu diketahui dari klien adalah tentang apa yang dikerjakannya, apa data yang menjadi masukan, apa yang dihasilkan. Jangan terburu-buru menanyakan bagaimana cara mengerjakannya. Jika kita bisa mengetahui apa sebenarnya yang dihasilkan dan apa yang menjadi masukan, ini adalah langkah baik untuk memperoleh gambaran tentang kebutuhan akan sebuah perangkat lunak.

Kumpulkan dokumen-dokumen yang selama ini digunakan oleh klien. Bisa jadi itu berupa tabel, formulir, laporan, daftar, dan semua "apa" yang berkaitan dengan perangkat lunak yang akan membantu pekerjaan mereka nantinya.

3.3 Gunakan Istilah yang Sederhana

Dalam berkomunikasi dengan klien, terutama ketika dalam proses analisa kebutuhan, jangan menggunakan istilah yang sulit dimengerti. Kebiasaan menggunakan istilah yang sulit, atau sangat spesifik dalam bidang komputer mungkin akan menjadikan orang kagum dengan anda, tapi ini bisa menjadi sebuah bencana. Komunikasi bisa menjadi tidak lancar, dan berpeluang menimbulkan kesalahpahaman. Tidaklah menjadi soal jika klien adalah orang yang cukup familiar dan juga bergelut dengan keahlian yang sama dengan pihak yang melakukan analisa.

3.4 Terbuka dengan Langkah yang Dilakukan

Bersikap terbuka tentang apa saja yang kita lakukan selama proses pembuatan perangkat lunak, adalah tindakan yang cukup membantu. Untuk sebuah pilihan yang diminta oleh klien, kita dapat juga memberitahu konsekuensinya. Ini akan membantu kedua belah pihak dalam memperoleh sebuah keputusan jika ada berbagai pilihan.

Dengan cara ini, klien akan mengerti mengapa satu hal harus begini, dan mengapa hal lain harus dengan cara tertentu juga. Klien yang ikut memahami sejumlah langkah dan konsekuensi terhadap pilihan tertentu, akan lebih kooperatif dalam menyampaikan kebutuhan mereka. Ini mengurangi tuntutan yang yang tidak perlu ketika perangkat lunak yang akan dihasilkan tersebut mulai digunakan.

3.5 Menampilkan Contoh Nyata

Tampilkan contoh yang nyata ketika klien memberitahu apa yang akan dimintanya. Bisa jadi contoh nyata ini dibuat oleh analis, atau juga contohnya dilihat dari apa yang sudah dimiliki klien. Misalkan untuk proses entri data. Klien dan analis sama-sama menyaksikan bagaimana proses entri data tersebut. Dengan cara ini akan sangat jelas apa yang dimaksud oleh klien.

Jika hanya disampaikan dengan deskripsi, kemungkinan interpretasi yang salah cukup terbuka lebar. Sedangkan dengan langsung menyaksikan, akan banyak mengurangi kesalahpahaman.

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

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.

Dalam melakukan uji coba ada 2 masalah penting yang akan dibahas, yaitu :

A. Teknik uji coba perangkat lunak

B. Strategi uji coba perangkat lunak



TEKNIK UJI COBA PERANGKAT LUNAK

Pada dasarnya, pengujian merupakan suatu proses rekayasa perangkat lunak yg dapat dianggap (secara psikologis) sebagai hal yg destruktif daripada konstruktif.



SASARAN PENGUJIAN (Glen Myers) :

1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan.
2. Test case yg baik adalah test case yg memiliki probabilitas tinggi untuk menemukan kesalahan yg belum pernah ditemukan sebalumnya.
3. Pengujian yg sukses adalah pengujian yg mengungkap semua kesalahan yg belum pernah ditemukan sebelumnya.



PRINSIP PENGUJIAN (diusulkan Davis) :

1. Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.
2. Pengujian harus direncanakan lama sebelum pengujian itu dimulai.
3. Prinsip Pareto berlaku untuk pengujian perangkat lunak. Prinsip Pareto mengimplikasikan 80% dari semua kesalahan yg ditemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20% dari semua modul program.
4. Pengujian harus mulai "dari yg kecil" dan berkembang ke pengujian "yang besar".
5. Pengujian yg mendalam tidak mungkin.
6. Paling efektif, pengujian dilakukan oleh pihak ketiga yg independen.



TESTABILITAS

Testabilitas perangkat lunak adalah seberapa mudah sebuah program komputer dapat diuji. Karena pengujian sangat sulit, perlu diketahui apa yg dapat dilakukan untuk membuatnya menjadi mudah.

Karakteristik perangkat lunak yg diuji :

* OPERABILITAS, semakin baik dia bekerja semakin efisien dia dapat diuji.
* OBSERVABILITAS, apa yg anda lihat adalah apa yg anda uji.
* KONTROLABILITAS, semakin baik kita dapat mengontrol perangkat lunak semakin banyak pengujian yg adapat diotomatisasi dan dioptimalkan.
* DEKOMPOSABILITAS, dengan mengontrol ruang lingkup pengujian kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali.
* KESEDERHANAAN, semakin sedikit yg diuji semakin cepat pengujian.
* STABILITAS, semakin sedikit perubahan semakin sedikit gangguan pengujian.
* KEMAMPUAN DIPAHAMI, semakin banyak informasi yg dimiliki semakin detail pengujiannya.



ATRIBUT PENGUJIAN YG BAIK :

* Memiliki probabilitas yg tinggi menemukan kesalahan.
* Tidak redundan.
* Harusnya ‘jenis terbaik’.
* Tidak boleh terlalu sederhana atau terlalu kompleks.



DESAIN TEST CASE

Terdapat bermacam-macam rancangan metode test case yg dapat digunakan, semua menyediakan pendekatan sistematis untuk uji coba, yg terpenting metode menyediakan kemungkinan yg cukup tinggi menemukan kesalahan.







Terdapat 2 macam test case:

1. Pengetahuan fungsi yg spesifik dari produk yg telah dirancang untuk diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana yg diharapkan.
2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk memperlihatkan cara kerja dari produk secara rinci sesuai dengan spesifikasinya.



Dua macam pendekatan test yaitu :

1. Black Box Testing

Test case ini bertujuan untuk menunjukkan fungsi perangkat lunak tentang cara beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya.

Tehnik pengujian black-box berfokus pada domain informasi dari perangkat lunak, dengan melakukan test case dengan menpartisi domain input dari suatu program dengan cara yang memberikan cakupan pengujian yang mendalam.

Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis nilai batas memeriksaa kemampuan program untuk menangani data pada batas yang dapat diterima.

Metode pengujian yang terspesialisasi meliputi sejumlah luas kemampuan perangkat lunak dan area aplikasi. GUI, arsitektur client/ server, dokumentasi dan fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan tehnik khusus untuk pengujian perangkat lunak.



2. White Box Testing

Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) perangkat lunak akan ditest dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.

Pengujian white-box berfokus pada struktur control program. Test case dilakukan untuk memastikan bahwa semua statemen pada program telah dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang independent secara linear yang akan memastikan cakupan.

Pengujian aliran data dan kondisi lebih lanjut menggunakan logika program dan pengujian loop menyempurnakan tehnik white-box yang lain dengan memberikan sebuah prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi. Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan fungsional tanpa mengabaikan kerja internal dari suatu program.



STRATEGI UJI COBA PERANGKAT LUNAK

Strategi uji coba perangkat lunak memudahkan para perancang untuk menentukan keberhasilan system yg telah dikerjakan. Hal yang harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yg diperlukan.

Strategi uji coba mempunyai karakteristik sbb :

* Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan dgn modul di atasnya kemudian hasilnya dipadukan.
* Teknik pengujian yang berbeda mungkin menghasilakn sedikit perbedaan (dalam hal waktu)
* Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatu kelompok pengujian yang independen.
* Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalam strategi pengujian.

Pengujian perangkat lunak adalah satu elemen dari topik yang lebih luas yang sering diacu sebagai verifikasi dan validasi (V& V).

Verifikasi : Kumpulan aktifitas yg menjamin penerapan perangkat lunak benar-benar sesuai dgn fungsinya.

Validasi : Kumpulan aktivitas yang berbeda yang memastikan bahwa perangkat lunak yang dibangun dapat memenuhi keperluan pelanggan.



1. PENGUJIAN UNIT

Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain perangkat lunak, yakni modul. Uji coba unit selalu berorientasi pada white box testing dan dapat dikerjakan paralel atau beruntun dengan modul lainnya.



2. PENGUJIAN INTEGRASI

Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur program, pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yg nantinya digabungkan dengan interface.

Metode pengujian

a) top down integration

b) buttom up integration



a) Top- down integration

Top down integration adalah pendekatan incremental dengan menggerakkan ke bawah melalui hirarki control, dimulai dengan control utama. Strategi intergrasi top-down memeriksa control mayor atau keputusan pada saat awal di dalam proses pengujian. Pada struktur program yang difaktorkan dengan baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi sehingga terjadi lebih dulu.

Strategi top-down kelihatannya tidak sangat rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic. Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.







b) Pengujian Integrasi Bottom-up

Bottom up integration memulai konstruksi dan pengujian dengan modul atomic (modul pada tingkat paling rendah pada struktur program). Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi integrasi bottom-up dapat diimplementasi dengan langkah-langkah:

1. modul tingkat rendah digabung ke dalam cluster (build) yang melakukan subfungsi perangkat lunak spesifik.
2. Driver (program control untuk pengujian) ditulis untuk mengkoordinasi input dan output test case
3. cluster diuji
4. driver diganti dan cluster digabungkan dengan menggerakkannya ke atas di dalam struktur program.

About this blog

About Me

Foto Saya
Bagus Alfiyanto
Mahasiswa yang ga mau repot
Lihat profil lengkapku

Followers

Powered By Blogger

Archive blog