Pert 12 Software Testing Strategies + Tmbhn

7/27/2019 Pert 12 Software Testing Strategies + Tmbhn

1/24

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 5/e and areprovided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001

Chapter 18Software Testing Strategies


2/24


Strategi pengujian perangkat

lunak mengintegrasikanmetode desain test caseperangkat lunak ke dalam

sederetan langkah yangdirencanakan dengan baik,dan hasilnya adalah konstruksi

perangkat lunak yang berhasil


3/24


Verifikasi dan Validasi

Pengujian PL adl satu elemen dari topik yang

lebih luas yang diacu sebagai verifikasi danvalidasi (V & V)

Verifikasi mengacu pada rangkaian aktivitas yangmemastikan PL secara tepat

mengimplementasikan fungsi tertentuValidasi mengacu pada serangkaian aktivitas

yang berbeda yang memastikan PL yangdibangun dapat ditelusuri ke persyaratan

pelanggan


4/24


Verifikasi dan Validasi

Definisi V&V meliputi berbagai aktivitas jaminankualitas PL:

Kajian Teknik Format

Metode RPL

Standar dan Prosedur

Software quality assurance (SQA) dan

Software configuration management (SCM)

PengujianPengukuran


5/24


Testing Strategy

unit test integrationtest

validationtest

systemtest


6/24


Strategi Pengujian


7/24


Unit Testing

moduleto be

tested

test cases

results

softwareengineer

Unit testing berkaitan dengan kode danbiasanya berorientasi pada white box


8/24


Unit Testing (1)

interface

local data structures

boundary conditionsindependent pathserror handling paths

moduleto be

tested

test cases


9/24


Unit Testing (2)interface : diuji untuk memastikan bahwa informasi secara

tepat mengalir masuk dan keluar dari inti

program yang diujilocal data structures : diuji untuk memastikan bahwa data

yang tersimpan secara temporal dapat menjagaintegritasnya selama semua langkah di dalam

suatu algoritma dieksekusiboundary conditions : untuk memastikan bahwa modul

beroperasi dengan tepat pada batas yang yangditentukan untuk membatasi pemrosesan

independent pathserror handling paths


10/24


Unit Test Environment

Module

stub stub

driver

RESULTS

interface

local data structures

boundary conditions

independent pathserror handling paths

test cases


11/24


Integration Testing Strategies

Options:

the big bang approach an incremental construction strategy


12/24


Top Down Integration

top module is tested withstubs

stubs are replaced one ata time, "depth first"

as new modules are integrated,some subset of tests is re-run

A

B

C

D E

F G


13/24


Bottom-Up Integration

drivers are replaced one at a

time, "depth first"

worker modules are grouped intobuilds and integrated

A

B

C

D E

F G

cluster


14/24


Sandwich Testing

Top modules aretested with stubs

Worker modules are grouped intobuilds and integrated

A

B

C

D E

F G

cluster


15/24


High Order Testing

validation test

system test

alpha and beta test

other specialized testing


16/24


Validation Test

Validasi PL dicapai melalui sederetan pengujian

black box (msl: apkh semua persyaratan fungsionadipenuhi, semua persyaratan kinerja dicapai,persyaratan lainnya: transportabilitas,kompatibilitas, pembetulan kesalahan,maintainbilitas)

Kajian konfigurasi

Pengujian alpha (dilakukan pada sisi pengembangoleh pelanggan) dan beta (dilakukan pada satu/lebpelanggan oleh pemakai akhir)

SystemTest


17/24


SystemTest Pengujian perbaikan : memaksa PL gagal dan

memeriksa apakah perbaikan dilakukan dengan tepa

Pengujian keamanan: membuktikan apakahmekanisme perlindungan pada sebuah sistem akanbenar-benar dapat melindungi dari case yang tidakbenar

Pengujian stress : didesain untuk melawan program

dalam keadaan abnormal (msl: kecepatan input datadapat ditambah dengan urutan besaran utkmenentukan bgm fungsi input akan merespon, testcase yang membutuhkan memori maks/sumber daya

lain dapat dieksekusi ) Pengujian kinerja : didesain untuk menguji kinerja ru

time dari PL dalam konteks sistem yang terintegrasi

D b i


18/24


Debugging:A Diagnostic Process

Debugging terjadi akibat dari pengujian yang berhasil.

Jika test case mengungkap kesalahan, maka debugginadl proses menghasilkan penghilangan kesalahan

Debugging bukan pengujian tetapi selalu terjadi sebagBagian akibat dari pengujian


19/24


The Debugging Process

test cases

results

Debugging

suspectedcauses

identifiedcauses

corrections

regressiontests

new testcases


20/24


Debugging Effort

time requiredto diagnose thesymptom anddetermine thecause

time requiredto correct the errorand conductregression tests


21/24


Symptoms & Causes

symptomcause

symptom and cause may begeographically separated

symptom may disappear whenanother problem is fixed

cause may be due to acombination of non-errors

cause may be due to a systemor compiler error

cause may be due toassumptions that everyonebelieves

symptom may be intermittent


22/24


Consequences of Bugs

damage

mildannoying

disturbing

serious

extremecatastrophic

infectious

Bug Type

Bug Catego r ies: function-related bugs,

system-related bugs, data bugs, coding bugs,design bugs, documentation bugs, standardsviolations, etc.


23/24


Debugging Techniques

brute force / testing

backtracking

cause elimination


24/24


Debugging: Final Thoughts

Don't run off half-cocked, think about thesymptom you're seeing.

Use tools (e.g., dynamic debugger) to gainmore insight.

If at an impasse, get help from someone else.

Be absolutely sure to conduct regression testswhen you do "fix" the bug.

1.

2.

3.

4.

Pert 12 Software Testing Strategies + Tmbhn

Documents

Transcript of Pert 12 Software Testing Strategies + Tmbhn