This approach allows us to emulate the behaviour proposed by Ballista, as it is a step towards the definition of valid, invalid and boundary test cases – if integand 8005 are indeed boundaries in decision structures. These constant values are, therefore, potential boundaries for numerical condition evaluation the rationale for this inference is the perception that this constitutes a common programming pattern. Bytecode instructions (Figure 3) at positions 4, 22 and 32 ( iconst_5 sipush 8000 sipush 8005 ) push the integer valand 8005 onto the top of the operand stack, for usage in posterior instructions of type “if”. The analysis that lead to the definition of this sub-set of terminal nodes follows. With this in mind, 9 additional terminal nodes were defined for this MUT, containing the following constant values: 4, 5, 6 7999, 8000, 8001 8004, 8005, 8006. With the Ballista methodology, testing is performed by passing combinations of acceptable, boundary and exceptional inputs as parameters to the test object via an ordinary method call. A distinct approach was, however, employed for the definition of terminal nodes representing numerical values – the Ballista fault injection methodology. For this case study’s MUT, the EMCDG analysis yielded the Function Set depicted in, which includes both the terminal and non-terminal STGP nodes involved in the method call sequence construction. This information is used to generate ECJ Parameter files that contain the constraints of the STGP system, and assures that the test cases’ call dependences are taken into account. These sets define the restrictions that must be imposed to STGP tree nodes specifically, they identify the children and return types of each node. Function and Terminal sets are then computed for each of the MUTs by evaluating the EMCDG. Secondly, the Extended Method Call Dependence Graph (EMCDG) is determined this structure describes the method call dependences involved in the test case construction. The first task is that of extracting the list of public methods from the test object’s bytecode by means of the Java Reflection API this list comprises the set of MUTs that are to be the subject of the unit-testing process. The test cluster’s Java bytecode analysis is performed by the ATOA module of the eCrash framework it is at this step that the Function and Terminal sets are defined, and hence it must precede the test set evolving and evaluation phases.
BYTECODE CONTROL FLOW GRAPH BUILDER CODE
The Controller.reconfigure(Config) public method was used as the method under test (MUT) its source code is depicted in Figure 2. In this experiment, the simple test cluster defined in is used for demonstration purposes.
It’s main task is that of generating Parameter Files containing the constraints needed for the STGP system. The test cluster analysis phase is performed by the “Automatic Test Object Analyser” (ATOA) module of the eCrash tool. ) and to visualize the trace information produced by the executions of instrumented programs. Additionally, it contains tools to perform various analyses using the outputs generated by its components (statistics, coverage reports. The Sofya package provides implementations and tools for the construction of various kinds of graphs – most notably CFGs – and native capabilities for dispatching event streams of specified program observations, which include instrumentators, event dispatchers, and event selection filters for semantic and structural event streams. The process of CFG building, bytecode instrumentation and event tracing is achieved with the aid of Sofya, a dynamic Java bytecode analysis framework. It is highly flexible, having nearly all classes and their settings being dynamically determined at runtime by user provided Parameter files and Function Set files. ECJ is a research package that incorporates several Universal Evolutionary Algorithms, and includes built-in support for Set- Based STGP. For evolving the set of test cases, the Evolutionary Computation in Java (ECJ) package is used. The framework of our tool is outlined in Figure 1. Test cases are evolved using a STGP mechanism, with the metrics required to evaluate their quality being collected at the bytecode level.
0 kommentar(er)
