Professional Documents
Culture Documents
Integration-
Chapter 16: Testingand
(2/2)
System Testing
Object-Oriented
SoftwareConstruction
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 2
Software Lifecycle Activities ...and their models
class...
class...
class... ?
class.... ?
Application Solution
Use Case Domain Sub- Domain Source Test
Model Objects systems Objects Code Cases
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 3
Test Team
Organizational issues
Professional
Tester too familiar
Programmer with code
Analyst
Test System
User Team Designer
Configuration
Management
Specialist
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 4
Types of Testing
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 5
Types of Testing
♦ System Testing:
The entire system
Carried out by developers (testers!)
Goal: Determine if the system meets the requirements (functional
and global)
Functional Testing: Test of functional requirements
Performance Testing: Test of non-functional requirements
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 6
Integration Testing Strategy
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 7
Example: Three Layer Call Hierarchy
User
Interface Layer III
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 8
Integration Testing:
Big-Bang Approach
Unit Test
A
Don’t try this!
Unit Test
B
Unit Test
C
System Test
Unit Test
D
♦ All components (units) are first tested individually and then together as
a single and entire system:
♦ Pros:
No test stubs (mocks) and drivers are needed
♦ Cons:
Difficult to pinpoint the specific component responsible for the failure
Î Results in Strategies that integrate only a few components at the time
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 9
Bottom-up Testing Strategy
♦ The subsystem in the lowest layer of the call hierarchy
are tested individually
Infrastructure is tested first
♦ Then the next subsystems are integrated and tested from
the next layer up that call the previously tested
subsystems
Increment one subsystem at a time
Order of integration depends on importance of subsystem etc.
♦ This is done repeatedly until all subsystems are included
in the testing
Regression Tests: Rerun previous tests
♦ Only Test Drivers are used to simulate the components of
higher layers
♦ No Test Stubs!
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 10
Bottom-up Integration
A
Layer III
Test E B C D Layer I
Test B, E, F E F G
Layer I
Test F
Test C Test
A, B, C, D,
E, F, G
Test D,G
Test G
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 11
Pros and Cons of bottom up
integration testing
♦ Pros:
Interface faults can be more easily found (the usage of test
drivers accomplishes a clear intention of the underlying
interfaces of the lower layer)
No Stubs are necessary
♦ Cons:
Components of the User Interface are tested last
Test cases often hard to derive
Faults found in the top layer may lead to changes in the
subsystems of lower layers, invalidating previous tests.
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 12
Top-down Testing Strategy
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 13
Top-down Integration Testing
A
Layer III
B C D Layer I
E F G
Layer I
Test
Test A Test A, B, C, D A, B, C, D,
E, F, G
Layer III
Layer III + II
All Layers
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 14
Pros and Cons of top-down
integration testing
♦ Pros:
Test cases can be defined in terms of the functionality of the
system (functional requirements)
More effective for finding faults that are visible to the user
♦ Cons:
Writing stubs can be difficult: Stubs must allow all possible
conditions to be tested.
Possibly a very large number of stubs may be required
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 15
Sandwich Testing Strategy
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 16
Sandwich Testing Strategy
A
Layer III
B C D Layer I
Test E
E F G
Layer I
Bottom Test B, E, F
Layer Test F
Tests
Test
A, B, C, D,
Test D,G E, F, G
Test G
Test A,B,C, D
Top
Layer
Tests Test A
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 17
Pros and Cons of Sandwich Testing
♦ Pros:
Top and Bottom Layer Tests can be done in parallel
No Stubs and Drivers (saves development time)
♦ Cons:
System implementation needs to be finished
Does not test the individual subsystems on the target layer
thoroughly before integration (C in the example)
♦ Solution: Modified sandwich testing strategy
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 18
Modified Sandwich Testing Strategy
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 19
Modified Sandwich Testing Strategy
A
Layer III
E F G
Test A,C Layer I
Test B Test
Test A,D
A, B, C, D
Test C
Test D
Test F Test
Test B, E, F A, B, C, D,
Test G E, F, G
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 20
Using the Bridge Pattern to enable
early Integration Testing
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 21
Summary
♦♦ Testing
Testing isis still
still aa black
black art,
art, but
but many
many rules
rules and
and heuristics
heuristics
are
are available
available
♦♦ Testing
Testing consists
consists of component-testing ((unit
of component-testing unit testing,
testing,
integration
integration testing)
testing) and
and system
system testing
testing
♦♦ Design
Design Patterns
Patterns can
can bebe used
used for
for integration
integration testing
testing
♦♦ Testing
Testing has
has its
its own
own lifecycle
lifecycle
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 22
Excurse: Agile Development
♦ Agile Development
♦ Extreme Programming (XP)
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 23
Agile Software Development:
Different Methods and Approaches
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 24
Agile Software Development:
The Agile Software Development Manifesto
Æ http://agilemanifesto.org/
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 25
Problems with agile methods
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 26
Extreme Programming (Beck, 2000)
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 27
Life Cycle of XP
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 30
How does XP work? (3)
♦ Collective ownership: Source code belongs to the team
everybody can make changes (consultation)
no fixed responsibilities
pairs work on all areas, no islands of expertise
♦ Continuous integration
integration several times a day
system is error-free every evening
♦ Standards (Coding)
is commonly accepted
♦ Customer agent is part of the team
available (in case of questions)
works out feature tests
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 31
Conclusions (XP)
♦ Advantages
Flexible
Quick
Customer-centered
Team-oriented
♦ Disadvantages
little documentation (only tests und code)
Scalability problems (only small and medium projects)
Depends strongly on team members
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 32