Integration Test Order For C++ Applications

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 to consider and, therefore, cannot be completely
object-oriented software is to determine the order in measured or estimated [2]. It has also been suggested that
which classes are integrated and tested. When one class creating stubs can be error prone and costly.
requires another to be available before it can be executed, A number of researchers have addressed
we define this kind of relationship to be a dependency. class integration and test order problem of object oriented
These two classes can be characterized as server and applications and several solutions have been proposed so
client classes. The client class is being compiled or far. The solutions can be categorized into graph-based
executed and the server class must be present. This and genetic algorithm-based approaches. In graph-based
dependency has a direction, and is based on one or more approach, classes and their relationships in software are
object-oriented relationships. The class integration and modeled as object relation diagrams (ORD) or test
test order problem is to find an ordering of nodes in the dependency graphs (TDG). An ORD or TDG is a directed
graph so that the classes can be integrated and tested with graph G (V; E) where V is a set of nodes representing
minimum effort. Computing an optimal class integration classes and E is a set of edges representing the
and test order (CITO) is a focus of the software testing relationships among classes. In some papers, the testing
community. When there is no cycle in the dependency of effort is estimated by counting the number of stubs that
classes or subsystems, the class integration and test order are required for testing assuming that all stubs are equally
(CITO) can be computed by a simple reverse topological difficult to write [1], [3], [4], [7]. While some others try to
ordering of classes based on their dependencies. consider test stub complexity when measuring testing
However, dependency cycles are common in real-world effort [8], [9], [10]. In the genetic algorithm based approach
systems and when present, topological sorting is not [11], inter-class coupling measurements and genetic
possible [1]. To solve the CITO problem in the presence algorithms are used in combination to assess the
of cycles, the cycles must be broken. The effect of complexity of test stubs and to minimize complex cost
breaking a dependency cycle is that a stub must be functions.
created for the class that is no longer present, thus Existing solution to the problem of finding
increasing the cost of integration testing. Our goal is to test order during integration testing of C++ application
find an optimal order that minimizes the stubbing effort have used a parameterized cost model that assign
for C++ applications. Stubbing effort has many elements 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
 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
owned Element, dependency and polymorphism. Then a
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 relationships, in order to measure the testing effort in
terms of stub complexity.
As coupling measurement captures class C++ application. This strategy is an integration of two
relationships, so to develop more precise testing and methods aimed at finding test order of object-oriented
maintenance predictive models, we define different types applications. The first one was proposed by Malloy [8],
of coupling based on explicit object-oriented class which aimed at finding test order for classes in C++
relationships and some implicit relationships. application using parameterized cost model. The second
We have tried to merge the merits of both the one was proposed by Abdurazik [9], [10] where they
approaches while at the same time overcoming some of modeled classes and their relationships with weights on
the more obvious shortcomings. The approach that we both nodes and edges and the weights of node and edges
have taken was first laid in [13]. Our work includes were based on a quantitative measure of coupling. Also
introducing some coupling measures that may exist they used an algorithm that incorporates edge and node
between classes in a C++ application and then proposing weights as well as cycle to weight ratio in cycle breaking.
a strategy for finding integration test order. The Similar to Malloy [8], the focus of our work is the analysis
organization of the paper is as follow. Section 2 presents, of existing C++ applications, including template functions
new dependencies/coupling that may exist between and classes, nested classes, friend classes and exception
classes in C++ application and model classes and their handling. Thus we have defined eight coupling types in
relationships using the coupling measures. A new our ORD as compared to six types defined in [8]. These
strategy is proposed and illustrated using an example in coupling are : Association Coupling, Composition
Section 3 along with the tool that implements it. Section 4 Coupling, Inheritance Coupling, Dependency Coupling,
presents the result of applying the tool Class test ordering Owned Element Coupling, Polymorphism coupling,
system to the C++ application given in Section 3. Finally, Friend Coupling and Exception Coupling. As with
conclusion and future work will be discussed in Section 5. 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.
2 COUPLING MEASURES
In this section, the program representation
Coupling refers to the degree of interdependence among that is used to find a class test order for class-based
the components of a software system. As coupling testing is discussed.
measures capture class relationships, so in this section
two features of C++ language that can introduce coupling 3.1 A Sample C++ Application
between classes are discussed. Fig. 1 contains a C++ program and Fig. 2 illustrates the
corresponding ORD for the program that is constructed
2.1 Friend Coupling by reverse engineering the source code of the C++
Friendship is a mechanism to selectively allow the body program.
of a class to be accessed by other classes; it reduces (1) template <class T>
information hiding, and increases coupling. A class can
be declared as a friend of another one, granting that first (2) class W {
class access to the protected and private members of the (3) public: void fun (T t) {}
second one. Hence friendship, may introduce stronger
coupling [12]. (4) private: T data;};
2.2 Exception Coupling (5) template <>

An exception is a situation in which a program has an (6) class W<char> {
unexpected circumstance that the section of code
(7) char* a;};
containing the problem is not explicitly designed to
handle. Exception handling deals with abnormal (8) class P;
situation. In C++ when a class raises an exception, the
Exception class object will be created. All the exception (9) class X {
classes are derived from Exception base class. The (10) W<P*> w; } ;
Exception class supports for both predefined exception
classes and user defined exception classes. This also (11) class P {
introduces some coupling between an exception throwing (12) public: void fun(X x) {}
class and an exception handling class, which is defined as
exception coupling. (13) private: W<char> wp;};
(14) class R;
3 A NEW STRATEGY (15) class E {
In our approach, Malloy [8] method for finding class test
(16) public: void exp() {} }
order of C++ application is extended by introducing some
new dependencies, which may exist between classes in a (17) class Q : public P {
© 2010 Journal of Computing Press, NY, USA, ISSN 2151-9617

http://sites.google.com/site/journalofcomputing/
(18) private: R* r; that the model can be tuned in an attempt to minimize the
number of edges that are removed or to minimize the
(19) public: friend class X; };
number of stubs that are required for untested supplier
(20) class R : public P {}; classes. The ORD used here is a multigraph G = (V, E),
where V is a set of vertices representing classes, and E is a
(21) class S : public R {}; set of edges representing the relationships between the
(22) class Y : public X { classes.
The cost model C= <W, f (e), w (m x, y) > is a 3-
(23) public: void fun() { tuple consisting of W, a set of weight assignments and
(24) try{ function f (e) and w (m x, y) as follows:
(25) } catch(E e) { W= {w1; w2; w3; w4; w5; w6; w7; w8} (1)
(26) e.exp (); }} };
f (e) is a function, f: E  W (2)
(27) class Z : public X {
(28) class Inner {}; }; for a given x, y  V, m x, y = {(x, y)  E} (3)
Fig. 1 An example C++ application 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
Fig. 2 A Sample ORD
weight of 5 to exception edges based on the estimation of
coupling measures by Abdurazik [9]. (2) defines a total
3.2 Cost Model function f as a mapping from the set of edges, E, to the set
The usual approach to the computation of an integration of weights W, so that for edge e, f (e) is the weight
order for classes in the presence of a cycle is to construct assignment for that edge. (3) defines a merged edge
an ORD and remove edges from the ORD until all cycles m x, y as a set of edges represented as ordered pairs (x, y),
are broken. where each edge in the set has the same source class and
Previous researchers have selected the same destination class. (4) defines w (m x, y), a function
Association edges to be removed, since association w that computes the weight of a merged edge m x, y as the
relations are the weakest [1], [4], [7]. Moreover for the sum of the weights of the individual edges in the set
situations where there are more than one candidate m x, y.
association edges that can be removed, various functions
had been proposed by researchers, on the basis of whom 3.3 Proposed Algorithm for Finding Test Order
the edges can be selected. As mentioned earlier most of The main objective of our work is to find an optimal
the functions defined for selecting a victim edge for integration and test order o by determining a set of k
removal are based on the number of cycles in which the edges to be removed, to make the ORD acyclic such that
edge is involved in. These types of functions didn’t the sum of the stubbing complexities for these edges is
consider the stub complexity. They considered that all minimum. This section presents an algorithm, which is
the stubs are equally difficult to write. used by the Class test ordering system to find a test order
However our approach uses a Class test of classes in C++ application during integration testing.
ordering system, a flexible framework that is driven by
a cost model that assign weights to the edges of an ORD ALGORITHM Finding Test Order During Integration
and these weights are used in addition to the number of Testing of C++ Applications
cycles in which the edge is involved to select a victim 1. Apply reverse engineering to build ORD, G, from the
edge for removal. given C++ code.
2. Use function f, (2), to assign a weight from the set W,
Our cost model is an extension of cost model (1), to each edge e in the ORD, G.
proposed by Malloy [8]. The parameters to the model 3. Merge the edges in G using w (m x, y), (4).
provide flexibility in guiding the edge removal process so 4. Use Tarjan’s algorithm to find all strongly connected
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:
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
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 Fig. 7 Output of phase III
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 Fig. 8 Output of phase IV
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 5. CONCLUSION AND FUTURE WORK
phase I, i.e. the ORD, is shown in Fig. 6. The output of In this paper, strategies for finding test order during
phase II is given as an input to phase III, which calculate integration testing of object oriented applications have
the cycle to weight ratio for each edge of SCC with more been discussed that includes both graph based as well as
than one node found during phase II and removes the genetic algorithms based techniques. Although genetic
edge with maximum cycle to weight ratio. This process is algorithm can be used to find optimal solutions but they
repeated until an acyclic ORD is obtained. Hence the must be run many times. Also it has been observed that
output of phase III is an acyclic ORD as shown in Fig. 7. some researchers have considered the number of stubs as
The acyclic ORD obtained during phase III is given as an the estimation of testing effort, while others have
input to phase IV, which applies topological sorting on considered test stub complexities while estimating testing
the acyclic ORD. The output of phase IV is shown in effort. A few of them have used slicing techniques to find
Fig. 8, the reverse of which gives the test order. 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
Fig. 5 Output of phase I 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
Fig. 6 Output of phase II associated with each dependency.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 9, SEPTEMBER 2010, ISSN 2151-9617 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.

Integration Test Order For C++ Applications

Uploaded by

Integration Test Order For C++ Applications

Uploaded by

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

Integration Test Order For C++ Applications

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

2.2 Exception Coupling (5) template <>

© 2010 Journal of Computing Press, NY, USA, ISSN 2151-9617

Fig. 1 An example C++ application w (m x, y) =  f (e) (4)

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

Table 1 shows the result from steps 5.2 through 5.3 of

No Edge Weight Cycles No. of Cycle to

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

After the initial computation of CWR values TABLE 3

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

No. Edge Weight Cycles Involved No. of Cycle to

3.5 Class Test Ordering System

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

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

You might also like