TEST RELATED

ATTRIBUTES
CONVENTIONAL TESTING FUNDAMENTALS AND EXAMPLES
PRESENTED BY: JEREMIAH DEARBORN F. GANGOSO
MIT208 SOFTWARE ENGINEERING
OUTLINE
Key points testing and the value thereof
Test characteristics
Test case design overview
Internal and external views of testing-aka white box and
black box testing
Examples of white box tests and black box tests
Key Points
testing ensures software quality
A part of the larger Validation and Verification (V & V)
process
Validation are we building the right product?
Verification are we building the product right?
Identify and correct errors before delivery
Performed with a mindset to break the software
Systematic testing is time consuming
Design a TESTABLE Software
Operabilityit operates cleanly
Observabilitythe results of each test case are readily observed
Controllabilitythe degree to which testing can be automated and
optimized
Decomposabilitytesting can be targeted
Simplicityreduce complex architecture and logic to simplify tests
Stabilityfew changes are requested during testing
Understandabilityof the design
What is a Good Test?
A good test has a high probability of finding an error
A good test is not redundant
A good test should be best of breed
A good test should be neither too simple nor too
complex
Internal and External Views of Testing
Any engineered product (and most other things) can be
tested in one of two ways:
Knowing the specified function that a product has been
designed to perform, tests can be conducted that
demonstrate each function is fully operational while at the
same time searching for errors in each function;
Knowing the internal workings of a product, tests can be
conducted to ensure that "all gears mesh," that is, internal
operations are performed according to specifications and
all internal components have been adequately exercised.
White-box and Black-box Tests

white-box black-box
methods methods

Methods

Strategies
Test Case Design Overview
OBJECTIVE - to uncover errors
CRITERIA - in a complete manner
CONSTRAINT - with a minimum of effort and time
Cases-a combination of data/parameters/values to use
in tests
Optimize/systematize teststhe longer (or more
complex) the code, the longer the testing
White-box Testing
Test the internal workings of the software (i.e., program
sequences, conditional operations, loop operations,
data structures,)
GOAL - ensure that all statements and conditions have
been executed at least once
logic errors and incorrect assumptions are inversely
proportional to a path's execution probability
Basis Path Testing
derive a logical complexity measure of a procedural
design and use this measure as a guide for defining a
basis set of execution paths
Test cases derived to exercise the basis set are
guaranteed to execute every statement in the program at
least one time during testing
Basis Path Testing Procedure
1. Using the design (flowchart) or code as a foundation,
draw a corresponding flow graph.
2. Determine the cyclomatic complexity of the resultant
flow graph.
3. Determine a basis set of linearly independent paths.
4. Prepare test cases that will force execution of each
path in the basis set.
Cyclomatic Complexity
A number of industry
studies have indicated modules
that the higher V(G),
the higher the
probability or errors.
V(G)

modules in this range are

more error prone
Flow Graph Notation
1 : Flowchart to Flow Graph Conversion
1 Rn Regions
Edges
Nodes
2

3 4
R2
5 6
R3
R1
7

8
R4
9

10
Cyclomatic Complexity
Defines the upper bound (max) on the number of tests that must be
designed and executed to guarantee coverage of all program statements
1. The number of regions of the flow graph corresponds to the
cyclomatic complexity.
2. Cyclomatic complexity V(G) for a flow graph G is also defined as
V(G)= (E N) + 2
where E is the number of flow graph edges and N is the number of flow
graph nodes or
V(G) = P + 1
where P is the number of predicate nodes contained in the flow graph
G.
2: Determining Cyclomatic Complexity
1 Rn Regions
Number of regions = 4 Edges
Nodes
2
Number of edges = 12
3 4
Number of nodes = 10 R2
5 6
V(G) = 4 (by region) R3
R1
V(G) = (12 10) + 2 = 4 (by edges and 7

nodes)
8

V(G) = 3 + 1 = 4 (by branches) R4

9

10
3: Independent Paths
any path through the program that introduces at least
one new set of processing statements or a new
condition
must move along at least one edge that has not been
traversed before the path is defined
Forms the basis setpath where all statements have
been executed at least once
Independent Paths
1 Rn Regions
Path 1 : 1-2-3-8-9-10 Edges
Nodes
2
Path 2 : 1-2-4-5-7-8-9-10
3 4
Path 3 : 1 -2-4-6-7-8-9-10 R2
5 6
Path 4: 1-2-4-3-8-9-2 R3
R1
7

Number of paths to find depends on 8

V(G) R4
9
Finally, we derive test cases to exercise
these paths 10
Another Example
Some Considerations
you don't need a flow chart,
but the picture will help when
you trace program paths
count each simple logical
test, compound tests count
as 2 or more
basis path testing should be
applied to critical modules
Using Program Design Language (PDL) /
Pseudocode
Graph Matrices
Each row and column corresponds
to an identified node, and matrix
entries correspond to connections
(an edge) between nodes.
By adding a link weight to each
matrix entry, the graph matrix can
become a powerful tool for
evaluating program control
structure during testing
Control Structure Tests
Condition testing a test case design method that
exercises the logical conditions contained in a program
module
Data flow testing selects test paths of a program
according to the locations of definitions and uses of
variables in the program
Loop Testing

Simple
loop
Nested
Loops

Concatenated
Loops Unstructured
Loops
Testing Simple Loops
1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through the loop

where n is the maximum number of allowable passes

Testing Nested & Concatenated Loops
Nested:
1. Start at the innermost loop. Set all outer loops to their
minimum iteration parameter values.
2. Test the min+1, typical, max-1 and max for the innermost loop,
while holding the outer loops at their minimum values.
3. Move out one loop and set it up as in step 2, holding all other
loops at typical values. Continue this step until the outermost
loop has been tested.
Concatenated:
1. If the loops are independent of one another then treat each as
a simple loop, otherwise treat as nested loops (for example,
the final loop counter value of loop 1 is used to initialize loop 2).
Black-box Testing
requirements

output

input events
Questions Answered in Black-box Tests
How is functional validity tested?
How is system behavior and performance tested?
What classes of input will make good test cases?
Is the system particularly sensitive to certain input values?
How are the boundaries of a data class isolated?
What data rates and data volume can the system tolerate?
What effect will specific combinations of data have on
system operation?
Graph Based Methods object Directed link object
#1 (link weight) #2

To understand the objects that are Node weight

Undirected link
modeled in software and the (value
)
relationships that connect these object
Parallel links

objects #
3

In this context, we consider the term (a)

objects in the broadest possible

context. It encompasses data objects, new menu select generates document
file (generation time 1.0 sec) window
traditional components (modules),
and object-oriented elements of allows editing
of
computer software. is represented as Attributes:
contains
document background color: white
tex text color: default color
t or preferences

(b)
 Equivalence Partitioning
Test cases are based on data classes

If an input condition specifies a range, one valid

and two invalid equivalence classes are defined.
If an input condition requires a specific value, one
valid and two invalid equivalence classes are
user output FK
defined. queries formats input
mouse data
If an input condition specifies a member of a set, picks prompts
one valid and one invalid equivalence class are
defined.
If an input condition is Boolean, one valid and one
invalid class are defined.
Boundary Value Analysis
A greater number of
errors occurs at the
boundaries of the
input domain rather user
queries
output FK
input
than in the center. mouse
picks
formats
prompts
data

Complements
Equivalence
Partitioning
output
input domain domain
BVA Example Test
Orthogonal Array Testing
Used when the number of input
parameters is small and the values
that each of the parameters may take
are clearly bounded
If test cases 1,2,3 result in an error,
then P1=1 is faulty (single mode fault)
If specific levels of two parameters
result in error, its double mode fault
Model Based Testing
1. Analyze an existing behavioral model for the software or create one.
Recall that a behavioral model indicates how software will respond to
external events or stimuli.
2. Traverse the behavioral model and specify the inputs that will force
the software to make the transition from state to state.
The inputs will trigger events that will cause the transition to occur.
3. Review the behavioral model and note the expected outputs as the
software makes the transition from state to state.
4. Execute the test cases.
5. Compare actual and expected results and take corrective action as
required.
Summary: Test and Test Attributes
Testing Considerations
Ensure Software Testability
Prepare Test Cases
Run Tests
Internal Views External Views
Basis Path (Cyclomatic Complexity) Graph Based Testing
Graph Matrices Equivalence Partitions and BVA
Control Structure Testing (Condition,
Orthogonal Array
Data flow, Loop)
Model Based Testing
References
Pressman, R. Software engineering: a practitioners
approach (7th Ed).
Sommerville,I. Software engineering (9th Ed).