Testing Tactics

TCS2411 Software Engineering 1

 Software Testing
Fundamentals
 Testability
 How easily a computer program can be
tested.
 What are the characteristics of testability?
 1.operability 5.Simplicity
 2.Observability 6.Stability
 3.Controllability 7.Understandability
 4.Decompsability

TCS2411 Software Engineering 2

 Operability
1. The better the software works, the more efficiently it
can be tested.
2. The system has few bugs (bugs add analysis and
reporting overhead to the test process)
3. No bugs block the execution of tests.
4. The product evolves in functional stages (allows
simultaneous development & testing

TCS2411 Software Engineering 3

 Observability in
Software Testing:
 .
1 What is seen is what is tested
2. Distinct output is generated for each input
3. System states and variables are visible or queriable during execution
4. Past system states and variables are visible or queriable (eg., transaction
logs)
5. All factors affecting the output are visible
6. Incorrect output is easily identified
7. Incorrect input is easily identified
8. Internal errors are automatically detected through self-testing
mechanism
9. Internally errors are automatically reported
10. Source code is accessible

TCS2411 Software Engineering 4

 Controllability in
Software Testing

1. The better the software is controlled, the more the testing can be
automated and optimized.
2. All possible outputs can be generated through some combination of
input in Software Testing
3. All code is executable through some combination of input in Software
Testing
4. Software and hardware states can be controlled directly by testing
5. Input and output formats are consistent and structured in Software
Testing
6. Tests can be conveniently specified, automated, and reproduced .

TCS2411 Software Engineering 5

 Decomposability in
Software Testing:


1. By controlling the scope of testing, problems can be
isolated quickly, and smarter testing can be performed.

2. The software system is built from independent
modules

3. Software modules can be tested independently in
Software Testing

TCS2411 Software Engineering 6

 Simplicity in Software
Testing:


1. The less there is to test, the more
quickly it can be tested in Software
Testing
2. Functional simplicity
3. Structural simplicity
4. Code simplicity

TCS2411 Software Engineering 7

 Stability in Software
Testing:

1. The fewer the changes, the fewer the disruptions to testing

2. Changes to the software are infrequent

3. Changes to the software are controlled in Software Testing

4. Changes to the software do not invalidate existing tests in

Software Testing

5. The software recovers well from failures in Software Testing

TCS2411 Software Engineering 8

 Understandability in
Software Testing
1. The more information we have, the smarter we will test
2. The design is well understood in Software Testing
3. Dependencies between internal external and shared
components are well understood.
4. Changes to the design are communicated.
5. Technical documentation is instantly accessible
6. Technical documentation is well organized in Software
Testing
7. Technical documentation is specific and detailed
8. Technical documentation is accurate

TCS2411 Software Engineering 9

 Software Testing
white- black-
box box
methods
methods

Methods
Strategies

TCS2411 Software Engineering 10

 White Box Testing

 Derived from knowledge of program’s

structure & implementation
 Structural testing - analyse code & use
knowledge of the structure of a
component to derive test data
 Logical paths are tested by providing test
cases that exercise specific sets of
conditions and/or loops
TCS2411 Software Engineering 11
 White Box Testing
(Continued)

 Thorough white box testing would lead to

“100 percent correct programs”
 Exhaustive testing are impractical - too
many tests!
 A limited number of logical paths can be
selected and exercised
 Important data structures can be probed
for validity
TCS2411 Software Engineering 12
 White Box Test Cases

 Guarantee that all independent paths have

been exercised at least once
 Exercise all logical decisions on their true
and false sides
 Execute all loops at their boundaries and
within their operational bounds
 Exercise internal data structures to ensure
their validity
TCS2411 Software Engineering 13
 White Box Testing
Techniques
 Basis path testing
 Flow graph notation
 Cyclomatic complexity
 Derived test cases
 Graph metrics
 Control structure testing
 Condition testing
 Data Flow testing
 Loop testing

TCS2411 Software Engineering 14

 Flow Graph Notation

Edge 1
Node
1
2,3
2
6 R2
4,5
3
R1
7 R3 8
6 4
Region
7 8 5 9
9
10
10
11 R4

11

TCS2411 Software Engineering 15

 Cyclomatic Complexity
 Provide quantitative measure for program logical
complexity.
 Defined number of independent path
 Any path that introduce one ser of processing
statements or new condition
 Eg :-
 Path 1 : 1-11
 Path 2 : 1-2-3-4-5-10-1-11
 Path 3 : 1-2-3-6-8-9-10-1-11
 Path 4 : 1-2-3-6-7-9-10-1-11

TCS2411 Software Engineering 16

 How Is Cyclomatic
Complexity Computed?

1. Number of regions
 The flow graph has 4 regions
2. V(G) = E – N + 2
 E : Number of flow graph edges
 N : Number of flow graph nodes
 V(G) = 11 edges – 9 nodes + 2 = 4
3. V(G) = P + 1
 P : Number of predicate nodes
 V(G) = 3 predicate nodes + 1 = 4

TCS2411 Software Engineering 17

 Deriving Test Cases
1. Draw flow graph from design/code as foundation.

1
…
i=1;
2
total.input = total.valid=0;
1
sum=0; 2
do while value[i] <> -999 and total.input<1003
4 increment total.input by 1;
if value[i] >= minimum AND value[i] <= maximum6 3
5 then increment total.valid by 1;
sum = sum + value[i]
7
else skip
8 end if 10 4
increment i by 1
9 End do
If total.valid > 0 10 12 11 5
11 then average = sum / total valid;
12 else average = -999;
13 End if 13
… 6

8 7

TCS2411 Software Engineering 18

 Deriving Test Cases
(cont)
2. Determine cyclomatic complexity
 V(G) = 6 regions
 V(G) = 17 edges – 13 nodes + 2 = 6
 V(G) = 5 predicates nodes + 1 = 6
3. Determine a basis set of linearly independent graph
 Path 1 = 1-2-10-11-13
 Path 2 = 1-2-10-12-13
 ….
4. Prepare test cases that will force execution of each
path in the basis set.
 Data should be chosen so that conditions at the predicate
nodes are appropriately set as each path is tested.
 Each test case is executed and compared to expected result.
TCS2411 Software Engineering 19
 Discussion on White
Box Testing
 Advantages
 Find errors on code level
 Typically based on a very systematic approach,
covering the complete internal module structure
 Constraints
 Does not find missing or additional functionality
 Does not really check the interface
 Difficult for large and complex module

TCS2411 Software Engineering 20

TCS2411 Software Engineering 21
 Control structure testing

 Condition testing
 Data Flow testing
 Loop testing

TCS2411 Software Engineering 22

For a statement with S as its statement number
DEF(s)={x/statement S contains definition of x}
 USE(s)={x/statement S contains a use of x}
A definition-use chain of variable x is of the form
[X,S,S’],where S,S’ are statement no,X is in DEF(S) and
USE(S’) and the definition of X in statement S is live at
23
statement S’.
 Loop testing
is a white-box testing technique
that focuses exclusively on the validity of
loop constructs.

TCS2411 Software Engineering 24

 Loop testing is a white-box testing technique that focuses
exclusively on the validity of loop constructs.

TCS2411 Software Engineering 25

TCS2411 Software Engineering 26
TCS2411 Software Engineering 27
 Black Box Testing
 Derived from program specification
 Functional testing of a component of a
system
 Examine behaviour through inputs & the
corresponding outputs
 Input is properly accepted, output is
correctly produced
 Disregard internal logical structure
TCS2411 Software Engineering 28
 Black Box Testing
(Continued)

Attempts to find the following errors:

 Incorrect or missing functions
 Interface errors
 Errors in data structures or external
database access
 Performance errors
 Initialisation and termination errors

TCS2411 Software Engineering 29

 Black Box Testing
Techniques

 Graph Based Testing Methods

 Equivalence Partitioning
 Boundary Value Analysis

TCS2411 Software Engineering 30

TCS2411 Software Engineering 31
 Equivalence Partitioning
 Divide input domain into classes of data
 Based on an evaluation of equivalence classes
for an input condition
 Guidelines to define equivalence classes
 Range input : One valid and two invalid equivalence
 Specific value : One valid and two invalid equivalence
 A member of a set : One valid and one invalid
equivalence
 Boolean : One valid and one invalid equivalence

TCS2411 Software Engineering 32

 Equivalence Partitioning
 In this method ,the input domain data is divided into
different equivalence data classes. This method is
typically used to reduce the total number of test
cases to a finite set of testable test cases, still covering
maximum requirements.

TCS2411 Software Engineering 33

 Example – Data for Automated
Banking Application
The use can access the bank using his personal computer, provide a six digit password, and follow
with a series of typed commands that trigger various banking function. During the log on sequence
the software supplied for the banking application accepts data in the form:

area code – blank or 3 digit numbers

prefix – 3 digit numbers, nor beginning with 0 or 1
suffix – 4 digit numbers
password – 6 digits alphanumeric strings
commands – “check”, “deposit”, “bill pay” etc

Input condition

area code : Input condition : Boolean – area code may or may not present
Input condition : Range – 200 – 999 with specific exception
prefix : Input condition : Range – specified value > 200 with no 0 digits
suffix : Input condition : Value – 4 digit length
password : Input condition : Boolean – password may or may not present
Input condition : Value – six character string
command : Input condition : Set – containing command
TCS2411 Software Engineering 34
 Boundary Value
Analysis
 It’s widely recognized that input values at the extreme
ends of input domain cause more errors in system. More
application errors occur at the boundaries of input
domain. ‘Boundary value analysis’ testing technique is
used to identify errors at boundaries rather than finding
those exist in center of input domain.

TCS2411 Software Engineering 35

 Boundary Value
Analysis
 Complement equivalence partitioning
 Test both sides of each boundary
 Look at output boundaries for test cases
 Test min, min-1, max, max+1, typical
values
 Example : 1 <= x <=100
 Valid : 1, 2, 99, 100
 Invalid : 0 and 101

TCS2411 Software Engineering 36

 Discussion on Black
Box Testing

 Advantages
 Find missing functionality
 Independent from code size and functionality
 Find some coding errors
 Constraints
 No systematic search for low level errors
 Specification errors not found

TCS2411 Software Engineering 37

 References
 “Software Engineering: A Practitioner’s
Approach” 5th Ed. by Roger S. Pressman,
Mc-Graw-Hill, 2001
 “Software Engineering” by Ian Sommerville,
Addison-Wesley, 2001

TCS2411 Software Engineering 38