L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, September 1976.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....an inspector method; in both cases, we simply refer to it as the use in the following. We use symbolic execution to compute the execution conditions of single paths within methods. Symbolic execution has been proposed in the seventies as a method for generating test cases for procedural programs [5, 19]. In the last decade, symbolic execution has been applied to many application domains [7, 8, 9, 22] In this paper, we use symbolic execution on paths within single methods as an aid to identify feasible sequences of method invocations. We limit our attention to paths that contain the definitions ....

L. A. Clarke. A system to generate test data and symbolically execute programs. Transactions on Software Engineering, 2(3):215--222, September 1976.

....: int, len : int; for (int i = len; i =0; int swapped = 0; for (int j = 0; j i; j ) if (a[j] a[j 1] Yes a[j 1] T; int T = a[j] a[j] a[j 1] swapped = 1; if ( swapped) return; The algorithm is based on combination of two techniques: 1. symbolic execution of the method [7] [8]; 2. speculative execution [9] Symbolic execution is interpretation of the model content from all methods, by solving logic expressions. Speculative execution is execution of all possible directions in each brunch of the control flow. ATPG algorithm provides condition decision, path covering ....

....Table 1. Example of Test Patterns and Test Cases Test Templates Path Covered Test Data len=0 0,1f,End a[ len=1 0,1t,2f,4t,End a[1] len=2; a[0] a[1] 0,1t,2t,3f,2f,4t,End a[1,7] len=2; a[0] a[1] 0,1t,2t,3t,2f,4f,1f,End a[3,2] len=3; a[0] a[1] a[1] a[2] 0,1t,2t,3f,2t,3f,2f,4t,End a[5,7,8] len=3; a[0] a[1] a[0] a[2] 0,1t,2t,3t,2t,3f,2f,4f,1t,2t,3f,2f,4t,End a[3,1,5] len=3; a[0] a[1] a[1] a[2] a[0] a[2] 0,1t,2t,3f,2t,3t,2f,4f,1t,2t,3f,2f,4t,End a[2,9,5] len=3; a[0] a[1] a[1] a[2] a[0] a[2] 0,1t,2t,3f,2t,3t,2f,4f,1t,2t,3t,2f,4f,1f,End a[3,7,2] len=3; ....

[Article contains additional citation context not shown here]

L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215-222, September 1976

....Criteria Branch coverage is one criterion that falls within this category. Statement coverage is the most basic criterion that one can use. Path Coverage Criterion[26, 23] is another which is used as a basis for pathwise test data generation methods[17] Two of these methods are symbolic execution[2, 6] and execution oriented [8] test data generation. Of particular interest is Korel dynamic test data generation method[9] This differs from the execution oriented test data generation method in that there is no longer a focus on covering paths. The goal now is to execute a selected location. The ....

L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215 -- 222, Mar. 1976.

....test cases is laborious, and its success depends on the experience of the tester. This problem is especially serious for users of spreadsheet languages, who typically are not experienced programmers and lack background in testing. Existing research on automated test case generation (e.g. [6, 8, 10, 13, 14, 15, 21]) however, has been directed at imperative languages, and we can nd no research speci cally addressing automated test case generation for spreadsheet languages. To address this problem, wehave been investigating how to automate the generation of test cases for spreadsheets in ways that support ....

....path that will meet a testing requirement, and then attempt to nd input values that cause that path to be executed. Ferguson and Korel distinguish twotypes of pathoriented techniques: those based on ######## #########, and those that are ##################. Techniques based on symbolic execution [6, 8, 13, 18] use symbolic execution to nd the constraints, in terms of input variables, that must be satis ed in order to execute a target path, and attempt to solve this system of constraints. The solution provides a test case for that path. A disadvantage of these techniques is that they can waste e ort ....

L. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215-222, Sept. 1976.

....satisfying the original predicate but not the mutated predicate, i.e. a test case satisfying the equal sign of the predicate is required. Thus, distinguishing for routants forces a tester to construct test cases which examine points on or near a predicate border. Such a process has been shown [3, 4, 6] to be effective in revealing certain types of faults such as the domain faults defined by Howden [16] 3 Comparison methodology Weyuker et al. [23] critically examined different relationships among test adequacy criteria. They argue that effectiveness, cost, and difficulty of satisfaction are ....

....of satisfaction are several meaningful bases against which test adequacy criteria should be compared. Effectiveness refers to the fault detection ca pability of a criterion. Cost refers to the wor necessary to satisfy it. Difficulty of satisfaction, also known as the subsumption relationship [6] and the strength [17, 19] refers to the com putation of scores on one adequacy criterion using adequate test sets of another criterion. In this work, we compare the cost of satisfying the mutation, x mutation, and abs ror mutation adequacy criteria. We also compare the relative strengths of ....

L. A. Clarke, "A system to generate test data and symbolically execute programs," IEEE T'as. o Software Egieerig, SE-2(3):215 222, September 1976.

....satisfying the original predicate but not the mutated predicate, i.e. a test case satisfying the equal sign of the predicate is required. Thus, distinguishing cot routants forces a tester to construct test cases which examine points on or near a predicate border. Such a processes have been shown [2, 3, 6] to be effective in exposing certain types of faults such as the domain faults defined by Howden [14] Offutt et al. 22] also conducted experiments based on Mathur s proposal of constrained mutation [18] by excluding certain mutant operators such as svr which generates a large percentage of a ....

L. A. Clarke, "A system to generate test data and symbolically execute programs," IEEE Trans. on Software Engineering, SE-2(3):215 222, September 1976.

....can also be naturally handled in conjunction with the derived constraints by the constraint solver. The key step of the above process is the derivation of the system of linear constraints from the program. We discuss two approaches to carry out this task: one is based upon symbolic evlauation [3] and the other is an execution based [24] approach. We illustrate these approaches through an example program of Fig. 11 which reads three input values into variables a, b and c and then changes the contents of the variables such that eventually a contains the smallest number and c contains the ....

L.A. Clarke, \A System to Generate Test Data and Symbolically Execute Programs," IEEE Transactions on Software Engineering, Vol. SE-2, No. 3, pages 215-222, September 1976.

....a particular path (a path to execute an exception raise expression) in the program, the analysis falls into the path wise test data generators. There are three kinds of test data generators: path wise test data generators to cover certain structural elements in the program [Kor90, DO91, OJP99, Cla76, BKM91, How77, RbFHC76, BBS 79] data specification generators to generate test data from a formal grammar [Mau90] and random test data generators [VMM91] Most of the path wise test data generators [Cla76, BKM91, How77, RbFHC76, BBS 79] have used symbolic execution and they do not ....

.... generators to cover certain structural elements in the program [Kor90, DO91, OJP99, Cla76, BKM91, How77, RbFHC76, BBS 79] data specification generators to generate test data from a formal grammar [Mau90] and random test data generators [VMM91] Most of the path wise test data generators [Cla76, BKM91, How77, RbFHC76, BBS 79] have used symbolic execution and they do not consider languages with exception mechanisms nor rigorously prove their soundness. Given a program and a designated path, the analysis symbolically executes the path and creates a set of constraints on the program s ....

[Article contains additional citation context not shown here]

Lori A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215--222, September 1976.

....of the CBT approach, and also draws from Korel s dynamic test data generation approach [46, 47] and symbolic evaluation. It uses a direct domain reduction method for deriving values, rather than function minimization methods as used by Korel or linear programminglike methods as used by Clarke [48]. Korel s dynamic method [47] executes a program along one speci c path by starting with a particular input. When a branching point is reached, if the current inputs will cause the appropriate branch to be taken, the inputs will remain the same. If a di erent branch is required, then the inputs ....

L. A. Clarke, \A system to generate test data and symbolically execute programs," IEEE Transactions on Software Engineering, vol. 2, pp. 215-222, September 1976.

....projects software verification usually relies on techniques such as code inspection and testing, while correctness is very seldom formally proved. Symbolic execution is a well known formal technique that has been proposed for many activities such as symbolic debugging [20] test data generation [7, 26, 27], verification of program (partial) correctness [12, 19] and program reduction [8, 10] However, symbolic execution is not currently used in industrial environments although several prototypes have been built. The main reasons for this are: 1. the inadequacy of existing symbolic executors in ....

....calls are managed by means of macro expansion. The symbolic execution jumps to the invoked sub program and executes it, making the necessary assignments to represent parameters passing and return. The interested reader can find details on how symbolic execution can be formally defined in [7, 20], while Section 6 discusses the state of the art to the best of our knowledge. 3. VERIFYING SAFETY CRITICAL SYSTEMS The software embedded in safety critical systems is often written in a subset of the C programming language, with the aim of reducing failures that are caused by potentially ....

Lori A. Clarke. "A system to generate test data and symbolically execute programs," IEEE Transactions on Software Engineering, 2(3):215-222, September 1976.

....to non linear problems can only be caused if each path within that tree involves a non linear problem. In our opinion, the probability for an execution tree to contain exclusively non linear paths is very low, as supported by research data on frequency of non linear problems in computer programs [6, 7]. The preliminary experiments we conducted show a very high degree of unconstrained edges coverage. In fact, only 1.6 of all the unconstrained edges were not covered by our analysis, which represents 2 unconstrained edges out of 124. In one case (trityp) complete coverage was not possible due ....

L. A. Clarke. "A system to generate test data and symbolically execute programs", IEEE Trans. Soft. Eng., sep. 1976, pp.215--222.

....[35] But our depth breadth search technique targets at in nite state systems representable by Presburger formulas instead of nite state systems represented in BDDs. Our method of image computations on an execution tree can be traced back to the earlier symbolic execution techniques for programs [15, 45, 44] as well as for speci cations [32] However, the major di erence is that our procedure is fully automatic and applicable to real time systems. An environment is tied to an ASTRAL transition at di erent levels of approximation: from the cheapest single event assumptions (i.e. assuming, during the ....

L. A. Clarke, \A system to generate test data and symbolically execute programs," IEEE Transactions on Software Engineering, vol. 2, no. 3, pp. 215-222, 1976.

....Test Data Consider the problem of choosing appropriate test data. In general, choosing input data to follow a path through the reachability graph in such a way that it correlates with the values of modeled variables is undecidable. In practice, it may be possible to use symbolic execution [5] or some heuristics [10, 14] or to use random test data, aborting those executions that are not exploring the part of the reachability graph of that is of interest. In this section we propose an approach for choosing values of variables that are modeled by the veri er. Many FSV approaches are ....

L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, SE-2(3), Sept. 1976.

No context found.

L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, September 1976.

No context found.

L. Clarke. A system to generate test data and symbolically execute programs. IEEE Trans. Software Eng., 2:215--222, 1976.

No context found.

L. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215--222, 1976.

No context found.

L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, Sept. 1976.

No context found.

L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215--222, Sept. 1976.

No context found.

L. Clarke. A system to generate test data and symbolically execute programs. IEEE Trans. Software Eng., 2:215--222, 1976.

No context found.

L. Clarke. A system to generate test data and symbolically execute programs. IEEE Trans. Software Eng., 2:215--222, 1976.

No context found.

L. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3), September 1976.

No context found.

Clarke, L.A. A system to generate test data and symbolically execute programs, IEEE Transactions on Software Engineering, v.2, p. 208-215, 1976

No context found.

L. A. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215--222, Sept. 1976.

No context found.

L. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215--222, 1976.

No context found.

L. Clarke. A system to generate test data and symbolically execute programs. IEEE Transactions on Software Engineering, 2(3):215-222, Sept. 1976.

First 50 documents  Next 50

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