An assembly generation method and device for system exception handling testing

Abstract

The present invention discloses a method and device for generating a program set for system exception handling test, wherein the method inserts a stub into an original program to form an insert program, then executes the insert program, tracks the exception handling chain through the inserted instructions, iterates and mutates the program according to the exception handling chain, and forms a mutated program set. Thus, programmers can test the exception handling of the system based on these mutated programs to find out the differences in the exception handling methods, thereby assisting the programmers in understanding the exception handling of the system, so that the codes developed by the programmers can be applicable to different systems.

Description

Technical Field

[0001] The present invention relates to exception handling testing. Background Art

[0002] Exception handling is an important means in software program systems. The exception handling process is related to the processing process defined by programming code on the one hand and the processing mechanism of the platform system on which the program runs on the other hand. Briefly speaking, for programs written in programming languages that are compiled and executed, the platform systems on which the program code runs after compilation are various operating systems, and different operating systems have different exception handling mechanisms; for programs written in interpreted programming languages such as Java, the platform systems on which their programs run, such as the Java virtual machine, and different Java virtual machines have different exception handling mechanisms. Although from the perspective of standardized programming languages, the exception handling process is generally similar, especially for program codes written in the same language, which should be the same logically. However, the underlying exception handling mechanisms of the platform systems on which the programs run are different. For example, in the case of the Java language, the underlying exception handling mechanisms of Java virtual machines developed by different manufacturers are different, and there may even be subtle differences between different versions of Java virtual machines developed by the same manufacturer.

[0003] Considering robustness, the written program needs to fit the platform system on which it runs. However, this is a huge challenge for programmers. On the one hand, in the testing of software programs, testing for exception handling is relatively difficult because exceptions are the abnormal states of the program and cannot be covered by ordinary test inputs. Special environments need to be constructed for testing. For example, for input / output exceptions and memory allocation exceptions, specific test conditions need to be constructed, such as filling up the disk space and extreme memory space allocation environments, etc. On the other hand, because there are differences in processing mechanisms among different operating systems, it is very difficult for programmers to understand all the details clearly. Especially when the platform system is updated, exceptions that could be correctly handled in the old version of the platform system may have exception handling problems in the new version of the platform system.

[0004] The best way for programmers to understand the exception handling mechanism of the platform system is to construct a series of exception handling programs for testing and then compare the differences between the old and new versions of the platform system. Programmers can then correctly modify the program based on the differences. However, manually constructing exception handling programs requires a large amount of manpower. Summary of the Invention

[0005] The problem to be solved by the present invention: Testing the exception mechanism of the platform system on which the program runs requires a large number of exception handling programs for testing to analyze the differences in exception handling mechanisms between different platform systems.

[0006] To solve the above problems, the solution adopted by the present invention is as follows:

[0007] A method for generating an assembly for system exception handling testing according to the present invention includes the following steps:

[0008] Step S1 is used to: obtain the original program and test input, and obtain the instrumented program after inserting exception path tracking instructions into the original program;

[0009] Step S2 is used to: execute the instrumented program according to the test input, obtain the execution path of the instrumented program through the inserted exception path tracking instructions, then extract the exception handling chain and function call stack from the instrumented program and the execution path to form exception handling chain information, and further form a set of exception handling chain information. Then, add the instrumented program, execution path, and set of exception handling chain information to the mutant program set;

[0010] The mutant program set is a set of mutant program information;

[0011] The mutant program information includes program code, execution path, and a set of exception handling chain information;

[0012] The exception handling chain information includes an exception handling chain and a function call stack;

[0013] The exception handling chain is a sequence of exception handling nodes arranged in the order of exception handling execution;

[0014] The exception handling node includes the location where the exception is thrown, the type of the exception thrown, the location where the exception is caught, and the type of the exception caught;

[0015] The location where the exception is thrown and the location where the exception is caught include the location in the execution path and the location in the program code;

[0016] The function call stack is the function call relationship stack where the exception corresponding to the exception handling chain is initially thrown;

[0017] Step S3 is used to: use the number of exception handling nodes in the mutant program information as a probability factor, and randomly select one piece of mutant program information from the mutant program set as a seed;

[0018] Step S4 is used to: randomly select an exception handling chain information from the set of exception handling chains of the seed as the seed exception handling chain information, and randomly select a mutation method to randomly mutate the program code of the seed to obtain a mutant program;

[0019] Step S5 is used to: execute the mutation program according to the test input, obtain the execution path of the mutation program through the inserted exception path tracking instruction, then extract the exception handling chain and function call stack from the mutation program and the execution path to form exception handling chain information, and further form a set of exception handling chain information, and find the mutated exception handling chain information corresponding to the seed exception handling chain information from the set of exception handling chain information;

[0020] Step S6 is used to: if the number of exception handling chain information of the mutation program is not less than the number of exception handling chain information of the seed and the number of exception handling nodes in the mutated exception handling chain information is not less than the number of exception handling nodes in the seed exception handling chain information, then add the mutation program, the execution path of the mutation program, and the set of exception handling chain information of the mutation program to the set of mutation programs;

[0021] Step S7 is used to: repeat Steps S3 to S6 until the end condition is met;

[0022] Step S8 is used to: extract the program codes of each mutation program information from the set of mutation programs to form a program set as the output.

[0023] Furthermore, according to the program set generation method for system exception handling test of the present invention, in Step S3, when randomly selecting a seed, the probability of selecting a mutation program information is: P(i)=B(i) / Sigma(B(i)); where P(i) is the selection probability of the i-th mutation program information in the set of mutation programs, B(i) is the probability distribution value of the i-th mutation program information in the set of mutation programs, and Sigma(B(i)) represents the sum of the probability distribution values of each mutation program information in the set of mutation programs; the probability distribution value B(i) is a monotonically increasing function of the number of exception handling nodes in the i-th mutation program information.

[0024] Furthermore, according to the program set generation method for system exception handling test of the present invention, the mutation methods include adding an exception capture block, deleting an exception capture block, swapping exception capture blocks, modifying the exception capture range, modifying the type of exception handling, deleting exception throws, and implanting exception throw captures.

[0025] Furthermore, according to the program set generation method for system exception handling test of the present invention, the end conditions include that the execution time reaches the limit condition and the number of mutation program information in the set of mutation programs reaches the limit requirement.

[0026] Furthermore, according to the program set generation method for system exception handling test of the present invention, "extracting the exception handling chain" includes the following steps:

[0027] Step S211 is used for: initializing the status of path nodes to be empty and the current exception handling chain to be empty;

[0028] Step S212 is used for: traversing the path nodes of the execution path in sequence and processing the traversed path nodes as follows:

[0029] If the path node is an exception throwing path node, and if the current exception handling chain is not empty, then add the current exception handling chain to the exception handling chain set and set the current exception handling chain to be empty, then mark the status of the path node as the exception throwing status, and record the position of the exception throwing path node in the execution path;

[0030] If the path node is an exception catching path node, if the status of the current path node is the exception catching status, and if the current exception handling chain is not empty, then add the current exception handling chain to the exception handling chain set and set the current exception handling chain to be empty, then construct an exception handling node, and add the constructed exception handling node to the current exception handling chain, and mark the status of the path node as the exception catching status;

[0031] If the path node is an exception catching path node, if the status of the current path node is not the exception catching status, then construct an exception handling node, and add the constructed exception handling node to the current exception handling chain, and mark the status of the path node as the exception catching status;

[0032] If the path node is an exception rethrowing path node, if the status of the current path node is the exception catching status, then mark the status of the path node as the exception rethrowing status, and record the position of the exception rethrowing path node in the execution path;

[0033] Step S213 is used for: after all the path nodes of the execution path are traversed, if the status of the current path node is the exception throwing status or the exception rethrowing status, or the last path node of the execution path is inconsistent with the exception path tracking instruction inserted at the end of the instrumentation program, then construct an exception handling node, and add the constructed exception handling node to the current exception handling chain.

[0034] A program set generation device for system exception handling test according to the present invention includes the following modules:

[0035] Module M1 is used for: obtaining the original program and test input, and obtaining the instrumented program after inserting the exception path tracking instruction into the original program;

[0036] Module M2 is used to: execute the instrumentation program according to the test input, obtain the execution path of the instrumentation program through the inserted exception path tracking instructions, then extract the exception handling chain and function call stack from the instrumentation program and the execution path to form exception handling chain information, and further form a set of exception handling chain information. Then, add the instrumentation program, the execution path, and the set of exception handling chain information to the mutant program set;

[0037] The mutant program set is a set of mutant program information;

[0038] The mutant program information includes program code, execution path, and a set of exception handling chain information;

[0039] The exception handling chain information includes an exception handling chain and a function call stack;

[0040] The exception handling chain is a sequence of exception handling nodes arranged in the order of exception handling execution;

[0041] The exception handling node includes the location where the exception is thrown, the type of the exception thrown, the location where the exception is caught, and the type of the exception caught;

[0042] The location where the exception is thrown and the location where the exception is caught include the location in the execution path and the location in the program code;

[0043] The function call stack is the function call relationship stack where the exception corresponding to the exception handling chain is initially thrown;

[0044] Module M3 is used to: use the number of exception handling nodes in the mutant program information as a probability factor, and randomly select one piece of mutant program information from the mutant program set as a seed;

[0045] Module M4 is used to: randomly select an exception handling chain information from the set of exception handling chains of the seed as the seed exception handling chain information, and randomly select a mutation method to randomly mutate the program code of the seed to obtain a mutant program;

[0046] Module M5 is used to: execute the mutant program according to the test input, obtain the execution path of the mutant program through the inserted exception path tracking instructions, then extract the exception handling chain and function call stack from the mutant program and the execution path to form exception handling chain information, and further form a set of exception handling chain information, and find the corresponding mutant exception handling chain information in the set of exception handling chain information for the seed exception handling chain information;

[0047] Module M6 is used to: if the number of exception handling chain information of the mutated program is not less than the number of exception handling chain information of the seed and the number of exception handling nodes in the mutated exception handling chain information is not less than the number of exception handling nodes in the seed exception handling chain information, add the mutated program, the execution path of the mutated program, and the set of exception handling chain information of the mutated program to the set of mutated programs;

[0048] Module M7 is used to: repeat Modules M3 to M6 until the end condition is met;

[0049] Module M8 is used to: extract the program codes of each mutated program information from the set of mutated programs to form a program set as the output.

[0050] Furthermore, for the program set generation device for system exception handling test according to the present invention, in Module M3, when randomly selecting a seed, the probability of selecting the mutated program information is: P(i) = B(i) / Sigma(B(i)); where P(i) is the selection probability of the i-th mutated program information in the set of mutated programs, B(i) is the probability distribution value of the i-th mutated program information in the set of mutated programs, and Sigma(B(i)) represents the sum of the probability distribution values of all mutated program information in the set of mutated programs; the probability distribution value B(i) is a monotonically increasing function of the number of exception handling nodes in the i-th mutated program information.

[0051] Furthermore, for the program set generation device for system exception handling test according to the present invention, the mutation methods include adding an exception capture block, deleting an exception capture block, swapping exception capture blocks, modifying the exception capture range, modifying the type of exception handling, deleting an exception throw, and implanting an exception throw capture.

[0052] Furthermore, for the program set generation device for system exception handling test according to the present invention, the end conditions include that the execution time reaches the specified condition and the number of mutated program information in the set of mutated programs reaches the specified requirement.

[0053] Furthermore, for the program set generation device for system exception handling test according to the present invention, "extracting the exception handling chain" includes the following modules:

[0054] Module M211 is used to: initialize the path node status as empty and the current exception handling chain as empty;

[0055] Module M212 is used to: sequentially traverse the path nodes of the execution path and process the traversed path nodes as follows:

[0056] If the path node is an exception - throwing path node, and if the current exception - handling chain is not empty, then add the current exception - handling chain to the set of exception - handling chains and empty the current exception - handling chain at the same time. Then mark the status of the path node as the exception - throwing status, and record the position of the exception - throwing path node in the execution path;

[0057] If the path node is an exception - catching path node, if the current status of the path node is the exception - catching status, and if the current exception - handling chain is not empty, then add the current exception - handling chain to the set of exception - handling chains and empty the current exception - handling chain at the same time. Then construct an exception - handling node, and add the constructed exception - handling node to the current exception - handling chain, and mark the status of the path node as the exception - catching status;

[0058] If the path node is an exception - catching path node, and if the current status of the path node is not the exception - catching status, then construct an exception - handling node, and add the constructed exception - handling node to the current exception - handling chain, and mark the status of the path node as the exception - catching status;

[0059] If the path node is an exception - re - throwing path node, and if the current status of the path node is the exception - catching status, then mark the status of the path node as the exception - re - throwing status, and record the position of the exception - re - throwing path node in the execution path;

[0060] Module M213 is used for: after all path nodes in the execution path are traversed, if the current status of the path node is the exception - throwing status or the exception - re - throwing status, or if the last path node in the execution path is inconsistent with the exception - path - tracking instruction inserted at the end of the instrumentation program, then construct an exception - handling node, and add the constructed exception - handling node to the current exception - handling chain.

[0061] The technical effects of the present invention are as follows: The present invention abstracts the exception - handling logic of the platform system into an exception - handling chain, accurately and fully describes the exception - handling logic in the program, mutates the program in a random mutation manner, and the user only needs to provide the initial program to construct a large number of programs for testing the exception - handling mechanism of the platform system, thereby improving the efficiency of the user in detecting the exception - handling mechanism of the platform system. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1 is the flowchart of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0063] The present invention will be further described in detail below with reference to the accompanying drawings.

[0064] The main idea of the method for generating an assembly for system exception handling testing in the present invention is to generate a series of programs as output by mutating a single original program input by the user through iterative looping. When iteratively mutating the program, it is required that the definition of the exception handling process of the program mutated in each round is more complex than that of the program before mutation. And to determine that the definition of the exception handling process of the mutated program is more complex than that of the program before mutation, it is necessary to analyze the exception handling processes of both after the program is executed. On the one hand, generally speaking, testing input is required to execute a program. Of course, it is not necessarily the case that all original programs need testing input. At this time, for original programs that do not require testing input, the testing input can be regarded as empty. Therefore, the input of the present invention is an original program and testing input, where the testing input is allowed to be empty. On the other hand, since it is necessary to analyze the exception handling process of program execution, and when analyzing the exception handling process of program execution, the program to be executed is instrumented, with path tracking instructions inserted, especially exception path tracking instructions for the exception handling process. The aforementioned step S1 is to obtain the original program and testing input, and after inserting exception path tracking instructions into the original program, an instrumented program is obtained. Here, it means that the original program and testing input are the input of the present invention. On the other hand, the input original program can also be the instrumented program after instrumentation. If the original program is not instrumented, then exception path tracking instructions are inserted into the original program. The following is an example code of an original program based on the Java programming language:

[0065] 01 class Foo {

[0066] 02 void foo1() throws IOException {

[0067] 03 try {

[0068] 04 methodThrowIOException();

[0069] 05} catch (IOException e) {

[0070] 06 RuntimeException er = new RuntimeException();

[0071] 07 e.initCause(er);

[0072] 08 throw e;

[0073] 09}

[0074] 10}

[0075] 11 char foo2() throws IOException {

[0076] 12 foo1();

[0077] 13 return 'a';

[0078] 14}

[0079] 15 public char foo3() throws IOException {

[0080] 16 foo2();

[0081] 17 return 'a';

[0082] 18}

[0083] 19}

[0084] 20 class Bar {

[0085] 21 public Token bar() {

[0086] 22 try {

[0087] 23 (new Foo()).foo3();

[0088] 24} catch (IOException e) {

[0089] 25}

[0090] 26 return new Token();

[0091] 27}

[0092] 28}

[0093] 29 public class Harness {

[0094] 30 private static void setBuildInfo() {

[0095] 31 try {

[0096] 32 methodThrowIOException();

[0097] 33} catch (Exception e) {

[0098] 34}

[0099] 35}

[0100] 36 public static void main(String[] args) {

[0101] 37 setBuildInfo();

[0102] 38 (new Bar()).bar();

[0103] 39}

[0104] 40}

[0105] The above example code defines three classes, namely Foo, Bar, and Harness. To avoid confusion between the word "method" in class methods and the "method" referred to in the present invention, class methods are uniformly referred to as functions. Among them, class Foo defines three functions, namely foo1, foo2, and foo3. Class Bar defines the function bar; class Harness defines two static functions, setBuildInfo and main. The function main first calls setBuildInfo and then calls the bar function of class Bar. An exception is thrown by the function methodThrowIOException in setBuildInfo and then caught. The bar function of class Bar calls the foo3 function of class Foo, the foo3 function calls the foo2 function, and the foo2 function calls the foo1 function. In the function foo1, an exception is thrown by the function methodThrowIOException and then caught. In the exception handling, the exception object instance e is redefined with the cause of the exception through the initCause function and then thrown again.

[0106] The above example code after instrumentation results in the following instrumented program:

[0107] 01 class Foo {

[0108] 02 void foo1() throws IOException {

[0109] 03 try {

[0110] 04 __RouteTrace.Log("Foo.foo1.1");

[0111] 05 methodThrowIOException();

[0112] 06 __RouteTrace.Log("Foo.foo1.2");

[0113] 07} catch (IOException e) {

[0114] 08 __RouteTrace.Log("Foo.foo1.3.C.IOException");

[0115] 09 RuntimeException er = new RuntimeException();

[0116] 10 __RouteTrace.Log("Foo.foo1.4");

[0117] 11 e.initCause(er);

[0118] 12 __RouteTrace.Log("Foo.foo1.5.L.IOException");

[0119] 13 throw e;

[0120] 14}

[0121] 15}

[0122] 16 char foo2() throws IOException {

[0123] 17 __RouteTrace.Log("Foo.foo2.1");

[0124] 18 foo1();

[0125] 19 __RouteTrace.Log("Foo.foo2.2");

[0126] 20 return 'a';

[0127] 21}

[0128] 22 public char foo3() throws IOException {

[0129] 23 __RouteTrace.Log("Foo.foo3.1");

[0130] 24 foo2();

[0131] 25 __RouteTrace.Log("Foo.foo3.2");

[0132] 26 return 'a';

[0133] 27}

[0134] 28}

[0135] 29 class Bar {

[0136] 30 public Token bar() {

[0137] 31 try {

[0138] 32 __RouteTrace.Log("Bar.bar.1");

[0139] 33 (new Foo()).foo3();

[0140] 34 __RouteTrace.Log("Bar.bar.2");

[0141] 35} catch (IOException e) {

[0142] 36 __RouteTrace.Log("Bar.bar.3.C.IOException");

[0143] 37}

[0144] 38 __RouteTrace.Log("Bar.bar.4");

[0145] 39 return new Token();

[0146] 40}

[0147] 41}

[0148] 42 public class Harness {

[0149] 43 private static void setBuildInfo() {

[0150] 44 try {

[0151] 45 __RouteTrace.Log("Harness.setBuildInfo.1");

[0152] 46 methodThrowIOException();

[0153] 47 __RouteTrace.Log("Harness.setBuildInfo.2");

[0154] 48} catch (Exception e) {

[0155] 49 __RouteTrace.Log("Harness.setBuildInfo.3.C.Exception");

[0156] 50}

[0157] 51}

[0158] 52 public static void main(String[] args) {

[0159] 53 __RouteTrace.Log("Harness.main.1");

[0160] 54 setBuildInfo();

[0161] 55 __RouteTrace.Log("Harness.main.2");

[0162] 56 (new Bar()).bar();

[0163] 57 __RouteTrace.Log("Harness.main.3");

[0164] 57}

[0165] 58}

[0166] In the above instrumentation program, the call to the function __RouteTrace.Log is an exception path tracing instruction, which is used to record the execution path of the program when it is executed. Different parameters of the function __RouteTrace.Log represent four different instructions:

[0167] The first type is the ordinary path tracing instruction, and its parameters include the location where the current instruction is executed. The location where the current instruction is executed is composed of the class name where the instruction is located, the function name where it is located, and the position number within the function. The class name, function name, and position number are separated by the delimiter "." For example, the parameter "Foo.foo1.2" on line 06 of the above example instrumentation program corresponds to the ordinary path tracing instruction called by the function __RouteTrace.Log. The parameter itself corresponds to an ordinary path node, where Foo is the class name, foo1 is the function name, and 2 is the position number.

[0168] The second type is the exception capture path tracing instruction, and its parameters include the location where the current instruction is executed, the exception capture indicator, and the type of the captured exception. The location where the current instruction is executed is the same as the aforementioned ordinary path tracing instruction and will not be elaborated here. The location where the current instruction is executed, the exception capture indicator, and the type of the captured exception are separated by the delimiter "." The exception capture indicator is represented by the character C. For example, the parameter "Foo.foo1.3.C.IOException" on line 08 of the above example instrumentation program corresponds to the exception capture path tracing instruction called by the function __RouteTrace.Log. The parameter itself corresponds to an exception capture path node, where Foo is the class name, foo1 is the function name, 3 is the position number, C is the exception capture indicator, and IOException represents the type of the captured exception.

[0169] The third type is the exception throw path tracing instruction, and its parameters include the location where the current instruction is executed, the exception throw indicator, and the type of the thrown exception. The location where the current instruction is executed is the same as the aforementioned ordinary path tracing instruction and will not be elaborated here. The location where the current instruction is executed, the exception throw indicator, and the type of the thrown exception are separated by the delimiter "." The exception throw indicator is represented by the character T. For example, the parameter "className.methodName.13.T.Exception" corresponds to the exception throw path tracing instruction called by the function __RouteTrace.Log. The parameter itself corresponds to an exception throw path node, where className is the class name, methodName is the function name, 13 is the position number, T is the exception throw indicator, and Exception represents the type of the thrown exception.

[0170] The fourth type is the abnormal re-throw path tracking instruction, and its parameters include the location where the current instruction is executed, the abnormal re-throw indicator, and the type of the re-thrown exception. The location where the current instruction is executed is the same as that of the aforementioned ordinary path tracking instruction, which will not be elaborated here. The location where the current instruction is executed, the abnormal re-throw indicator, and the type of the re-thrown exception are separated by the delimiter "." The abnormal re-throw indicator is represented by the character L. For example, the parameter "Foo.foo1.5.L.IOException" on the 12th line of the above example instrumentation program corresponds to the abnormal re-throw path tracking instruction for the function __RouteTrace.Log call, and the parameter itself corresponds to the abnormal re-throw path node. Among them, Foo is the class name, foo1 is the function name, 5 is the location serial number, L is the abnormal re-throw indicator, and IOException represents the type of the thrown exception.

[0171] The difference between the abnormal throw path tracking instruction and the abnormal re-throw path tracking instruction is that the latter is located within the program block that processes the exception defined by the catch statement for catching the exception.

[0172] The output of the abnormal path tracking instruction is usually saved in a file. Specifically, in the example of the above instrumentation program, after the function __RouteTrace.Log is called, its parameters are output in text format to a file.

[0173] According to the example of the above instrumentation program, inserting the abnormal path tracking instruction follows the following rules:

[0174] At least one abnormal path tracking instruction is inserted before and after each statement of the original program;

[0175] One abnormal path tracking instruction is inserted after the catch statement for exception capture, and the inserted abnormal path tracking instruction is the abnormal capture path tracking instruction;

[0176] If the abnormal throw throw statement is within the catch statement block, the abnormal path tracking instruction inserted before the abnormal throw throw statement is the abnormal re-throw path tracking instruction, otherwise it is the abnormal throw path tracking instruction.

[0177] The abnormal path tracking instructions inserted in other positions are ordinary path tracking instructions.

[0178] According to the above instrumentation rules, those skilled in the art can easily implement the above instrumentation, and the specific process will not be elaborated here.

[0179] According to the main idea of the method for generating an assembly for system exception handling testing of the present invention, refer to Figure 1, the method for generating an assembly for system exception handling test in this embodiment includes the following steps: mutated assembly initialization step, seed selection step, seed mutation step, analysis step of the exception handling chain of the mutated program, step of adding the mutated program to the mutated assembly, loop iteration processing step, and assembly output step.

[0180] The mutated assembly initialization step is used to construct an initial mutated assembly according to the instrumented program corresponding to the original program. The mutated assembly is a collection of mutated program information. The mutated program information includes program code, execution path, and a set of exception handling chain information. The exception handling chain information includes the exception handling chain and the function call stack. Among them, the execution path, the exception handling chain, and the function call stack all need to be obtained by executing the program. The initial mutated assembly includes one piece of mutated program information. The program code in this mutated program information is the instrumented program input in the aforementioned step S1 or the instrumented program obtained after instrumenting the input original program. The execution path is the output after executing the exception path tracking instruction. For example, the execution path output by the call of the function __RouteTrace.Log after the instrumented program in the above example is executed is as follows:

[0181] 01 Harness.main.1

[0182] 02 Harness.setBuildInfo.1

[0183] 03 Harness.setBuildInfo.3.C.Exception

[0184] 04 Harness.main.2

[0185] 05 Bar.bar.1

[0186] 06 Foo.foo3.1

[0187] 07 Foo.foo2.1

[0188] 08 Foo.foo1.1

[0189] 09 Foo.foo1.3.C.IOException

[0190] 10 Foo.foo1.4

[0191] 11 Foo.foo1.5.L.IOException

[0192] 12 Bar.bar.3.C.IOException

[0193] 13 Bar.bar.4

[0194] 14 Harness.main.3

[0195] In the above execution path, each line is represented as a path node.

[0196] The exception handling chain and the function call stack are obtained by analysis based on the instrumentation program and the execution path. Therefore, the specific process of the mutant program set initialization step is the aforementioned step S2. Execute the instrumentation program according to the test input, obtain the execution path of the instrumentation program through the inserted exception path tracking instructions, and then extract the exception handling chain and the function call stack from the instrumentation program and the execution path to form the exception handling chain information, and then form the exception handling chain information set. Then, add the instrumentation program, the execution path, and the exception handling chain information set to the mutant program set.

[0197] The exception handling chain information set is a set of exception handling chain information. The exception handling chain information includes the exception handling chain and the function call stack. The exception handling chain is a sequence of exception handling nodes arranged in the order of exception handling execution. The specific process of constructing the exception handling chain in this embodiment is as follows:

[0198] Step S211, initialize the path node status to be empty and the current exception handling chain to be empty;

[0199] Step S212, traverse the path nodes in sequence for the execution path, and process the traversed path nodes as follows:

[0200] If the path node is an exception throwing path node, if the current exception handling chain is not empty, then add the current exception handling chain to the exception handling chain set and set the current exception handling chain to be empty, then mark the path node status as the exception throwing status, and record the position of the exception throwing path node in the execution path;

[0201] If the path node is an exception catching path node, if the current path node status is the exception catching status, if the current exception handling chain is not empty, then add the current exception handling chain to the exception handling chain set and set the current exception handling chain to be empty, then construct an exception handling node, and add the constructed exception handling node to the current exception handling chain, and mark the path node status as the exception catching status;

[0202] If the path node is an exception catching path node, if the current path node status is not the exception catching status, then construct an exception handling node, and add the constructed exception handling node to the current exception handling chain, and mark the path node status as the exception catching status;

[0203] If the path node is an exception continuation path node, and if the current path node state is an exception capture state, then the path node state is marked as an exception continuation state, and the position of the exception continuation path node in the execution path is recorded;

[0204] Step S213, after all path nodes of the execution path are traversed, if the current path node state is an exception throwing state or an exception continuation throwing state, or the last path node of the execution path is inconsistent with the exception path tracking instruction inserted at the end of the stub program, then an exception handling node is constructed and the constructed exception handling node is added to the current exception handling chain.

[0205] In the above processing, there are four states of the path node: empty, exception throwing state, exception continuation throwing state, and exception capture state. If the path node is an exception capture path node, and the current path node state is not in the exception capture state, the current path node state may be empty, or it may be in the normal throwing state or the exception continuation throwing state. If the current path node state is empty, it means that the exception is implicitly thrown. For example, in the execution path of the above example, the path node "Harness.setBuildInfo.3.C.Exception" in line 02 is an exception capture path node, corresponding to the implicit exception throw of the methodThrowIOException function. If the current path node state is empty, it means that the exception is explicitly thrown. For example, in the above execution path, the path node "Bar.bar.3.C.IOException" in line 12 is an exception capture path node. According to the path node "Foo.foo1.5.L.IOException" in line 11 of the previous sequence, it is an exception continuation throwing path node. At line 12, the current path node state is in the exception continuation throwing state, corresponding to the instruction "throw e" in line 13 of the above example stub program.

[0206] In the above processing, the exception handling node is constructed when the path node is an exception capture path node. Therefore, the exception handling node corresponds to the process of throwing to capturing each exception. The exception handling node includes exception throwing information and exception capture information. The exception throwing information includes the location where the exception is thrown and the type of the thrown exception. The exception capture information includes the location where the exception is captured and the type of the captured exception. The location where the exception is thrown and the location where the exception is captured include the location in the execution path and the location in the program code.

[0207] In this embodiment, when constructing an exception handling node, the line where the current path node is located serves as the position of the caught exception of the exception handling node in the execution path, and the current path node serves as the position of the caught exception of the exception handling node in the program code; if the status of the current path node is empty or in the exception-catching state, then the previous line of the current path node is used as the position of the thrown exception of the exception handling node in the execution path, and the previous path node of the current path node is used as the position of the thrown exception of the exception handling node in the program code; if the status of the current path node is in the exception-throwing state or the exception-rethrowing state, then the position of the recorded exception-throwing path node in the execution path or the position of the recorded exception-rethrowing path node in the execution path is used as the position of the thrown exception of the exception handling node in the execution path, and the recorded exception-throwing path node or the exception-rethrowing path node itself is used as the position of the thrown exception of the exception handling node in the program code. Specifically, in the execution path of the foregoing example:

[0208] According to the path node "Harness.setBuildInfo.3.C.Exception" on line 03, which is an exception-catching path node, an exception handling node can be constructed. When constructing this exception handling node, the status of the current path node is empty. Therefore, the position of the thrown exception of this exception handling node in the execution path is the previous line, that is, line 02, and the position of the thrown exception in the program code is the previous path node, that is, "Harness.setBuildInfo.1", the position of the caught exception in the execution path is line 03, and the position of the caught exception in the program code is "Harness.setBuildInfo.3.C.Exception".

[0209] According to the path node "Foo.foo1.3.C.IOException" on line 09, which is an exception-catching path node, an exception handling node can be constructed. When constructing this exception handling node, the status of the current path node is in the exception-catching state. Therefore, the position of the thrown exception of this exception handling node in the execution path is the previous line, that is, line 08, and the position of the thrown exception in the program code is the previous path, that is, "Foo.foo1.1", the position of the caught exception in the execution path is line 09, and the position of the caught exception in the program code is "Foo.foo1.3.C.IOException".

[0210] Based on the path node "Bar.bar.3.C.IOException" at line 12 being an exception-catching path node, an exception handling node can be constructed. When constructing this exception handling node, the current path node state is the exception re-throwing state. Thus, the position of the thrown exception in the execution path is at line 11 where the exception re-throwing path node "Foo.foo1.5.L.IOException" is located, the position of the thrown exception in the program code is the exception re-throwing path node "Foo.foo1.5.L.IOException", the position of the caught exception in the execution path is at line 12, and the position of the caught exception in the program code is "Bar.bar.3.C.IOException".

[0211] According to the above processing and the example of the above execution path, two exception handling chains can be constructed: the first exception handling chain and the second exception handling chain. The first exception handling chain includes the exception handling node constructed based on the exception-catching path node at line 03. The second exception handling chain includes two exception handling nodes constructed based on the exception-catching path nodes at line 09 and line 12.

[0212] It should be noted that the path node corresponds to the call parameter of the function __RouteTrace.Log inserted by the instrumentation program. Obviously, each call parameter of the function __RouteTrace.Log inserted by the instrumentation program exists uniquely in the instrumentation program. Therefore, the corresponding position of the instrumentation program can be found according to the path node. For example, based on the positions of the thrown exceptions in the program code mentioned above, such as "Harness.setBuildInfo.1" and "Foo.foo1.1", it is easy to find the corresponding positions in the instrumentation program through text search: the thrown exception statement "methodThrowIOException();" at line 05 and line 46; based on the position of the thrown exception in the program code "Foo.foo1.5.L.IOException" mentioned above, it is easy to find the corresponding position in the instrumentation program through text search: the thrown exception statement "throw e;" at line 13; the positions of the caught exceptions in the program code "Harness.setBuildInfo.3.C.Exception", "Foo.foo1.3.C.IOException", and "Bar.bar.3.C.IOException" are easy to find the corresponding positions in the instrumentation program through text search: the catch statements for catching exceptions at line 48, line 7, and line 35.

[0213] In addition, step S213 corresponds to the case where an exception is thrown, but the instrumentation program itself does not catch the exception, and instead the platform system catches the exception. In this case, an exception handling node for an uncaught exception is constructed. For example, in the aforementioned instrumentation program, if there are no try and catch statements on lines 31 and 35, the execution path output by the instrumentation program is as follows:

[0214] 01 Harness.main.1

[0215] 02 Harness.setBuildInfo.1

[0216] 03 Harness.setBuildInfo.3.C.Exception

[0217] 04 Harness.main.2

[0218] 05 Bar.bar.1

[0219] 06 Foo.foo3.1

[0220] 07 Foo.foo2.1

[0221] 08 Foo.foo1.1

[0222] 09 Foo.foo1.3.C.IOException

[0223] 10 Foo.foo1.4

[0224] 11 Foo.foo1.5.L.IOException

[0225] At this time, after traversing all the path nodes of the execution path, the current path node state corresponds to the exception continuation throwing state, indicating that the instrumentation program execution has thrown an exception but has not been caught by the instrumentation program. At this time, an exception handling node needs to be constructed. When constructing this exception handling node, the position of the recorded exception continuation throwing path node in the execution path, which is line 11, is used as the position of the thrown exception of this exception handling node in the execution path; the recorded exception continuation throwing path node "Foo.foo1.5.L.IOException" is used as the position of the thrown exception of the exception handling node in the program code. The positions of the caught exception of the exception handling node in the execution path and in the program code are set to null. The null positions of the caught exception in the execution path and in the program code indicate that the exception corresponding to this exception handling node has not been caught by the program code.

[0226] For another example, in the aforementioned instrumentation program, if there are no try and catch statements on lines 44 and 48, the execution path output by the instrumentation program is as follows:

[0227] 01 Harness.main.1

[0228] 02 Harness.setBuildInfo.1

[0229] At this time, after traversing all the path nodes of the execution path, the status of the current path node is empty. However, the last path node of the execution path, "Harness.setBuildInfo.1", is inconsistent with the exception path tracing instruction "__RouteTrace.Log(\"Harness.main.3\")" inserted at the end of the instrumentation program. This indicates that an exception was thrown during the execution of the instrumentation program but not caught by the instrumentation program. At this time, an exception handling node needs to be constructed. When constructing this exception handling node, the last path node of the execution path, "Harness.setBuildInfo.1", and its line number are used as the positions of the thrown exception in the program code and in the execution path for this exception handling node. The positions of the caught exception in the execution path and in the program code of the exception handling node are set to empty.

[0230] In addition, in this embodiment, the exception handling node also includes the processing information after exception capture. The processing information after exception capture mainly targets two functions in the Java programming language for exception handling: addSuppressed for exception suppression and initCause for exception redefinition. Other programming languages may not have the addSuppressed and initCause mechanisms, and there is no need to record the processing information after exception capture. Therefore, in the exception handling node, the processing information after exception capture is non-essential information.

[0231] The function call stack in the exception handling chain information is the function call relationship stack where the exception corresponding to the exception handling chain was initially thrown. More specifically, the function call stack is the function call stack of the function where the first exception handling node in the exception handling chain throws an exception. For example, in the aforementioned example of the execution path, two exception handling chains are constructed: the first exception handling chain and the second exception handling chain. The first exception handling node of the first exception handling chain is the exception handling node constructed based on the exception capture path node "Harness.setBuildInfo.3.C.Exception" on line 03 of the execution path. The function where this exception handling node throws an exception is: Harness.setBuildInfo, and the function that initially throws the exception is methodThrowIOException. The corresponding function call stack is as follows:

[0232] methodThrowIOException

[0233] Harness.setBuildInfo

[0234] Harness.main

[0235] Similarly, the first exception handling node of the second exception handling chain is an exception handling node constructed based on the exception capture path node "Foo.foo1.3.C.IOException" at line 09 of the execution path. The function where the exception is thrown by this exception handling node is Foo.foo1, and the function that initially throws the exception is methodThrowIOException. The corresponding function call stack is as follows:

[0236] methodThrowIOException

[0237] Foo.foo1

[0238] Foo.foo2

[0239] Foo.foo3

[0240] Bar.bar

[0241] Harness.main

[0242] The exception handling chain information corresponds to the exception handling chain. From the above example, it can be known that multiple exception handling chains may be obtained through the analysis of the instrumented program and the execution path, and thus multiple exception handling chain information can be correspondingly obtained. Multiple exception handling chain information constitutes an exception handling chain information set. In the mutant program set initialization step, the mutant program set is initialized into a mutant program information set including one mutant program information. The program code of this mutant program information is the aforementioned instrumented program, and the execution path is the output of the exception path tracking instruction inserted by the instrumented program.

[0243] The seed selection step is used to select a seed for the subsequent program mutation step. This step is the aforementioned step S3. Using the number of exception handling nodes in the mutation program information as a probability factor, a mutation program information is randomly selected from the mutation program set as the seed. Since the mutation program information includes program code, execution path, and exception handling chain information set, therefore, the seed includes program code, execution path, and exception handling chain information set. "Using the number of exception handling nodes in the mutation program information as a probability factor" in step S3 means that when randomly selecting a seed, it is selected according to a certain selection probability, and this selection probability is related to the number of exception handling nodes. Here, the selection probability is the probability of selecting a certain mutation program information. In this embodiment, the probability of selecting a certain mutation program information is: P(i)=B(i) / Sigma(B(i)). Among them, P(i) is the selection probability of the i-th mutation program information in the mutation program set, B(i) is the probability distribution value of the i-th mutation program information in the mutation program set, Sigma(B(i)) represents the sum of the probability distribution values of each mutation program information in the mutation program set, and the probability distribution value B(i) is a monotonically increasing function of the number of exception handling nodes in the i-th mutation program information.

[0244] The probability distribution value B(i) can be expressed as a function: B(i)=f(N(i)); where N(i) is the number of exception handling nodes in the i-th mutation program information; the function f is monotonically increasing in the interval not less than 0. Those skilled in the art understand that there are many such functions, such as the square function f(x)= square(x), the exponential function f(x)=exp(x), etc. In this embodiment, the square function is preferably used, that is, B(i)=square(N(i)).

[0245] The seed mutation step is used to randomly mutate the seed program. Here, the seed program is the program code of the seed. This step is the aforementioned step S4, specifically: randomly select an exception handling chain information in the exception handling chain set of the seed as the seed exception handling chain information, and randomly select a mutation method to randomly mutate the program code of the seed to obtain a mutated program. The mutation methods include adding an exception capture block, deleting an exception capture block, swapping exception capture blocks, modifying the exception capture range, modifying the type of exception handling, deleting exception throws, and implanting exception throw captures.

[0246] Adding an exception capture block means adding a statement block for exception capture. The mutation of adding an exception capture block is based on the function call stack of the seed exception handling chain information. Specifically, a function is randomly selected from the function call stack, and a statement block for exception capture is added to the call of this function. For example, in the aforementioned example, the randomly selected exception handling chain information corresponds to the second exception handling chain, and the function randomly selected from the function call stack corresponding to this exception handling chain is: methodThrowIOException. Therefore, a statement block for exception capture is added to the call Foo.foo1 of this function. After adding the statement block for exception capture, the function Foo.foo1 mutates into, for example:

[0247] void foo1() throws IOException {

[0248] try {

[0249] __RouteTrace.Log("Foo.foo1.1");

[0250] methodThrowIOException();

[0251] __RouteTrace.Log("Foo.foo1.2");

[0252] } catch (IOException e) {

[0253] __RouteTrace.Log("Foo.foo1.3.C.IOException");

[0254] RuntimeException er = new RuntimeException();

[0255] __RouteTrace.Log("Foo.foo1.4");

[0256] e.initCause(er);

[0257] __RouteTrace.Log("Foo.foo1.5.L.IOException");

[0258] throw e;

[0259] } catch (NullPointerException e) {

[0260] {

[0261] __RouteTrace.Log("Foo.foo1.6.C.NullPointerException");

[0262] }

[0263] }

[0264] Note that when inserting mutant code, it is necessary to re-insert the exception path tracing instruction for the mutated code.

[0265] Deleting the exception capture block means deleting the statement block for exception capture. The mutation of deleting the exception capture block is based on the exception handling nodes in the exception handling chain. Specifically, randomly select an exception handling node in the exception handling chain where the exception capture position is not null, and delete the corresponding statement block for capturing the exception. For example, in the previous example, the randomly selected exception handling chain information corresponds to the first exception handling chain, and this exception handling chain includes only one exception handling node where the exception capture position is not null. Thus, based on the position of the exception capture in the program code "Harness.setBuildInfo.3.C.Exception", find the corresponding try and catch statements and delete the relevant statement blocks. After deletion, the Harness.setBuildInfo function is mutated to:

[0266] private static void setBuildInfo() {

[0267] __RouteTrace.Log("Harness.setBuildInfo.1");

[0268] methodThrowIOException();

[0269] __RouteTrace.Log("Harness.setBuildInfo.2");

[0270] }

[0271] Swapping the exception capture blocks means swapping the contents of the catch statement blocks. According to the mutated example of the function Foo.foo1 mentioned above, it includes two catch statement blocks. After swapping, the following program block can be obtained:

[0272] void foo1() throws IOException {

[0273] try {

[0274] __RouteTrace.Log("Foo.foo1.1");

[0275] methodThrowIOException();

[0276] __RouteTrace.Log("Foo.foo1.2");

[0277] } catch (IOException e) {

[0278] __RouteTrace.Log("Foo.foo1.3.C.IOException");

[0279] } catch (NullPointerException e) {

[0280] {

[0281] __RouteTrace.Log("Foo.foo1.4.C.NullPointerException");

[0282] RuntimeException er = new RuntimeException();

[0283] __RouteTrace.Log("Foo.foo1.5");

[0284] e.initCause(er);

[0285] __RouteTrace.Log("Foo.foo1.6.L.IOException");

[0286] throw e;

[0287] }

[0288] }

[0289] Modify the exception capture scope, that is, modify the scope covered by the try statement, which is divided into two cases: the first is to modify the start scope of the try statement, and the second is to modify the end scope of the try statement. For example, for the exception handling try block corresponding to the first exception handling chain mentioned above, after modifying the start scope of the try statement, it can be modified to:

[0290] private static void setBuildInfo() {

[0291] __RouteTrace.Log("Harness.setBuildInfo.1");

[0292] methodThrowIOException();

[0293] try {

[0294] __RouteTrace.Log("Harness.setBuildInfo.2");

[0295] } catch (Exception e) {

[0296] __RouteTrace.Log("Harness.setBuildInfo.3.C.Exception");

[0297] }

[0298] }

[0299] After modifying the end range of the try statement, it can be modified to:

[0300] private static void setBuildInfo() {

[0301] try {

[0302] __RouteTrace.Log("Harness.setBuildInfo.1");

[0303] } catch (Exception e) {

[0304] __RouteTrace.Log("Harness.setBuildInfo.2.C.Exception");

[0305] }

[0306] __RouteTrace.Log("Harness.setBuildInfo.3");

[0307] methodThrowIOException();

[0308] }

[0309] When modifying the exception capture range, the start range of the try statement can be obtained by searching forward for the try statement based on the position of the thrown exception corresponding to the exception handling node in the program code.

[0310] Modify the type of exception handling, that is, modify the type of exception in the catch statement. For example, in the program block corresponding to the first exception handling chain mentioned above, modifying the exception type in the catch statement can obtain:

[0311] private static void setBuildInfo() {

[0312] try {

[0313] __RouteTrace.Log("Harness.setBuildInfo.1");

[0314] methodThrowIOException();

[0315] __RouteTrace.Log("Harness.setBuildInfo.2");

[0316] } catch (RuntimeException e) {

[0317] __RouteTrace.Log("Harness.setBuildInfo.3.C.RuntimeException");

[0318] }

[0319] }

[0320] Delete the exception throw, that is, delete the throw exception throw statement among them. For example, after deleting the exception throw instruction in the instrumentation program function Foo.foo1 in the above example, the following program block can be obtained:

[0321] void foo1() throws IOException {

[0322] try {

[0323] __RouteTrace.Log("Foo.foo1.1");

[0324] methodThrowIOException();

[0325] __RouteTrace.Log("Foo.foo1.2");

[0326] } catch (IOException e) {

[0327] __RouteTrace.Log("Foo.foo1.3.C.IOException");

[0328] RuntimeException er = new RuntimeException();

[0329] __RouteTrace.Log("Foo.foo1.4");

[0330] e.initCause(er);

[0331] }

[0332] }

[0333] Exception implantation and throwing capture is used to implant a statement block that throws an exception and catches the thrown exception. Different from other mutation methods, the purpose of exception implantation and throwing capture is to add an exception handling chain, while the mutations of other mutation methods are targeted at the information of the selected seed exception handling chain. For example, in the previous example, adding a random exception implantation and throwing capture statement block in Foo.foo2, the resulting mutated block is as follows:

[0334] char foo2() throws IOException {

[0335] try {

[0336] __RouteTrace.Log("Foo.foo2.1.T.NullPointerException");

[0337] throw new NullPointerException();

[0338] } catch (NullPointerException e)

[0339] {

[0340] }

[0341] __RouteTrace.Log("Foo.foo2.2");

[0342] foo1();

[0343] __RouteTrace.Log("Foo.foo2.3");

[0344] return 'a';

[0345] }

[0346] The analysis steps of the exception handling chain of the mutant program, that is, step S5, are specifically as follows: Execute the mutant program according to the test input, obtain the execution path of the mutant program through the inserted exception path tracking instructions, then extract the exception handling chain and function call stack from the mutant program and the execution path to form the exception handling chain information, and further form the exception handling chain information set, and find the mutant exception handling chain information corresponding to the seed exception handling chain information from the exception handling chain information set.

[0347] Step S5 can be divided into two steps:

[0348] Step S51: Execute the mutant program according to the test input, obtain the execution path of the mutant program through the inserted exception path tracking instructions, then extract the exception handling chain and function call stack from the mutant program and the execution path to form the exception handling chain information, and further form the exception handling chain information set;

[0349] Step S52: Find the mutant exception handling chain information corresponding to the seed exception handling chain information from the exception handling chain information set.

[0350] Among them, step S51 is the same as the aforementioned mutant program set initialization step, and the mutant program in step S51 is the instrumented program in step S2. The difference between step S51 and the mutant program set initialization step is only that when step S51 is executed, the mutant program set is not empty.

[0351] The purpose of step S52 is to find the mutant exception handling chain information on the same exception handling chain as the seed exception handling chain information in the program codes before and after mutation. Specifically, it is only necessary to compare whether the statements that initially throw exceptions in the two exception handling chains are the same. The statement that initially throws an exception in the exception handling chain is also the throw exception statement corresponding to the position of the throw exception of the first exception handling node in the program code.

[0352] The step of adding the mutated program to the mutated program set, that is, the aforementioned step S6. If the number of exception handling chain information of the mutated program is not less than the number of exception handling chain information of the seed, and the number of exception handling nodes in the mutated exception handling chain information is not less than the number of exception handling nodes in the seed exception handling chain information, then the mutated program, the execution path of the mutated program, and the set of exception handling chain information of the mutated program are added to the mutated program set. Among them, if the number of exception handling chain information of the mutated program is not less than the number of exception handling chain information of the seed, and the number of exception handling nodes in the mutated exception handling chain information is not less than the number of exception handling nodes in the seed exception handling chain information, it is the adaptability of the exception handling chain. The number of exception handling chains and the number of exception handling nodes in the exception handling chain can be regarded as the complexity of exception handling. Obviously, the more the number of exception handling chains and the more the number of exception handling nodes in the exception handling chain, the more complex the exception handling of the program. The adaptability condition of the exception handling chain means that if the exception handling complexity of the mutated program after mutation is higher than that of the seed program before mutation, the mutated program is typed into the mutated program set, otherwise it is discarded.

[0353] The loop iteration processing step, that is, the aforementioned step S7, repeats steps S3 to S6 until the end condition is met. The loop iteration processing step is used to determine whether the loop iteration meets the end condition. If the end condition is met, the loop of steps S3 to S6 ends, otherwise the loop process continues. The end conditions include that the execution time reaches the limit condition and the number of mutated program information in the mutated program set reaches the limit requirement. These two end conditions can be used alone as the condition for judging whether to end the loop, or can be combined as the condition for judging whether to end the loop.

[0354] The program set output step, that is, the aforementioned step S8, extracts the program codes of each mutated program information from the mutated program set to form a program set as the output. The program set output by step S8 is also the output of the present invention. After obtaining these program sets, programmers can test the differences in exception handling between different platform systems based on these program sets.

[0355] In addition, it should be noted that the example of the original program in this embodiment uses program source code. Those skilled in the art understand that in the actual processing process, the program source code in the example can also be replaced with intermediate code. For example, the source code written in the Java language in the example can also be converted into the bytecode of the class file through a compilation tool. At this time, the instrumentation and mutation processes can be directly based on the bytecode of the class file.

[0356] In addition, the device referred to in the present invention corresponds to the virtual device of the aforementioned method, and the modules it contains correspond to the steps of the method, which will not be elaborated here.

Claims

1. A method for generating an assembly for system exception handling testing, characterized in that, it includes the following steps: Step S1, for: obtaining the original program and test input, and obtaining the instrumented program after inserting exception path tracking instructions into the original program; Step S2, for: executing the instrumented program according to the test input, obtaining the execution path of the instrumented program through the inserted exception path tracking instructions, then extracting the exception handling chain and function call stack from the instrumented program and the execution path to form exception handling chain information, and further forming a set of exception handling chain information. Then, adding the instrumented program, the execution path, and the set of exception handling chain information to the mutant program set; The mutant program set is a set of mutant program information; The mutant program information includes program code, execution path, and a set of exception handling chain information; The exception handling chain information includes an exception handling chain and a function call stack; The exception handling chain is a sequence of exception handling nodes arranged in the order of exception handling execution; The exception handling nodes include the position where the exception is thrown, the type of the exception thrown, the position where the exception is caught, and the type of the exception caught; The position where the exception is thrown and the position where the exception is caught include the position in the execution path and the position in the program code; The function call stack is the function call relationship stack where the exception corresponding to the exception handling chain is initially thrown; Step S3, for: using the number of exception handling nodes in the mutant program information as a probability factor, randomly selecting one piece of mutant program information from the mutant program set as a seed; Step S4, for: randomly selecting one piece of exception handling chain information from the set of exception handling chains of the seed as the seed exception handling chain information, and randomly selecting a mutation method to randomly mutate the program code of the seed to obtain a mutant program; Step S5, for: executing the mutant program according to the test input, obtaining the execution path of the mutant program through the inserted exception path tracking instructions, then extracting the exception handling chain and function call stack from the mutant program and the execution path to form exception handling chain information, and further forming a set of exception handling chain information, and finding the corresponding mutant exception handling chain information in the set of exception handling chain information for the seed exception handling chain information; Step S6, for: if the number of exception handling chain information of the mutant program is not less than the number of exception handling chain information of the seed and the number of exception handling nodes in the mutant exception handling chain information is not less than the number of exception handling nodes in the seed exception handling chain information, then adding the mutant program, the execution path of the mutant program, and the set of exception handling chain information of the mutant program to the mutant program set; Step S7, for: repeating steps S3 to S6 until the end condition is met; Step S8, for: extracting the program code of each piece of mutant program information from the mutant program set to form a program set as the output; "Extracting the exception handling chain" includes the following steps: Step S211, for: initializing the path node status to be empty and the current exception handling chain to be empty; Step S212 is used for: traversing the path nodes of the execution path in sequence and processing the traversed path nodes as follows: If the path node is an exception - throwing path node, and if the current exception - handling chain is not empty, then add the current exception - handling chain to the exception - handling chain set and empty the current exception - handling chain. Then, mark the status of the path node as the exception - throwing status, and record the position of the exception - throwing path node in the execution path; If the path node is an exception - catching path node, and if the status of the current path node is the exception - catching status, and if the current exception - handling chain is not empty, then add the current exception - handling chain to the exception - handling chain set and empty the current exception - handling chain. Then, construct an exception - handling node and add the constructed exception - handling node to the current exception - handling chain, and mark the status of the path node as the exception - catching status; If the path node is an exception - catching path node, and if the status of the current path node is not the exception - catching status, then construct an exception - handling node and add the constructed exception - handling node to the current exception - handling chain, and mark the status of the path node as the exception - catching status; If the path node is an exception - re - throwing path node, and if the status of the current path node is the exception - catching status, then mark the status of the path node as the exception - re - throwing status, and record the position of the exception - re - throwing path node in the execution path; Step S213 is used for: after all the path nodes of the execution path are traversed, if the status of the current path node is the exception - throwing status or the exception - re - throwing status, or if the last path node of the execution path is inconsistent with the exception path - tracking instruction inserted at the end of the instrumentation program, then construct an exception - handling node and add the constructed exception - handling node to the current exception - handling chain.

2. The method for generating an assembly for system exception - handling testing according to claim 1, characterized in that, in step S3, when randomly selecting seeds, the probability of selecting mutant program information is: P(i)=B(i) / Sigma(B(i)); where P(i) is the selection probability of the i - th mutant program information in the mutant program set, B(i) is the probability distribution value of the i - th mutant program information in the mutant program set, and Sigma(B(i)) represents the sum of the probability distribution values of all mutant program information in the mutant program set; the probability distribution value B(i) is a monotonically increasing function of the number of exception - handling nodes in the i - th mutant program information.

3. The method for generating an assembly for system exception - handling testing according to claim 1, characterized in that, the mutation methods include adding an exception - catching block, deleting an exception - catching block, swapping exception - catching blocks, modifying the exception - catching range, modifying the type of exception - handling, deleting exception - throwing, and implanting exception - throwing and catching.

4. The method for generating an assembly for system exception - handling testing according to claim 1, characterized in that, the end conditions include that the execution time reaches the specified condition and the number of mutant program information in the mutant program set reaches the specified requirement.

5. An assembly generation device for system exception - handling testing, characterized in that, comprises the following modules: Module M1, for: obtaining the original program and test input, and inserting exception path tracking instructions into the original program to obtain an instrumented program; Module M2, for: executing the instrumented program according to the test input, obtaining the execution path of the instrumented program through the inserted exception path tracking instructions, then extracting an exception handling chain and a function call stack from the instrumented program and the execution path to form exception handling chain information, further forming a set of exception handling chain information, and then adding the instrumented program, the execution path, and the set of exception handling chain information to the mutant program set; The mutant program set is a set of mutant program information; The mutant program information includes program code, execution path, and a set of exception handling chain information; The exception handling chain information includes an exception handling chain and a function call stack; The exception handling chain is a sequence of exception handling nodes arranged in the order of exception handling execution; The exception handling node includes the location where the exception is thrown, the type of the exception thrown, the location where the exception is caught, and the type of the exception caught; The location where the exception is thrown and the location where the exception is caught include the location in the execution path and the location in the program code; The function call stack is the function call relationship stack where the exception corresponding to the exception handling chain is initially thrown; Module M3, for: using the number of exception handling nodes in the mutant program information as a probability factor, randomly selecting one piece of mutant program information from the mutant program set as a seed; Module M4, for: randomly selecting one piece of exception handling chain information from the set of exception handling chains of the seed as the seed exception handling chain information, and randomly selecting a mutation method to randomly mutate the program code of the seed to obtain a mutant program; Module M5, for: executing the mutant program according to the test input, obtaining the execution path of the mutant program through the inserted exception path tracking instructions, then extracting an exception handling chain and a function call stack from the mutant program and the execution path to form exception handling chain information, further forming a set of exception handling chain information, and finding the corresponding mutant exception handling chain information in the set of exception handling chain information for the seed exception handling chain information; Module M6, for: if the number of exception handling chain information of the mutant program is not less than the number of exception handling chain information of the seed and the number of exception handling nodes in the mutant exception handling chain information is not less than the number of exception handling nodes in the seed exception handling chain information, then adding the mutant program, the execution path of the mutant program, and the set of exception handling chain information of the mutant program to the mutant program set; Module M7, for: repeating Modules M3 to M6 until the end condition is met; Module M8, for: extracting the program code of each piece of mutant program information from the mutant program set to form a program set as the output; "Extracting the exception handling chain" includes the following modules: Module M211, for: initializing the path node status to be empty and the current exception handling chain to be empty; Module M212, for: traversing the path nodes in order for the execution path, and processing the traversed path nodes as follows: If the path node is an exception-throwing path node, and if the current exception handling chain is not empty, then add the current exception handling chain to the exception handling chain set and empty the current exception handling chain. Then, mark the status of the path node as the exception-throwing status, and record the position of the exception-throwing path node in the execution path; If the path node is an exception-catching path node, if the current path node status is the exception-catching status, and if the current exception handling chain is not empty, then add the current exception handling chain to the exception handling chain set and empty the current exception handling chain. Then, construct an exception handling node, and add the constructed exception handling node to the current exception handling chain, and mark the status of the path node as the exception-catching status; If the path node is an exception-catching path node, and if the current path node status is not the exception-catching status, then construct an exception handling node, and add the constructed exception handling node to the current exception handling chain, and mark the status of the path node as the exception-catching status; If the path node is an exception-rethrowing path node, and if the current path node status is the exception-catching status, then mark the status of the path node as the exception-rethrowing status, and record the position of the exception-rethrowing path node in the execution path; Module M213 is used for: after all path nodes of the execution path are traversed, if the current path node status is the exception-throwing status or the exception-rethrowing status, or if the last path node of the execution path is inconsistent with the exception path tracking instruction inserted at the end of the instrumentation program, then construct an exception handling node, and add the constructed exception handling node to the current exception handling chain.

6. The program set generation device for system exception handling test as described in claim 5, characterized in that, when randomly selecting seeds in the module M3, the probability of selecting mutant program information is: P(i) = B(i) / Sigma(B(i)); where P(i) is the selection probability of the i-th mutant program information in the mutant program set, B(i) is the probability distribution value of the i-th mutant program information in the mutant program set, and Sigma(B(i)) represents the sum of the probability distribution values of each mutant program information in the mutant program set; the probability distribution value B(i) is a monotonically increasing function of the number of exception handling nodes in the i-th mutant program information.

7. The program set generation device for system exception handling test as described in claim 5, characterized in that, the mutation methods include adding an exception-catching block, deleting an exception-catching block, swapping exception-catching blocks, modifying the exception-catching range, modifying the type of exception handling, deleting exception throwing, and implanting exception throwing and catching.

8. The program set generation device for system exception handling test as described in claim 5, characterized in that, the end conditions include that the execution time reaches the limit condition and the number of mutant program information in the mutant program set reaches the limit requirement.

Images