Rekayasa Perangkat Lunak

Sesi 14Software Testing

Outline of this presentation

• What Testing is• Testing In Development Process• Types Of Testing and Definitions• Verification & Validation• Purpose and Goal of Testing• Who Tests Software• Testing Technique• Testing Step• Testing Strategy

2

What’s Wrong?

3

TF

A=2 ?

A=A + 0.1

A=0

Print A Print A

What testing is..................

4

Mau Tau ya....

5

Mau Tau aja atau

mau tau banget ???

6

What testing is..................

7

”Testing is a technical investigation of a product, done to expose quality-related information.”

Testing is to execute a program with the purpose of finding

defects

1) Common definition

2) Wider definition

testing

Testing in Development Process

• Testing activities take place in all parts of software development

• From requirement eliciting to final shipment• Testing is part of the development process• Testing is part of the company business

process

8

Testing in Development Process

• Testing During implementation: test to verify that software behaves as intended by the designer.

• Testing After implementation: test for conformance with requirements and reliability, and other non functional requirement

9

Types of testing and definitions

• Validation and Verification– Validate

• correctness or suitability• vertical experts to confirm master results

– Verification• confirm software operates as it is required• double check to ensure results match those previously

validated and if not then re-validate them

10

11

Maintenance

Testing

Development

Design

Analysis

Requirements

TransitionConstructionInception Elaboration

Cor

e W

orkf

low

PhaseRational UnifiedProcess (RUP)

Testing can take place as part of each phase of development .

12

Maintenance

Testing

Development

Design

Analysis

Requirements

TransitionConstructionInception Elaboration

Cor

e W

orkf

low

PhaseRational UnifiedProcess (RUP)

Test

ing

can

take

pla

ce a

s par

t of e

ach

core

w

orkf

low

invo

lved

in d

evel

opm

ent

orga

niza

tion.

Verification & Validation

• Software V & V defined as a systems engineering methodology to ensure that quality is built into the software during development.

• Software V & V is complementary to and supportive of quality assurance, project management, systems engineering, and development.

13

Verification & Validation versus Debugging

• Verification & Validation– a process that establish the existence of

defects in a system

• Debugging– a process that locates and corrects these

defects

14

Verification versus Validation• Software Verification Process

– is a process for determining whether the software products of an activity fulfill the requirements or conditions imposed on them in the previous activities.

• Software Validation Process– is a process for determining whether the

requirements and the final, as-built system or software product fulfills its specific intended use.

15

Verification versus Validation

• Verification:– “Are we building the system in the right way?”– The system should conform to the specification– It does what you specified it should do

16

Validation: “Are we building the right system? ” The system should do what the users really

requires

The V & V Objectives

• There are two principal objectives:

– To discover and rectify defects in a system

– To assess whether or not the system is usable in an operational situation.

17

The V & V Objectives

• Software V & V determines that the software performs its intended functions correctly.

• Ensure that the software performs no unintended functions

• Measure and assess the quality and reliability of software.

18

The V & V Objectives

• As a software engineering discipline, software V & V also assesses, analyzes, and tests the software on

– how it interfaces with systems elements

– Influences the performance, or reacts to stimuli from system elements

19

The V & V process

• V & V Is a whole life-cycle process

• V & V should be applied at each stage in the software process.

20

21

Formalspecification

High-leveldesign

Requirementsspecification

Detaileddesign

Code/Program

Prototype

Static and Dynamic V&V

Check correspondence between a program and its specification

Are we buildingthe system

In the right way?

Are we buildingthe right system?

StaticVerification

DynamicValidation

Execution base testing

• Static Verification Concerned with analysis of the static

system representation to discover problems– Analysis of all documents produced

that represent the system– Can be applied during all stages of the

software process

22

Static and Dynamic V&V

23

V & V

Inspect artifacts

Dynamic = “testing”

Execute systems

to discover problems(static verification)

observing product behaviour(dynamic validation)

Static

24

V & V

Complements each other

Inspect artifacts

Dynamic = “testing”

Execute systems

Static

25

V & VStatic Dynamic =

”Testing”

Review Inspection Walkthrough

Unit test Integrationtest

AcceptancetestSystem test

Purpose and goal of testing are situation dependent

1. Find defects2. Maximize bug count3. Block premature product releases4. Help managers make ship/no-ship

decisions5. Assess quality6. Minimize technical support costs

26

Purpose and goal of testing are situation dependent

7. Conform to regulations8. Minimize safety-related lawsuit risk9. Assess conformance to specification10.Find safe scenarios for use of the

product (find ways to get it to work, in spite of the bugs)

11.Verify correctness of the product12.Assure quality

27

Purpose and goal of testing are situation dependent

13.Testing cannot show the absence of errors, only their presence

14.We test a program to find the existence of an error

15.If we find no errors then we have been unsuccessful

16.If an error is found debugging should occur

28

Unsuitable objectives with testing

29

Showing that a system is without errors

Show that a system does what it is supposed to do

30

Who Tests Software?

userindependent testerindependent testerdeveloperdeveloper

31

Who Tests Software?

• Software Developer– Understand system– Test gently– Driven by delivery

• Independent Tester– Doesn’t understand system– Will try to break it– Quality driven

32

Who Tests Software?

• User– Test while using it

• It’s not in purpose to do so

– Indirect test

33

Static verification

• Review (desk checking)– Code reading done by a single person, – informal.– Uneffective compared to walkthrough or

inspection

• Walkthrough– The programmer(s) ”walks through”/”executes”

his code while invited participants ask questions and makes comments.

– Relatively informal

• Inspection– Usually a checklist of common errors is used to

compare the code against.

34

Testing Technique

• Two views on Software testing:

White Box Testing

Black boxBlack Box Testing

35

Testing Technique

White box testing - tests what the program does.Test sets are developed by using knowledge of the algorithms, data structures, and control statements.

36

Testing Technique

Black box

Black box testing - tests what the program is supposed to do.Test sets are developed and evaluated solely on the specification. There is no knowledge of the algorithms, data structures, or control statements.

37

White-box testing

Also known as: Structure based (Structural) testing Code based testing Glass box testing Clear box testing Logic driven testing

38

• White-box (or Structural) testing:– Use knowledge of the program to derive

test cases to provide more complete coverage

– Problem: What criteria to use?

White-box testing

39

... our goal is to ensure that all ... our goal is to ensure that all Statements, decisions, conditions, and paths have Statements, decisions, conditions, and paths have been executed at least once ...been executed at least once ...

White-box testing

40

White-box testing

The system is looked upon as an open box. The test cases is based on the internal structure of

the system (code) Theoretically desirable but impossible and

insufficient goal: all paths of the code exercise

41

• Also known as:– Functional Testing

• because it test all the functions– Behavioral Testing

• because the program is tested against the expected behavior (described by requirements and/or design)

Black-box testing

Black box

42

– The software is viewed as a black box which transforms input to output based on the specifications of what the software is supposed to do.

requirements

inputevents

output

Black-box testing

43

– Check The Conformity of the tested S/W against established behaviour, and

– Detect errors generated by fault• Software fault is a software part which is not

according to its definition provided in the development document

Black-box testing

44

– Functional tests examine the observable behavior of software as evidenced by its outputs without reference to internal functions.

– If the program consistently provides the desired features with acceptable performance, then specific source code features are irrelevant.

Black-box testing

45

– Should consider only from the standpoint of its:• Input data• Output data

– Knowledge of its internal structured should not be

– It is very often impossible to test all the input data

– It is hence necessary to select a subset of possible input

Black-box testing

46

Testing Steps

Unittest

Unittest

Unittest

Integrationtest

Functiontest

Performancetest

Acceptancetest

Installationtest

Unit

code

Unit

code

Unit

code

.

.

.

Integratedmodules

Functioningsystem

Verified,validatedsoftware

Acceptedsystem

SYSTEMIN USE!

Designspecifications

Systemfunctional

requirements

Othersoftware

requirements

Customerrequirementsspecification

Userenvironment

Testing StepsAcceptance Test

type of acceptance testing performed by customer at the developer’s site is usually called alpha testing

software

developer site

customertests

48

beta testing is a type of acceptance testing involving a software product to be marketed for use by many users

selected users receive the system first and report problems back to the developer

users enjoy it - usually receive large discounts and feel important

developers like it - exposes their product to real use and often reveals unanticipated errors

software

customer site

customer tests

Testing Steps Acceptance Test

49

Testing Strategy

BigBang!

Top-down

Bottom-up

non-incremental incremental

SandwichCompromise

50

Testing Strategy

Big bang integration (all components together)

Bottom up integration (from lower levels No test stubs necessary)

Top down integration (from higher levels no test drivers are

needed)

Sandwich testing (combination of bottom-up and top-down no test stubs and drivers needed)

Kesawah Naik Bis....

Wahhhh ... materi kuliahnya sudah habis....

Terimakasih…..Untuk mahasiswa/i yang tidak ngantuk dan tetap konsentrasi Mengikuti

Perkuliahan.Semoga Sukses di UAS