A PARTICLE SWARM OPTIMIZATION TECHNIQUE FOR GENERATING PAIRWISE TEST CASES

1
CHAPTER 1
INTRODUCTION
1.1 INTRODUCTION
Software testing and debugging is an essential part in software development process but
this process is confirmed to be intensive and expensive. In research and industry
communities, researchers and practitioners focus on finding automatic cost-effective
software testing and debugging techniques while still maintaining high fault detection and
localization ability to ensure releasing high-quality software productions. Nowadays
software testing research mainly concerns such issues as test coverage criterion design,
test generation problem, test oracle problem, regression testing problem and fault
localization problem. Among these issues, test generation problem is deemed to be an
important issue in software testing research.
In numerous test generation techniques, combinatorial testing is considered to be an
important test input generation technique and it is an important complement to other black
box testing techniques such as boundary value analysis and equivalence class partition.
Combinatorial testing generates test suites according to artifacts under test. These artifacts
come from either functional requirements or detailed development specifications. Given
an input described by factors and levels after analyzing a specific artifact, to make an
exhaustive test, we should generate a set of tests to cover every possible combination of all
those factors. However the size of generated tests may be too large and the required test
cost is prohibitive. To overcome this shortcoming, Cohen et al. firstly introduced the
concept of combinatorial testing and proposed a greedy algorithm AETG. This testing
technique can extremely reduce the number of tests by only concerning combinations of a
few factors and they demonstrated that the size of the optimal test suite grows at most
logarithmically with the number of factors. When we only want to cover all the
combinations of arbitrary two factors, we call it pairwise testing. However, the reduction
of tests does not seriously weaken the effectiveness of fault detection ability.
Empirical studies found that a significant number of faults are triggered by the
combinations of a small number of factors in a variety of application domains. For
example, Kuhn et al. analyzed error reports of a large distributed system after applying
combinatorial testing and found that more than 70% bugs were found by pairwise testing.
To find all the faults, they only need 6-way combinatorial testing at most. Nowadays, most

2
of research works in combinatorial testing aims to generate combinatorial test suites with
minimum size. However, the difficulty of solving this problem is demonstrated to be NP-
hard. By now many approaches have been proposed and many tools have been developed
to find optimal or near optimal combinatorial test suites in polynomial time. Existing
approaches and tools can be briefly divided into three categories: algebraic construction,
greedy algorithm and meta-heuristic search. The brief description of these approaches can
be found in section V.
1.2 MOTIVATION
Pair-wise testing is a specification based testing criterion, which requires that for each pair
number of input parameters of a system, every combination of valid values of these
parameters be covered by at least one test case. Empirical results show that pair-wise
testing is practical and effective for various types of software systems. By seeing the graph
we have found that there are 90% of errors can be covered by applying pair-wise testing.
Hence pair-wise testing can be used in web applications.
Fig: 1 Percentage of failures trigger by t-way interactions
1.3 AIM AND OBJECTIVE
Combinatorial interaction testing is an existing technique that appropriately reduces the
number of test cases by choosing pairs, triplets, etc., i.e. pair, of input values. Of course,
the effectiveness of a test suite is higher when choosing e.g. triplets of inputs rather than
pairs. Since high values of pairs are preferable, a large number of test cases could still be
generated. This approach is motivated by the observation that in many applications a
significant number of faults are caused by interactions of a smaller number of parameters.
The main aim of our project is to generate the optimized pair wise test cases test suite for
testing WEB based applications using PSO technique.

3
1.4 SUMMARY OF THE PROJECT
The next chapter in this project (Chapter-2) is about survey of the Literature. In Chapter 3
we present the definition of the Problem and various feasibility analysis studies regarding
this project.Chapter-4 of this project precisely says about software Requirements
Specification (SRS) needed for developing the project. In Chapter-5 we mention various
design issues and different UML diagrams required to develop the design of the proposing
system. In Chapter-6 we mention the implementation issues of this project. Last chapter
in this report is briefly about the references, different textbooks and websites we referred
for this project.

4
CHAPTER 2
SURVEY OF THE LITERATURE
2.1 INTRODUCTION
Lack of testing often leads to disastrous consequences including loss of data, fortunes and
Even lives. For these reasons, many input parameters and system conditions need to be
tested against the specifications of the system for conformance. Although desirable,
exhaustive testing is prohibitively expensive even in a moderate-sized project, due to
resources as well as timing constraints. Therefore, it is necessary to reduce the test
selection space in a systematic manner. In line with increasing consumer demands for new
functionalities and innovations, software applications grew tremendously in size over the
last 15 years. This sudden increase has a profound impact as far as testing is concerned.
Here, the test size grew significantly as a result. To address the aforementioned issues,
much research is now focusing on sampling techniques based on interaction testing
(termed t-way testing strategy) in order to derive the most optimum test suite for testing
consideration (i.e., termed as Covering Array (CA)for uniform parameter values and
Mixed Covering Array(MCA) for non-uniform parameter values respectively).
Two-way testing (also termed pair wise) appears to be adequate for achieving good
test coverage in some existing system, a counter argument suggests that such a conclusion
cannot be generalized to all (future) software system. Often, the net effect of software
growth introduces new intertwined dependency between parameters involved, thus,
justifying the need to support for high interaction strength (t).One reduction approach is
via pair wise testing. Pair wise testing helps detect faults caused by interactions between
two parameters. Indeed, earlier work demonstrates that pair wise testing achieves higher
block and decision coverage than traditional methods for a commercial email system.
While such a conclusion can be true for some system, a counter argument suggests that
some faults may also be caused by the interaction of more than two parameters (i.e. often
termed as t-way testing). For example, by applying pair-way testing to a telephone
software system demonstrates that several faults can only be detected under certain
combinations of input parameters.
A study conducted by The National Institute of Standards and Technology (NIST)
has shown that 95% of actual faults are caused by 4-wayinteractions in some system. In

5
fact, only after considering up to 6-way interactions can all the faults be found. Given that
software applications grew tremendously in the last 15years, there is clearly a need to
consider the support for high interaction strength, that is, to cater for the possibility of new
intertwined dependencies between involved parameters. Considering more than two
parameter interactions is not without difficulties. When the number of parameter coverage
increases, the size of pair-way test sets also increases exponentially. As such, for a large
system, considering a higher order t-way test set can lead to a combinatorial explosion
problem. Here, computational efforts required in search of an optimum test set, termed as
Covering Array (CA)(in which the parameter values are uniform) and Mixed Covering
Array (MCA) (in which the parameter values are non-uniform), can be expensive
especially when each interaction is to be covered optimally by the minimum number of
test cases for a given interaction strength (t).Addressing the aforementioned issues, this
paper proposes a new strategy, called Modified IPOG for pair-way testing.
Some of pair-wise test techniques are available to generate the pair-wise test cases like,
ACO (Ant Colony Optimization), BCO (Bee colony Optimization), and Simulated
Annealing etc. For a system with two or more input parameters, the GA strategy generates
a pair-wise test set for the first pair parameters, extends the test and continues to do so for
each additional parameter.
2.2 LITERATURE SURVEY
2.2.1 Using Organizational Evolutionary Particle Swarm Techniques to Generate
TestCases for Combinatorial Testing
Based on the analysis of the characteristics of combinatorial testing, an organizational
evolutionary particle swarm algorithm (OEPST) to generate test cases for combinatorial
testing is proposed. This algorithm is used to select the test cases of local optimal coverage
in current environment based on these test cases, and then a test suite satisfying the pair-
wise coverage criterion is built. The empirical results show that their approach can
effectively reduce the number of test case.
2.2.2 An Improved Algorithm for Test Data Generation Based on Particle Swarm
Optimization
The test case generation is one of key issues of combinatorial testing. In this paper, a new
algorithm for test data generation based on Particle Swarm Optimization PSO is presented.
Based on Particle Swarm Optimization, the optimization base and extended parameters are

6
introduced. The number of the current output test data is adjusted dynamically according
to the data generated before. The efficiency of the test data generation is improved
effectively on the premise of ensuring the optimization of the data generated.
2.2.3 PSTG: A T-Way Strategy Adopting Particle Swarm Optimization
As an activity to ensure quality and conformance, testing is one of the most important
activities in any software or hardware product development cycle. Often, the challenge in
testing is that the system may support a wide range of configurations. Ideally, it is
desirable to test all of these configurations exhaustively. However, exhaustive testing is
practically impossible due to time and resource limitations. To address this issue, there is a
need for a sampling strategy that can select a subset of inputs as test data from an
inherently large search space. Recent findings demonstrate that t-way interaction testing
strategies based on artificial intelligence (i.e. where t indicates interaction strength) have
been successful to obtain a near optimal solution resulting into smaller test set to be
considered. Motivated by such findings, we have developed a new test generation strategy,
called Particle Swarm Test Generator (PSTG). In this paper, we discuss the design of
PSTG and demonstrate our preliminary test size reduction results against other competing
t-way strategies including IPOG, WHITCH, Jenny, TConfig, and TVG.
2.2.4 T-Way Test Data Generation Strategy Based on Particle Swarm
Optimization
Due to market demands, software has grown tremendously in size and functionalities over
the years. As side effects of such growth, there tend to be more and more unwanted
interaction between software and system parameters. These unwanted interactions can
sometimes lead to nasty and difficult bugs to detect. In order to address these issues, t-way
strategies (i.e. where t indicates interaction strength) are helpful to generate a set of test
cases (i.e. to form a complete suite) that cover the required interaction strength as least
once from a typically large space of possible test values. In this paper, we highlight a new
t-way strategy based on Particle Swarm Optimization, called PSTG. Preliminary results
demonstrated that PSTG compares well against other existing t-way strategies.

7
2.3 EXISTING SYSTEM
The research area of search based software engineering (SBSE) was firstly proposed by
arman and Jones . They suggest that many difficult software engineering problems, which
can be abstracted as combinatorial optimization problems, can be successfully solved by
meta-heuristic search techniques. Common adopted techniques include hill climbing,
simulated annealing and genetic algorithm. In this paper, we want to use particle swarm
optimization (PSO), a global search algorithm, to build pair wise test suites. PSO is a
relative new swarm-based meta-heuristic search technique and is inspired by social
behavior of bird flocking, animals herding or fishes schooling where these swarms search
for food in a cooperative way. It was firstly formalized into a meta-heuristic search
technique by Eberhart and Kennedy in 1995 . PSO can be easily implemented and have a
few design parameters to set compared to other swarm-based metaheuristic search
techniques, such as genetic algorithm and ant colony optimization.
In the rest of this section, we give some definitions of PSO and briefly describe its
evolution process. Definition 7 (Particle): Each individual in the swarm is referred to as a
particle. The motion of particles is based on the following principal: They accelerate
toward the best individual location and the best global location while checking their
current location. Definition 8 (The Position of the Particle): The search space can be
modeled as an N-dimensional space. A position of the particle (i.e. a solution of the
problem) in iteration t can be expressed as a coordinate. Definition 9 (The Fitness
Function of the Particle): The setting of the fitness function is an important part in all 109
meta-heuristic search techniques. Here, this function is used to evaluate the goodness of a
candidate solution generated by a particle. The fitness function takes the position as an
input and outputs a fitness value representing the goodness of this candidate solution .The
main evolution process of PSO is described as follows: The system represented by a
swarm is initialized first and then the swarm is evolved to find an optimal solution. In the
initialization phase, the position and the velocity of all the particles in the swarm are
generated in random. In the iteration process, particle i keeps record of the best individual
location of the particle (i.e. pbesti) and the best global location of the swarm (i.e. gbest).
To evolve to the next generation, the particle changes its velocity toward its pbest and
gbest location and then changes its position according to current position and velocity.

8
2.4 PROPOSED SYSTEM
In this paper, we propose two different algorithms to systematically generate final pairwise
test suites. One algorithm is based on one-test-at-a-time strategy, the other is based on
IPO-like strategy. In both algorithms, we use PSO to complete the construction of a single
test (i.e. choose proper levels for the unfixed factors) aiming to cover more new
combinations. In this section, we first show how to use PSO to guide one test construction
process. Then we will introduce our two different algorithms.
A. Using PSO to Complete the Construction of a Single Test
In this subsection, we will show how to use PSO to complete the construction of a single
test. During the process of our two different algorithms, they often generate some tests. In
these tests, some factors are fixed to specific levels, while the other factors remain free to
take any possible valid level. Here we use PSO to choose appropriate valid level for these
unfixed factors with the aim of covering more new combinations.

9
B. Two PSO Based Approaches
Based on Algorithm 1 used to complete the construction of a single test, in this paper we
propose two different algorithms to guide the systematically generation process of pair
wise test suites. One algorithm is based on one-test-at-a-time strategy. The other algorithm
is based on IPO-like strategy. 1) Strategy A, One-test-at-a-time strategy: One-test-at-atime
strategy was firstly adopted by AETG approach and was further used by Bryce et al..
Using this strategy, it firstly generates an empty test suite TS, then generate a test t
according to some strategies, remove the combinations covered by t and add t to the test
suite TS. When all the combinations are covered, it terminates the loop and return
combinatorial test suite TS. We modified this strategy in the single test generation phase.
Here we randomly choose a pairwise combination from uncovered combination set Q and
fix the corresponding factors according to the chosen combination (in Lines 4-6). Then we

10
will use Algorithm 1 to choose proper levels for other unfixed factors. The pseudo code is
shown in the Algorithm 2.
2) Strategy B, IPO-like strategy: IPO is firstly proposed by Tai and Yu [21]. Unlike one-
test-at-a-time strategy, this strategy includes horizontal growth phase and vertical growth
phase. But our approach has some difference compared to IPO. The pseudo-code is shown
in Algorithm 3. First, we sort the factors in non-increasing order according to their level
size. Then we suppose that after the sorting, the first factor has l_ 1 levels and the second
factor has l_ 2 levels. We will generate l_ 1 × l_ 2 tests for the first two factors and then
immediately extend the test suite to all the factors. In these tests, other value of (k − 2) free
factors will be determined by PSO one by one (in Lines 4-7). This phase is familiar with
horizontal growth phase in IPO to a certain extent. Lastly, we will append some tests to
cover all the remaining combinations (in Lines 8-13). This phase is familiar with vertical
growth phase in IPO.
2.5 FEASIBILITY ANALYSIS
Feasibility steady ensures that whether to proceed with the development of the project or
to stop by conducting study on primary areas such as economy, technical and operational
environments. This analysis confirms the feasibility of achieving the product or the
system. It is necessary and prudent to evaluate the feasibility of a project at the earliest
possible time. It can be measured in different scales. The following feasibility studies were
performed to gauge the feasibility of the system.
 Operational Feasibility
 Technical Feasibility
 Economic Feasibility

11
Operational Feasibility
Operational feasibility checks the operational scope of the system. The system under
consideration should have enough operational reach. It is observed that the design of
auditing system is flexible and ease to develop in terms of language dependent and
language independent components reduces the work of the designer, as only resource
sharing utilization should be recorded. Also, since we need dynamic feedback mechanism
on timely manner to achieve required goal of auditing in easy way and displays all the
information of shared resources. Hence the operational feasibility of the proposed system
is found to be high.
Technical Feasibility
Technical feasibility checks the technical possibilities of the system to be developed and
includes a study of function, performance and constraints to achieve the goals of the
system.
1. Hardware Resources
The proposed system needs to be developed over the Windows platform, the machines
required are Pentium IV class or compatible processor and a minimum of 512MB RAM.
2. Software Resources
The software required are Windows XP, Borland or Turbo C compiler,Umbrello.
3. Books
A good number of books and reference manuals are required to develop the system. Most
of the necessary books are available in the Library and the necessary reference manuals
are found on INTENET also. As the developers have made provisions for hardware and
software resources, the proposed system is technically feasible.
Economical Feasibility
An evaluation of development cost weighed against the ultimate income or benefit derived
from the development of the proposed system is made. It should be seen to that the cost of
production does not exceed the income from the system. As the developers have made
enough provisions for the required resources, the cost incurred is minimal. As Windows
XP and Borland C editors are easily available and at the feasible cost, this project will
suitable as per the project cost. Hence, the entire system is feasible.

12
CHAPTER 3
DESIGN ISSUES
3.1 SYSTEM DESIGN
Software design is an interactive process through which requirements are translated into a
blue print for constructing software. Design has been described as a multi-step process in

13
which representations of data structure program structure interface characteristics and
procedure details are synthesized from information requirements. The objective is to
provide the systematic approach for the derivation of the design. The Blueprint from
which software is to be constructed.
Design is a phase where the requirements are actually translated into a finished
software product or system. Preliminary design is concerned with the transformation of
requirements into data and software architecture detailed design focuses on refinements to
the architectural implementation that lead to detailed data structure and algorithmic
representation for software.
Fig: 3.1.1 System Design
3.1.1 Description about Modules
The system after careful analysis has been identified to be presented with the following
modules:
1. Input Module:
In this module it takes the inputs as number of parameters and the number of values for
those parameters for generating the test cases.
2. Internal Module: In this module, a particle swarm optimization technique is being
implemented for generating the optimized pair wise tests cases. Initially this module, the

14
PSO takes the number of parameters and their values takes as input and sends the
optimized result to the output module.
3. Output Module:
The Output Module displays the optimal pair wise test suite as output.
3.2 DETAILED DESIGN OF THE PROJECT
Unified Modeling Language (UML) is a standard language for writing software blue
prints. The language which provides a vocabulary and the rules for combining words for
the purpose of communication. A modeling language is a language whose vocabulary
and rules focus on the conceptual and physical representation of a system. A modeling
language such as the UML is thus a standard language for software blueprints. Modeling
is a central part of all the activities that lead up to the deployment of good software. We
build models to communicate the desired structure and behavior of our system.
UML is a general purpose visual modeling language that is used to specify, visualize,
construct, and document the artifacts of the software system. UML will provide
vocabulary and rules for communications and functions on conceptual and physical
representation. So it is called as modeling language. The UML is applicable to object-
orient problem solving. A model is an abstraction of the underlying problem. The
domain is the actual world from which the problem comes. Models consist of Object that
interacts by sending each other message. Think of an object as “alive”. Objects have
things they know (attributes) and things they can do (behaviors or operations). The
values of an object’s attributes determine its state. Classes are the “blueprint” for objects
UML Diagrams
A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and arcs (relationships).There are two types of
diagrams.
They are:
1. Structural Diagrams
2. Behavioral Diagrams
Structural Diagrams

15
The UML‘s four structural diagrams exist to visualize, specify, construct and document
the static aspects of a system. We can View the static parts of a system using one of the
following diagrams.
1. Component diagram
Behavioral Diagrams
The UML’s five behavioral diagrams are used to visualize, specify, construct, and
document the dynamic aspects of a system. The UML’s behavioral diagrams are roughly
organized around the major ways which can model the dynamics of a system.
1. Use case diagram
2. Sequence diagram
3. Activity diagram
Use case Diagram
A use case diagram shows a set of use cases and actors and their relationships. Use case
diagrams address the static use case view of a system. These diagrams are especially
important in organizing and modeling the behaviors of a system.
5.2.1.2.1 Use case diagram
Activity Diagram:
An Activity Diagram shows the flow from activity to activity. The activity diagram
emphasizes the dynamic view of a system. Activity Diagram commonly contains,
• Activity States and Action States
• Transitions

16
• Objects
Activity diagram
Sequence Diagram
The sequence diagram is an interaction diagram that emphasizes the time ordering of
messages. Graphically, a sequence diagram is a table that shows objects arranged along
the X axis and messages, ordered in increasing time, along the Y axis.
Common Uses:
 We use sequence diagram to illustrate the dynamic view of a system.
 Sequence diagram show explicit sequence of messages.
 To model the message sequence.

17
Sequence diagram
Component Diagram
A component diagram is a diagram that shows relationships among software building
blocks. A component diagram shows the organizations and dependencies among a set of
components.
The component diagram emphasizes the static implementation view of a system.
Component Diagram consists of components, interfaces & dependency relationship.
 Component:A component is a physical and replaceable part of a system that
conforms to and provides the realization of a set of interfaces.
 Interface:An interface is a collection of operations that are used to specify a
service of a class or component.
Component diagram

18
CHAPTER 4
IMPLEMENTATION ISSUES
4.1 INTRODUCTION
Implementation phase is an important phase in the software development process. After
having a clear idea on the elements that comprised the final model; the next step was to
take the design from a conceptual idea into a practical model. The goal of the phase is to
translate the design of the system produced during the design phase into source code in a
given programming language. A well-written code can then reduce the testing and
maintenance effort.
4.2 REQUIREMENTS
The system requirements analysis aims at studying the available resources and estimating
how to use each of them. As far as computer projects are concerned two types of
requirements are essential.
4.2.1 Hardware Requirements
Minimum requirements of hardware include any processor with core2duo, 2 GB RAM, 80
GB hard disk space.
4.2.2 Software Requirements
Software requirements are Operating system: have windows XP/7Language: Language:
C.
4.3 Testing
INTRODUCTION
Software testing is a critical element of software quality assurance and represents the
ultimate review of specification, design and coding. In fact, testing is the one step in the
software engineering process that could be viewed as destructive rather than constructive.
A strategy for software testing integrates software test case design methods into a well-
planned series of steps that result in the successful construction of software. Testing is the
set of activities that can be planned in advance and conducted systematically. The
underlying motivation of program testing is to affirm software quality with methods that
can economically and effectively apply to both strategic to both large and small-scale
systems.

19
Psychology of Testing
The aim of the testing is often to demonstrate that a program works by showing that it has
no errors. This is the opposite of what testing should be viewed as. The basic purpose of
testing phase is to detect the errors that may be present in the program. Hence, one should
not start testing with the intent of showing that a program works; but the intent should be
show that a program does not work. With this in mind we define testing as follows.
Testing is the process of executing a program with the intent of finding errors.
TESTING ISSUES
Testing Strategies
As quality assurance is the review of software products and related documentation for
completeness, correctness, reliability and maintainability. Quality assurance can be done by
Testing
Verification and Validation
This developed software is allowed to undergo testing in different strategies. The software,
which has been developed, has to be tested to prove its validity. Testing is considered
the least creative phase of the whole cycle of system design.

20
Testing Methods
Black box Testing
It is the testing process in which tester can perform testing on an application without
having any internal structural knowledge of application. Usually Test Engineers are
involved in the black box testing.
White box Testing
It is the testing process in which tester can perform testing on an application with having
internal structural knowledge. Usually the developers are involved in white box testing.
Gray Box Testing
It is the process in which the combination of black box and white box techniques are used.
Types of Testing
This project was tested along the following guide lines to prove its validity. It was tested
using the following techniques of software testing.
White Box Testing

21
By using this technique, it was tested that all the individual logical paths
were executed at least once. All the logical decisions were tested on both their true and false
sides. All the loops were tested with data in between the ranges and especially at
the boundary values.
Black Box Testing
By the use of this technique the missing functions were identified and placed their
positions. The errors in the interfaces were identified and corrected. This technique was
also used to identify the initialization and termination.
Unit Testing
Unit testing focus verifications on the smallest unit of software designs the module. Using
the detailed description as a guide, important control paths are tested uncover errors within
the boundary of the module. The relative complexity of tests and the errors detected as
result is limited by the constrained scope established for unit testing. The unit test is
always white box oriented, and the step can be deducted in parallel for multiple
modules. In the lines of this strategy, all the individual function and modules were put to
test independently.
Verification and Validation Testing
There are two basic approaches to software testing: verification and validation.
Verification refers to the set of activities that ensure that software correctly implements
a specific function. Validation refers to a different set of activities that ensure that the
software that has been built is to customer requirements. Validation begins as soon as
the project starts, but verification can begin only after a specification has been accepted
.verification and validation are independent of each other. It is possible to have a
product that corresponds to the specification, but if the specification proves to be
incorrect, one could not have the right product.
 Verification:" are we building the product right?"
 Validation:" are we building right product?"
Although testing plays an extremely important role in verification and validation,
many other activities are necessary.
Test data and test output

22
Taking various types of data we do the above testing. Preparation of test data plays
a vital role in system testing. After preparing the test the system under study is
tested using the test data. While testing the system by using the test data, errors
are again uncovered and corrected by using the above testing; errors are again
uncovered by using the above testing and correction methods.
DEBUGGING
The faults can be found by starting from an unplanned failure. The developer moves the
system through a succession of states, ultimately arriving at and identifying the erroneous
state. Once this state is identified, the algorithm or mechanical fault causing this state
needs to be determined.
Correctness Debugging
It addresses the deviation between the observed and specified functional requirements.
Performance debugging
It addresses the deviation between the observed and specified nonfunctional requirements
such as response time.
TEST PLAN
Test Plan is defined as a strategic document which describes the procedure how to perform
various testing on the total application in the most efficient way.
 This document involves the scope of testing,
 Objective of testing,
 Areas that need to be tested,
 Areas that should not be tested,
 Scheduling Resource Planning,
 Areas to be automated, various testing tools Used….
4.4 I/O WINDOWS
EXAMPLE 1:
Window 1:

23
Fig: Parameters and values for pair wise testing.
Window2:
Fig: Reading the values of the parameters
Window 3:
Fig: Combinations of all parameter value pairs

24
Window4
Fig: Generated the optimized pairwise test suit
EXAMPLE 2:

25
Fig: Generated the optimized pair wise test suit

26
CHAPTER 5
CONCLUSION AND FUTURE ENHANCEMENTS
Hence we concluded that a PSO technique was implemented to generate the optimized
pair wise test cases for testing WEB based Applications.
We have implemented this test generation algorithm and have shown some empirical
results. When used properly, pair wise test set generation is an important technique
that can helps to produce minimal test cases for testing WEB applications. The
experiment results illustrated that our proposed PSO technique will yields better results
when comparing to other deterministic techniques like IPOAETG, ACO, and SBC etc.
As mentioned earlier, pair wise testing (or 2-way testing) is a special case of n-way
testing. Our proposed strategy presented in this project can be easily extended for n-way
testing. We are investigating possible improvements of our algorithm without increasing
time complexity.

27
REFERENCES
TEXT BOOKS
1. Paul Ammann and Jeff Offutt, “Introduction to Software Testing”, Cambridge Press,
2008
2. Srinivasa Desikan & Gopalaswamy Ramesh, “Software Testing – Principles and
Practices”, Pearson, 2007.
3. Pressman R S, Software Engineering-A Practitioner’s Approach, 6th edition, McGraw-
Hill, 2005.
4. Sommerville I, Software Engineering, 5th edition, Pearson Education, 1996.
5. Jawadekar W S, Software Engineering – Principles and Practice, Tata McGraw-Hill,
2004.
6. Behforooz A, and Hudson F J, Software Engineering Fundamentals, Oxford University
Press, 1996.
WEBSITES
1. www.slideshare.net
2. www.mendeley.com
3. www.cs.binghamton.edu.com
4. www.wikipedia.org
5. www.chetanasprojects.com
6. www.simmine.com
7. www.google.com

A PARTICLE SWARM OPTIMIZATION TECHNIQUE FOR GENERATING PAIRWISE TEST CASES

More Related Content

What's hot (20)

Similar to A PARTICLE SWARM OPTIMIZATION TECHNIQUE FOR GENERATING PAIRWISE TEST CASES (20)

Recently uploaded (20)

A PARTICLE SWARM OPTIMIZATION TECHNIQUE FOR GENERATING PAIRWISE TEST CASES