Scribd
Upload
12 views

Software testiting II Lecture 12

Uploaded by

gunetoday
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
12 views

Software testiting II Lecture 12

Uploaded by

gunetoday
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 19

Software testing

Remark that the slides are highly adapted from Ian Sommerville, Software Engineering, 9th ed.
Partition testing
• Input data and output results often fall into
different classes where all members of a class
are related.
• Each of these classes is an equivalence
partition or domain where the program
behaves in an equivalent way for each class
member.
• Test cases should be chosen from each
partition.
Equivalence partitioning

Invalid inputs Valid inputs

System

Outputs
Equivalence partitions
3 11
4 7 10

Less than 4 Between 4 and 0


1 More than 1
0

Number ofinput values

9999 100000
10000 50000 99999

Less than 1
0000 Between 10000 and 99999 More than 99999

Input values
Search routine specification
procedure Search (Key : ELEM ; T: SEQ of ELEM;
Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

Pre-condition
-- the sequence has at least one element
T’FIRST <= T’LAST
Post-condition
-- the element is found and is referenced by L
( Found and T (L) = Key)
or
-- the element is not in the array
( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
Search routine - input partitions
• Inputs which conform to the pre-conditions.
• Inputs where a pre-condition does not hold.
• Inputs where the key element is a member of
the array.
• Inputs where the key element is not a
member of the array.
Testing guidelines (sequences)
• Test software with sequences which have only
a single value.
• Use sequences of different sizes in different
tests.
• Derive tests so that the first, middle and last
elements of the sequence are accessed.
• Test with sequences of zero length.
Search routine - input partitions
Structural testing
• Sometime called white-box testing.
• Derivation of test cases according to program
structure. Knowledge of the program is used
to identify additional test cases.
• Objective is to exercise all program
statements (not all path combinations).
Structural testing

Test data

Tests Derives

Component Test
code outputs
Binary search - equiv. partitions
• Pre-conditions satisfied, key element in array.
• Pre-conditions satisfied, key element not in
array.
• Pre-conditions unsatisfied, key element in array.
• Pre-conditions unsatisfied, key element not in array.
• Input array has a single value.
• Input array has an even number of values.
• Input array has an odd number of values.
Binary search equiv. partitions

Equivalence class boundaries

Elements < Mid Elements > Mid

Mid-point
Binary search - test cases
Path testing
• The objective of path testing is to ensure that
the set of test cases is such that each path
through the program is executed at least
once.
• The starting point for path testing is a
program flow graph that shows nodes
representing program decisions and arcs
representing the flow of control.
• Statements with conditions are therefore
nodes in the flow graph.
Binary search flow graph
1

bottom > top while bottom <= top


5

elemArray [mid] != key


7 11
elemArray
elemArray [mid] > key elemArray [mid] < key
[mid] = key

8
12 13

14 10
Independent paths
• 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
• 1, 2, 3, 4, 5, 14
• 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …
• 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …
• Test cases should be derived so that all of
these paths are executed
• A dynamic program analyser may be used to
check that paths have been executed
Test automation
• Testing is an expensive process phase. Testing workbenches
provide a range of tools to reduce the time required and total
testing costs.
• Systems such as Junit support the automatic execution of
tests.
• Most testing workbenches are open systems because testing
needs are organisation-specific.
• They are sometimes difficult to integrate with closed design
and analysis workbenches.
A testing workbench
Test data
Specification
generator

Source Test
Test data Oracle
code manager

Dynamic Program Test


Test results
analyser being tested predictions

Execution File
Simulator
report comparator

Report Test results


generator report
Testing workbench adaptation
• Scripts may be developed for user interface
simulators and patterns for test data
generators.
• Test outputs may have to be prepared
manually for comparison.
• Special-purpose file comparators may be
developed.

You might also like