| Evelyn Duesterwald, Rajiv Gupta, and Mary Lou Sofia. A demand-driven analyzer for data flow testing at the integration level. In Proceedings of the 18th International Conference on Software Engineering, pages 575-586, mar 1996. |
....contributions, we had to propose ourselves almost everything that we have presented, so it is not surprising to find that there is virtually no related work. In fact, the most closely related work is so more by the name than by the ideas. Demand driven analyses are presented by Duesterwald et al. [22, 23], by Agrawal [1, 2] and by Heintze and Tardieu [30] The analyses that are presented are a data flow analysis, a simultaneous data flow and call graph analysis, and a pointer analysis, respectively. In essence, these works consist in taking classical static analyses and turning them into lazy ....
Evelyn Duesterwald, Rajiv Gupta, and Mary Lou Sofia. A demand-driven analyzer for data flow testing at the integration level. In Proceedings of the 18th International Conference on Software Engineering, pages 575-586, mar 1996.
.... Analyses Related interprocedural analyses include compile time interprocedural program slicing [GL91, HRB90, OO84, RR95, GS96, LH96, HC98, SHR99, TCFR96, Tip96, Ven91, Wei84, TAFM97, AG96, AG98] interprocedural def use associations [PLR94, HS94, GH98, CR99] and, demand analyses [HRS95, DGS95, DGS96] Slicing determines the data and control dependent parts of a program which correspond to a particular computation. Def use associations trace value flow on static paths in a program; they are useful for various machine independent optimizations and data flow testing methods. Demand data flow ....
Evelyn Duesterwald, Rajiv Gupta, and Mary Lou So#a. A demand-driven analyzer for data flow testing at the integration level. In Proceedings of the International Conference on Software Engineering (ICSE'96), March 1996.
....is part of future work. We also plan to incorporate DefUse Algo in a tool for generating test cases and measuring def use coverage of O O libraries. The library needs to be instrumented to observe def use relationships executed by a set of test cases. 8 Related Work Data flow based testing [DGS96, FO76, LK83, FW93, HL91, Wey94] has been advocated since 1985 to supplement control flow based methods. Coverage metrics for def uses have been discussed [RW85, FW88, OW91, LCS89] and coverage checking tools exist [PFW85, Ost90] Def use analyses for C [PLR94] and Fortran [HS94] have been developed. Recent work explores ....
Evelyn Duesterwald, Rajiv Gupta, and Mary Lou So#a. A demand-driven analyzer for data flow testing at the integration level. In Proceedings of the International Conference on Software Engineering (ICSE'96), March 1996.
....scalability of incremental analysis comes from reducing the amount of recompilation, reanalysis and reoptimization necessary; however, there is still an unscalable step of exhaustive analysis needed before incremental analysis can be performed. 2.4. 3 Demand driven Analysis Demand driven analysis [27, 28, 26, 45] has the goal of applying analysis and other optimizations only when they are needed, on demand, so that compile time and memory requirements can be managed. For example, if profiling information is being used during compilation, the compiler can decide on the fly which procedures it wishes to ....
E. Duesterwald, R. Gupta, and M. L. Soffa. A demand-driven analyzer for data flow testing at the integration level. In IEEE/ACM International Conference on Software Engineering, pages 575--584, Mar. 1996.
....analysis techniques. A more ambitious use of the demand driven paradigm involves reformulating the underlying algorithms to answer individual queries on demand. Recent work on demand driven data flow analysis provides an alternative to the exhaustive computation of data flow information [15, 16, 49]. These approaches answer single data flow queries at individual program locations, one at a time. An interactive software refactory based on such algorithms would not require a data flow representation of the program such as a PDG. However, methods for applying demand driven program analysis to ....
....by reversing the original analysis process. Exhaustive forward propagation is replaced with a goal oriented backward search. The search is triggered by a query for the definitions that reach a selected node and terminates as soon as all nodes that contain a relevant definition have been found [16]. The demand driven technique is basically a breadth first search through the program s control flow starting at the initial (selected) statement. This search may include any number of lvalues. The algorithm simultaneously checks for all interesting definitions, adding each one encountered to the ....
[Article contains additional citation context not shown here]
E. Duesterwald, R. Gupta, and M. L. Soffa. A demand-driven analyzer for data flow testing at the integration level. In Proceedings of the 18th International Conference on Software Engineering, pages 575--584, 1996.
No context found.
E. Duesterwald, R. Gupta, and M.L. Soa, \A Demand-Driven Analyzer for Data Flow Testing at the Integration Level," SIGSOFT/IEEE 18th International Conference on Software Engineering, pages 575-584, 1996.
....be eliminated from the set of requirements to be covered by test cases. Since 100 test coverage can rarely be achieved on real programs due to presence of infeasible paths, reducing the number of infeasible def use pairs increases the confidence in regression testing [11] and integration testing [4]. By avoiding the consideration of infeasible paths during static slicing [10, 14, 17] fewer statements are added to the program slice, thus more precisely identifying the potentially erroneous statements. In this paper we present a static def use pair analysis technique that avoids ....
....4 can take the false exit of node 7. Also during the analysis of node 7, the copy assignment in node 9 changes the query from (v = 5) to (w = 5) with the result that node 1 is identified as a node that makes the true exit of node 7 impossible. The resulting infeasible paths from node 1 are 1 2 [3 4] 5 6 7 8 9 (10 11 13 6 14) 10 11 13 6 7. The shortest infeasible paths exclude 1 2 [3 4] because it is guaranteed that at node 5, the value of w is still the constant 1. The infeasible paths for the false exit of node 10 are also shown in the figure. v= 5 T read(w) v 0 z: x y v: w out(x) T F F ....
[Article contains additional citation context not shown here]
E. Duesterwald, R. Gupta, and M.L. Soffa, "A Demand-Driven Analyzer for Data Flow Testing at the Integration Level," International Conference on Software Engineering, Berlin, Germany, March 1996.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC