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

1

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 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

2

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.

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.

3

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

4

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

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

5

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

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

6

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.

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

7

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.

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.

8

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

9

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

10

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.

11

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

12

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

13

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

14

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

15

• Transitions

• 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.

16

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

17

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

18

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.

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.

19

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

20

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

21

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:

22

Window 1:

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

23

Window4

Fig: Generated the optimized pairwise test suit

EXAMPLE 2:

Fig: Parameters and values for pair wise testing.

24

Fig: Parameters and values for pair wise testing.

Fig: Generated the optimized pair wise test suit

25

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.

26

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

27

28