Teknik Informatika S1

Testing

Rekayasa Perangkat Lunak

1

Software Testing Objectives

Pengujian?

2

Software Testing Objectives

Pengujian adalah proses eksekusi program dengan

maksud menemukan kesalahan.

Sebuah test case yang baik adalah dengan probabilitas

tinggi untuk menemukan suatu yang belum ditemukan

kesalahan.

Sebuah tes yang sukses adalah menemukan kesalahan

yang belum ditemukan.

3

Strategic Approach to Software Testing

Pengujian dimulai pada tingkat komponen dan bekerja ke luar

menuju integrasi seluruh sistem yang berbasis komputer.

Teknik pengujian yang berbeda sesuai pada berbagai titik

dalam waktu tertentu.

Pengembang perangkat lunak melakukan pengujian dan dapat

dibantu oleh kelompok uji independen (ITG) untuk proyek-

proyek besar.

Pengujian dan debugging merupakan aktivitas yang berbeda.

* Debugging harus diakomodasi dalam strategi pengujian.

4

Verification and Validation

Verifikasi (are we building the product right?)

Validasi (are we building the right product?)

Pengujian Software adalah hanya salah satu unsur

Software Quality Assurance (SQA)

Kualitas harus dibangun untuk proses pembangunan,

Anda tidak dapat menggunakan pengujian untuk

menambah kualitas setelah fakta yang ada

5

Organizing for Software Testing

Peran Uji Kelompok Independen (ITG) adalah untuk menghilangkan konflik kepentingan yang melekat ketika pembangun sedang menguji produk sendiri.

Kesalahpahaman mengenai penggunaan tim pengujian independen o Pengembang harus melakukan pengujian yang tidak ada sama

sekali o Software dilempar "over the wall" kepada orang-orang untuk

menguji tanpa ampun o Penguji tidak terlibat dengan proyek ini sampai saatnya untuk

itu harus diuji

Para pengembang dan ITGC harus bekerja sama di seluruh proyek perangkat lunak untuk memastikan bahwa tes menyeluruh akan dilakukan

6

Software Testing Strategy for

Traditional Software Architectures

Unit Testing

Menitikberatkan pada penggunaan teknik pengujian aliran

kontrol tertentu untuk mendeteksi kesalahan dalam setiap komponen

perangkat lunak individual

Integration Testing

Berfokus pada isu-isu yang terkait dengan verifikasi dan

konstruksi program sebagai komponen yang berinteraksi satu sama

lain

7

Software Testing Strategy for

Traditional Software Architectures

Validation Testing

Memberikan jaminan bahwa kriteria validasi perangkat lunak

(selama analisis kebutuhan) memenuhi semua persyaratan fungsional,

perilaku, dan kinerja

System Testing

Memverifikasi bahwa semua elemen sistem berjalan dengan

benar dan bahwa fungsi sistem secara keseluruhan dan kinerja yang

telah dicapai

8

Strategic Testing Issues

Tentukan persyaratan produk secara kuantitatif sebelum

pengujian dimulai.

Tentukan tujuan pengujian secara eksplisit.

Mengidentifikasi kategori pengguna untuk perangkat

lunak dan mengembangkan profil untuk masing-masing.

Mengembangkan rencana tes yang menekankan pengujian

siklus yang cepat.

9

Strategic Testing Issues

Membangun perangkat lunak yang kuat yang dirancang

untuk menguji dirinya sendiri.

Gunakan bahasa formil efektif sebagai filter sebelum

pengujian.

Melakukan tinjauan teknis formal untuk menilai strategi

tes dan uji kasus.

Mengembangkan pendekatan perbaikan terus-menerus

untuk proses pengujian.

10

Unit Testing

Interface modul diuji untuk aliran informasi yang tepat.

Data lokal diperiksa untuk memastikan bahwa integritas

dipertahankan.

Kondisi batas diuji.

Dasar (independen) jalur diuji.

Semua jalur penanganan kesalahan harus diuji.

11

Integration Testing

Pengujian integrasi Top-down

Main control modul yang digunakan sebagai test driver dan stub

merupakan pengganti untuk komponen langsung bawahan untuk itu.

Rintisan bertopik bawahan diganti satu per satu dengan komponen

yang nyata (setelah depth-first atau breadth-first approach).

Pengujian dilakukan karena setiap komponen terintegrasi.

Setelah menyelesaikan setiap rangkaian tes dan rintisan lainnya

diganti dengan komponen nyata, pengujian regresi dapat digunakan

untuk memastikan bahwa kesalahan baru tidak diperkenalkan.

12

Integration Testing

Pengujian integrasi Bottom-up

Komponen tingkat rendah digabungkan ke dalam kelompok yang

melakukan fungsi perangkat lunak tertentu.

Program kontrol ditulis untuk mengkoordinasikan masukan kasus uji

dan output.

Cluster ini diuji.

Driver dihapus dan cluster dikombinasikan bergerak ke atas dalam

struktur program.

13

Integration Testing (2)

Pengujian regresi

Digunakan untuk memeriksa cacat disebarkan ke modul lain dengan

perubahan yang dibuat untuk program yang ada

Sampel yang representatif dari kasus uji yang ada digunakan untuk

melaksanakan semua fungsi perangkat lunak.

Kasus uji tambahan memfokuskan fungsi perangkat lunak mungkin

akan terpengaruh oleh perubahan itu.

Tes kasus yang berfokus pada komponen perangkat lunak berubah.

(baik top-down atau bottom integrasi dapat digunakan).

14

Integration Testing (2)

Smoke Testing

Komponen perangkat lunak yang sudah diterjemahkan ke dalam

kode diintegrasikan ke dalam untuk membangun.

Serangkaian tes yang dirancang untuk mengekspos kesalahan dari

fungsi yang diciptakan.

Pembangunan ini terintegrasi dengan yang lain.

15

General Software Test Criteria

Interface integrity

Interface modul internal dan eksternal diuji karena setiap

modul atau cluster ditambahkan ke perangkat lunak

Validitas fungsional

Tes untuk mengungkap cacat fungsional dalam perangkat lunak

Information content

Tes untuk kesalahan dalam struktur data lokal atau global

Performance

Batas kinerja tertentu diuji

16

Acceptance Testing

Memastikan perangkat lunak tersebut bekerja dengan

benar untuk pengguna dimaksudkan dalam lingkungan

kerja yang normal.

Pengujian Alpha - Versi perangkat lunak lengkap diuji

oleh pelanggan di bawah pengawasan pengembang di

situs pengembang

Pengujian beta - Versi perangkat lunak yang lengkap

diuji oleh pelanggan pada situs-nya sendiri tanpa

pengembang yang hadir

17

System Testing

Recovery testing

o Memeriksa kemampuan sistem untuk pulih dari kegagalan

Security testing

o Memverifikasi bahwa mekanisme perlindungan sistem mencegah

penetrasi yang tidak tepat atau terjadi perubahan data

18

System Testing

Stress testing

o Program diperiksa untuk melihat seberapa baik berkaitan dengan

tuntutan sumber daya yang abnormal (yaitu, jumlah, frekuensi,

atau volume)

Performance testing

o Dirancang untuk menguji kinerja run-time perangkat lunak,

khususnya perangkat lunak real-time

19

Debugging

Debugging (penghapusan cacat) terjadi sebagai

konsekuensi dari pengujian yang berhasil.

Beberapa orang lebih baik dalam debugging daripada

yang lain.

Pendekatan umum:

Brute force - dump memori dan jejak run-time diperiksa untuk

petunjuk penyebab kesalahan

Backtracking - kode sumber diperiksa dengan melihat mundur dari

gejala untuk potensi penyebab kesalahan

Cause elimination - menggunakan partisi biner untuk mengurangi

jumlah lokasi yang potensial (di mana kesalahan bisa eksis) 20

Pertimbangan Bug Removal

• Apakah penyebab bug direproduksi di bagian lain dari

program ini?

• Apa "bug berikutnya" mungkin diperkenalkan oleh

perbaikan yang diusulkan?

• Apa yang bisa dilakukan untuk mencegah bug ini di

tempat pertama?

21

Software Testability Checklist

Operability

Semakin baik kerja software semakin efisien untuk diuji

Observabilty

Apa yang Anda lihat adalah apa yang anda uji

Controllability

Perangkat lunak lebih baik dapat dikontrol lebih sehingga pengujian

dapat diotomatisasi dan dioptimalkan

Decomposability

Dengan mengontrol ruang lingkup pengujian, semakin cepat masalah

dapat diisolasi dan diuji ulang dengan cerdas

22

Software Testability Checklist

Simplicity

Semakin sederhana perangkat lunak, semakin cepat kita menguji

Stability

Semakin sedikit perubahan, semakin sedikit gangguan pengujian

Understandability

Semakin banyak informasi diketahui, semakin cerdas pengujian

23

Good Test Attributes

Sebuah tes yang baik memiliki probabilitas tinggi untuk

menemukan kesalahan.

Sebuah tes yang baik adalah tidak berlebihan.

Sebuah tes yang baik harus berkembang.

Sebuah tes yang baik tidak boleh terlalu sederhana

atau terlalu rumit.

24

Test Case Design Strategies

Black-box or behavioral testing

Mengetahui fungsi tertentu produk adalah untuk melakukan dan menunjukkan

operasi yang benar hanya berdasarkan spesifikasi tanpa memperhatikan logika

internal

White-box or glass-box testing

Mengetahui kerja internal suatu produk, tes dilakukan untuk memeriksa kerja dari

semua kemungkinan jalur logika

25

Test Case Design Strategies

White-box or glass-box testing (Struktural)

White box testing 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%.

26

Test Case Design Strategies

Kelebihan White Box Testing

i. Kesalahan logika. Digunakan pada sintaks ‘if’ dan pengulangan. Dimana White Box Testing akan mendeteksi kondisi-kondisi yang tidak sesuai dan mendeteksi kapan proses pengulangan akan berhenti.

ii. Ketidaksesuaian asumsi. Menampilkan asumsi yang tidak sesuai dengan kenyataan, untuk di analisa dan diperbaiki.

iii. Kesalahan ketik. Mendeteksi bahasa pemrograman yang bersifat case sensitive.

Kelemahan White Box Testing Untuk perangkat lunak yang tergolong besar, White Box Testing dianggap sebagai strategi yang tergolong boros, karena akan melibatkan sumber daya yang besar untuk melakukannya.

27

Test Case Design Strategies

Black-box or behavioral testing

Black box testing adalah pengujian yang dilakukan hanya mengamati hasil

eksekusi melalui data uji dan memeriksa fungsional dari perangkat lunak.

Jadi dianalogikan seperti kita melihat suatu kotak hitam, kita hanya bisa

melihat penampilan luarnya saja, tanpa tau ada apa dibalik bungkus hitam

nya. Sama seperti pengujian black box, mengevaluasi hanya dari tampilan

luarnya (interfacenya), fungsionalitasnya tanpa mengetahui apa

sesungguhnya yang terjadi dalam proses detilnya (hanya mengetahui input

dan output). 28

Test Case Design Strategies

Kelebihan Black-box or behavioral testing

i. Dapat memilih subset test secara efektif dan efisien

ii. Dapat menemukan cacat

iii. Memaksimalkan testing investment

Kelemahan Black-box or behavioral testing

Tester tidak pernah yakin apakah PL tersebut benar – benar lulus uji.

29

TERIMA KASIH

30