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