JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617

HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 61

Integration Test Order For C++ Applications

Priti Agarwal, Sangeeta Sabharwal, Parneeta Dhaliwal

Abstract— This paper presents an improvement to the existing strategy for finding test order during integration testing of C++
applications. Our strategy is an integration of two existing strategies aimed at finding test order of object-oriented applications.
The first one was proposed was Malloy and is based on parameterized cost model that assigns weights to different edge type and
then breaks the cycle by removing edge with the minimum weight. The second one was proposed by Abdurazik and is based on
assigning weights to both nodes and edges. The weights were based on the quantitative measure of coupling and cycle to weight
ratio was used for selecting a victim edge for removal. This paper builds upon the approach that was laid in a previous paper by
the authors and which combines some principles of both the strategies and addresses some of their shortcomings. Some new
dependencies that may exist between classes in a C++ application are also included in this paper. We also present a tool Class
Test Ordering System developed to automate the whole strategy.

Index Terms—Coupling, Friend Class, Integration Testing, Test Order

——————————  ——————————

1 INTRODUCTION
A common problem in inter-class integration testing of
object-oriented software is to determine the order in
which classes are integrated and tested. When one class
requires another to be available before it can be executed,
we define this kind of relationship to be a dependency.
These two classes can be characterized as server and
client classes. The client class is being compiled or
executed and the server class must be present. This
dependency has a direction, and is based on one or more
object-oriented relationships. The class integration and
test order problem is to find an ordering of nodes in the
graph so that the classes can be integrated and tested with
minimum effort. Computing an optimal class integration
and test order (CITO) is a focus of the software testing
community. When there is no cycle in the dependency of
classes or subsystems, the class integration and test order
(CITO) can be computed by a simple reverse topological
ordering of classes based on their dependencies.
However, dependency cycles are common in real-world
systems and when present, topological sorting is not
possible [1]. To solve the CITO problem in the presence
of cycles, the cycles must be broken. The effect of
breaking a dependency cycle is that a stub must be
created for the class that is no longer present, thus
increasing the cost of integration testing. Our goal is to
find an optimal order that minimizes the stubbing effort
for C++ applications. Stubbing effort has many elements
————————————————
 Priti Agarwal is working as Assistant Professor Computer science with  defined six types of dependencies that may exist between
ITM University, Gurgaon.   classes. These are association, composition, inheritance,
 Sangeeta Sabharwal is working with as Professor in Netaji Subhas Institute
of Technology, University of Delhi, New Delhi.
 Parneeta Dhaliwal is working as Assistant professor with KIIT College of cost function is defined that assign weights to these
Engineering, Gurgaon
 
to consider and, therefore, cannot be completely
measured or estimated [2]. It has also been suggested that
creating stubs can be error prone and costly.
A number of researchers have addressed
class integration and test order problem of object oriented
applications and several solutions have been proposed so
far. The solutions can be categorized into graph-based
and genetic algorithm-based approaches. In graph-based
approach, classes and their relationships in software are
modeled as object relation diagrams (ORD) or test
dependency graphs (TDG). An ORD or TDG is a directed
graph G (V; E) where V is a set of nodes representing
classes and E is a set of edges representing the
relationships among classes. In some papers, the testing
effort is estimated by counting the number of stubs that
are required for testing assuming that all stubs are equally
difficult to write [1], [3], [4], [7]. While some others try to
consider test stub complexity when measuring testing
effort [8], [9], [10]. In the genetic algorithm based approach
[11], inter-class coupling measurements and genetic
algorithms are used in combination to assess the
complexity of test stubs and to minimize complex cost
functions.
Existing solution to the problem of finding
test order during integration testing of C++ application
have used a parameterized cost model that assign
weights to different kind of edges in the ORD. These
edges represent the various types of relations that may
exist between classes in a C++ application. Malloy [8] has
owned Element, dependency and polymorphism. Then a
relationships, in order to measure the testing effort in
terms of stub complexity.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
    As  coupling  measurement  captures  class
relationships, so to develop more precise testing and
maintenance predictive models, we define different types
of coupling based on explicit object-oriented class
relationships and some implicit relationships.
We have tried to merge the merits of both the
approaches while at the same time overcoming some of
the more obvious shortcomings. The approach that we
have taken was first laid in [13]. Our work includes
introducing some coupling measures that may exist
between classes in a C++ application and then proposing
a strategy for finding integration test order. The
organization of the paper is as follow. Section 2 presents,
new dependencies/coupling that may exist between
classes in C++ application and model classes and their
relationships using the coupling measures. A new
strategy is proposed and illustrated using an example in
Section 3 along with the tool that implements it. Section 4
presents the result of applying the tool Class test ordering
system to the C++ application given in Section 3. Finally,
conclusion and future work will be discussed in Section 5.
2 COUPLING MEASURES
Coupling refers to the degree of interdependence among
the components of a software system. As coupling
measures capture class relationships, so in this section
two features of C++ language that can introduce coupling
between classes are discussed.
2.1 Friend Coupling
Friendship is a mechanism to selectively allow the body
of a class to be accessed by other classes; it reduces
information hiding, and increases coupling. A class can
be declared as a friend of another one, granting that first
class access to the protected and private members of the
second one. Hence friendship, may introduce stronger
coupling [12].
2.2 Exception Coupling
An exception is a situation in which a program has an
unexpected circumstance that the section of code
containing the problem is not explicitly designed to
handle. Exception handling deals with abnormal
situation. In C++ when a class raises an exception, the
Exception class object will be created. All the exception
classes are derived from Exception base class. The
Exception class supports for both predefined exception
classes and user defined exception classes. This also
introduces some coupling between an exception throwing
class and an exception handling class, which is defined as
exception coupling.
3 A NEW STRATEGY
In our approach, Malloy [8] method for finding class test
order of C++ application is extended by introducing some
new dependencies, which may exist between classes in a
© 2010 Journal of Computing Press, NY, USA, ISSN 2151-9617
http://sites.google.com/site/journalofcomputing/
62
C++ application. This strategy is an integration of two
methods aimed at finding test order of object-oriented
applications. The first one was proposed by Malloy [8],
which aimed at finding test order for classes in C++
application using parameterized cost model. The second
one was proposed by Abdurazik [9], [10] where they
modeled classes and their relationships with weights on
both nodes and edges and the weights of node and edges
were based on a quantitative measure of coupling. Also
they used an algorithm that incorporates edge and node
weights as well as cycle to weight ratio in cycle breaking.
Similar to Malloy [8], the focus of our work is the analysis
of existing C++ applications, including template functions
and classes, nested classes, friend classes and exception
handling. Thus we have defined eight coupling types in
our ORD as compared to six types defined in [8]. These
coupling are : Association Coupling, Composition
Coupling, Inheritance Coupling, Dependency Coupling,
Owned Element Coupling, Polymorphism coupling,
Friend Coupling and Exception Coupling. As with
Abdurazik [10], cycle to weight ratio is used within each
SCC to choose a victim edge for removal, with the aim of
minimizing the cost of stub creation.
In this section, the program representation
that is used to find a class test order for class-based
testing is discussed.
3.1 A Sample C++ Application
Fig. 1 contains a C++ program and Fig. 2 illustrates the
corresponding ORD for the program that is constructed
by reverse engineering the source code of the C++
program.
(1) template <class T>
(2) class W {
(3) public: void fun (T t) {}
(4) private: T data;};
(5) template <>
(6) class W<char> {
(7) char* a;};
(8) class P;
(9) class X {
(10) W<P*> w; } ;
(11) class P {
(12) public: void fun(X x) {}
(13) private: W<char> wp;};
(14) class R;
(15) class E {
(16) public: void exp() {} }
(17) class Q : public P {
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
(18) private: R* r;
(19) public: friend class X; };
(20) class R : public P {};
(21) class S : public R {};
(22) class Y : public X {
(23) public: void fun() {
(24) try{
(25) } catch(E e) {
(26) e.exp (); }} };
(27) class Z : public X {
(28) class Inner {}; };
Fig. 1 An example C++ application
Fig. 2 A Sample ORD
3.2 Cost Model
The usual approach to the computation of an integration
order for classes in the presence of a cycle is to construct
an ORD and remove edges from the ORD until all cycles
are broken.
Previous researchers have selected
Association edges to be removed, since association
relations are the weakest [1], [4], [7]. Moreover for the
situations where there are more than one candidate
association edges that can be removed, various functions
had been proposed by researchers, on the basis of whom
the edges can be selected. As mentioned earlier most of
the functions defined for selecting a victim edge for
removal are based on the number of cycles in which the
edge is involved in. These types of functions didn’t
consider the stub complexity. They considered that all
the stubs are equally difficult to write.
However our approach uses a Class test
ordering system, a flexible framework that is driven by
a cost model that assign weights to the edges of an ORD
and these weights are used in addition to the number of
cycles in which the edge is involved to select a victim
edge for removal.
Our cost model is an extension of cost model
proposed by Malloy [8]. The parameters to the model
provide flexibility in guiding the edge removal process so
63
that the model can be tuned in an attempt to minimize the
number of edges that are removed or to minimize the
number of stubs that are required for untested supplier
classes. The ORD used here is a multigraph G = (V, E),
where V is a set of vertices representing classes, and E is a
set of edges representing the relationships between the
classes.
The cost model C= <W, f (e), w (m x, y) > is a 3-
tuple consisting of W, a set of weight assignments and
function f (e) and w (m x, y) as follows:
W= {w1; w2; w3; w4; w5; w6; w7; w8} (1)
f (e) is a function, f: E  W (2)
for a given x, y  V, m x, y = {(x, y)  E} (3)
w (m x, y) =  f (e) (4)
e m x, y
Equation (1) is a set of weight assignments
for the eight edge type designations for inheritance,
association, composition, dependence, polymorphic,
ownedElement, friend and exception edges. A weight of
(2, 2, 20, 5, 20, 20) is assigned to inheritance, association,
composition, dependency, polymorphic and ownedEle-
ment edges respectively as estimated by Malloy [8]. These
weight assignments are based on their estimation of the
cost of stub construction for untested classes. Further we
are assigning a weight of 25 to friend edges, since friend
relations may introduce stronger coupling between
classes as compared to other relationships [12] and a
weight of 5 to exception edges based on the estimation of
coupling measures by Abdurazik [9]. (2) defines a total
function f as a mapping from the set of edges, E, to the set
of weights W, so that for edge e, f (e) is the weight
assignment for that edge. (3) defines a merged edge
m x, y as a set of edges represented as ordered pairs (x, y),
where each edge in the set has the same source class and
the same destination class. (4) defines w (m x, y), a function
w that computes the weight of a merged edge m x, y as the
sum of the weights of the individual edges in the set
m x, y.
3.3 Proposed Algorithm for Finding Test Order
The main objective of our work is to find an optimal
integration and test order o by determining a set of k
edges to be removed, to make the ORD acyclic such that
the sum of the stubbing complexities for these edges is
minimum. This section presents an algorithm, which is
used by the Class test ordering system to find a test order
of classes in C++ application during integration testing.
ALGORITHM Finding Test Order During Integration
Testing of C++ Applications
1. Apply reverse engineering to build ORD, G, from the
given C++ code.
2. Use function f, (2), to assign a weight from the set W,
(1), to each edge e in the ORD, G.
3. Merge the edges in G using w (m x, y), (4).
4. Use Tarjan’s algorithm to find all strongly connected
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 64

components, SCC’s in the ORD, G. {X, W<P*>, Composition} , {W<P*>, P, Merged},

5. For (each SCC (Vscci, Escci )  SCC’s) with more than
one node do {P, X, Dependency}, {X, Q, Friend}, {Q, R, Association},
5.1Find the total number of cycles: Total cycles {Q, P, Inheritance}, {R, P, Inheritance}, {S, R, Inheritance},
5.2For (each e  Escci ) do
{W<P*>, Q, Polymorphism}, {W<P*>, S, Polymorphism},
Find the number of cycles in which e is involved.
Compute the cycle to weight ratio for each e {W<P*>, R, Polymorphism}, {Q, S, Polymorphism}
5.3 End For
SINGLETONS: 6
5.4 while (totalCycles != 0) do
After applying Step 5 of algorithm on SCC 7
5.4.1 Order all edges according to the descending
with more than one node, nine cycles are identified which
order of their cycle-weight ratio are listed below:
5.4.2 Remove the edge with the highest cycle-
weight ratio from G 1. X  W<P*>PX
5.4.3 totalCycle = totalCycle - number of cycles
broken 2. X  W<P*>  Q PX
5.4.4 Update the number of cycles that use e in 3. X  W<P*>  Q RPX
the remaining edge set
5.4.5 Recompute the cycle-weight ratio for the 4. X  W<P*>  Q S RPX
remaining edges 5. X  W<P*>  S RPX
5.5End While
6. End For 6. X  W<P*>  RPX
7. Find a class order for testing as follows:
7. X  Q PX
7.1 For each edge e removed in Step 5.4.2, remove e
from G; let resulting graph be G’ 8. X QRPX
7.2 Order the classes in G’ in reverse topological order
9. X Q S RPX

Table 1 shows the result from steps 5.2 through 5.3 of

Algorithm.

TABLE 1
CYCLE-WEIGHT RATIO FOR EDGES IN
SCC {X, W<P*>, Q, S, R, P}

No Edge Weight Cycles No. of Cycle to

Involved Cycles weight
Fig. 3 Sample ORD after applying cost model
involved ratio
3.4 Application to the Example (CWR)
Algorithm is illustrated through the example given in 1 XW<P*> 20 {1,2,3,4,5, 6 0.3
Fig. 1. After applying step 1 of the algorithm, an ORD is 6,}
obtained as shown in Fig. 2. After applying step 2 where 2 W<P*>P 7 {1} 1 0.14
the cost model is used to assign weights to various edges 3 PX 5 {1,2,3,4,5, 9 1.8
and step 3 where the edges are merged using the function 6,7,8,9}
w(m x, y) , the ORD obtained is shown in Fig. 3. Step 4 in
4 XQ 25 {7,8,9} 3 0.12
algorithm identifies SCC’s within the ORD. The following
SCC’s are identified within the ORD of Fig. 3 : 5 QR 2 {3,8} 2 1

6 QP 2 {2,7} 2 1
STRONGLY CONNECTED COMPONENTS: 
7 RP 2 {3,4,5,6,8, 6 3
SCC 1: 1 node(s): W and 0 edge(s)
9}
SCC 2: 1 node(s): E and 0 edge(s) 8 SR 2 {4,9} 2 1

SCC 3: 1 node(s): Y and 0 edge(s) 9 W<P*> 20 {2,3,4} 3 0.15

Q
SCC 4: 1 node(s): W<char*> and 0 edge(s) 10 W<P*>S 20 {5} 1 0.05
SCC 5: 1 node(s): Z and 0 edge(s) 11 W<P*>R 20 {6} 1 0.05
SCC 6: 1 node(s): Inner and 0 edge(s) 12 Q S 20 {4,9} 2 0.1
SCC 7: 6 node(s): {X, W<P*>, Q, S, R, P} and 12 edges:
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 65

                      After the initial computation of CWR values TABLE 3

for edges, the algorithm works in the following steps: CYCLE-WEIGHT RATIO FOR EDGES IN
SCC {X, W<P*>, Q, S, R, P} – { R P, Q P}
1. Choose an edge from Table 1 with maximum cycle- No. Edge Weight Cycles No.of Cycle to
weight ratio (CWR) and remove that edge from the ORD. Involved Cycles weight
At this point, the edge with the maximum cycle-weight involved ratio
(CWR)
ratio is R P with a ratio of 3. Removing edge R P
breaks six cycles 3, 4, 5, 6, 8 and 9, leaving three cycles as 1 XW<P*> 20 {1} 1 0.05
shown below. 2 W<P*>P 7 {1} 1 0.14
3 PX 5 {1} 1 0.2
1. X  W<P*>PX
4 XQ 25 {} 0 0
2. X  W<P*>  Q PX
5 QR 2 {} 0 0
3. X  Q PX
6 QP 2 {} 0 0
2. Recompute the cycle-weight ratio for the remaining 7 RP 2 {} 0
edges. The result is shown in Table 2. At this point, the
edge with the maximum cycle-weight ratio is Q P with 8 SR 2 {} 0 0
a ratio of 1. Removing edge Q P breaks two cycles, 2 9 W<P*>Q 20 {} 0 0
and 3, leaving one cycle as shown below.
10 W<P*>S 20 {} 0 0

1. X  W<P*>PX 11 W<P*>R 20 {} 0 0

3. Recompute the cycle-weight ratio for remaining edges 12 Q S 20 {} 0 0

in Table 2. The result is shown in Table 3. Now the edge                Thus, we break all 9 cycles by removing three
with maximum cycle-weight ratio is PX with a ratio of edges, R P, Q P and PX. The total cost is 2+2+5 = 9.
0.2. Removing edge P X breaks one cycle, and makes
the ORD acyclic. 4. After applying step 7.1 of algorithm, an acyclic ORD is
  obtained as shown in Fig. 4.
TABLE 2 
CYCLE-WEIGHT RATIO FOR EDGES IN
SCC {X, W<P*>, Q, S, R, P} – { R P}

No. Edge Weight Cycles Involved No. of Cycle to

Cycles weight
involved ratio
(CWR)
1 XW<P*> 20 {1,2} 2 0.1
2 W<P*>P 7 {1} 1 0.14
3 PX 5 {1,2,7} 3 0.6 Fig. 4 An acylic ORD

4 XQ 25 {7} 1 0.04 5. By applying step 7.2 on the acyclic ORD of Fig. 4, a test
order is obtained as given below:
5 QR 2 {} 0 0
Class R
6 QP 2 {2,7} 2 1
Class S
7 RP 2 {] 0 0
Class Q
8 SR 2 {} 0 0
Class E
9 W<P*>Q 20 {2} 1 0.05
Class Inner
10 W<P*>S 20 {} 0 0
Class W<Char>
11 W<P*>R 20 {} 0 0 Class P
12 Q S 20 {} 0 0 Class W<P*>
Class X
Class Y
Class Z
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
3.5 Class Test Ordering System
The whole approach is automated using a software tool
called class test ordering system (CTOS). This tool is
implemented using ruby and java. It runs on ruby
interpreter 1.8.6 and JVM 1.6. This tool consists of four
interconnected phases. It takes as input a C++ application
and then extracts relations between the classes, find out
strongly connected components within the SCC’s, remove
edges based on cycle to weight ratio to make the ORD
acyclic and finally gives as output an integration test
order for the given C++ application.
4. CASE STUDY
Using Class Test Ordering System (CTOS), our approach
is applied to the C++ application given in Section 3.1.As
discussed in Section 3.5 CTOS consists of four phases.
Phase I of the CTOS parses the input C++ application and
displays the class information along with the relation-
ships between them as shown in Fig. 5. After getting the
class information, an ORD is constructed, which is given
as an input to Phase II of the Class Test Ordering System.
Phase II of the system finds the strongly connected
components in the ORD using Tarjan’s algorithm. The
output of applying Tarjan’s algorithm to the output of
phase I, i.e. the ORD, is shown in Fig. 6. The output of
phase II is given as an input to phase III, which calculate
the cycle to weight ratio for each edge of SCC with more
than one node found during phase II and removes the
edge with maximum cycle to weight ratio. This process is
repeated until an acyclic ORD is obtained. Hence the
output of phase III is an acyclic ORD as shown in Fig. 7.
The acyclic ORD obtained during phase III is given as an
input to phase IV, which applies topological sorting on
the acyclic ORD. The output of phase IV is shown in
Fig. 8, the reverse of which gives the test order.
Fig. 5 Output of phase I
Fig. 6 Output of phase II
66
 
Fig. 7 Output of phase III
 
Fig. 8 Output of phase IV
5. CONCLUSION AND FUTURE WORK
In this paper, strategies for finding test order during
integration testing of object oriented applications have
been discussed that includes both graph based as well as
genetic algorithms based techniques. Although genetic
algorithm can be used to find optimal solutions but they
must be run many times. Also it has been observed that
some researchers have considered the number of stubs as
the estimation of testing effort, while others have
considered test stub complexities while estimating testing
effort. A few of them have used slicing techniques to find
test order which decreases test stubs construction and
testing time. In this paper a new approach for finding test
order during integration testing of C++ applications is
presented. The goal of the technique is to define an
integration test order strategy suitable for object-oriented
systems, to identify the test order with minimum cost
effort. This approach takes into account design level
relationships among OO software components and their
effects on implementation level couplings. Design level
relationships are mapped onto implementation level
couplings. The approach is based on the static analysis of
object-oriented programs, and also dynamic time
relations like polymorphism are also considered. Our
approach shows how to effectively measure relationships
among classes and apply the measures to specific
problems in testing.
In this paper approximate values of the
weights are taken based on literature survey and have
done experiments on relatively smaller systems. In future,
we will try to focus our research on many complex
systems and will see how well these results will scale to
large systems. Also we will work on the weights that
have been assigned to new dependencies and will find
out the more accurate and precise value of the weights
associated with each dependency.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617 67
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 67

6. REFERENCES
[1] D. Kung, J. Gao, P. Hsia, Y. Toyoshima, and C. Chen. A test strategy
for object-oriented programs. In 19th Computer Software and
Applications Conference (COMPSAC 95), pages 239 {244, Dallas, TX,
August 1995. IEEE Computer Society Press.
[2]  B. Beizer. Software Testing Techniques. Van Nostrand Reinhold, Inc,
New York NY, 2nd edition, 1990. ISBN 0-442-20672-0.
[3] Y. L. Traon, T. Jeron, J.-M. Jezequel, and P. Morel. Efficient object-
oriented integration and regression testing. IEEE Transactions on
Reliability, pages 12-25, March 2000.
[4] K.C. Tai and F. Daniels. Test order for inter-class integration testing of
object-oriented software. In The Twenty-First Annual International
Computer Software and Applications Conference (COMPSAC '97),
pages 602{607, Santa Barbara CA, 1997. IEEE Computer Society.
[5] Y. Labiche, P. Thevenod-Fosse, H. Waeselynck, and M. H. Durand.
Testing levels for object-oriented software in ICSE, pages 136–145,
New York, June 2000.
[6] L. C. Briand, Y. Labiche, and Y. Wang. An investigation of graph-
based class integration test order strategies. IEEE Transactions on
Software Engineering, 29(7): 594{607, July 2003
[7] L. C. Briand, Y. Labiche, and Y. Wang. Revisiting strategies for order-
ing class integration testing in the presence of dependency cycles.
Technical report SCE-01-02, Careleton University, 2001.
[8] B. A. Malloy, P. J. Clarke, and E. L. Lloyd. A parameterized cost
model to order classes for class-based testing of C++ applications. In
Proceedings of the 14th International Symposium on Software Relia-
bility Engineering (ISSRE'03), pages 353{364, Denver, Colorado, 2003.
IEEE Computer Society Press.
[9] A. Abdurazik and Jeff Offutt, “Coupling-based Class Integration and
Test Order”,.In Workshop on Automation of Software Test (AST
2006), pages 50{56, Shanghai, China, May 2006.
[10] A. Abdurazik and Jeff Offutt, Using coupling-based weights for the
class integration and test order problem. Computer Journal, 2007.
[11] L. C. Briand, J. Feng, and Y. Labiche. Using genetic algorithms and
coupling measures to devise optimal integration test orders. In
Proceedings of the 14th International Conference on Software
Engineering and Knowledge Engineering, pages 43{50, Ischia, Italy,
2002. IEEE Computer Society Press.
[12] L. Briand , P. Devanbu and W. Melo, An investigation into coupling
measures for C++, Proceedings of the 19th international conference
on Software engineering, p.412-421, May 17-23, 1997, Boston,
Massachusetts, United States.
[13] P. Bansal , S. Sabharwal and P. Sidhu, An investigation of strategies
for finding test order during integration testing of object oriented
applications, International Conferenece on Methods and Models in
Computer Science (ICM2CS-09).
[14] Jutarat Jaroenpiboonkit, Taratip Suwannasart, "Finding a Test Order
using Object-Oriented Slicing Technique," apsec, pp.49-56, 14th Asia-
Pacific Software Engineering Conference (APSEC'07), 2007
 
 
Priti Agarwal, B.Tech-CSE (2001), M.tech-IS(2009). Presently
working as Assistant Professor in ITM University, Gurgaon Published
many papers in National and International Conferences in the field of
Software Engineering.

Sangeeta Sabharwal, B.Tech, M.tech and PhD in Computer

Science. Presently working as Professor in NSIT, New Delhi. Under
my guidance many students have submitted their M.Tech Thesis and
successfully completed their PhD.

Parneeta Dhaliwal, B.Tech-CSE (2002), M.tech-IS(2009), Member

of the IEEE. Presently working as Assistant Professor in KIIT
College of Engineering. Published many papers in National and
International Conferences in the field of Software Engineering.