Software Engineering

Software Engineering
Chapter 5 : Software Testing
What is Software Testing

Software testing can be stated as the process of verifying and validating whether a
software or application is bug-free, meets the technical requirements as guided by its design
and development, and meets the user requirements effectively and efficiently by handling all
the exceptional and boundary cases.
The process of software testing aims not only at finding faults in the existing software but
also at finding measures to improve the software in terms of efficiency, accuracy, and
usability. It mainly aims at measuring the specification, functionality, and performance of a
software program or application.
Software testing is a process of identifying the correctness of software by considering its all
attributes (Reliability, Scalability, Portability, Re-usability, Usability) and evaluating the execution of
software components to find the software bugs or errors or defects.
Software testing can be divided into two steps:

1. Verification: it refers to the set of tasks that ensure that the software correctly implements
a specific function.
2. Validation: it refers to a different set of tasks that ensure that the software that has been
built is traceable to customer requirements.
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”
Software Testing Strategy
—-----------------------------------------------------------------------------------------------------------------------------------------------
Software Engineering - Dr.A.K.Magore,Computer Engineering Department,GIT,Lavel
Types of Software Testing
If we want to ensure that our software is bug-free or stable, we must perform the various types of
software testing because testing is the only method that makes our application bug-free.
The categorization of software testing is a part of diverse testing activities, such as test strategy,
test deliverables, a defined test objective, etc. And software testing is the execution of the software
to find defects.
—-----------------------------------------------------------------------------------------------------------------------------------------------
The software testing mainly divided into two parts, which are as follows:
● Manual Testing
● Automation Testing
What is Manual Testing?

Testing any software or an application according to the client's needs without using any automation
tool is known as manual testing.
In other words, we can say that it is a procedure of verification and validation. Manual testing is
used to verify the behavior of an application or software in contradiction of requirements
specification.
We do not require any precise knowledge of any testing tool to execute the manual test cases. We
can easily prepare the test document while performing manual testing on any application.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Automation Testing
The most significant part of Software testing is Automation testing. It uses specific tools to
automate manual design test cases without any human interference.
Automation testing is the best way to enhance the efficiency, productivity, and coverage of Software
testing.
It is used to re-run the test scenarios, which were executed manually, quickly, and repeatedly.
In other words, we can say that whenever we are testing an application by using some tools is known
as automation testing.
We will go for automation testing when various releases or several regression cycles goes on the
application or software. We cannot write the test script or perform the automation testing without
understanding the programming language.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Unit Testing
Unit testing involves the testing of each unit or an individual component of the software application.
It is the first level of functional testing. The aim behind unit testing is to validate unit components
with its performance.
A unit is a single testable part of a software system and tested during the development phase of the
application software.
The purpose of unit testing is to test the correctness of isolated code. A unit component is an
individual function or code of the application. White box testing approach used for unit testing and
usually done by the developers.
Whenever the application is ready and given to the Test engineer, he/she will start checking every
component of the module or module of the application independently or one by one, and this
process is known as Unit testing or components testing.
Why Unit Testing?

In a testing level hierarchy, unit testing is the first level of testing done before integration and other
remaining levels of the testing. It uses modules for the testing process which reduces the
dependency of waiting for Unit testing frameworks, stubs, drivers and mock objects are used for
assistance in unit testing.
Some crucial reasons are listed below:

● Unit testing helps testers and developers to understand the base of code that makes them
able to change defect causing code quickly.
● Unit testing helps in the documentation.
● Unit testing fixes defects very early in the development phase that's why there is a possibility
to occur a smaller number of defects in upcoming testing levels.
● It helps with code reusability by migrating code and test cases.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Example of Unit testing
Let us see one sample example for a better understanding of the concept of unit testing:
For the amount transfer, requirements are as follows:
1. Amount transfer
1.1 From account number (FAN)→ Text Box
1.1.1 FAN→ accept only 4 digit
1.2 To account no (TAN)→ Text Box
1.2.1 TAN→ Accept only 4 digit
1.3 Amount→ Text Box
1.3.1 Amount → Accept maximum 4 digit
1.4 Transfer→ Button
1.4.1 Transfer → Enabled
1.5 Cancel→ Button
1.5.1 Cancel→ Enabled
—-----------------------------------------------------------------------------------------------------------------------------------------------
Below are the application access details, which is given by the customer
● URL→ login Page
● Username/password/OK → home page
● To reach Amount transfer module follow the below
Loans → sales → Amount transfer
While performing unit testing, we should follow some rules, which are as follows:
● To start unit testing, at least we should have one module.
● Test for positive values
● Test for negative values
● No over testing
● No assumption required
When we feel that the maximum test coverage is achieved, we will stop the testing.
Now, we will start performing the unit testing on the different components such as
● From account number(FAN)
● To account number(TAN)
● Amount
● Transfer
● Cancel
—-----------------------------------------------------------------------------------------------------------------------------------------------
For the FAN components
Values Description
1234 accept
4311 Error message→ account valid or not
blank Error message→ enter some values
5 digit/ 3 digit Error message→ accept only 4 digit
Alphanumeric Error message → accept only digit
Blocked account no Error message
Copy and paste the value Error message→ type the value
Same as FAN and TAN Error message
—-----------------------------------------------------------------------------------------------------------------------------------------------
For the TAN component
● Provide the values just like we did in From account number (FAN) components
For Amount component
● Provide the values just like we did in FAN and TAN components.
For Transfer component
● Enter valid FAN value

● Enter valid TAN value
● Enter the correct value of Amount
● Click on the Transfer button→ amount transfer successfully( confirmation message)
For Cancel Component
● Enter the values of FAN, TAN, and amount.

● Click on the Cancel button → all data should be cleared.
Unit Testing Tools

We have various types of unit testing tools available in the market, which are as follows:
● NUnit
● JUnit
● PHPunit
● Parasoft Jtest
● EMMA
Unit Testing Techniques:
Unit testing uses all white box testing techniques as it uses the code of software application:
● Data flow Testing

● Control Flow Testing
● Branch Coverage Testing
● Statement Coverage Testing
● Decision Coverage Testing
—-----------------------------------------------------------------------------------------------------------------------------------------------
How to achieve the best result via Unit testing?
Unit testing can give best results without getting confused and increase complexity by following the
steps listed below:
● Test cases must be independent because if there is any change or enhancement in

requirement, the test cases will not be affected.
● Naming conventions for unit test cases must be clear and consistent.
● During unit testing, the identified bugs must be fixed before jump on next phase of the SDLC.
● Only one code should be tested at one time.
● Adopt test cases with the writing of the code, if not doing so, the number of execution paths
will be increased.
● If there are changes in the code of any module, ensure the corresponding unit test is available
or not for that module.
Advantages and disadvantages of unit testing

Advantages
● Unit testing uses a module approach due to that any part can be tested without waiting for
completion of another parts testing.
● The developing team focuses on the provided functionality of the unit and how functionality
should look in unit test suits to understand the unit API.
● Unit testing allows the developer to refactor code after a number of days and ensure the
module is still working without any defect.
Disadvantages
● It cannot identify integration or broad level error as it works on units of the code.
● In the unit testing, evaluation of all execution paths is not possible, so unit testing is not able
to catch each and every error in a program.
● It is best suitable for conjunction with other testing activities.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Integration testing
Integration testing is the second level of the software testing process after unit testing. In this
testing, units or individual components of the software are tested in a group. The focus of the
integration testing level is to expose defects at the time of interaction between integrated
components or units.
Unit testing uses modules for testing purposes, and these modules are combined and tested in
integration testing. The Software is developed with a number of software modules that are coded by
different coders or programmers. The goal of integration testing is to check the correctness of
communication among all the modules.
Once all the components or modules are working independently, then we need to check the data flow
between the dependent modules is known as integration testing.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Let us see one sample example of a banking application, as we can see in the below image of
amount transfer.
● First, we will login as a user P to the amount transfer and send Rs200 amount, the
confirmation message should be displayed on the screen as amount transfer successfully.
Now logout as P and login as user Q and go to the amount balance page and check for a
balance in that account = Present balance + Received Balance. Therefore, the integration test
is successful.
● Also, we check if the amount of balance has reduced by Rs200 in P user account.
● Click on the transaction, in P and Q, the message should be displayed regarding the data and
time of the amount transfer.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Guidelines for Integration Testing
● We go for the integration testing only after the functional testing is completed on each
module of the application.
● We always do integration testing by picking module by module so that a proper sequence is

followed, and also we don't miss out on any integration scenarios.
● First, determine the test case strategy through which executable test cases can be prepared
according to test data.
● Examine the structure and architecture of the application and identify the crucial modules to
test them first and also identify all possible scenarios.
● Design test cases to verify each interface in detail.
● Choose input data for test case execution. Input data plays a significant role in testing.
● If we find any bugs then communicate the bug reports to developers and fix defects and
retest.
● Perform positive and negative integration testing.
Here positive testing implies that if the total balance is Rs15, 000 and we are transferring Rs1500
and checking if the amount transfer works fine. If it does, then the test would be a pass.
And negative testing means, if the total balance is Rs15, 000 and we are transferring Rs20, 000 and
check if amount transfer occurs or not, if it does not occur, the test is a pass. If it happens, then there
is a bug in the code, and we will send it to the development team for fixing that bug.
Any application in this world will do functional testing compulsory, whereas integration testing will be
done only if the modules are dependent on each other. Each integration scenario should
compulsorily have source→ data→destination. Any scenario can be called an integration scenario
only if the data gets saved in the destination.
For example: In the Gmail application, the Source could be Compose, Data could be Email and the
Destination could be the Inbox.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Example of integration testing
Let us assume that we have a Gmail application where we perform the integration testing.
First, we will do functional testing on the login page, which includes the various components such
as username, password, submit, and cancel button. Then only we can perform integration testing.
The different integration scenarios are as follows:
Scenarios1:
● First, we login as P users and click on the Compose mail and perform the functional testing
for the specific components.
● Now we click on the Send and also check for Save Drafts.
● After that, we send a mail to Q and verify in the Send Items folder of P to check if the send
mail is there.
● Now, we will log out as P and login as Q and move to the Inbox and verify that if the mail has
reached.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Secanrios2: We also perform the integration testing on Spam folders. If the particular contact has
been marked as spam, then any mail sent by that user should go to the spam folder and not in the
inbox.
As we can see in the below image, we will perform the functional testing for all the text fields and
every feature. Then we will perform integration testing for the related functions. We first test the add
user, list of users, delete user, edit user, and then search user.
Note:
● There are some features, we might be performing only the functional testing, and there are
some features where we are performing both functional and integration testing based on the
feature's requirements.
● Prioritizing is essential, and we should perform it at all the phases, which means we will open
the application and select which feature needs to be tested first. Then go to that feature and
choose which component must be tested first. Go to those components and determine what
values to be entered first.
And don't apply the same rule everywhere because testing logic varies from feature to feature.
● While performing testing, we should test one feature entirely and then only proceed to another
function.
● Among the two features, we must be performing only positive integrating testing or both
positive and negative integration testing, and this also depends on the features need.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Reason Behind Integration Testing
Although all modules of software application already tested in unit testing, errors still exist due to the
following reasons:
1. Each module is designed by individual software developers whose programming logic may
differ from developers of other modules, so; integration testing becomes essential to
determine the working of software modules.
2. To check the interaction of software modules with the database whether it is erroneous or
not.
3. Requirements can be changed or enhanced at the time of module development. These new
requirements may not be tested at the level of unit testing hence integration testing becomes
mandatory.
4. Incompatibility between modules of software could create errors.
5. To test hardware's compatibility with software.
6. If exception handling is inadequate between modules, it can create bugs.
Integration Testing Techniques

Any testing technique (Blackbox, Whitebox, and Greybox) can be used for Integration Testing; some
are listed below:
Black Box Testing

● State Transition technique
● Decision Table Technique
● Boundary Value Analysis
● All-pairs Testing
● Cause and Effect Graph
● Equivalence Partitioning
● Error Guessing
White Box Testing
● Data flow testing

● Control Flow Testing
● Branch Coverage Testing
● Decision Coverage Testing
—-----------------------------------------------------------------------------------------------------------------------------------------------
Types of Integration Testing
Integration testing can be classified into two parts:
● Incremental integration testing

● Non-incremental integration testing
Incremental Approach
In the Incremental Approach, modules are added in ascending order one by one or according to
need. The selected modules must be logically related. Generally, two or more than two modules are
added and tested to determine the correctness of functions. The process continues until the
successful testing of all the modules.
OR
In this type of testing, there is a strong relationship between the dependent modules. Suppose we
take two or more modules and verify that the data flow between them is working fine. If it is, then
add more modules and test again.
—-----------------------------------------------------------------------------------------------------------------------------------------------
For example: Suppose we have a Flipkart application, we will perform incremental integration
testing, and the flow of the application would like this:
Flipkart→ Login→ Home → Search→ Add cart→Payment → Logout
Incremental integration testing is carried out by further methods:
● Top-Down approach
● Bottom-Up approach
Top-Down ApproachThe top-down testing strategy deals with the process in which higher level
modules are tested with lower level modules until the successful completion of testing of all the
modules. Major design flaws can be detected and fixed early because critical modules are tested
first. In this type of method, we will add the modules incrementally or one by one and check the data
flow in the same order.
In the top-down approach, we will be ensuring that the module we are adding is the child of the
previous one like Child C is a child of Child B and so on as we can see in the below image:
—-----------------------------------------------------------------------------------------------------------------------------------------------
Advantages:
● Identification of defect is difficult.

● An early prototype is possible.
Disadvantages:
● Due to the high number of stubs, it gets quite complicated.

● Lower level modules are tested inadequately.
● Critical Modules are tested first so that fewer chances of defects.
Bottom-Up Method
The bottom to up testing strategy deals with the process in which lower level modules are tested
with higher level modules until the successful completion of testing of all the modules. Top level
critical modules are tested at last, so it may cause a defect. Or we can say that we will be adding the
modules from bottom to the top and check the data flow in the same order.
—-----------------------------------------------------------------------------------------------------------------------------------------------
In the bottom-up method, we will ensure that the modules we are adding are the parent of the
previous one as we can see in the below image:
Advantages
● Identification of defect is easy.

● Do not need to wait for the development of all the modules as it saves time.
Disadvantages
● Critical modules are tested last due to which the defects can occur.
● There is no possibility of an early prototype.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Hybrid Testing Method
In this approach, both Top-Down and Bottom-Up approaches are combined for testing. In this
process, top-level modules are tested with lower level modules and lower level modules tested with
high-level modules simultaneously. There is less possibility of occurrence of defects because each
module interface is tested.
Advantages
● The hybrid method provides features of both Bottom Up and Top Down methods.
● It is most time reducing method.
● It provides complete testing of all modules.
Disadvantages
● This method needs a higher level of concentration as the process carried out in both
directions simultaneously.
● Complicated method.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Non- incremental integration testing
We will go for this method, when the data flow is very complex and when it is difficult to find who is a
parent and who is a child. And in such a case, we will create the data in any module bang on all other
existing modules and check if the data is present. Hence, it is also known as the Big bang method.
Big Bang Method
In this approach, testing is done via integration of all modules at once. It is convenient for small
software systems, if used for large software systems identification of defects is difficult.
Since this testing can be done after completion of all modules due to that testing team has less time
for execution of this process so that internally linked interfaces and high-risk critical modules can be
missed easily.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Advantages:
● It is convenient for small size software systems.
Disadvantages:
● Identification of defects is difficult because finding the error where it came from is a problem,
and we don't know the source of the bug.
● Small modules missed easily.
● Time provided for testing is very less.
● We may miss to test some of the interfaces.
Let us see examples for our better understanding of the non-incremental integration testing or big
bang method:
Example1
In the below example, the development team develops the application and sends it to the CEO of the
testing team. Then the CEO will log in to the application and generate the username and password
and send a mail to the manager. After that, the CEO will tell them to start testing the application.
Then the manager manages the username and the password and produces a username and
password and sends it to the test leads. And the test leads will send it to the test engineers for
further testing purposes. This order from the CEO to the test engineer is top-down incremental
integrating testing.
In the same way, when the test engineers are done with testing, they send a report to the test leads,
who then submit a report to the manager, and the manager will send a report to the CEO. This
process is known as Bottom-up incremental integration testing as we can see in the below image:
Note: The combination incremental integration testing (I.I.T) and non-incremental integration testing
is known as sandwich testing.
—-----------------------------------------------------------------------------------------------------------------------------------------------
System Testing
System Testing includes testing of a fully integrated software system.
The software is developed in units and then interfaced with other software and hardware to create a
complete computer system. In other words, a computer system consists of a group of software to
perform the various tasks, but only software cannot perform the task; for that software must be
interfaced with compatible hardware.
System testing is a series of different types of tests with the purpose to exercise and examine the
full working of an integrated software computer system against requirements.
To check the end-to-end flow of an application or the software as a user is known as System testing.
In this, we navigate (go through) all the necessary modules of an application and check if the end
features or the end business works fine, and test the product as a whole system.
It is end-to-end testing where the testing environment is similar to the production environment.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Types of System Testing
System testing is divided into more than 50 types, but software testing companies typically uses
some of them. These are listed below:
Regression Testing
Regression testing is performed under system testing to confirm and identify if there's any defect in
the system due to modification in any other part of the system. It makes sure, any changes done
during the development process have not introduced a new defect and also gives assurance; old
defects will not exist on the addition of new software over the time.
Load Testing
Load testing is performed under system testing to clarify whether the system can work under
real-time loads or not.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Functional Testing
Functional testing of a system is performed to find if there's any missing function in the system.
Tester makes a list of vital functions that should be in the system and can be added during
functional testing and should improve the quality of the system.
Recovery Testing
Recovery testing of a system is performed under system testing to confirm reliability,
trustworthiness, accountability of the system and all are lying on recouping skills of the system. It
should be able to recover from all the possible system crashes successfully.
In this testing, we will test the application to check how well it recovers from the crashes or
disasters.
Recovery testing contains the following steps:
● Whenever the software crashes, it should not vanish but should write the crash log message
or the error log message where the reason for crash should be mentioned. For example:
C://Program Files/QTP/Cresh.log
● It should kill its own procedure before it vanishes. Like, in Windows, we have the Task
Manager to show which process is running.
● We will introduce the bug and crash the application, which means that someone will lead us to
how and when will the application crash. Or By experiences, after few months of involvement
on working the product, we can get to know how and when the application will crash.
● Re-open the application; the application must be reopened with earlier settings.
For example: Suppose, we are using the Google Chrome browser, if the power goes off, then we
switch on the system and re-open the Google chrome, we get a message asking whether we want to
start a new session or restore the previous session.
For any developed product, the developer writes a recovery program that describes why the software
or the application is crashing, whether the crash log messages are written or not, etc.
Migration Testing
Migration testing is performed to ensure that if the system needs to be modified in new
infrastructure so it should be modified without any issue.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Usability Testing
The purpose of this testing is to make sure that the system is well familiar with the user and it meets
its objective for what it is supposed to do.
Software and Hardware Testing
This testing of the system intends to check hardware and software compatibility. The hardware
configuration must be compatible with the software to run it without any issue. Compatibility provides
flexibility by providing interactions between hardware and software.
Why is System Testing Important?
● System Testing gives hundred percent assurance of system performance as it covers end to
end function of the system.
● It includes testing of System software architecture and business requirements.
● It helps in mitigating live issues and bugs even after production.
● System testing uses both existing system and a new system to feed the same data in both
and then compare the differences in functionalities of added and existing functions so the
user can understand benefits of new added functions of the system.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Verification and Validation Testing
Verification testing
Verification testing includes different activities such as business requirements, system requirements,
design review, and code walkthrough while developing a product.
It is also known as static testing, where we are ensuring that "we are developing the right product or
not". And it also checks that the developed application fulfills all the requirements given by the client.
Validation testing
Validation testing is testing where testers performed functional and non-functional testing. Here
functional testing includes Unit Testing(UT), Integration Testing(IT) and System Testing (ST), and
non-functional testing includes User acceptance testing (UAT).
Validation testing is also known as dynamic testing, where we are ensuring that "we have developed
the product right." And it also checks that the software meets the business needs of the client.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Validation testing can be best demonstrated using V-Model. The Software/product under test is
evaluated during this type of testing.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Difference between verification and validation testing
Verification Validation
We check whether we are developing the right We check whether the developed product is right.
product or not.
Verification is also known as static testing. Validation is also known as dynamic testing.
Verification includes different methods like Validation includes testing like functional, system,
Inspections, Reviews, and Walkthroughs. integration and User acceptance testing.
It is a process of checking the work-products (not It is a process of checking the software during or at
the final product) of a development cycle to decide the end of the development cycle to decide whether
whether the product meets the specified the software follow the specified business
requirements. requirements.
Quality assurance comes under verification testing. Quality control comes under validation testing.
The execution of code does not happen in the In validation testing, the execution of code happens.
verification testing.
In verification testing, we can find the bugs early in In the validation testing, we can find those bugs,
the development phase of the product. which are not caught in the verification process.
Verification testing is executed by the Quality Validation testing is executed by the testing team to
assurance team to make sure that the product is test the application.
developed according to customers' requirements.
Verification is done before the validation testing. After verification testing, validation testing takes
place.
In this type of testing, we can verify that the inputs In this type of testing, we can validate that the user
follow the outputs or not. accepts the product or not.
—-----------------------------------------------------------------------------------------------------------------------------------------------
WHITE-BOX TESTING
White Box Testing is a testing technique in which software’s internal structure, design, and
coding are tested to verify input-output flow and improve design, usability, and security. In white box
testing, code is visible to testers, so it is also called Clear box testing, Open box testing, Transparent
box testing, Code-based testing, and Glass box testing.
Using white-box testing methods, you can derive test cases that
(1) guarantee that all independent paths within a module have been exercised at least once,
(2) exercise all logical decisions on their true and false sides,
(3) execute all loops at their boundaries and within their operational bounds, and
(4) exercise internal data structures to ensure their valid
BASIS PATH TESTING :

Basis Path Testing in software engineering is a White Box Testing method in which test cases
are defined based on flows or logical paths that can be taken through the program.
- The objective of basis path testing is to define the number of independent paths, so the
number of test cases needed can be defined explicitly to maximize test coverage.
- In software engineering, Basis path testing involves execution of all possible blocks in a
program and achieves maximum path coverage with the least number of test cases.
- It is a hybrid method of branch testing and path testing methods.
- A path is the route of nodes in the control flow graph that a program takes from one
point to another.
- An independent path is a path that adds at least one node in the already defined
independent paths. In other words, the independent paths of a program are all unique.
Steps for basis path testing

To conduct basis path testing of a program, follow the steps below:
1. Draw the control flow graph of the program.
2. Calculate the cyclomatic complexity of the control flow graph. This will be the
maximum number of independent paths in the graph.
3. Identify independent paths in the control flow graph.
4. Design test cases based on the independent paths identified so that the test cases
execute all independent paths.
—-----------------------------------------------------------------------------------------------------------------------------------------------
1. Control Flow Graph –
A control flow graph (or simply, flow graph) is a directed graph which represents the control
structure of a program or module. A control flow graph (V, E) has V number of nodes/vertices
and E number of edges in it. A control graph can also have :
● Junction Node – a node with more than one arrow entering it.
● Decision Node – a node with more then one arrow leaving it.
● Region – area bounded by edges and nodes (area outside the graph is also
counted as a region.).
—-----------------------------------------------------------------------------------------------------------------------------------------------
Below are the notations used while constructing a flow graph :
● Sequential Statements –
● If – Then – Else –
—-----------------------------------------------------------------------------------------------------------------------------------------------
● Do – While –
● While – Do –
—-----------------------------------------------------------------------------------------------------------------------------------------------
● Switch – Case –
Here we will take a simple example, to get a better idea what is basis path testing include
In the above example, we can see there are few conditional statements that is executed depending on
what condition it suffice. Here there are 3 paths or condition that need to be tested to get the output,
● Path 1: 1,2,3,5,6, 7
● Path 2: 1,2,4,5,6, 7
● Path 3: 1, 6, 7
—-----------------------------------------------------------------------------------------------------------------------------------------------
Cyclomatic Complexity –
The cyclomatic complexity V(G) is said to be a measure of the logical complexity of a program. It
can be calculated using three different formulae :
Formula based on edges and nodes :
V(G) = e - n + 2*P
Where,
e is number of edges,
n is number of vertices,
P is number of connected components.
For example, consider first graph given above,

where, e = 4, n = 4 and p = 1
So,
Cyclomatic complexity V(G)
= 4 - 4 + 2 * 1
= 2
Formula based on Decision Nodes :

V(G) = d + P
where,
d is number of decision nodes,
P is the number of connected nodes.
where, d = 1 and p = 1
So,
Cyclomatic Complexity V(G)
= 1 + 1
= 2
Formula based on Regions :
V(G) = number of regions in the graph
Cyclomatic complexity V(G)
= 1 (for Region 1) + 1 (for Region 2)
= 2
Hence, using all the three above formulae, the cyclomatic complexity obtained remains
same. All these three formulae can be used to compute and verify the cyclomatic complexity
of the flow graph.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Independent Paths :
An independent path in the control flow graph is the one which introduces at least one
new edge that has not been traversed before the path is defined. The cyclomatic
complexity gives the number of independent paths present in a flow graph. This is because
the cyclomatic complexity is used as an upper-bound for the number of tests that should be
executed in order to make sure that all the statements in the program have been executed at
least once.
Design Test Cases :

Finally, after obtaining the independent paths, test cases can be designed where each test
case represents one or more independent paths.
Advantages :
Basis Path Testing can be applicable in the following cases:
1. More Coverage –
Basis path testing provides the best code coverage as it aims to achieve maximum
logic coverage instead of maximum path coverage. This results in an overall
thorough testing of the code.
2. Maintenance Testing –
When a software is modified, it is still necessary to test the changes made in the
software which as a result, requires path testing.
3. Unit Testing –
When a developer writes the code, he or she tests the structure of the program or
module themselves first. This is why basis path testing requires enough knowledge
about the structure of the code.
4. Integration Testing –
When one module calls other modules, there are high chances of Interface errors.
In order to avoid the case of such errors, path testing is performed to test all the
paths on the interfaces of the modules.
5. Testing Effort –
Since the basis path testing technique takes into account the complexity of the
software (i.e., program or module) while computing the cyclomatic complexity,
therefore it is intuitive to note that testing effort in case of basis path testing is
directly proportional to the complexity of the software or program.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Example :
Consider the code snippet below, which is a simple program to add two numbers
together.
int a = 1;
int b = 2;
cout<<"a + b = "<<a+b;
Control flow graph

The control flow graph of the code snippet above will be as follows:
Cyclomatic complexity
The cyclomatic complexity of the control flow graph will be calculated as:
● E: the number of edges in the control graph = 2

● N: the number of nodes in the control graph = 3
● P: the number of connected components in the control graph = 1
● D: the number of decisions in the control graph = 0
Method 1
CC = E - N + 2P
CC = 2 - 3 + 2(1)
CC = 1
Method 2
CC = D + 1
CC = 0 + 1
CC = 1
—-----------------------------------------------------------------------------------------------------------------------------------------------
Consider the code snippet below, which is a program to get the maximum of two
numbers.
int a = 1;
int b = 2;
if (a>b){
cout<<"a is greater";
}else{
cout<<"b is greater";
}
Control flow graph
The control flow graph of the code snippet above will be as follows:
Cyclomatic complexity
The cyclomatic complexity of the control flow graph will be calculated as:
● E: the number of edges in the control graph = 6

● N: the number of nodes in the control graph = 6
● P: the number of connected components in the control graph = 1
● D: the number of decisions in the control graph = 1
Method 1
CC = E - N + 2P
CC = 6 - 6 + 2(1)
CC = 2
Method 2
CC = D + 1
CC = 1 + 1
CC = 2
—-----------------------------------------------------------------------------------------------------------------------------------------------
int main (){
int n, index;
cout << "Enter a number: " << endl;
cin >> n;
index = 2;
while (index <= n - 1) {
if (n % index == 0) {
cout << "It is not a prime number" << endl;
break;
}
index++;
}
if (index == n)
cout << "It is a prime number" << endl;
} // end main
Solution: 1. Create a Control Flow Diagram

Step 1 − After declaring the variables, begin numbering the statements (if no variables have been
initialized in that statement). If a variable is initialized and declared on the same line, however, the
numbering should begin on that line.
This is how numbering will be done for the supplied program −
int main (){

int n, index;
cout << "Enter a number: " <> n;
index = 2;
while (index <= n - 1){
if (n % index == 0){
cout << "It is not a prime number" << endl;
break;
}
index++;
}
if (index == n)
cout << "It is a prime number" << endl;
} // end main
—-----------------------------------------------------------------------------------------------------------------------------------------------
Step 2 − Combine all of the sequential statements into one node. Statements 1, 2, and 3 are, for
example, all consecutive statements that should be concatenated into a single node. For the rest of
the statements, we'll use the notations described here.
Note − To keep things simple, number nodes in alphabetical order.
The resulting graph will look like this −
Calculate the cyclomatic complexity by using the following formula −

Method 1:
V(G) = e - n + 2*p
In the control flow diagram above,
where e = 10, n = 8, and p =1
As a result, V(G) = 10 - 8 + 2 * 1 = 4 Cyclomatic Complexity
—-----------------------------------------------------------------------------------------------------------------------------------------------
Method 2:
V(G) = d + p
In the control flow diagram above,
where d = 3 (Node B, C, and F) and p = 1
As a result, the cyclomatic complexity V(G) = 3 + 1 = 4
Method 3:
V(G) = Number of Regions (method 3)
There are four zones in the aforementioned control flow graph, as indicated below −
As a result, there are four distinct regions: R1, R2, R3, and R4.
V(G) = 1 + 1 + 1 + 1 = 4 cyclomatic complexity
It's worth noting that all three ways get the same cyclomatic complexity V value (G).
—-----------------------------------------------------------------------------------------------------------------------------------------------
Independent Paths
Because the cyclomatic complexity V(G) for the graph is 4, there are 4 independent paths.
Path 1 covers (in red) the following edges −
A – B – F – G – H is the first path.
—-----------------------------------------------------------------------------------------------------------------------------------------------
The following are the edges that Path 1 and Path 2 cover −
A – B – F – H is the second path.
Path 1, Path 2, and Path 3 cover the following edges −
—-----------------------------------------------------------------------------------------------------------------------------------------------
A - B - C - E - B - F - G - H is the third path
Only two edges remain uncovered, namely edge C-D and edge D-F. As a result, these two edges
must be included in Path 4.
A - B - C - D - F - H is the fourth path.
Each of these pathways has at least one new edge that has never been crossed previously.
Note that independent pathways aren't always unique.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Test Cases
We must use the previously discovered independent paths to generate test cases. Provide input to
the program in such a way that each independent path is executed to create a test case.
The following test cases will be obtained for the supplied program −
Test case ID Input Number Output Independent Path covered
1 1 No output A-B-F-H
2 2 It is a prime number A-B-F-G-H
3 3 It is a prime number A-B-C-E-B-F-G-H
4 4 It is not a prime number A-B-C-D-F-H
—-----------------------------------------------------------------------------------------------------------------------------------------------
Control Structure Testing
Control structure testing is used to increase the coverage area by testing various control
structures present in the program. The different types of testing performed under control
structure testing are as follows-
1. Condition Testing
2. Data Flow Testing
3. Loop Testing
1. Condition Testing :
Condition testing is a test cased design method, which ensures that the logical condition and
decision statements are free from errors. The errors present in logical conditions can be
incorrect boolean operators, missing parentheses in a booleans expression, error in
relational operators, arithmetic expressions, and so on.
The common types of logical conditions that are tested using condition testing are-
1. A relation expression, like E1 op E2 where ‘E1’ and ‘E2’ are arithmetic expressions
and ‘OP’ is an operator.
2. A simple condition like any relational expression preceded by a NOT (~) operator.
For example, (~E1) where ‘E1’ is an arithmetic expression and ‘a’ denotes NOT
operator.
3. A compound condition consists of two or more simple conditions, Boolean operator,
and parenthesis.
For example, (E1 & E2)|(E2 & E3) where E1, E2, E3 denote arithmetic expression and
‘&’ and ‘|’ denote AND or OR operators.
4. A Boolean expression consists of operands and a Boolean operator like ‘AND’, OR,
NOT.
For example, ‘A|B’ is a Boolean expression where ‘A’ and ‘B’ denote operands and |
denotes OR operator.
—-----------------------------------------------------------------------------------------------------------------------------------------------
2. Data Flow Testing :
Data Flow Testing is a specific strategy of software testing that focuses on data
variables and their values. It makes use of the control flow graph. When it comes to
categorization Data flow testing will can be considered as a type of white box testing and
structural types of testing. It keeps a check at the data receiving points by the variables
and its usage points. It is done to cover the path testing and branch testing gap.
The process is conducted to detect the bugs because of the incorrect usage of data
variables or data values. For e.g. Initialization of data variables in programming code, etc.
What is Data flow Testing?
● The programmer can perform numerous tests on data values and variables.
This type of testing is referred to as data flow testing.
● It is performed at two abstract levels: static data flow testing and dynamic data
flow testing.
● The static data flow testing process involves analyzing the source code without
executing it.
● Static data flow testing exposes possible defects known as data flow anomaly.
● Dynamic data flow identifies program paths from source code.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Let us understand this with the help of an example.
There are 8 statements in this code. In this code we cannot cover all 8 statements in a
single path as if 2 is valid then 4, 5, 6, 7 are not traversed, and if 4 is valid then statement
2 and 3 will not be traversed.
Hence we will consider two paths so that we can cover all the statements.
x= 1
Path – 1, 2, 3, 8
Output = 2
If we consider x = 1, in step 1; x is assigned a value of 1 then we move to step 2 (since,
x>0 we will move to statement 3 (a= x+1) and at end, it will go to statement 8 and print x
=2.
For the second path, we assign x as 1
Set x= -1
Path = 1, 2, 4, 5, 6, 5, 6, 5, 7, 8
—-----------------------------------------------------------------------------------------------------------------------------------------------
Output = 2
x is set as 1 then it goes to step 1 to assign x as 1 and then moves to step 2 which is
false as x is smaller than 0 (x>0 and here x=-1). It will then move to step 3 and then jump
to step 4; as 4 is true (x<=0 and their x is less than 0) it will jump on 5 (x<1) which is true
and it will move to step 6 (x=x+1) and here x is increased by 1.
So,
x=-1+1
x=0
x become 0 and it goes to step 5(x<1),as it is true it will jump to step
6 (x=x+1)
x=x+1
x= 0+1
x=1
x is now 1 and jump to step 5 (x<1) and now the condition is false and it will jump to step
7 (a=x+1) and set a=2 as x is 1. At the end the value of a is 2. And on step 8 we get the
output as 2.
—-----------------------------------------------------------------------------------------------------------------------------------------------
3. Loop Testing :
Loop testing is actually a white box testing technique. It specifically focuses on the validity of
loop construction.
Following are the types of loops.
1. Simple Loop – The following set of test can be applied to simple loops, where the
maximum allowable number through the loop is n.
1. Skip the entire loop.
2. Traverse the loop only once.
3. Traverse the loop two times.
4. Make p passes through the loop where p<n.
5. Traverse the loop n-1, n, n+1 times.
—-----------------------------------------------------------------------------------------------------------------------------------------------
2. Concatenated Loops – If loops are not dependent on each other, contact loops
can be tested using the approach used in simple loops. if the loops are
interdependent, the steps are followed in nested loops.
3. Nested Loops – Loops within loops are called as nested loops. when testing
nested loops, the number of tested increases as level nesting increases.
The following steps for testing nested loops are as follows-
1. Start with inner loop. set all other loops to minimum values.
2. Conduct simple loop testing on inner loop.
3. Work outwards.
4. Continue until all loops tested.
—-----------------------------------------------------------------------------------------------------------------------------------------------
4. Unstructured loops – This type of loops should be redesigned, whenever
possible, to reflect the use of unstructured the structured programming constructs.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Black Box Testing
Black-box testing also called behavioral testing,
● It focuses on the functional requirements of the software.
● Functional testing of a component of a system
● Examine behavior through inputs & the corresponding outputs.
● Input is properly accepted, output is correctly produced.
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
● Black box testing is used during the later stages of testing after white
box testing has been performed.
● Different Black box testing techniques
○ (1) Graph Based Testing Methods
○ (2) Equivalence Partitioning
○ (3) Boundary Value Analysis

—-----------------------------------------------------------------------------------------------------------------------------------------------
Graph-Based Testing Methods
● The first step in black-box testing is to understand the objects that are modeled in
software and the relationships that connect these objects.
● Once this has been accomplished, the next step is to define a series of tests that
verify “all objects have the expected relationship to one another”.
● Graph Representation
○ A collection of nodes that represent objects,

○ Links that represent the relationships between objects,
○ Node weights that describe the properties of a node (e.g., a specific data
value or state behavior),
○ Link weights that describe some characteristic of a link.
○ The symbolic representation of a graph is shown in Figure.
○ Nodes are represented as circles connected by links that take a number of
different forms.
○ A directed link (represented by an arrow) indicates that a relationship
moves in only one direction.
○ A bidirectional link, also called a symmetric link, implies that the
relationship applies in both directions.
○ Parallel links are used when a number of different relationships are
established between graph nodes.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Equivalence Partitioning Method
● Equivalence partitioning is a black-box testing method that divides the input

domain of a program into classes of data from which test cases can be derived.
● This technique is also known as Equivalence Class Partitioning (ECP). In this technique, input
values to the system or application are divided into different classes or groups based on its
similarity in the outcome.
● Hence, instead of using each and every input value, we can now use any one value from the
group/class to test the outcome. This way, we can maintain test coverage while we can reduce the
amount of rework and most importantly the time spent.
● Equivalence classes guidelines
● If an input condition specifies a range,
○ one valid and two invalid equivalence classes are defined
○ Input range: 1 – 10 Eq classes: {1..10}, {x < 1}, {x > 10}
● If an input condition requires a specific value,
○ one valid and two invalid equivalence classes are defined
○ Input value: 250 Eq classes: {250}, {x < 250}, {x > 250}
● If an input condition specifies a member of a set,
○ one valid and one invalid equivalence class are defined
○ Input set: {-2.5, 7.3, 8.4} Eq classes: {-2.5, 7.3, 8.4}, {any other x}
● If an input condition is a Boolean value,
○ one valid and one invalid class are define
○ Input: {true condition} Eq classes: {true condition}, {false condition}
For Example:
—-----------------------------------------------------------------------------------------------------------------------------------------------
As present in the above image, the “AGE” text field accepts only numbers from 18 to 60. There will be
three sets of classes or groups.
Two invalid classes will be:
a) Less than or equal to 17.

b) Greater than or equal to 61.
A valid class will be anything between 18 and 60.
We have thus reduced the test cases to only 3 test cases based on the formed classes thereby covering
all the possibilities. So, testing with any one value from each set of the class is sufficient to test the above
scenario.
Examples of Equivalence Partitioning technique
Assume that there is a function of a software application that accepts a particular number of digits,
not greater and less than that particular number. For example, an OTP number which contains only
six digits, less or more than six digits will not be accepted, and the application will redirect the user
to the error page.
OTP Number = 6 digits
—-----------------------------------------------------------------------------------------------------------------------------------------------
Boundary Value Analysis Technique
The name itself defines that in this technique, we focus on the values at boundaries as it is found that
many applications have a high amount of issues on the boundaries.
Boundary refers to values near the limit where the behavior of the system changes. In boundary value
analysis, both valid and invalid inputs are being tested to verify the issues.
● A greater number of errors occurs at the boundaries of the input domain.
● It is for this reason that boundary value analysis (BVA) has been developed as
a testing technique
● 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
● Guidelines for BVA
○ If an input condition specifies a range bounded by values a and b, test

cases should be designed with values a and b and just above and just below
a and b.
○ If an input condition specifies a number of values, test cases should be

developed that exercise the minimum and maximum numbers. Values just
above and below minimum and maximum are also tested.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Let's understand via practical:
Imagine, there is a function that accepts a number between 18 to 30, where 18 is the minimum and
30 is the maximum value of valid partition, the other values of this partition are 19, 20, 21, 22, 23, 24,
25, 26, 27, 28 and 29. The invalid partition consists of the numbers which are less than 18 such as
12, 14, 15, 16 and 17, and more than 30 such as 31, 32, 34, 36 and 40. Tester develops test cases for
both valid and invalid partitions to capture the behavior of the system on different input conditions.
The software system will be passed in the test if it accepts a valid number and gives the desired
output, if it is not, then it is unsuccessful. In another scenario, the software system should not accept
invalid numbers, and if the entered number is invalid, then it should display error massage.
If the software which is under test, follows all the testing guidelines and specifications then it is sent
to the releasing team otherwise to the development team to fix the defects.
—-----------------------------------------------------------------------------------------------------------------------------------------------
What is Test case?
A test case is a document, which has a set of test data, preconditions, expected results and
postconditions, developed for a particular test scenario in order to verify compliance against a
specific requirement.
Test Case acts as the starting point for the test execution, and after applying a set of input values,
the application has a definitive outcome and leaves the system at some end point or also known as
execution postcondition.
Typical Test Case Parameters:

● Test Case ID
● Test Scenario
● Test Case Description
● Test Steps
● Prerequisite
● Test Data
● Expected Result
● Test Parameters
● Actual Result
● Environment Information
● Comments
Example:
Let us say that we need to check an input field that can accept maximum of 10 characters.
While developing the test cases for the above scenario, the test cases are documented the
following way. In the below example, the first case is a pass scenario while the second case is a
FAIL.
Scenario Test Step Expected Result Actual Outcome
Verify that the input field that Login to application Application should be Application accepts
can accept maximum of 10 and key in 10 able to accept all 10 all 10 characters.
characters characters characters.
Verify that the input field that Login to application Application should NOT Application accepts
can accept maximum of 11 and key in 11 accept all 11 characters. all 10 characters.
characters characters
If the expected result doesn't match with the actual result, then we log a defect. The defect goes
through the defect life cycle and the testers address the same after fix.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Software Maintenance
Software maintenance is a part of the Software Development Life Cycle. Its primary goal is to modify
and update software applications after delivery to correct errors and to improve performance.
Software is a model of the real world. When the real world changes, the software requires alteration
wherever possible.
Software Maintenance is an inclusive activity that includes error corrections, enhancement of

capabilities, deletion of obsolete capabilities, and optimization.
Need for Maintenance

● Correct errors
● Change in user requirement with time
● Changing hardware/software requirements
● To improve system efficiency
● To optimize the code to run faster
● To modify the components
● To reduce any unwanted side effects.
Thus the maintenance is required to ensure that the system continues to satisfy user requirements.
Types of Software Maintenance
—-----------------------------------------------------------------------------------------------------------------------------------------------
1. Corrective Maintenance
Corrective maintenance aims to correct any remaining errors regardless of where they may cause
specifications, design, coding, testing, and documentation, etc.
This includes modifications and updations done in order to correct or fix problems, which are either
discovered by user or concluded by user error reports.
2. Adaptive Maintenance
It contains modifying the software to match changes in the ever-changing environment.
This includes modifications and updations applied to keep the software product up-to date and
tuned to the ever changing world of technology and business environment.
3. Preventive Maintenance
This includes modifications and updates done in order to keep the software usable over long period
of time. It includes new features, new user requirements for refining the software and improve its
reliability and performance.
It is the process by which we prevent our system from being obsolete. It involves the concept of
reengineering & reverse engineering in which an old system with old technology is re-engineered
using new technology. This maintenance prevents the system from dying out.
4. Perfective Maintenance
It defines improving processing efficiency or performance or restricting the software to enhance
changeability. This may contain enhancement of existing system functionality, improvement in
computational efficiency, etc.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software maintenance
found that the cost of maintenance is as high as 67% of the cost of entire software process cycle.
On an average, the cost of software maintenance is more than 50% of all SDLC phases. There are
various factors, which trigger maintenance cost go high, such as:
Real-world factors affecting Maintenance Cost

● The standard age of any software is considered up to 10 to 15 years.
● Older softwares, which were meant to work on slow machines with less memory and
storage capacity cannot keep themselves challenging against newly coming enhanced
softwares on modern hardware.
● As technology advances, it becomes costly to maintain old software.
● Most maintenance engineers are newbie and use trial and error method to rectify
problem.
● Often, changes made can easily hurt the original structure of the software, making it
hard for any subsequent changes.
● Changes are often left undocumented which may cause more conflicts in future.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Software-end factors affecting Maintenance Cost
● Structure of Software Program
● Programming Language
● Dependence on external environment
● Staff reliability and availability
Maintenance Activities
IEEE provides a framework for sequential maintenance process activities. It can be used in iterative
manner and can be extended so that customized items and processes can be included.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Software Re-engineering
When we need to update the software to keep it to the current market, without impacting its
functionality, it is called software re-engineering. It is a thorough process where the design of
software is changed and programs are re-written.
Legacy software cannot keep tuning with the latest technology available in the market. As the
hardware becomes obsolete, updating software becomes a headache. Even if software grows old
with time, its functionality does not.
For example, initially Unix was developed in assembly language. When language C came into
existence, Unix was re-engineered in C, because working in assembly language was difficult.
Other than this, sometimes programmers notice that few parts of software need more maintenance
than others and they also need re-engineering.
Re-Engineering Process
● Decide what to re-engineer. Is it whole software or a part of it?
● Perform Reverse Engineering, in order to obtain specifications of existing software.
● Restructure Program if required. For example, changing function-oriented programs
into object-oriented programs.
● Re-structure data as required.
● Apply Forward engineering concepts in order to get re-engineered software.
—-----------------------------------------------------------------------------------------------------------------------------------------------
There are few important terms used in Software re-engineering
Reverse Engineering
It is a process to achieve system specification by thoroughly analyzing, understanding the existing
system. This process can be seen as a reverse SDLC model, i.e. we try to get a higher abstraction
level by analyzing lower abstraction levels.
An existing system is a previously implemented design, about which we know nothing. Designers
then do reverse engineering by looking at the code and trying to get the design. With design in
hand, they try to conclude the specifications. Thus, going in reverse from code to system
specification.
Program Restructuring
It is a process to restructure and re-construct the existing software. It is all about re-arranging the
source code, either in the same programming language or from one programming language to a
different one. Restructuring can have either source code-restructuring and data-restructuring or
both.
Re-structuring does not impact the functionality of the software but enhances reliability and
maintainability. Program components, which cause errors very frequently can be changed, or
updated with restructuring.
The dependability of software on obsolete hardware platforms can be removed via restructuring.
Forward Engineering
Forward engineering is a process of obtaining desired software from the specifications in hand
which were brought down by means of reverse engineering. It assumes that there was some
software engineering already done in the past.
Forward engineering is same as software engineering process with only one difference – it is carried
out always after reverse engineering.
—-----------------------------------------------------------------------------------------------------------------------------------------------
Component reusability
A component is a part of software program code, which executes an independent task in the
system. It can be a small module or sub-system itself.
—-----------------------------------------------------------------------------------------------------------------------------------------------

Software Engineering - Chapter 6

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering - Chapter 6

Uploaded by

Copyright:

Available Formats

Chapter 5 : Software Testing

What is Software Testing

Software testing can be divided into two steps:

Software Testing Strategy

What is Manual Testing?

Why Unit Testing?

Some crucial reasons are listed below:

For the amount transfer, requirements are as follows:

1.1 From account number (FAN)→ Text Box

1.1.1 FAN→ accept only 4 digit

1.2 To account no (TAN)→ Text Box

1.2.1 TAN→ Accept only 4 digit

1.3 Amount→ Text Box

1.3.1 Amount → Accept maximum 4 digit

1.4 Transfer→ Button

1.4.1 Transfer → Enabled

1.5 Cancel→ Button

1.5.1 Cancel→ Enabled

● URL→ login Page

● Username/password/OK → home page

● To reach Amount transfer module follow the below

Loans → sales → Amount transfer

● To start unit testing, at least we should have one module.

● Test for positive values

● Test for negative values

● From account number(FAN)

4311 Error message→ account valid or not

blank Error message→ enter some values

5 digit/ 3 digit Error message→ accept only 4 digit

Alphanumeric Error message → accept only digit

Blocked account no Error message

Same as FAN and TAN Error message

For Amount component

For Transfer component

● Enter valid FAN value

For Cancel Component

● Enter the values of FAN, TAN, and amount.

Unit Testing Tools

Unit Testing Techniques:

● Data flow Testing

● Test cases must be independent because if there is any change or enhancement in

● Only one code should be tested at one time.

Advantages and disadvantages of unit testing

● It is best suitable for conjunction with other testing activities.

● We always do integration testing by picking module by module so that a proper sequence is

● Design test cases to verify each interface in detail.

● Perform positive and negative integration testing.

The different integration scenarios are as follows:

4. Incompatibility between modules of software could create errors.

5. To test hardware's compatibility with software.

6. If exception handling is inadequate between modules, it can create bugs.

Integration Testing Techniques

Black Box Testing

White Box Testing

● Data flow testing

● Incremental integration testing

Flipkart→ Login→ Home → Search→ Add cart→Payment → Logout

Incremental integration testing is carried out by further methods:

● Identification of defect is difficult.

● Due to the high number of stubs, it gets quite complicated.

● Identification of defect is easy.