1
Software Testing and Quality Assurance
Lecture 21 – Class Testing Basics (Chapter 5, A Practical Guide to Testing Object-
Oriented Software)
2
Lecture Outline Dimensions of Class Testing Construction of Test Cases Adequacy of Test Suites for a Class
3
Class testing: dimensions of class testing (cont...)
Who — developer What — code implements the
specification exactly When —
A test plan should be developed soon after the specification of the class is ready for coding
4
Class testing: dimensions of class testing (cont...)
Class testing should be done prior to its use in other portion of the software
Regression class testing should be performed whenever the class implementation is changed
5
Class testing: dimensions of class testing (cont...)
How — develop a test driver that creates instances of the class and sets up a suitable environment around these instances to run a test case
How much — Test operations and state transitions in all
sorts of combinations Exhaustive or selective with combination with
risk analysis.
6
Constructing test cases Possible ways for identifying test cases
Class specification Pre- and post-conditions (OCL) State transition diagram
Class implementation
7
Constructing test cases Test case construction from Pre- and
Post-conditions Programming style: defensive vs.
contract Steps in generating test cases from Pre-
and Post-conditions Identify a list of pre-condition contributions Identify a list of post-condition contributions
8
Constructing test cases Form test case requirements by making
all possible combinations of entries from the contributions lists
Eliminate any conditions generated that are not meaningful
For example, a precondition, say (color = red) or (color = blue) will generate a test case in which (color = red) and (color = blue), which cannot satisfied.
9
Constructing test cases Test case construction from
state transition diagram: Each transition on the
diagram represents a requirement for one or more test cases
When testing based on state transition diagrams, make sure you investigate the boundaries and results of each transitions
10
Constructing test cases: adequacy of test suites for a class
Common ways used measures of adequacy: State-based coverage: how many of the
transitions in a state transition diagram are covered by the test suite.
Constraint-based coverage: how many pairs of pre- and postconditions have been covered.
Code-based coverage: how much of the code that implements the class is executed across all test cases in the suite.
11
Constructing test cases Boundary conditions:
Boundary is the input value on which a large change occurs and must be identified when test cases are identified.
Example: sorting an array the boundary values can be
An array with zero elements An array with one element An array with two elements An array with many elements
12
Constructing test cases We need implementation-based testing,
test cases derived from the specifications may not be enough: Example: the size of the array is used
to choose the sorting algorithm for sorting an array
13
Constructing a test driver A test driver is a program that runs test
cases and collects the results. Two approaches to build a test driver
Embed the testing into the class under test itself
Implement a separate class Keep relationship between CUT and its tester
class through name, like a tester for Velocity class as VelocityTester.
14
Constructing a test driver: test driver requirements
Test driver should have relatively simple design.
Test driver must be easy to maintain and adapt in response to changes.
Test driver should be reusable to create new drivers.
15
Constructing a test driver: test driver requirements (cont...)
A class model for requirements for a tester class: Public interface Tester is an abstract
class.
16
Constructing a test driver: test driver requirements (cont...)
Test case suites: Functional (specification-based)— if
derived from specification. Structural (implementation-based)— if
identified from code. Interaction — if derived from sequence of
events on an object such as pairs of input/output transitions.
17
Constructing a test driver: tester class design
Tester class example
18
Constructing a test driver The main responsibility of the tester class is
to run test cases and report results. Test case methods: one method per test
case or group of closely related test cases: Execute a test case by creating the input
state, generating a sequence of events, and checking the output state.
Provide traceability to the test plan.
19
Constructing a test driver (cont...) Baseline testing: a baseline test suite is a set of test
cases that tests the operations of the CUT that are needed for the other test cases to verify their outcome.
This suite includes testing constructors and accessors. Two basic approaches to baseline testing: specification-
based and implementation-based: Check that all the constructors and accessors are
self-consistent. Create a test case for each constructor and verify that all attributes are correct by invoking accessors.
Check that all the constructors and accessors use the variables in an object correctly.
20
Constructing a test driver (cont...)
Running test suites: The abstract Tester class includes in its
protocol some operations to run all test cases or selected test suites.
Each calls a sequence of test case methods.
Make sure that the baseline test suite is executed before any of these other suites are executed.
21
Constructing a test driver (cont...)
Reporting test results: A test case method determines the
success of a test case. The test case should report results to the
tester instance.
22
Key points Possible ways for identifying test cases
Pre- and post-conditions (OCL) State transition diagram
Common ways used measures of adequacy: state-based coverage, constraint-based coverage and code-based coverage.
Boundary conditions is the input value on which a large change occurs.
23
Key points (cont...) Test driver should have relatively simple
design, easy to maintain and reusable to create new drivers.
Test case suites: functional, structural, and interaction
Test case methods: one method per test case or group of closely related test cases:
Baseline — checking test cases results and accessor and modifier methods.
