Interprocedural Dynamic Slicing A pplied to Interprocedural Data Flow Testing Mariam Kamkar (marka@)ida.liu.se) Peter Fritzson (
[email protected]) Nahid Shahmehri (
[email protected])
Department of Computer and Information Science Linkaping University, S-58 1 83 Linkaping Sweden Phone: 46-13-281OO0, Fax: 46-13-282666 Abstract
can be canputed for programs with procedures, and these slices consist d all executed call statements which are rel-
During the past ten years several variants of an analysis technique called program slicing have been developed. Program slicing has applications in maintenance tasks such as debugging, testing,program integration,program verification, etc., and can be characterized as a type of dependence analysis. A program slice can loosely be defined as the subset of a program needed to compute a certain variable value at a certain program position. Recently we have developed a novel method for interprocedural dynamic slicing which is more precise than interprocedural static slicing methods and is useful for dependence analysis at the procedural abstraction level. In this paper we demonstrate how interprocedural dynamic slicing can be used to increase the reliability and precision of interprocedural data flow testing. We have generalized the work on data flow testing by Duesterwald and colleagues [ I ] , which is a novel method for dataflow testing through output influences.
1
evant for the cumputation of the specified variable at the specifiedprogram point. Recently we have developed the first technique for interprocedural dynamic slicing [lo. 73 which deals with p r o c d m s (or functions) at the abstract level. This technique first generates summary informationfar each p r o w dure call (or function application), then represents a program as a summary graph of dynamic dependem. A slice on this graph consists of vertices for all procedure calls oftheprogram that affect the value of a given variable at the specsed program point. The a m m t of information saved by this method is considerably less than what is needed by previous methods for dynamic slicing, since it only depends on the size of the program’s execution tree, i.e.. the number of executed procedure calls. which is smaller than the trace of all executed statements. This paper describes how interprocedural dynamic slicing can be applied to data flow testing to haease the precision and reliability of the testing method. We have generalized the work on data flow testing by Duesterwald and colleagues 111. which is a novel method for datajrow testing through output influences.They use intraprocedural slicing, within a single procedure. to reveal the emrs involved in computing an erroneous output result. We have applied interprocedural dynamic slicing to generalize this method for data flow testing to work across procedure boundaries. Thus. most of the data flow testing dehitions andtermsare~wedframtheoriginalworkpresentedin [6. 11. In the next section we provide a short overview of data flow testing through output influences and in Section 3 we present the basic principles of interprocedural dynamic slicing. Section 4 describes our novel method for performing data flow testing at the procedural level.
Introduction The needs of program maintenauce tasks such as test-
ing, debugging and modification often demand that large programs be decomposed into manageable pieces. and that accurate dependences between different parts of programs can be determined. Program slicing [12. 5. 101 is one method for such analysis. A program slice with respect to a specified variable at some program point consists of those parts of the program that may directly or indirectly affect the value of that variable at the particular program point. This is useful for understanding dependences within programs. A static program slice is computed using static data- and control flow analysis and is valid for all possible executions of the program. Static slices are often imprecise, i.e., they contain unnecessarily large parts of the program. Dynamic slices. however, are precise but are valid only for a single execution of the program. Interprocedural dynamic slices
1063-6773193 $3.00 0 1993 IEEE
I1
386
2
Principles of data flow testing through output influences Data flow testing is one of several existing test
methods.In thismethod [4.8]a variabledefinition* is tested by selecting test cases that execute subpaths from this definition to all its c 0 do begm sum:= s u m + i; i:=i+2;
(u1,d3,d~)
K= n-1
(s7)
(d2)
(uz) (d5U344) (d6.u5)
(d79u6)
end; (sg) i
write~output,sum) end.
(u79u8d8)
Figure 1:An example pragram which computes the square of the integer n through summation of the first n odd numbersstarting at 1, q..% denote statements of the program, dl..& and ul.au6 are unique definition and use indications respectively. In Figure 1 the definition of variable swn at statement s,. r e f d to as dl, has ause in statement s5. referred to as u3. In Figure 2. the dependence graph o f this program. d1 and u3 =present outgoing and hccmiug variable swn at statement instancessf and s5 respectively.The data dependence edge between thesetwo variables represents the defin i t i o n - ~pair d 1 ~ 3 .Other definition-use pairs in the program are Computable in the same way. Note that the file variable input is both defined and used in statement s3. and e w and used in statethat the file variable output is also d ment sa.All exercised dehition-use pairs are as follows:
* A variable x is defined in a statement s if an execution of s assigns a value to n The variable x is also r e f d to as an outgoing variable of s. A statement has a (possibly empty) set of definitions. t A variable x is used in a statement s if an execution of s requks that the value of x be evaluated (referenced). The variable x is also refermi to as an incoming variable to statement S. An example is a variable usage in a predicate of an if-statement. A statement has a (possibly empty) set of U=.
diuj. 4 ~ 4d2u5, . d4u2. d4U6, d5u8, d7u2
387
7
< (in: input) (in: autput) entlym0fdW (aut input) (aut output) >
d8
sum) ss (aut: output):
-
.___. . . e
\
/
Figure 3: The! exccutjon slice on the dymmlc graph in Flgure 2 with respect to variable sum at statement % graphs. Now.au execution slice with mspect to variable swn at statement su (the write statement in the progtam) will Abstraction of intrapraxdurat information for contain definition-u~epairs d+8, d 2 ~ 4 ,dlUjl. d 4 ~ 2 .~ e e each procedure and construction o f au interproF i g u r e 3. ”he Slice d m notcontain Statements S 6 and S7 and cedural summary graph. coarectly indicates that none of the deiinition-use pairs dzU5. d4U6 and d7U2 bolved in tbe executionofthose State* Computation of hterprocedural slices. ments will be c o v e d by the test case. Thus the cover set will be: Cover(t:n=l) = {dlu3, d2u4.d 4 ~ 2d&. . A slice is extractedfrom the hterproceduralsummary graph that mplesents the cmfrol and -data dependences of 3 Interprocedural dynamic slicing variables that extend across&D h d a l i e s . nus. his section presents out approach, for computing the essential portion of Our slicing technique is the i n t e q r d u r a l dynamic slices of a program, based on: cmstructian of the interprocedural summary graph. Collection and cumputah of intraprocedural The umtrol dependence information is derived from control and data dependence information and the program strucm. This information is static, since for representation of this information as temporary a given statements. the s t a ~ n t that s s is am101 depen-
11
dent on do not h u g e in different executions. However,the statements that s is data dependent on may vary in di€femnt executions. Hence. the data dependences among program statements are dynamic. "hecomputationofcontroldependencesin arbitrary programs is described in [31. Kamkar [7] describes three alternative methods far collecting data dependence informatia statically over all executions, dynamically with respect to a specific execution,and in a combined statiddynamicmanner. Using any of these methods. we obtain an inte~oceduralsummary graph for Computing inteqrocedural dynamic slices.The interprocedural summary graph is constructed dynamically at run-time,so a slice on this graph is a dypamic slice. However, if the data dependeme information in the interprocedural summary graph is computed statically, the resulting slices aredynamic slicesbasedonstatic information. Similarly, if dynamic (coonbined statiddpamk) data dependence information is used,the slices are dynamic slices based on dynamic (combined statiddynamic)information. The next d o n introduces the COILcept of the dynamic interprocedural summary graph. Section 3.2 explains the process of extracting a slice on this graph. and Section 3.3 describes a mapping function h n a slice into the source program.
are actual ~ ~ m t g o i variables. n g Definition: hComing(p) is the set of all i n c mvariables to procedure p . and OutGoing(p) is the set of all outgoing variables ofp. A variable can belong to both InComing(p) and OutGoing(p). Definition: An activation edge from procedure pl to procedure pz represents an activation of procedurepz from the body o f p l . In the case of static infamation this is a possible activation, and in the case of dynamic information this is an actual activation. Definition: A swnmary dependence relation on the set of illudq/outgoillg variables is the set of all ordered y> such that x and y are bath h"hg/outgoing pairs a, variabla and x has a transitive dependence m y through combined data and umtrol dependii!mxs. The pair is called a summary dependence edge. It represents a p s i b l e dependence when consideaing static iuformation, and an actuald€p"3otherwise. Definition: A procedure instance is a pattern which represents a procedure and its incomhg and outgoing variables. Different executions of a procedure may give rise to m t procedure instances,due to d i f f m t values of its incoming and outgoing variables, since execution can follow different paths inside the procedure. procedure instance where
V = { s I s is a procedure instance: }
+ s2 between two such an edge shows that procedure p 2 in s2 is activated from the body o f procedure p I in sx during program execution. procedure instances sl and s2 are in a parent-child
procedureandwhosevalueisaccessibleoutsi&theprocedue. An incomingloutgoing variable ders to a variable which is an i"bg variable or an outgoing variable or both.&lesofthesevariablesamreferencepa"eters. which can be used as both inuming and outgoing in a procedure. andvalueparameters. whichcan ady be used as incoming. Global variables a~ treated variables. outgoing variables cr both according to their usage within the prooedure. If this iIlfamatial is &ted statia y . h Y represmt
m
E = a set o f activation edges sl
procedure
relation. Let SwnmaryG2 be a direded graph with a set d vertices Vand a set of edges E as follows: Sssm"yG2 = whcm
Vari-
abb. while in dynamic collection d this infamation tbey 389
11
inSWS.
V = { v I v is a variable instance: < p . x > where p represents a procedure. and x E InComing(p) U OutGoing(p)}
The value of outgoing variable w of P is also d e p dent on activation of P3. This value is affected by outgoing variable g o f P3 with the chain of affects as follows: w o f P -+ g o f P 3 +j o f P 4 -+ I o f P s -+ k o f PS + h o f P4 + e o f P3 +x of P A dynamicdependencesummary graph is constructed
E = a set of summary dependence edges v2 t vl* between variable instances. Such an edge shows that the computation of the value of x in vI is dependent on the value of y in v2. An edge represents a transitive dependence provided by summarizing control and data dependences between two variables. We distinguish these two kinds of dependence edges:
at run-timeduring execution of a program.
3.2 Interproceduralexecution slice Once the interproceduralsummary graph of a program hasbeenconstnmcted.the~putationofanexecutianslice on an in"i@outgoing variable is straightfmard. We d e b a slice criterion C to be a pair of a vertex s in SummaryGl representing a procedure instance where the incomingoutgoingvariable x belongs to in,, outp or both: c = A slice on the summary graph with respect to the slicing criterion C is a subgraphContaining all vertices with a variable y such that there is a transitive dependence between x, observed at the slicing criterion C,and y. The interprocedural execution slice consists of all p r o " instances which have affected the computation of the value ofx. It is possible that only some of the h"hg/outgoing variables of a selected procedure instance. . are involved in computation of x. We refer to such a prowdure instance as a partial procedure instance &',, p . out',>. Thus, only these partial procedure instances and their dependem edges will be in the slice. Let a partial procedure instance of a procedure instance be: such that: in', E in, andlor out', E outp
Intra-summary dependence. when an edge connects two variables belonging to the same procedure instance.This is caused only by local d e p within a procedure, the effect d the calls from the body ofthe procsdure are excluded. Inter-summarydependence, when an edge connects two variables belonging to procedure instances that are either in a parent-child relationship or have the same parent.
Intuitively. these two graphs together represent an execution tree of a program, decorated with dependence information for all incomi&outgoing variables of its p r o " instances. As we are going touse both graphs in parallel in the remainder of the thesis, for the sake of simplicity we repment them as one single graph. This graph is called the dynamic deperrdence summary graph or simply the summay graph. We further simplify the illustration of the summary graph by using simple lines instead of arrows to repment the activation edges. This is due to the fact that the e x d o n tree of a program is acyclic. Thus, the intuitive k t i m of the activation edges in figmix is top-down. As an example, consider Figure 4 where p r o " P calls procedm PI. P2, and P3. procedure P3 in turncalls procedure P4 and P4 calls Ps. The value of the outgoing variabley o f P is a result of activation o f two proceduresPI and P2. This value is affected by the outgoing variable d of P2 whiled in turn is a f f ~ t by d the value o f ofP2 ~ and SO on.These affect relations create a chain as follows: y of P +d o f P 2 + c o f Pz + b o f P l + a o f P I + x ofP The value of P's outgoing variable z is dependent on the activation o f P3 and not on P I or P2. The chain o f
affects is: z of P
We d e b an execution slice on the two graphs SummaryGl and Su"aryG2 with respect to the slicing critaion C= as two subgraphs SummaryGl' and SwnmaryG2'. Su"aryGl'= executionslicesu"c,,uc;l(C) =&, E'> Where V = { s } U {s' I s ' isapartialprocedureinstanceof a procedure instance in SummryGl with at least one incoming/outgoing variable y in s' reachable from x in s through same edges in SwnmaryG2)
E' = { e I e is an activation edge, in SummaryGl, between two vertices belonging to Y } SwnmaryG2'= executions l i ~ e ~ , , - ~ ~ (=W, C ) E'> Where V = { v } U {v' I v' is a variable instance in SmmryG2 with an outgoing variable y in v' reachable from x in v through some edges in the graph}
+f o f P 3 + i o f P 4 + h o f P 4 + e o f P 3 + x
ofP
* We we backward edges to denote dependence. as in othar slicingliterature.
390
r
#-...--< (in: a) PI (out:b) >
I
7
< (in:x) P (aut: y) (out: z) (out:w) >
-
< (in:
C)
P2 (out:d) >
< (in: h) P4(out: i) (out: j) >
activation edge
depend==
< (in: e) P3 (out f) (aut:g) >
< (in: k) Ps (Out: 1) > ~..-......- -J
edge
/
Figure 4: A summary graph representing dependence relations between procedure instances. E' = { e I e is a summary dependence edge, in the SummaryG2, between two variables such that the edge is part of the path starting from slicing variable x}
and
4
3.3 Mapping from execution slice to interprocedural program slice The execution slice on a summary graph contains all procedure instances which affect the value of a specified variable. These pmcedure instances mpresent execution of call statements in a program. Note that several procedure instances which denote difkrent executions af a procedue can arise from the same call statement. Here we define an interproceduralprogram slice to be the set of call statements in a program whose executicn (and hence executicm ofprocedurescalledby tht?m)affects the value of a specised variable. Other inteqmtations of the interproceduralprogram slice are the set of all statements (not just call statements) which affect the specified variable value, ae a reduced program (containing all mlevant procedm) which will be able to canpute the variable value of inkmst. Sioce we primarily deal with slicing at the procedural abstraction level in this paper, we use the interpretation set of call statements for interproceduralprogram slice. Amany-to-onemappingfunctionMfkomanexecution slice to the source prwam will provide a program slice. The mapping function M maps one or several vexties in the execution slice to a single call statement in the source ProgramM(s)=cs when s is a vertex in the execution slice and cs is a call statement in the source program
391
Application of interprocedural dynamic slicing in testing at the procedural level In the previous section, the definition-use pairs were
directly mapped to the ixmming and outgoingvariables of statement instancesin the dynamic proceduredependence graph. However,we caunat perform a similar mapping from definition-usepairs m a s procedure boundaries to the incoming and outgoing variables of the procedure instances in the dynamic dependence summary graph In order to clarify the matter let us coasider the following defixitian [a: Definition: The dehition-use pairs across procedure boundaries illustrate direct or indkct data dependences. Direct dependences exist when a~ of the two following cases holds (1) a definition of an actual parameter in one procedure reaches a use of the corresponding formal parameter in a called procedure OT (2) a definition of a farmalparameterin acalledprocedurereachesauseofthe correspae~dingactual parameter in the calling procedure. conditionsfor indirect d e p e " are similartotha6.efor direct dependences except that multiple levels of procedure calls and returns are ccmsi-. When a formal parameter is passed as an actual parameter at a call site, an indirect data flow dependencemay exist. In this case, a definitionof an actual parameter in one procedure may have uses in procedures more than level away in the calling sequence,considering both calls and returns. Consider the example d Figure 5. Definition dl assigns a value to variable v and variable v is passed as an
actual paramem to procedure q in which these is ause ul
of this value as the formal parameter c. Thus. definition dl in procedwep and use UI in procedwe q represent a defmi-
2.
tion-use pair across p r d w e boundaries. hothex exampleis definitiond2 in procedure q and use u2 in pnx;edwep,wherede~tiondzassignsavaluetofonnalpanuneter h and this value is returned to procedm p thrc gh actual parameter w the use of which is labeled U,.
(3
/pl.cedure p(var a,b:integer); var v. w: integec begin v:= a + 5; q(v.w); b:= w + 5 ; end;
\
(d3p U 2
V = { s Is is a procedure instance: < inp,p . oufp >)
E = a set o f activation edges sl procedure instances.
(11,
(dZJ41)
V = {v I v is a variable instance: < p , x, uld-set > whexe p represents a procedure. x is eithex an incoming variable with uld-set E U, which contains uses of x, or x is an outgoing variable with uld-set E D, which Contains def~tionsof x} .
1
samc: of the i n t e l p d u r a l definition-use pairs map directly to immming and outgoinsvariables of a procedure. procedurep whereas some others do not. In Figure 5 0. contains two definitions and two W S : (1) d&itia d1 af local variable v, (2) use u3 of incoming variable a, (3) definitimd3 o f outgoingVariable b, and (4) use U, of local variable w. Two of these are directly mapped to the i"ing and outgoing variables o f p . i.e. u3 and d3. The other two. although not mapped into any incoming or outgoing varistill involved in the computation of the incoming able, and outgoing variables. Hence we should also consider these pairs at the procedural abstraction level. We identify the following cases for determining definitim and uses in a procedm p (with p d m instance < inp.p , out,, >) which may belong to inteqrocedural definitim-usepairs: We select the sets of uses and definitim as follows: interprocedural-usesp:
E = a set of summary dependence edges vI t v2 between variable instances: Such an edge is labeled with a uld-set showing that the computation of the value of x in vI is dependent on the value o f y in v2. An edge represents a transitive dependence provided by summarizing control and data dependences between two variables. uld-set E {U2U D z } attached to a dependence edge represents the existence of required uses and/or defiitions in the path from v1 to v2. We construct the summary graph by summarizing dependence information from temporary graphs. At the same time we cau transfex the definitions and uses of interest from temporary graphs to the summary graph. Figure 60 shows the temporary graph for procedure p in F i p 5. Definitions and uses are atta&ed to incomingand outgoingvariables of each statement instance.The t e m p rary graph for procedure q in Figure 5 is shown in Figure 60.Apartofthesummarygraphcmtahhgpandthecall to q is umstructed by summarizieg the two abovementi& temporary graphs, see F w6 0 . Definitions and uses t r d d from tempmlq graphs to the summary graph m attec$ed to incosning and outgoing variables of procedure inst" and the edges of the
u1={ul uisauseofanincomingvarjablebeltmging to inp of }
2.
U2 ={U I thtx is acall statement i n p with statement instance < in,, s, out,> and U gets its value from an outgoingvariable belonging to out,} interprocedural-&finitionsp:
1.
+ s2 between two
SwnmaryG2 = 4,E> where
Figure 5: An example of definltion-use pairs across procedure boundaries
1.
ins 1
Now.we modify the definition of the summary graph to include the information about definitions and uses as defined above in order to adapt the graph for inkrprocedural data flow testing.We recall fiom Section 3.1 that the summary dependence graph is represented by two graphs SWnmaryGl and swnmaryG2. The new definition of the summary graph demands modifications to SwnmaryG2. while SwnmaryGl remains the same as before: SmmaryGl= where
(d1&')
procedure q(var c.dinteger); begin
d := c; end;
belonging to outp o f < inp p , out, > 1 D2= { d I there is a call statement in p with statement instance < in,, s, out,> and the value of d is used through an incoming variable belonging to
DI = { d Id is a definition of an outgoing variable 392
I
-ary
graph. Once the modified version of the summary graph is
constructed, the~utationofilltelp~aldefinitionuse pairs is straightforwardby traversingthegraph throplgh dependence edges. Considering Figure 60. a traversal from outgoing variable b af procedure Wtance p to incoming variable (I ofthe same proced~re$stance will pkk UP u ~ ~2 e with dehitim d2 and u ~ UI e with definition d l . An execution slice an the summary graph with respect to acarrect output value will t h e n d e t e " thecontents of the cover set, i.e.. the inteaprocedural dehiticm-use pairs which affectthat value. T
:(in: a) entryp (out b) >
t
1 Id11 'gg-
/-
program sumofoddnrs ~inpllkoutput>; var n,sum,i.s:integez; procedure init (var sum.i,n:integer);
'
besin sum:* (4) k=l; (4 read(hma) fUId3rd4) end; procedure add(var a:integer; binteger); begin
'i,
tu31
execution of program swnofoddnrs with the test case t: n=I.The definitions anduses axe attached tovertices and edges of the summary graph.
x=a+b (dS&&) end; procedure i"ent2(var c:integer); begin c:=c+2 (d69U4) end;
\ e (in: c) entry, (out d) >
*.--I--- 1 .. e . '
I . . . .
_*+-
procedure df!crementl(var diateger); begin d=d- 1 (d7.4) end;
procedure su"ation(var s,iainteger); begin addb3; incmnent2(i); decmxntl(n) end; begin main *) init(s,i,n); while n > 0 do (45)
i"
s l " a t i o n ( S in); (* omitted sum:=s; *)
write(output,sum) end.
Figure 6: (I)Temporary graph of procedurep In Figure 5. (II)Temporary graph of procedure q in ngure 5. (111) A part of the summary graph representing p and the call to q.
\
(u79u&d8)
1
Rgure 7: The example program sumofoddnrs decomposed into procedures
F i 9 contains a clearer illustration of the interprod u r a l definition-usepairs. In this figure we have removed the dependence edges and cormected each definition to its
5
Anexample As an example consider the program in F i7, anew version of the program in F i 1. decomposed into S e V d p r d U R S . In this program d1.. da and U ] . . U8
correspondinguses.
represent definitions and uses respectively. We have induced an error in the program by 0mitthg the statement sum:= s from the body of the main program. Figure 8 shows the dynamic summary graph amslructed during 393
< (in: input) (in: output) e.nbym0fdm(out: input) (out: output) >
k. .4'. L .
. e .
*/
k- -._._....-...-.
-.-.I.
k. -_.__.._._.. -.--.'
Figure 8: The summary graph of an execution of sumofoddnrsfor the test case:n=l I
.
< (in: input) (in: output) e n b y - , f ~ ~(out: input) (out: output) >
%
-
idd
c (in: sum) (in: output) write (out:output) >
Figure 9: Definition-use pairs across procedure boundaries
With the uld-set attached to vertices and edges of the the interprocedural definition-use pairs processed during execution can be computed. For the example above. we get the following interprocedural definition-use pairs: summary graph.
sum in procedure init dl i in procedure init n in procedure read Since the while-loop in the p m a m is executed only awe.the definitim d6 does not reach any uses and hence is not included in the processed definition-usepairs. 394
(in:
input) init (oUt‘~i.%llj) (out: i){dd ./‘ (outn) g,x’
---.-..
(aut: input) >
Flgure 10: The execution slice on the summary graph In flgure 8 with respect to fllewrlable output. Jeanne Fenante. Karl J. Ottenstein. and Joe D. Warren. The Program Dependence Graph and its Use in Optimization. ACM Transactions on Programming Languages and Systems. 9(3):319-349, July 1987.
Now, we extract an execution slice from the summary graph in Figure 8 with respect to the outgoing file-variable output which contains the value of sum in the main program. Figure 10, the execution slice, shows that only one definition-use pair, d p 8 , related to procedm init and procedure write a€fects the value of sum. If this value is correct Bccording to user’s expectations then the Cover(t) = id& dherwise it will be empty. This example shows that none d the exercised definition-use pairs involved in the current execution of procedure s m u t i o n is covered by the test case and theirefore the error in Figme 7 will not avoid detection during testing.
6
P.G. Frankl and EJ. Weyuker. An Applicable Family of Data Flow Testing Criteria.IEEE Transactions on Software Engineering, SE-14(10):1483-1498, October 1988. Susan HorwitZ, Thomas Reps. and David Binkley. Interprocedural Slicing using Dependence Graphs. ACM Transactionr on Programming Languages and Systems,
12(1):2641.January 1990. Mary Jean Harrold and Mary Lou Soffa. Interprocedural Data Flow Testing. In Proceedings of Symposium on Software Testing, Analysis and Verification. pages 158167, Key West,Florida, December 1989.
Conclusion In this paper we have demonstrated how interproCe-
dural dynamic slicing C~II be used to increase the ~ l i ability and precision af i n t e r p d u r a l data flow testing. thus obtaining an interprocedural method for data flow testing through output influences. The h&qmcedural dynamic slicing algorithm has been implemented and so far used on Pascal program examples of size up to 400 lines. We expect to e v a l e it on larger examples in the near future. Despite being a prototype it seem reasonably efficient (6 seconds for slicing the 400 line example) more efficient than an available prototype for interprocedural static slicing 151. For additional practical evaluation this data flow testing algorithmshould be integrated into a practical testing system that has functionalityfor test case generation.
Mariam Kamkar. Interprocedural Dynamic slicing with Applications to Debugging and Testing. Ph.D. Thesis. Department of Computer and Information Science, Linktiping University. April 1993. B. Korel and J. Laski. A Tool for Data Flow oriented program testing. ACM Sofrfair Proceedings, pages 34-38, December 1985.
-
7
References
[ 11
Evelyn Duesterwald, Fbjiv Gupta, and Mary Lou Soffa. Rigorous Data Flow Testing through OutputMluences. In Proceedings of the Second lwine Software Symposium, ISS’92. pages 131-145, California. March 1992.
[2]
Bogdan Korel. Automated software test data generation. IEEE Transactions on Sofrware Engineering. SE16(8):870-879, August 1990. [lo] Mariam Kamkar. Nahid Shahmehri, and Peter Fritzson. Inteaprocedural Dynamic Slicing. In Proceedings qf the Fourth International Conference on Programming
Language Implementation and Logic Programming, PLILP’92, pages 370-384. Luven, Belgium. August 1992. Springer-Verlag. Lecture Notes in Computer Science, volume 631. [ l l ] C.V. R a m a m d y . On the Automated Generation of Program Test Data. IEEE Transactions on Somare Engineering, SE-2(4):293-300, December 1976.
R.A. D e m o and AJ. Offutt. Constraint-based automatic test data generation. IEEE Transactions on Sofrware Engineering, SE-17(9):900-910. September 1991.
[12] Mark W e k . Program Slicing. ZEEE Transactions on Software Engineering, SE-10(4):352-357, July 1984.
395