Real Estate

A Dependence Graph-Based Test Coverage Analysis Technique for Object-Oriented Programs

Description
We propose a novel test coverage analysis technique for object-oriented programs. Our technique consists of three phases: graph construction, instrumentation, and coverage analysis. In the graph construction phase, the source program is converted
Categories
Published
of 7
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
  This is the accepted (preprint) version of the following article:E. S. F. Najumudheen, R. Mall and D. Samanta, "A Dependence Graph-BasedTest Coverage Analysis Technique for Object-Oriented Programs," 2009 SixthInternational Conference on Information Technology: New Generations, LasVegas, NV, 2009, pp. 763-768. doi: 10.1109/ITNG.2009.284, which has beenpublished in final form at http://ieeexplore.ieee.org/document/5070713/ Personal use of this material is permitted. Permission from IEEE must be obtainedfor all other uses, in any current or future media, including reprinting/republishingthis material for advertising or promotional purposes, creating new collective works,for resale or redistribution to servers or lists, or reuse of any copyrighted componentof this work in other works.  A Dependence Graph-based Test Coverage Analysis Technique forObject-Oriented Programs E S F Najumudheen ∗  Dept. of Computer Sc. & Engg. Rajib Mall  Dept. of Computer Sc. & Engg. Debasis Samanta School of Information Tech. Indian Institute of Technology, Kharagpur 721302, India ∗ Corresponding author: najum@cse.iitkgp.ernet.in Abstract We propose a novel test coverage analysis technique for object-oriented programs. Our technique consists of three phases: graph construction, instrumentation, and coverageanalysis. In the graph construction phase, the source pro-gramis convertedinto a dependencegraph-basedrepresen-tation, named Call-based Object-Oriented System Depen-dence Graph (COSDG). In the instrumentation phase, thesource code is instrumented at specific points. During thecoverage analysis phase, the instrumented source code isexecuted for different test inputs, and the edges of COSDGare marked by the graph marker. Various coverage mea-sures are computed from the marked COSDG by the cover-age analyzer to finally produce a coverage report. Inheri-tance and polymorphic coverage are considered in additionto traditional coverage measures.  Keywords:  Test coverage analysis, software testing, object-oriented program, dependence graph. 1. Introduction Coverageanalysishasbecomeanessentialpartoftestingin today’s software development process. During testing,coverage analysis is used to help determine the extent towhichsomefeatureofinteresthas beenexercisedbyagiventest suite [2].In the past, several researchers have proposed differenttechniques to perform test coverage analysis. In most of theapproaches,either the sourcecodeor the object/bytecodeisused to build the data structures required for coverage anal-ysis. Some of the approaches use tables while some othersuse some form of flow-graph or call graph to represent thedifferent features of a program. Agrawal uses dominatorgraphs to perform coverage testing based on control-flowand data-flow criteria [1]. The work of Rountev  et al.  wasbased on polymorphic coverage criteria [8]. Vinzenzi  et al. uses def-use graph to derive control-flow and data-flow cri-teria [9]. Jeff Offut  et al.  proposed a graphical model torealize polymorphic and inheritance faults [7]. These work are based on some specific criteria such as control-flow,data-flow, def-use, polymorphism, inheritance, etc. But, weare unable to find any work in the literature that proposesa coverage technique providing a gamut of traditional andobject-oriented coverage measures.In this paper, we propose a novel technique to performcoverage analysis of object-oriented programs. Our tech-nique is intended to provide a more accurate coverage of object-orientedfeatures than the existing techniques. To fa-cilitate coverage analysis, we first convert a program intoa suitable dependence graph-based intermediate represen-tation, named  Call-based Object-Oriented System Depen-dence Graph  (COSDG). COSDG is a multigraph that cap-tures both structural as well as various object-oriented fea-tures of interest. We have developed a marking algorithmto mark the edges of COSDG, and use the marked COSDGto perform coverage analysis. In our analysis, we considerinheritance and polymorphic coverage in addition to tradi-tional coverage.The rest of this paper is organized as follows. In thenext section, we provide an overview of the prevailing ap-proaches to test coverage analysis. Section 3 describes ourproposed representation, the Call-based Object-OrientedSystem Dependence Graph (COSDG), and proposed ap-proachtotest coverageanalysis. We compareourworkwithrelated work in Section 4. Section 5 concludes this paper. 2. Background Existing approaches to test coverage analysis employone of the following. •  Analyze the source code to insert probes at specificprogram locations, compile and execute the instru-mented program, use execution traces to computecoverage. •  Analyze the byte code to insert probes, execute the in-strumented byte code, use execution traces to computecoverage.  •  Convert the source or object/byte code to some formof flow-graph, use this graph to find probe locations,instrument the source code, compile and execute, useexecution traces to compute coverage.However, it is difficult to analyze object-oriented fea-tures such as inheritance, polymorphism, dynamic binding,etc., using source code or byte code only. Further, cover-age measures based on  control/data flow graphs  [3],  class flow graph  [2], etc., may be effective in determining theextent to which the structural aspects of the code within amethod or class have been exercised, i.e., coverage of inde-pendent paths, logical decisions, etc. But flow-graph basedrepresentations do not address features specific to object-oriented software such as inheritance, associations, etc. [9].Therefore, for a satisfactory object-oriented test coverageanalysis, we need a representation that explicitly representsflow, dependency, as well as object-oriented features. 3. Our Approach to Test Coverage Analysis In this section, we describe our proposed approach totestcoverageanalysisofobject-orientedprograms. Figure 1illustrates the various activities of the coverage analysistechnique. Our technique consists of three phases:  graphconstruction ,  instrumentation , and  coverage analysis . Dur-ing the graph construction phase, the COSDG representa-tion of the source program is constructed. During the in-strumentationphase, thesource codeis instrumentedat spe-cific points. During the coverage analysis phase, the instru-mented source code is executed in an integrated environ-ment for different test inputs, and the edges of COSDG aremarked by the graph marker based on the results of execu-tion. Next, various coverage measures are computed fromthe markedCOSDG by the coverageanalyzerto finally pro-duce a coverage report. Prior to explaining the differentactivities in each phase, we present our representation forobject-oriented programs, the COSDG. 3.1. Call-based Object-Oriented SystemDependence Graph (COSDG) In this section, we present our dependence graph-basedrepresentation for object-oriented programs, namedCall-based Object-Oriented System Dependence Graph(COSDG) [6]. COSDG is a directed, connected multigraph G  = ( V  ,  E  ) , consisting of a set  V   of vertices and a set  E   of edges. A vertex  v  ∈ V   represents one of the three categoriesof vertices, namely,  statement vertices ,  entry vertices , and  parameter vertices . An edge  e  ∈  E   represents one of theseven categories of edges, namely,  control dependenceedges ,  data dependence edges ,  parameter dependenceedges ,  method call edges ,  summary edges ,  class member edges , and  inheritance edges  . The different types of vertices and edges are explained in the following sections. Instrumentation  .  Coverage AnalysisGraph Construction Integrated Run-time EnvironmentCodeParserSource CodeInstrumenterRun-timeGraph MarkerCoverageAnalyzerCoverageReportInstrumentationCriteriaTestCasesInstrumentedSource CodeCOSDGMarkedCOSDGSourceCodeASTGraphBuilder Figure 1. Overview of the proposed approachto test coverage analysis. 3.1.1. Vertices A vertexis denoted as  v t  . n  ( v t  . n  ∈ V  ) where  t   specifies thetype of a vertexand  n  is an integer value that uniquelyiden-tifies a vertex. Program statements that constitute the bodyof the methods are represented by  statement   vertices ( V  s ).These are of two types: method call statements ( call sites )are represented by  call  vertices ( V  s 2 ), and statements otherthan methodcalls, such as assignment, loop, condition,etc.,are represented by  simple statement   vertices ( V  s 1 ). Classand method headers are represented by  class entry  vertices( V  e 1 ), and  method entry  vertices ( V  e 2 ), respectively. Param-eter passing between a caller and a callee 1 is modeled byusing  parameter   vertices ( V   p ) [6].For example,  v s 1 . n  ∈ V  s ,  v e 1 . n  ∈ V  e , and  v  p 1 . n  ∈ V   p  denotea simple statement, a class entry, and a formal-in vertex,respectively. 3.1.2. Edges An edge is denoted as  e t  . n  ( e t  . n  ∈  E  ) where  t   specifiesthe type of an edge, and  n  is an integer value that uniquelyidentifies an edge. Passing of values between actual andformal parameters is represented by  parameter dependence edges (  E   p ), which are of two types:  parameter-in  (  E   p 1 ) and  parameter-out   (  E   p 2 ) edges.  Data dependence edges  (  E  d  ) 1 we use the terms ‘caller’ and ‘callee’ to refer to a ‘calling statement’(a call site) and a ‘called method’, respectively.  represent the flow of data between different statement ver-ticesoftheCOSDG. Summaryedges (  E  s )representthetran-sitiveflowofdependencebetweenparametervertices. Classmember edges (  E  b ) represent the membership relation be-tween a class and its methods [6].For example,  e  p 1 . n  ∈  E   p 1 ,  e s . n  ∈  E  s , and  e b . n  ∈  E  b  denotea  parameter-in , a  summary  edge, and a  class member   edgerespectively. Other types of edges are explained in the fol-lowing subsections. Inheritance Edges Inheritance edges (  E  i ) represent inheritance relations be-tween classes. An inheritance edge connects a child classto its parent class in the direction of the inheritance depen-dence. It is tagged by a list of methods of a parent classthat are visible to its child class [6]. An inheritance edge isdenoted as  e i . n  where  i  specifies an inheritance edge, and  n is an integer number that uniquely identifies the edge. Control Dependence Edges Control dependence edges (  E  c ) represent control condi-tionson whichthe executionofa programelement depends.A control dependence edge is used to connect a pair of ver-tices, say  v 2  and  v 1 , each vertex representing a program el-ement, if   v 2  is  control dependent   on  v 2  [6]. Method Call Edges Method call edges (  E  m ) are of three types, namely, sim-ple call edges (  E  m 1 ), inherited call edges (  E  m 2 ), and poly-morphic call edges (  E  m 3 ). Simple Call Edge.  A simple call edge connects a callsite to a method defined in the class of an invoking object.It is denoted as  e m 1 . n  where  m 1  specifies a simple methodcall, and  n  is an integer number that uniquely identifies thecall edge. Inherited Call Edge.  An inherited call edge connectsa call site to a method inherited by the class of an invokingobject. It is denoted as  e m 2 . n  where  m 2  specifies an inher-ited method call, and  n  is an integer number that uniquelyidentifies the call edge. Polymorphic Call Edge.  A polymorphic call edgeconnectsacallsite toa methoddefinedinoneofthefeasiblereceiver classes [6]. It is denoted as  e m 3 . n  where  m 3  speci-fies a polymorphic method call, and  n  is an integer numberthat uniquely identifies the call edge.The graphical symbols used to represent the differenttypes of vertices and edges are shown in Figure 2. Differ-ent instances of simple, inherited, and polymorphicmethodcalls are shown in the example programin Figure 3(a). Fig-ure 3(b) illustrates the various types of method call edgescreated at different call sites in the program.  class entry, method entry parameter statement, call control dependence inheritance data dependence simple method call parameter dependence inherited method call class member polymorphic method call summary Symbols for EdgesSymbols for Vertices Figure 2. Graphical symbols used to repre-sent the different types of vertices and edgesin a COSDG. 01: class  A {02:  void  m0(){}  //base }03: class  B  extends  A {04: B() {}  //constr. 05:  void  m1()06: { m2(); }07:  void  m2() {}08:  void  m3()09: { m0(); }10:  void  m4()11: { m1(); }}12: class  C  extends  B {13: C() {}  //constr. 14:  void  m2() {}  //ovrdn. }15: class  X {16:  void  main(String[] args) {17:  int  x = args.length;18: B Obj_B= new   B();  //simple 19: C Obj_C= new   C();  //simple 20: Obj_B.m1();  //simple 21: Obj_C.m1();  //inherited  22:  if  (x==1)23: Obj_B.m3();  //simple else  {24: Obj_C.m4();  //inherited  25: Obj_B= new   C();  //simple }26: Obj_B.m2();  //polymorphic  } (a) s2.20s2.19s2.18e2.16e1.15s2.21e2.05e1.03e2.13e1.12e2.07 e m1.01 e m1.02 e2.04e2.14 e m1.03  e m2.05 s2.06 e m1.04 e m1.06 s2.23s2.24e2.08 e m1.07 e m2.09 s2.09 e m2.08 e1.01e2.02e2.10 e m2.10 s2.11 simple call inherited call polymorphic calls2.25s2.26 e m1.11 e m3.12 e m3.13FT F s2.17s2.22 (b) Figure 3. (a) An example Java program(b) Edges showing various types of methodcalls. 3.2. Construction of COSDG The COSDG is constructed in two steps:  code parsing and  graph building . During parsing, the source code isparsed by the  code parser   to create an  abstract syntax tree  Algorithm  ConstructCOSDG 1. Construct  class dependence graphs a. Create a class entry vertex for eachclassb. For each method in the class, con-struct a  method dependence graph by calling  ConstructMDG c. Add class member edges2. Build inheritance hierarchy3. Process call sitesa. Perform  BuildCallSite  foreachcall-siteinnon- main methodsb. Perform  BuildCallSite  foreach call-site in  main  method Algorithm  ConstructMDG 1. Process method headera. Create a method entry vertexb. Create formal parameter verticesc. Add control dependence edges2. Create statement and call-site vertices3. Determine control dependencesbetween vertices and add controldependence edges4. Determine data dependences betweenvertices and add data dependenceedges Algorithm  BuildCallSite 1. Create actual parameter vertices2. Add a parameter edge for each pairof actual/formal vertices3. Determine transitive dependencesand add summary edges4. Process method calls and addmethod call edges Figure 4. Algorthim to construct the COSDGfor a program. (AST). During graph building, the COSDG of the sourceprogramis constructed by the  graph builder   using the AST. 3.2.1. Graph Builder We now outline the various steps involved in the processof graph building. First, a dependence graph for each classis constructedby creatinga class entryvertex,a dependencegraph for each method in a class, and connecting the entryvertexto each methoddependencegraphby a class memberedge. Next, the inheritance hierarchy among classes is es-tablished by connecting the parent and child classes withinheritance edges. Finally, algorithm  BuildCallSite processes call sites in each methodto establish a connectionbetweena call site anda callee, which results in a connectedmultigraph. This is done in two stages. First, call-sites inall the non- main 2 methods are processed to build clusters.Next, call sites in the  main  method are processed to es-tablish a connectionbetween the class containing the main methodand the classes within each cluster. Thus, it builds acall graph for a complete program by incrementally addingmethod call edges at call sites. These steps are presented inpseudo-code form in Figure 4. 3.3. Code Instrumentation Codeinstrumentationformsanimportantpartofourpro-posed approach to test coverage analysis. The instrumentedprogram when executed, provides a  run-time trace  whichis used by the  graph marker   in the coverage analysis phase.Thetask ofinstrumentationis performedbythe  source codeinstrumenter  . Theinstrumenterusesthe abstractsyntaxtree (AST) created by the code parser and generates the instru-mented code based on the details provided by the user. 2 Here, we assume that the main method represents the  test driver   codeto test the various features of classes. Sinceinstrumentationintroducesconsiderabletimeover-head during programexecution, it has to be kept to the min-imum possible [4]. To achieve this, the user’s requirementis analyzed and transformed into  instrumentation criteria .This criteria provides details regarding the instrumentationpoints in a program. The instrumenter performs a  tree walk  over the AST, extracts the necessary information from ASTnodes, and generates the source code. During code genera-tion, it inserts tracestatements at the instrumentationpoints. 3.4. Coverage Analysis The coverage analysis phase consists of two steps,namely,  graph marking  and  coverage analysis . Duringgraph marking, the instrumented program is executed fordifferent test cases in an integrated execution environment.Based on the run-time execution traces of the program, theedges of COSDG are marked by a  run-time graph marker  to produce a  marked COSDG .During coverage analysis, the marking on the edgesof COSDG is analyzed (either  visited   or  unvisited  ) by a coverage analyzer   to compute the required coverage mea-sures. These measures are consolidated to provide a  test coverage report  . 3.4.1. Graph Marker The graph marker follows the marking procedure shownin Figure 5(a) to mark the edges of the COSDG. Ini-tially, all vertices and edges are marked  unvisited  . Step Iof the  MarkCOSDG  is an initialization step. Step II of  MarkCOSDG  consists of four sub-steps. Initially, from thelist of edges srcinating from the source vertex  v src , edgesthat terminate at destination vertex  v dest   alone are added toedge list  E  src  (Step 1). If   E  src  is non-empty,  MarkCOSDG identifies and marks a unique edge in  E  src  using algo-rithm  MarkEdges  (Step 2). If successful,  MarkEdges returns the marked edge. The type of the last methodcall encountered during execution is stored in the variable  prev _ call _ type . Finally,  MarkCOSDG  sets  v dest   with thenext vertex from the run-time execution trace (Step 4).Algorithm MarkEdges marks an edge as follows: If anedge  e s  is a control dependence edge,  MarkEdges  marks e s  as  visited   if the source vertex of   e s  is a non-derivedclass,or the invokingobject is an instance of parent class. Else,  e s is tagged with the vertex  id   of the class of invoking object.If   e s  is a method call edge, it straightaway marks the edgeas  visited  . The COSDG with its edges marked (shown inbold lines) corresponding to the execution trace of the ex-ample Java program in Figure 3 is shown in Figure 5(b) 3 .Edges have been marked for the command-line execution: "javaX" . 3 To avoid cluttering, parameter vertices, data dependence, summary,and parameter edges are not shown in the figure.
Search
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks