Nama : Sri Wulandari
Npm : 1208158
kelas : 4ka09
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.
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
*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).
* 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.
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.
Sumber : http://bagusalfiyanto.blogspot.com/2010/06/software-pengujian-perangkat-lunak.html
Read More
<$BlogCommentBody$>
<$BlogCommentDeleteIcon$>