7/28/2019 Testing Unit
1/10
ConqueringC
omplexandChangingSystems
Object-Ori
entedSoftwareEngin
eering
Chapter 11,
Unit Testing
7/28/2019 Testing Unit
2/10
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
Testing Activities
Tested
Subsystem
SubsystemCode
FunctionalIntegration
Unit
T
ested
Subsystem
Requirements
AnalysisDocument
System
Design
Document
Tested Subsystem
Test Test
Test
UnitTest
Unit
TestUser
Manual
Requirements
AnalysisDocument
Subsystem
Code
Subsystem
Code
All tests by developer
Functioning
SystemIntegrated
Subsystems
Detailed
Design
(blackbox)
Source Code
(whitebox)
7/28/2019 Testing Unit
3/10
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3
GlobalRequirements
Testing Activities ctd
Users understandingTests by developer
Performance Acceptance
Clients
Understanding
of Requirements
Test
Functioning
SystemTest
Installation
UserEnvironment
Test
System inUse
Usable
System
Validated
System
Accepted
System
Tests (?) by user
Tests by client
7/28/2019 Testing Unit
4/10
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4
Unit Testing
Informal:
Incremental coding
Static Analysis:
Hand execution: Reading the source code
Walk-Through (informal presentation to others)
Code Inspection (formal presentation to others) Automated Tools checking for
syntactic and semantic errors
departure from coding standards
Dynamic Analysis: Black-box testing (Test the input/output behavior)
White-box testing (Test the internal logic of the subsystem orobject)
Data-structure based testing (Data types determine test cases)
7/28/2019 Testing Unit
5/10
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5
The 4 Testing Steps (presented before)
1. Select what has to bemeasured
Code tested for correctnesswith respect to:
requirements
architecture
detailed design
2. Decide how the testing isdone for each level of testing
Code inspection
Black-box, white box,
Select integration testingstrategy (big bang, bottomup, top down, sandwich)
3. Develop test cases
A test case is a set of test data
or situations that will beused to exercise the unit(code, module, system) beingtested or about the attributebeing measured
4. Create the test oracle An oracle contains of the
predicted results for a set oftest cases
I.e., expected output foreach test
The test oracle has to bewritten down before theactual testing takes place
This is the difficult step
7/28/2019 Testing Unit
6/10
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6
Black-box Testing
Focus: I/O behavior. If for any given input, we can predict theoutput, then the module passes the test.
Almost always impossible to generate all possible inputs ("testcases")
need techniques to define the input values
Derive tests using the detailed design
Goal: Reduce number of test cases by equivalence partitioning:
Divide input conditions into equivalence classes
Choose test cases for each equivalence class. (Example: If an object
is supposed to accept a negative number, testing one negativenumber is enough)
7/28/2019 Testing Unit
7/10Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7
Black-box Testing (Continued)
Selection of equivalence classes (No rules, only guidelines):
Input is valid across range of values. Select test cases from 3equivalence classes:
Below the range
Within the range
Above the range
Input is valid if it is from a discrete set. Select test cases from 2equivalence classes:
Valid discrete value
Invalid discrete value
Another solution to select only a limited amount of test cases:
Get knowledge about the inner workings of the unit being tested =>white-box testing
7/28/2019 Testing Unit
8/10Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8
White-box Testing
Focus: Thoroughness (Coverage)
Derive tests using the source code
Four types of white-box testing
Statement Testing
Loop TestingPath Testing
Branch Testing
7/28/2019 Testing Unit
9/10Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9
if ( i = TRUE) printf("YES\n");else printf("NO\n");Test cases: 1) i = TRUE; 2) i = FALSE
White-box Testing (Continued)
Statement Testing:
Select and test single statements
Loop Testing:
Cause execution of the loop to be skipped completely
Note. cannot do this on repeat until loops
Loop to be executed exactly once
Loop to be executed more than once
Path testing:
Make sure all paths in the program are executed
Branch Testing (Conditional Testing): Make sure that eachpossible outcome from a condition is tested at least once
7/28/2019 Testing Unit
10/10
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10
Unit Level
We can use the same testing approaches (whitebox, blackbox)
in testing the classes The same testing activities occur, but now they are applied at a
lower level of abstraction
Top Related