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