MAHARANA PRATAP GROUP OF INSTITUTIONS

KOTHI MANDHANA, KANPUR

(Approved by AICTE, New Delhi and Affiliated to Dr. AKTU, Lucknow)

Digital Notes
[Department of Computer Applications]
Subject Name : Software Engineering
Subject Code : KCA-203
Course : MCA
Branch : MCA
Semester : III
Prepared by : Mr. Yogendra Singh

Reference No./MCA/Yogendra Singh/KCA-302/3/2

Page 1 of 14
 UN IT IV: Software Testing

Introduction to Software Testing

 Software testing is a process used to identify the correctness, completeness and the
quality of developed software. It includes a set of activities to develop with intent of
finding errors in software. So that it could be corrected before the product is released to
end users.
 The aim of the testing process is to identify all defects existing in a software product.
 Thus testing provides a practical way of reducing defects in a system and increasing the
users’ confidence in a developed system.

Differentiate between verification and validation:

Verification is the process of determining whether the output of one phase of software
development conforms to that of its previous phase, whereas validation is the process of
determining whether a fully developed system conforms to its requirements specification.
Thus while verification is concerned with phase containment of errors, the aim of validation
is that the final product be error free.

Validation: Are we doing the right jobs?

Verification: Are we doing the job right?

What are the different levels of testing? Explain in details.

Ans: The different levels of testing are:

1. Unit Testing

2. Integration Testing

3. System Testing

Page 2 of 14
1. Unit Testing:
 Unit testing is undertaken after a module has been coded and successfully reviewed.
Unit testing (or module testing) is the testing of different modules of a system in
isolation.

 Unit testing is performed by the developers before the setup is handed over to the testing
team to formally execute the test cases.

 The goal of unit testing is to isolate each part of the program and show that individual

parts are correct in terms of requirements and functionality.

Advantages:

Errors can be detected at early stages, saving time and money to fix it.

Limitations: Integration issues are not detected in this stage; modules may work perfectly on
Isolation but can have issues in interfacing between the modules.

2. Integration Testing:
 Integration testing is performed immediately after the unit testing. In this all modules are
combined of an application to determine if they function correctly together is Integration
testing.
 The primary objective of integration testing is to test the module interfaces, i.e. there are
no errors in the parameter passing, when one module invokes another module. During
integration testing, different modules of a system are integrated in a planned manner
using an integration plan

Fig: Integration Testing

Integration test approaches
There are four types of integration testing approaches. Any one (or a mixture) of the following
approaches can be used to develop the integration test plan. Those approaches are the following:

Page 3 of 14
 1. Top-down Integration testing.
2. Bottom-up Integration testing
3. Big-Bang Integrtion Testing
4. Sandwich Testing

1. Top-down Integration Testing:

 In this case we start the top most module in the hierarchy and move down till the leaf
modules are tested.
 As there is very much possibility that the lower level modules might not have been
developed while beginning with top level modules. So in these case STUBS are used.

Fig: Top-down Approach

2. Bottom-up Integration testing:

In this type of testing the modules at the leaf level are first tested and then we move up in the
hierarchy.
Drivers are used in this type of testing at different levels of hierarchy. Driver is a program
which accepts the test case data to be inputted and printed by the module to be tested.

.
Fig: Bottom up Approach

Top-Down and Bottom-Up Testing Strategies:

1. DRIVERS:
 Drivers are used in bottom up testing approach. Drivers are dummy codes, which are
used when the sub-modules are ready but the main module is still not ready.

Page 4 of 14
  All dummy program which are used to call the function of the lowest module in case
when the calling function doesn’t exist.

Fig: DEIVERS

2. STUBs:

Stubs are used in top-down testing approach. STUBs are dummy code, which are used when you
have the major module ready to test but the sub module are still not ready yet.

Fig: STUBs

Page 5 of 14
Difference between Stubs and Drivers:

Stubs Drivers
Used in Top-down approach Used in Bottom-up approach
Top most module is tested first Lowest module is tested first
Simulate the lower level of component Simulate the higher level of component
Dummy program of lower level Dummy program for higher level
component component

3. Big-Bang Integration Testing: In this all the modules after unit testing are combined
and tested in one go. The problem with this kind of testing is debugging of errors.

4. Sandwich Integration Testing: A Sandwiched integration testing follows a

combination of top-down and bottom-up testing approaches. In top-down approach, testing can
start only after the top-level modules have been coded and unit tested. Similarly, bottom-up
testing can start only after the bottom level modules are ready. The mixed approach overcomes
this shortcoming of the top-down and bottom-up approaches. In the mixed testing approaches,
testing can start as and when modules become available. Therefore, this is one of the most
commonly used integration testing approaches.

Page 6 of 14
System Testing:
System tests are designed to validate a fully developed system to assure that it meets its
requirements. System testing is a black-box testing

There are essentially three main kinds of system testing:

1. Alpha Testing.
 Alpha testing refers to the system testing carried out by the test team within

the developing organization.

 Alpha testing is performed by highly skilled tester at onsite.

 Application is testing before releasing in beta version.

 The focus of this testing is to simulate real users by black box and white box

techniques.
2. Beta testing.
 Beta testing is the system testing performed by a select group of friendly

customers.
 Beta testing helps us to test the application in real time environment.

 Quality is improved as per the feedback of the user for application.

Example of Beta testing: Chrome Beta, Google Nexus6, etc

3. Acceptance Testing. Acceptance testing is the system testing performed by the

customer to determine whether he should accept the delivery of the system.

Regression Testing
Whenever a software product is updated with new code, feature or functionality, it is tested
thoroughly to detect if there is any negative impact of the added code. This is known as
regression testing.

Regression Testing Techniques:

1. Retest all.
2. Regression test selection.
3. Prioritization of test cases.

Page 7 of 14
Functional testing vs. Structural testing
In the black-box testing approach, test cases are designed using only the functional specification
of the software, i.e. without any knowledge of the internal structure of the software. For this
reason, black-box testing is known as functional testing.

On the other hand, in the white-box testing approach, designing test cases requires thorough
knowledge about the internal structure of software, and therefore the white-box testing is called
structural testing.\

Testing Techniques:

There are various methods or techniques for testing the software:

1. Black Box Testing

2. White Box Testing

1. Black Box Testing:

In the black-box testing, test cases are designed from an examination of the input/output
values only and no knowledge of design or code is required.

Fig: Black Box Testing

Black Box Testing attempts to find errors in the following categories:-

1) Incorrect or missing functions.
2) Interface errors.
3) Errors in data structures or external database access.
4) Behavior or performance errors.
5) Initialization and termination errors.

Page 8 of 14
Black-box testing techniques:
The following are the three main approaches to designing black box test cases.

1. Equivalence Class Portioning

2. Boundary Value Analysis (BVA)
3. Cause –Effect Graphs

1. Equivalence Class Partitioning

Equivalence Class Partitioning is type of black box testing technique which can be applied to all
levels of software testing like unit, integration, system, etc.

In this approach, the domain of input values to a program is partitioned into a set of
equivalence classes. This partitioning is done such that the behavior of the program is similar
for every input data belonging to the same equivalence class.

Example of Equivalence Class Partitioning

1. Let’s consider the behavior of Order Pizza
2. Pizza values 1 to 10 is considered valid.
3. While value 11 to 99 are considered invalid for order and an error message will
appear, “Only 10 Pizza can be ordered”

Example: For a software that computes the square root of an input integer which can assume
values in the range of 0 to 5000, there are three equivalence classes: The set of negative
integers, the set of integers in the range of 0 and 5000, and the integers larger than 5000.
Therefore, the test cases must include representatives for each of the three equivalence
classes and a possible test set can be: {-5, 500, 6000}.

Page 9 of 14
2. Boundary Value Analysis (BVA):

Boundary Value Analysis (BVA) is a Black-Box testing technique are helpful for detecting any
errors or threats at the boundary of an input domain

A type of programming error frequently occurs at the boundaries of different equivalence

classes of inputs.

Example of Boundary Value Analysis:

Let us assume test case that takes the speed of a car from 40 to 80 to get the best fuel
efficiency.
Boundary Value test Case
Invalid Test Case Valid Test Case Invalid Test Case
(Min Value-1) {Min; Min+1; Max-1; Max} (Max Value +1 )
39 (40, 41, 79, 80) 81

Example: For a function that computes the square root of integer values in the range of 0 and
5000, the test cases must include the following values: {0, -1, 5000, 5001}.

White Box Testing:

 White box testing is a software testing method in which the internal structure/design/
implementation is known to the testers.
 It is also called as glass box testing, structural testing etc.
 It is applicable to lower level testing like unit testing, integration testing.
 In this method test case are derived from the internal structure of the system.
 White Box Testing is also known as Glass Box, Structural; Clear Box, Open Box,
Logic Driven, or Path Oriented.
 It checks the internal functionality of the system

Page 10 of 14
In this testing method, the design and structure of the code are known to the tester. Programmers
of the code conduct this test on the code.

White Box Testing Techniques:

1. Statement Coverage Testing

The statement coverage strategy aims to design test cases so that every statement in a program is
executed at least once. The principal idea governing the statement coverage strategy is that
unless a statement is executed, it is very hard to determine if an error exists in that statement.
Unless a statement is executed, it is very difficult to observe whether it causes failure due to
some illegal memory access, wrong result computation, etc. However, executing some statement
once and observing that it behaves properly for that input value is no guarantee that it will
behave correctly for all input values. In the following, designing of test cases using the statement
coverage strategy have been shown.

Example: Consider the Euclid’s GCD computation algorithm:

int compute_gcd(x, y)
int x, y;
{
1 while (x! = y){
2 if (x>y) then
3 x= x – y;
4 else y= y – x;
5}
6 return x;
}
By choosing the test set {(x=3, y=3), (x=4, y=3), (x=3, y=4)}, we can exercise the program such
that all statements are executed at least once.

Page 11 of 14
2. Branch Coverage:
In the branch coverage-based testing strategy, test cases are designed to make each branch
condition to assume true and false values in turn. Branch testing is also known as edge testing as
in this testing scheme, each edge of a program’s control flow graph is traversed at least once.

It is obvious that branch testing guarantees statement coverage and thus is a stronger testing
strategy compared to the statement coverage-based testing. For Euclid’s GCD computation
algorithm , the test cases for branch coverage can be {(x=3, y=3), (x=3, y=2), (x=4, y=3), (x=3,
y=4)}.

3. Path coverage:

The path coverage-based testing strategy requires us to design test cases such that all linearly
independent paths in the program are executed at least once. A linearly independent path can be
defined in terms of the control flow graph (CFG) of a program.

Difference between black box testing and white box testing

S.N Black Box Testing White Box Testing

1 Implementation knowledge is not Implementation knowledge is required
required
2 Black Box Testing also known as White Box Testing also known as clear box
closed box testing, data driven testing testing , structural testing or code based
and functional testing testing
3 Performed by end users and also by Normally done by software developers
software testers.
4 Programming knowledge is not Programming knowledge is required
required
5 Types: Functional Testing , Non- Types: Path Testing , Loop Testing, Condition
functional Testing & Regression Testing
Testing

Page 12 of 14
Code review:
Code review for a model is carried out after the module is successfully compiled and the all the
syntax errors have been eliminated. Code reviews are extremely cost-effective strategies for
reduction in coding errors and to produce high quality code.
Normally, two types of reviews are carried out on the code of a module. These two types code
review techniques are:
1. Code inspection and
2. Code walkthrough

Code Walkthrough:
 Code walkthrough is an informal code analysis technique. In this technique, after a

module has been coded, compiled successfully, and all syntax errors eliminated.
 It used to discover the algorithm and logical errors in the code.

Code Inspection
In contrast to code walk through, the aim of code inspection is to discover some common types
of errors caused due to oversight and improper programming.
Following is a list of some classical programming errors which can be checked during code
inspection:
• Use of uninitialized variables.
• Jumps into loops.
• Non-terminating loops.
• Incompatible assignments.
• Array indices out of bounds.
• Improper storage allocation and de-allocation.

Page 13 of 14
Page 14 of 14