| Korel, B. Automated software test data generation, IEEE Transactions on Software Engineering, 16(8). 1990. |
....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 program is executed with ....
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870 -- 879, Aug. 1990.
....be exercised. In order to know the level of completion attained by a set of test cases, a coverage measure provides the percentage of exercised structural entities. One of the approaches for obtaining test cases through structural testing is the dynamic test data generation [14]. In this alternative, an instrumented version of the programme is constructed. When an input is executed, the instrumentation made brings out information concerning the exercised structural entities. This information is used to assess the closeness of inputs to cover the desired entities and ....
....[7] The manner in which the heuristic technique takes part remains open, however, the work on the eld to date is concentrated mainly on structural test data generation, whilst the usual heuristic optimization method is the GA. The bulk of existing works is based on the system described in [14]. This is an iterative process which conforms to a dynamic test data generation strategy. At each step, an entity is selected as the actual goal and a function is associated. The function is formulated so that if an executed input exercises the goal, the value is minimum, otherwise the value is ....
B. Korel, Automated software test data generation, IEEE Transactions on Software Engineering, 16(8):870-879, 1990.
.... generating test inputs automatically: a static approach that generates inputs from some kind of model of the system (also called modelbased testing) and a dynamic approach that generates tests by executing the program repeatedly, while employing criteria to rank the quality of the tests produced [20,24]. The dynamic approach is based on the observation that test input generation can be seen as an optimization problem, where the cost function used for optimization is typically related to the code coverage (e.g. statement or branch coverage) The model based test input (test case) generation ....
B. Korel. Automated Software Test Data Generation. IEEE Transaction on Software Engineering, 16(8):870-879, August 1990.
....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 ....
....for infeasible paths; they can also require large amounts of memory to store the expressions encountered during symbolic execution, and powerful constraint solvers to solve complex equalities and inequalities. They may also have diculties handling complex expressions. Execution oriented techniques [15] alleviate some of these diculties by incorporating dynamic execution information into the search for inputs, using function minimization to solve subgoals that contribute toward an intended coverage goal. Goal oriented test case generation techniques [10, 14] like execution oriented techniques, ....
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870-897, Aug. 1990.
....a test data generator system. gram. There exist many di#erent definitions on control flowgraphs throughout the literature. Depending on the properties of the language to model, the definition might di#er [5, 6] The definition used here has been inspired by Beizer [1] as well as Korel et al. [5, 8]. Figure 3 shows a sample flowgraph and its corresponding program. A control flowgraph of a program is a directed graph G = N, E, s, e) consisting of a set of nodes N and a set of edges E = n, m) n, m N connecting the nodes. In each flowgraph there are two special nodes: one ....
....selecting among a set of paths, but just one specific. In this way it is the same as a goal oriented test data generation, except for the use of specific paths. Successively this leads to a better prediction of coverage. On the other hand it is harder to find test data. CASEGEN [13] and TESTGEN [8] are two systems using this technique. Since they are solely based on the control flow graph they often lead to selection of infeasible paths (both relatively and absolutely) DeMillo and O#utt [4] have proposed a constraintbased test data generation method. It is focused on fault based testing ....
[Article contains additional citation context not shown here]
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, August 1990.
....is its complexity. For a big program it requires a lot of computer resources, e.g. expressions have to be resolved and transformed. It also puts restrictions on the program. For instance, it is di#cult to handle function calls to modules where there is no access to source code. In dynamic tdg [8], in contrast to the static approach, values of variables are known, since the generation is performed during runtime. Here the data is generated without deriving the constraints. The program is run for some (possibly random) input. By monitoring the program flow the generator can determine if the ....
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, August 1990.
....A simple example already given to argue for oating point CSP is the following equation : x y = y where y is a constant. This equation was used to show that solvers over IR do not take into account addition cancellation. 7 Dead code is a piece of code in a program, which can never be executed [Kor90]. Consider the equation x 16:1 = 16:1. Table 1 and table 2 show the computation results of DeClic, PROLOG IV, and FB filtering on two di erent instances of such an equation. Table 1. Computing results for x 16:1 = 16:1 results [x; x] DeClic [ 7:10542735760100186e 15; 7:10542735760100186e ....
Bogdan Korel. Automated Software Test Data Generation. IEEE Transactions on Software Engineering, 16(8):870879, august 1990.
....our analysis covers 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 ....
Bokdan Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, August 1990.
No context found.
Korel, B. Automated software test data generation, IEEE Transactions on Software Engineering, 16(8). 1990.
No context found.
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, 1990.
No context found.
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, 1990.
No context found.
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, 1990.
No context found.
B. Korel. Automated software test data generation. 879, 1990.
No context found.
Bogdan Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, 1990.
No context found.
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, 1990.
No context found.
B. Korel. Automated Software Test Data Generation. IEEE Transaction on Software Engineering, 16(8):870879, August 1990.
No context found.
B. Korel. Automated software test data generation. 16(8):870--879, 1990.
No context found.
B. Korel, "Automated Software Test Data Generation, " IEEE Transactions on Software Engineering, Vol. 16, No.8, pp. 870-879, Aug. 1990.
No context found.
Bogdan Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, 1990.
No context found.
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870--879, 1990.
No context found.
B. Korel. Automated software test data generation. 879, 1990.
No context found.
Bogdan Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870-879, August 1990.
No context found.
B. Korel. Automated Software Test Data Generation. In IEEE Transaction on Software Engineering, 16(8):870879, August 1990.
No context found.
B. Korel. Automated software test data generation. IEEE Transactions on Software Engineering, 16(8):870-897, Aug. 1990.
No context found.
B. Korel, \Automated Software Test Data Generation," IEEE Transactions on Software Engineering, Vol. 16, No. 8, pages 870-879, August 1990.
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