Software Testing

Software Testing
Executing a program with the intent of
finding an error.

To check if the system meets the

requirements and be executed successfully in
the Intended environment.

To check if the system does what it is

expected to do.
Objective of Software Testing
A good test case is one that has a probability
of finding undiscovered error.
A good test should neither be too simple nor
too complex.
A good test is not redundant.
Some popular errors: Ariane 5
Some Terminologies
Error : Errors are coding mistakes that can lead to
unintended outcomes during software execution (Coding)
Bug: An identified defects as flaws during development
and testing, are known as Bugs (Testing)
Fault: Inappropriate data definition (error) use during
execution leads to fault (Execution Time)
Failure: Failures occur when the software doesn’t perform
as expected outcomes during execution (Deployment)
ERRO FAILUR
R E
Leads to
BUG/
FAULT
 Test case
Test Case
Test Case Expected Actual
Descriptio Test Data Pass/Fail
# Result Result
n
Check
Email:
response
guru99@g Login
when valid mail.com Login was
1 should be Pass
email and Password: successful
successful
password lNf9^Oti7
is entered ^2h
Types of Testing
Unit Testing
Unit Testing is the process of checking small
piece of code to ensure that the individual
parts of program work properly on their own.
Unit Testing are used to check individual
block (units) of functionality
Unit Testing is done by developers

Frameworks-Junit (Tool-NetBeans)
Integration Testing
 Integration testing: Integrated collection of modules
tested as a group or partial system

 To find interface errors.

 Integration plan specifies the order in which to combine

modules into partial systems

 Different approaches to integration testing

 Bottom-up
 Top-down
 Big-bang
 Sandwich or mixed (Top down + Bottom up)
Integration Testing
int Get_Radius()
{
int R;
printf("Input the Radius of a circle:\n");
scanf("%d",&R);
return R;
}

float ACIRCLE()
{
float R,A;
R=Get_Radius();
A=R*R*3.14;
return A;
}
int main(){
float Area;
Area=ACIRCLE();
printf(“%f”, Area);
return 0;
}
Types of Integration Testing
Big-bang Testing:- At least combine two or more
module and perform testing
Top down :- First develop the module and at final
integrate it and perform test on modules. Top
priority modules are tested first. Module which call
another module for performing operation gets tested
here. (Dependent modules)
Bottom up:- Low priority module integrated first and
then testing is performed. The module which does
not call any other module or terminal module is
tested first. (Independent modules)
Mixed :- Top down + Bottom up
Bottom-up Integration
A B

C H

E F G I
Top-down Integration
A B

C
H

E F G I
System Testing
System testing is a level of testing that validates
the complete and fully integrated s/w product
The purpose of a system testing is to evaluate
the end-to-end system specification
System testing is also known as black-box testing

Test cases derived from

requirements specification
 system objectives, user documentation
(SRS document is required in system testing)
Types of System Tests
Non Functional Testing and Functional Testing

Volume testing
 To determine whether the program can handle the
required volumes of data, requests, etc.
Load/Stress testing
 To identify peak load conditions at which the program

will fail to handle required processing loads within

required time spans
Security Testing
 To show that the program’s security requirements can
be subverted
Types of System Tests
Performance testing
 To determine whether the program meets its performance
requirements (eg. response times, throughput rates, etc.)
Recovery testing
 To determine whether the system or program meets its
requirements for recovery after a failure
Configuration Testing
 To determine whether the program operates properly
when the software or hardware is configured in a required
manner
Reliability/availability testing
 To determine whether the system meets its reliability and
availability requirements
Functional Testing
Acceptance Testing
 Performed by the customer or end user
 Compare the software to its initial requirements and
needs of its end users
Alpha testing
 conducted at the developer’s site by a Testing team /
development team
 tests conducted in a controlled environment
 Beta testing
 conducted at one or more User sites by the end user of
the SW
 it is a “live” use of the SW in an environment over which
the developer has no control
Regression testing
 It preserves all the test cases for a program

 During the maintenance phase, when a change is made to the

program, the test cases that have been saved are used to do
regression testing
 figuring out if a change made to the program introduced any
faults

 Regression testing is crucial during maintenance

 It is a good idea to automate regression testing so that all test
cases are run after each modification to the software

 When you find a bug in your program you should write a test
case that exhibits the bug
 Then using regression testing you can make sure that the old
bugs do not reappear
WBT
It is also known as clear-box testing, glass-box
testing, transparent testing, and structural testing
It is type of testing where source code is verified
with its internal working and dependency
Design Techniques (Static Testing)
 Control Flow Testing
 Data Flow Testing
 Branch Testing
 Statement Coverage
 Decision Coverage
 Path Testing
Data Flow Testing
Data Flow Testing focuses on two points
In which statement the variables are defined
In which statement the variables are used
1. Read a, b, c Variables Defined Used
2. If (a>b) a 1 2,3
3. X=a+1 b 1 2,6

4. print X c 1 NA
X 3,6 4
5. Else
Z NA 7
6. X=b-1
7. Print Z
1. A Variable that is declared but not used in program
2. A variable that is used but never declared
3. A variable that is defined multiple time before its use
4. Deallocating a variable before it is used
Branch Testing (Decision Coverage)
1. Read a, b, c, d Test
2. If (a==0 || b==0) a=0 b=0 c=0 d=0
3. {
¼ = 25 %
coverage
4. print (“1”);
5. }
a=1 b=0 c=0 d=0
6. Else 2/4 = 50%
7. { coverage
8. If(c==0 || d==0)
9. { a=1 b=1 c=0 d=0
10. Print (“2”); ¾ =75% coverage
11. }
12. } a=1 b=1 c=1 d=0
4/4= 100 %
coverage
Statement Coverage
1. main()
2. {
3. int n1, n2, n3; Input

4. if (n1>=n2 && n1>=n3) n1=10 n2= 20 n3=30

5. printf(“n1 is largest”)
Statement coverage
6. else if(n2>=n1 &&
n2>=n3) 8/10 =80 %

7. printf(“n2 is largest”)
8. else
9. printf(“n3 is largest”)
10. }
Control Flow Testing
For control flow testing, control flow graph is
created
It is use to check path of the program
It comes under unit testing
The purpose is to find unreachable code in
program
Flow Graph
The control flow of a program can be
analysed using a graphical representation
known as flow graph.
The flow graph is a directed graph in which
nodes are either entire statements or
fragments of a statement, and edges
represents flow of control.
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

Path testing – Control Flow Graph
 White-box technique is based on the program flow graph (CFG)
Many paths between 1 (begin) and 6 (end)
1
1, 2, 5, 6

1, 2, 2
3, 4, 2, 6

1, 2, 3, 4, 2, 3, 4, 2, 5, 6
3
…
4

 Prepare test cases that will force the execution of each path in the basis set.

 Test case : ((inputs …) , (expected outputs …))

26
Path Testing
 Cyclomatic Complexity determines the basis set of
linearly independent paths and tries to measure the
complexity of a program
 McCabe’s cyclomatic metric V(G) = e – n + 2.
 For example, a flow graph shown in in Fig. 21 with entry node ‘a’
and exit node ‘f’.
 The value of cyclomatic complexity can be calculated as : V(G) =
9–6+2=5
 Here e = 9, n = 6 and P =1
 Path 1 : a c f
 Path 2 : a b e f
 Path 3 : a d c f
 Path 4 : a b e a c f or a b e a b e f
 Path 5 : a b e b e f
Cyclomatic Complexity
Consider a flow graph given and calculate
the cyclomatic complexity by all three
methods.

1. V(G) = e – n + 2P
= 13 – 10 + 2 = 5
2. V(G) = + 1
= 4 + 1 = 5
3. V(G) = number of regions
= 5
Graph Matrices
A graph matrix is a square matrix with one
row and one column for every node in the
graph. The size of the matrix (i.e., the number
of rows and columns) is equal to the number
of nodes in the flow graph. Some examples of
graphs and associated matrices are shown in
fig.
Graph Matrices
WBT Vs BBT
White Box Testing Black Box Testing
Performed by Development Team Performed by Testing Team
What the software is supposed to What the software supposed to
do also aware of how it works do but is not how it does
To perform WBT one should have In BBT no need to have
knowledge of programming knowledge of programming
In this source code logic is Here, we check functionality of
verified applications
Developer should know internal No need of knowledge of internal
design of source code design of the source code
Unit testing and Integration System Testing is the example
Testing is the example
Black-box Testing Strategies
Black box testing (Specification Based)
Equivalence Class Partitioning
Boundary Value Analysis
Decision Table
Cause-effect graphing
Equivalence Class Partitioning

Partition the program input domain into

equivalence classes (according to the
specifications)
The rationale is that test of a representative
value of each class is equivalent to a test of
any other value of the same class.
Identify valid as well as invalid equivalence
classes
One test case from each equivalence class
Example ( Discount Module)
Invalid Valid Valid Valid Valid Invalid
5% 10% 15% 20%
$.99 $1 - $100 $101 - $201 - $501 - $2001
$200 $500 $2000
Boundary Value Analysis
The basis of Boundary Value Analysis
(BVA) is testing the boundaries at partitions.
Design test cases that exercise values that lie
at the boundaries of an input equivalence
class.
Example: input condition 0 <= x <= max
Example (Discount Module)

Boundar $1- $101- $201 - $501 -

y Value $100.99 $200.99 $500.99 $2000.9
9

If boundary value is not checked then $100.99 will be converted to $101

Decision Table or Cause Effect Table
Decision table showing the combinations of
input conditions that make an effect true.
Test applications where the action is basis of
multiple input combinations.
A decision table is a good way to deal with
different combination inputs with their
associated outputs.
Example (Signup module)
Name Y N N N Y Y Y N
Email Y Y N N N N Y Y
Address Y Y Y N Y N N N
Success Y N N N N N N N
MSG
Error N Y Y Y Y Y Y Y
MSG
Test TC- TC-2 TC-3 TC-4 TC-5 TC-6 TC-7 TC-8
Case 1
(TC)
Cause Effect Graphing Technique
A technique that aids in selecting test cases for
combinations of input conditions in a systematic
way Steps:
1. Identify the causes (input conditions) and effects
(output conditions) of the program under test.
2. For each effect, identify the causes that can
produce that effect. Draw a Cause-Effect Graph.
3. Generate a test case for each combination of
input conditions that make some effect to be
true.
Cause Effect graph (Notation)
Coding Standards
Advantages of Coding Guidelines:
 Coding guidelines increase the efficiency of the
software and reduces the development time.
 Coding guidelines help in detecting errors in the
early phases, so it helps to reduce the extra cost
incurred by the software project.
 If coding guidelines are maintained properly,
then the software code increases readability and
understandability thus it reduces the complexity
of the code.
 It reduces the hidden cost for developing the
software.
Refactoring
The purposes of refactoring according to M. Fowler are
stated in the following:
 Refactoring Improves the Design of Software
 Refactoring Makes Software Easier to Understand
 Refactoring Helps Finding Bugs
 Refactoring Helps Programming Faster
 Types of refactoring in coding
 Introduce variable => Change the variable names in different
source file
 Introduce constants => Define value for a constant variables
 Introduce field => Define new variable for expression evaluation
 Introduce parameters => Set variables as a parameters of functions
 Introduce methods => Convert set of code into functions
Maintenance
Primary goal of maintenance to modify and
update s/w application after delivery to
correct errors and improve performance.
S/w Maintenance is an inclusive activity that
includes
Error correction
Detection of obsolete capabilities
Enhancement of capabilities
 Types of Maintenance
Types of maintenance
Corrective maintenance: Bugs correction
Adaptive Maintenance: Working with different
platform
Preventive maintenance: Proactive Risk analysis
Perfective Maintenance: Security, Load, Execution
Time (NF)
Maintenance Matrices
MTBF (Mean Time between Failure)
It is the average time available for a system or
component to perform its normal operations
b/w failure
MTBF= (sum of operational time / Total no. of
failure)
MTTR (Mean Time to Repair)
It is the average time required to repair a
failed component
MTTR = (Sum of downtime / Total no. of
failure)
Example
A machine that runs for 24 hours, during that
time it failed twice, and each time it took an hour
to get it back up and running. Find the MTBF and
MTTR

Down Time = 2 * 1 = 2 hours

MTBF= 22/ 2 = 11 hours (After 11 hours system

goes in failure stage)
MTTR= 2/2 = 1 hour (system get repair in 1 hour)
Availibility = 11/12 = 91 %
Reverse Engineering Vs Forward
Engineering
UNIT-IV (Completed)