KGiSL Institute of Technology
(Approved by AICTE, New Delhi; Affiliated to Anna University, Chennai)
Recognized by UGC, Accredited by NBA (IT)
365, KGiSL Campus, Thudiyalur Road, Saravanampatti, Coimbatore – 641035.
Department of Computer Science and Engineering
Name of the Faculty : Mrs. S Jayashree
Subject Name & Code : CCS366/ Software Testing and Automation
Branch & Department : Computer Science and Engineering
Year & Semester : III / VI
Academic Year :2024-25
Syllabus
UNIT I FOUNDATIONS OF SOFTWARE TESTING
Why do we test Software?- Black-Box Testing and White-Box Testing-
Software Testing Life Cycle- V-model of Software Testing- Program
Correctness and Verification- Reliability versus Safety- Failures- Errors
and Faults (Defects)- Software Testing Principles- Program Inspections-
Stages of Testing: Unit Testing- Integration Testing- System Testing.
Course Outcome
CO1: Understand the basic concepts of software testing and the
need for software testing K2 LEVEL
CCS366/STA/III CSE/VI SEM/KG-KiTE
WHITE BOX TESTING
• White-box testing is another effective testing technique in dynamic
testing
• Everything required to implement the software should be visible hence,
it is also known as Glass box Testing or Structural or Development
testing.
• The intention is to test this logic so that required results or
functionalities can be achieved.
• White-box testing ensures that the internal parts of the software are
adequately tested
CCS366/STA/III CSE/VI SEM/KG-KiTE
WHITE BOX TESTING TYPES
There are different types of White box testing, they are
Basis Path testing
Graph Matrices
Loop Testing
Data Flow Testing
Mutation Testing
CCS366/STA/III CSE/VI SEM/KG-KiTE
Need for White Box Testing
• Used for testing the module in initial stage
• The test cases can be executed only after code is produced
and checked using white box testing
• The categories of bugs can be revealed by white box
testing
• White box testing checks all portions of code
CCS366/STA/III CSE/VI SEM/KG-KiTE
Logic Coverage Criteria
Statement Coverage: If all the statements of the module are executed once, every bug will be notified.
Statement coverage is a necessary but not a sufficient criteria for logic coverage.
Decision or Branch Coverage: Branch coverage states that each decision takes on all possible
outcomes (True or False) at least once. Test cases must be designed for both outcomes
Condition Coverage: Condition coverage states that each condition in a decision takes on all possible
outcomes at least once.
Decision / Condition Coverage: Condition coverage in a decision does not mean that the decision has
been covered. If the decision is being tested, the condition coverage would allow one to write two
test cases: Test case 1: A is True, B is False. Test case 2: A is False, B is True
Multiple condition coverage: Multiple condition coverage requires to write sufficient test cases such
that all possible combinations of condition outcomes in each decision and all points of entry are
invoked at least once. The following test cases can be there:
Test case 1: A = True, B = True
Test case 2: A = True, B = False
Test case 3: A = False, B = True
Test case 4: A = False, B = False
CCS366/STA/III CSE/VI SEM/KG-KiTE
Basis Path Testing
The guidelines for effectiveness of path testing are discussed below:
1. Path testing is based on control structure of the program for which
flow graph is prepared.
2. Path testing requires complete knowledge of the program’s
structure.
3. Path testing is closer to the developer and used by him to test his
module.
4. The effectiveness of path testing gets reduced with the increase in
size of software under test
5. Choose enough paths in a program such that maximum logic
coverage is achieved.
CCS366/STA/III CSE/VI SEM/KG-KiTE
Basis Path Testing
CONTROL FLOW GRAPH: The control flow graph is a graphical representation of control
structure of a program. Flow graphs can be prepared as a directed graph. A directed graph (V,
E) consists of a set of vertices V and a set of edges E that are ordered pairs of elements of V.
FLOW GRAPH NOTATIONS FOR DIFFERENT PROGRAMMING CONSTRUCTS:
The flow graph is also known as decision-to-decision-graph or DD graph.
CCS366/STA/III CSE/VI SEM/KG-KiTE
Basis Path Testing
PATH TESTING TERMINOLOGY:
Path: A path through a program is a sequence of instructions or statements that
starts at an entry, junction, or decision and ends at another, or possibly the
same, junction, decision, or exit.
Segment Paths consist of segments. The smallest segment is a link, that is, a
single process that lies between two nodes
Path segment: A path segment is a succession of consecutive links that
belongs to some path.
Length of a path: The length of a path is measured by the number of links in it
and not by the number of instructions or statements executed along the path.
Independent path: An independent path must move along at least one edge
that has not been traversed before the path is defined.
CCS366/STA/III CSE/VI SEM/KG-KiTE
Basis Path Testing
CYCLOMATIC COMPLEXITY: measure the complexity by considering the
number of paths in the control graph of the program
V(G) = e – n + 2
CCS366/STA/III CSE/VI SEM/KG-KiTE
main()
int number, index;
1. printf(“Enter a number”);
2. scanf(“%d, &number);
3. index = 2;
4. while(index <= number – 1)
5. {
if (number % index == 0)
{
printf(“Not a prime number”);
break;
}
index++;
6. }
7. if(index == number)
8. printf(“Prime number”);
} //end main
CCS366/STA/III CSE/VI SEM/KG-KiTE
Basis Path Testing
The following steps should be followed for designing test cases using path
testing:
Draw the flow graph using the code provided for which we have to write
test cases.
Determine the cyclomatic complexity of the flow graph.
Cyclomatic complexity provides the number of independent paths.
Determine a basis set of independent paths through the program
control structure.
The basis set is in fact the base for designing the test cases. Based on
every independent path, choose the data such that this path is executed.
CCS366/STA/III CSE/VI SEM/KG-KiTE
Graph Matrices
• Graph matrix, a data structure, is the solution which can assist in
developing a tool for automation of path tracing.
• A graph matrix is a square matrix whose rows and columns are equal to
the number of nodes in the flow graph.
• Each row and column identifies a particular node and matrix entries
represent a connection between the nodes.
1. Each cell in the matrix can be a direct connection or link between one
node to another node.
2. If there is a connection from node ‘a’ to node ‘b’, then it does not
mean that there is connection from node ‘b’ to node ‘a’.
3. Conventionally, to represent a graph matrix, digits are used for nodes
and letter symbols for edges or connections.
CCS366/STA/III CSE/VI SEM/KG-KiTE
Graph Matrix
CCS366/STA/III CSE/VI SEM/KG-KiTE
Graph Matrix
CCS366/STA/III CSE/VI SEM/KG-KiTE
CONNECTION MATRIX
• Tabular representation and does not provide any useful information.
• If we add link weights to each cell entry, then graph matrix can be used as a powerful tool in
testing.
• The links between two nodes are assigned a link weight which becomes the entry in the cell
of matrix.
• A matrix defined with link weights is called a connection matrix.
CCS366/STA/III CSE/VI SEM/KG-KiTE
USE OF CONNECTION MATRIX IN FINDING CYCLOMATIC
COMPLEXITY NUMBER
• Connection matrix is used to see the control flow of the program.
• It is used to find the cyclomatic complexity number of the flow graph.
Given below is the procedure to find the cyclomatic number from the
connection matrix:
Step 1: For each row, count the number of 1s and write it in front of that
row.
Step 2: Subtract 1 from that count. Ignore the blank rows, if any.
Step 3: Add the final count of each row.
Step 4: Add 1 to the sum calculated in Step 3.
Step 5: The final sum in Step 4 is the cyclomatic number of the graph.
CCS366/STA/III CSE/VI SEM/KG-KiTE
CYCLOMATIC COMPLEXITY NUMBER
CCS366/STA/III CSE/VI SEM/KG-KiTE
Software Testing Life Cycle
CCS366/STA/III CSE/VI SEM/KG-KiTE
STLC
• Test Planning
• Test Design
• Test Execution
CCS366/STA/III CSE/VI SEM/KG-KiTE
Verification & Validation
• Verification refers to the set of activities that ensures correct
implementation of functions in a software. We check every sub-task to
ensure that you are working in the right direction.
• Validation is a very general term to test the software as a whole in
conformance with customer expectations.
• After the sub-tasks have been completed and merged, the entire task is
checked to ensure the required task goals have been achieved. This is
validation.
• Verification is ‘Are we building the product right?’
• Validation is ‘Are we building the right product?’
CCS366/STA/III CSE/VI SEM/KG-KiTE
V Model
CCS366/STA/III CSE/VI SEM/KG-KiTE
Extended V Model
CCS366/STA/III CSE/VI SEM/KG-KiTE
V Model
• Verification and validation (V&V) are the building blocks of a testing
process
• The development team attempts to implement the software, the testing
team concurrently starts checking the software.
• (i) Verification of every step of SDLC
• (ii) Validation of the verified system at the end.
VALIDATION ACTIVITIES
• Unit Testing- Isolate code, Verify Correctness & test every function,
fix bugs
• Integration Testing – determine the correctness of interface
• System Testing –testing complete and fully integrated
CCS366/STA/III CSE/VI SEM/KG-KiTE
