JP5505227B2 - Repetitive symbolic execution method, program, and apparatus - Google Patents

Description

  The present technology relates to a symbolic execution technology.

  The code coverage is an index indicating how exhaustively the test is performed on the internal structure of the program. Code coverage includes types such as statement coverage, branch coverage, condition coverage, and path coverage. When testing a program, test data and scenarios are designed so that such an index reaches a reference value (for example, 100%).

As an example, consider that a program having a control structure as shown in FIG. 1 is tested and branch coverage is set to 100%. First, test execution is performed using test data {a = 11, b = 1}. The branches B ₁ , B ₃ and B ₄ can then be executed. Further, if the test execution is performed using the test data {a = 10, b = 1}, the branches B ₁ , B ₃ and B ₅ can be executed. Then, in order to execute the remaining branches B ₂ and B ₆ , test execution is performed using the test data {a = 0, b = 0}. In this way, (the number of branches executed) / (the number of all branches) * 100 = 100, and the branch coverage is 100%. However, such a test data set is generally created by humans after understanding the internal structure of the program, which is very time-consuming.

  On the other hand, it is known to test a program using a technique called symbolic execution. Symbolic execution is a technique in which variables in a program are converted into symbols and execution is performed with the symbols as they are. The basic matters regarding symbolic execution are described in detail in, for example, Tetsuo Tamai, Koichi Fukunaga, "Symbol Execution System", Information Processing, pp18-28, 1982/01/15, etc. I want to be.

  Here, consider performing symbolic execution on a program having a control structure as shown in FIG. Since the variable a and variable b exist in this program, the variable a and variable b are symbolized and symbolic execution is performed. FIG. 2 shows a control flow when symbolic execution is performed on this program. As shown in FIG. 2, in symbolic execution, execution is performed for all cases in a branch in a branch involving a symbolized variable. As a result, all six paths in the program can be executed. That is, the path coverage is 100%.

In this way, in the conventional symbolic execution, in principle, all paths are executed (however, if all paths cannot be executed depending on the structure of the program, such as having an infinite loop) There). On the other hand, as long as all branches can be executed, it is not always necessary to execute all paths. For example, in the example of FIG. 1, if three paths “B ₁ → B ₃ → B ₄ ”, “B ₁ → B ₃ → B ₅ ”, and “B ₂ → B ₆ ” are executed, all branches are taken. Can be covered.

  Therefore, when it is sufficient to achieve the reference value for branch coverage or the like, if symbolic execution is performed as in the past, test execution that is not originally performed is performed. If this is a simple program like the example of FIG. 1, there is no problem. However, in the case of a program of a general size, a combination explosion caused by a branch structure in the program occurs, and a huge number of test executions must be performed. Therefore, the time until completion of the test becomes very long. Therefore, since the test execution is continued for a long time even though the test is substantially completed, it is not efficient.

JP 2009-87355 A

  Therefore, the objective of this technique is to provide the technique for testing a program more efficiently using symbolic execution according to one side surface.

  In this iterative symbolic execution method, the symbolic execution unit that executes symbolic execution repeatedly performs symbolic execution while changing the variables to be symbolized so as to cover all variables defined in the analysis target program. The first execution step, the acquisition step of acquiring the code coverage of the analysis target program from the symbolic execution unit and storing it in the execution result storage unit, and the code coverage rate stored in the execution result storage unit satisfy a predetermined standard And a step of storing, in the output data storage unit, data indicating that the test of the analysis target program is completed when it is determined that the code coverage rate satisfies a predetermined criterion.

  It becomes possible to test the program more efficiently by using symbolic execution.

FIG. 1 is a diagram illustrating an example of a control structure of a test program. FIG. 2 is a diagram illustrating an example of a control flow of the test program. FIG. 3 is a system outline diagram according to the present embodiment. FIG. 4 is a diagram illustrating an example of data stored in the default value storage unit. FIG. 5 is a diagram showing a program to be analyzed. FIG. 6 is a diagram showing a main processing flow in the present embodiment. FIG. 7 is a diagram illustrating an example of data stored in the execution data storage unit. FIG. 8 is a diagram illustrating an example of data stored in the execution data storage unit. FIG. 9 is a diagram illustrating an example of data stored in the driver storage unit. FIG. 10 is a diagram illustrating an example of data stored in the driver storage unit. FIG. 11 is a diagram illustrating an example of the driver code. FIG. 12 is a diagram illustrating a processing flow of the coverage rate calculation processing. FIG. 13 is a diagram illustrating an example of data stored in the execution data storage unit. FIG. 14 is a diagram illustrating a processing flow of analysis processing. FIG. 15 is a diagram illustrating an example of data stored in the execution data storage unit. FIG. 16 is a diagram illustrating a process flow of the specific value setting process. FIG. 17 is a diagram illustrating an example of data stored in the sufficiency value storage unit. FIG. 18 is a diagram illustrating an example of data stored in the execution data storage unit. FIG. 19 is a diagram illustrating an example of data stored in the driver storage unit. FIG. 20 is a diagram illustrating an example of data stored in the driver storage unit. FIG. 21 is a diagram illustrating an example of the driver code. FIG. 22 is a functional block diagram of a computer.

  FIG. 3 shows a system outline diagram according to the present embodiment. The example of FIG. 3 includes a repeated execution support device 1, a symbolic execution device 3, and a determination device 5 via a network such as a LAN (Local Area Network).

  The repeated execution support apparatus 1 includes a program storage unit 101, a default value storage unit 102, an extraction unit 103, an execution data storage unit 104, an execution pattern generation unit 105, a driver generation unit 106, and a driver storage unit 107. The execution request unit 108, the coverage rate storage unit 109, the analysis unit 110, the determination request unit 111, the sufficiency value storage unit 112, the output unit 113, and the output data storage unit 114.

  The extraction unit 103 performs processing using the analysis target program stored in the program storage unit 101 and the data stored in the default value storage unit 102, and stores the processing result in the execution data storage unit 104. The execution pattern generation unit 105 performs processing using the data stored in the execution data storage unit 104 to generate an execution pattern and store it in the driver storage unit 107, or instructs the driver generation unit 106 to generate a driver. Process. The driver generation unit 106 generates a driver code corresponding to the execution pattern stored in the driver storage unit 107 and stores it in the driver storage unit 107. The execution request unit 108 performs a process of transmitting a symbolic execution request to the symbolic execution device 3 using the data stored in the driver storage unit 107, and executes the processing result as an execution data storage unit 104 and a coverage rate storage unit. 109 is stored. The analysis unit 110 performs processing using the data stored in the coverage rate storage unit 109 and the execution data storage unit 104, notifies the determination request unit 111 of the processing result, and sends the processing result to the output data storage unit 113. Processing to store is performed. The determination request unit 111 transmits a satisfaction value generation instruction to the determination device 5, or performs a process of updating data stored in the execution data storage unit 104. The output unit 114 performs processing for displaying data stored in the output data storage unit 113 on a display device or the like.

  The symbolic execution device 3 includes an execution unit 31 and a coverage rate calculation unit 32. The execution unit 31 is a module that performs existing symbolic execution, and may be, for example, a Symbolic PathFinder that is an extension of Java (registered trademark) PathFinder. The coverage rate calculation unit 32 calculates a code coverage rate (for example, branch coverage) using the execution result of the symbolic execution by the execution unit 31. The coverage rate calculation unit 32 may use EclEmma (http://www.eclemma.org/), for example. Note that the symbolic execution unit 31 and the coverage rate calculation unit 32 may be realized on Eclipse (http://www.eclipse.org/), for example.

  The determination device 5 is a device that performs satisfiability determination (for example, SAT (SATisfiability) solver, SMT (Satisfiability Modulo Theory) solver, etc.), and a path condition according to a request from the determination request unit 111 in the repeated execution support device 1. Generate a sufficiency value that satisfies (also called a logical constraint). For example, when generation of a sufficiency value that satisfies the path condition “(10 ≧ x) and (5 ≦ x)” is requested, for example, “7” is generated as the sufficiency value.

  FIG. 4 shows an example of data stored in the default value storage unit 102. The example of FIG. 4 includes a variable type column and a default value column.

  Assume that the analysis target program to be processed in this embodiment is the program shown in FIG. The control structure and control flow of this program are those shown in FIGS. In the present embodiment, symbolic execution is performed so that the branch coverage of the program shown in FIG. 5 reaches a predetermined standard (for example, 100%).

  Next, processing contents of the system shown in FIG. 3 will be described with reference to FIGS. First, the extraction unit 103 extracts a variable defined in the analysis target program and the type of the variable from the analysis target program (FIG. 5) stored in the program storage unit 101, and executes the execution data storage unit. 104 (FIG. 6: step S1).

  FIG. 7 shows an example of data stored in the execution data storage unit 104 when Step S1 is performed. In the example of FIG. 7, variables and variable types are stored.

  Further, the extraction unit 103 identifies a specific value corresponding to the variable type extracted in step S1 from the default value storage unit 102 (FIG. 4), and stores it in the execution data storage unit 104 (step S3).

  FIG. 8 shows an example of data stored in the execution data storage unit 104 when Step S3 is performed. In the example of FIG. 8, variables, variable types, and specific values are stored.

  Then, the execution pattern generation unit 105 generates an execution pattern for each of the variables stored in the execution data storage unit 104 (FIG. 8) and stores it in the driver storage unit 107 (step S5).

  FIG. 9 shows an example of data stored in the driver storage unit 107 when Step S5 is performed. As shown in the example of FIG. 9, in the present embodiment, one of the variables defined in the analysis target program is symbolized, and the specific values specified in step S3 are set for the remaining variables. The execution pattern in the first line is an execution pattern in which the variable a is symbolized and the specific value “0” is set in the variable b. The execution pattern on the second line is an execution pattern in which the variable b is symbolized and a specific value “0” is set in the variable a.

  Then, the driver generation unit 106 generates a driver code corresponding to each execution pattern stored in the driver storage unit 107 (FIG. 9), and stores it in the driver storage unit 107 (step S7).

  FIG. 10 shows an example of data stored in the driver storage unit 107 when step S7 is performed. In the example of FIG. 10, an execution pattern and a driver code are stored. Here, driver code 1 is generated for the execution pattern “int a = $, int b = 0”, and driver code 2 is generated for the execution pattern “int a = 0, int b = $”. Has been generated.

  FIG. 11 shows an example of the driver code 1 and the driver code 2. In the present embodiment, the symbolic execution device 3 performs symbolic execution using the driver code as shown in FIG. 11 and the analysis target program.

  Returning to the description of FIG. 6, the execution requesting unit 108 performs a coverage rate calculation process (step S <b> 9). The coverage rate calculation process will be described with reference to FIGS.

  First, the execution request unit 108 symbolizes an execution request including an unprocessed driver code among the driver codes stored in the driver storage unit 107 and the analysis target program stored in the program storage unit 101. 3 (FIG. 12: step S21).

  In response to this, the execution unit 31 in the symbolic execution device 3 performs symbolic execution. In the symbolic execution, the path condition is accumulated every time the symbolized variable passes through the associated path condition among the path conditions defined in the program. For example, when symbolic execution is performed using the driver code 1 and the analysis target program shown in FIG. 11, path conditions “a> 0” and “a ≦ 0” are accumulated. Then, the execution unit 31 repeatedly transmits the execution result including the accumulated path condition to the execution support device 1.

Further, when symbolic execution is performed by the execution unit 31, the coverage rate calculation unit 32 calculates branch coverage. In the symbolic execution device 3, the execution unit 31 manages the path condition passed at the time of symbolic execution using a management table (not shown) so that the control flow of the analysis target program can be grasped using the management table. It has become. The coverage rate calculation unit 32 acquires the number of all branches of the analysis target program using this management table. In the case of the program of FIG. 5, the total number of branches is 6. On the other hand, when the symbolic execution using driver code 1 for analyte program shown in FIG. 5, it is possible to perform the three branches of the branch B _1, B ₂ and B _6. Therefore, the branch coverage is 3/6 * 100≈50 (%).

When symbolic execution is performed using the driver code 1 and then symbolic execution is performed using the driver code 2, further branches B ₂ , B ₃ , B ₅ and B ₆ can be executed. . In this case, when combined with the result of the symbolic execution using the driver code 1, the branches B ₁ , B ₂ , B ₃ , B ₅ and B ₆ can be executed, so that the branch coverage is 5/6 * 100≈ 83 (%). The coverage rate calculation unit 32 repeatedly transmits the branch coverage calculated in this way to the execution support device 1. The coverage rate calculation unit 32 stores the executed branch data in a storage device such as a main memory, and uses it later when calculating branch coverage again.

  On the other hand, the execution request unit 108 of the repeated execution support device 1 receives the path condition from the symbolic execution device 3 and stores it in the execution data storage unit 104, and also receives the branch coverage from the symbolic execution device 3, and the coverage rate storage unit 109 (step S23). The coverage rate storage unit 109 stores the newly received branch coverage so as to update the already received branch coverage.

  FIG. 13 shows an example of data stored in the execution data storage unit 104 when Step S23 is performed. In the example of FIG. 13, variables, types, specific values, and path conditions are stored.

  Then, the execution request unit 108 determines whether there is an unprocessed driver code in the driver storage unit 107 (step S25). If it is determined that there is an unprocessed driver code (step S25: Yes route), the process returns to step S21 to process the unprocessed driver code. On the other hand, when it is determined that there is no unprocessed driver code in the driver storage unit 107 (step S25: No route), the process returns to the original process.

  By acquiring the branch coverage as described above, it is possible to determine whether or not the test of the analysis target program is completed. In addition, since there is one variable to be symbolized, a program test by symbolic execution can be performed even for a program including a nonlinear operation such as multiplication.

  Returning to the description of FIG. 6, the analysis unit 110 determines whether the branch coverage stored in the coverage rate storage unit 109 is 100% (step S <b> 11). It may be determined whether it is not 100% or more than a predetermined reference value.

  When the branch coverage is 100% (step S11: Yes route), the analysis unit 110 generates a test completion message indicating that the program test is completed, and stores it in the output data storage unit 113 (step S17). . Then, the output unit 114 displays the test completion message stored in the output data storage unit 113 on the display device. Then, the process ends.

  On the other hand, when the branch coverage is not 100% (step S11: No route), the analysis unit 110 performs an analysis process (step S13). The analysis process will be described with reference to FIGS.

  First, the analysis unit 110 identifies one unprocessed variable (hereinafter referred to as a variable to be processed) among the variables stored in the execution data storage unit 104 (FIG. 14: step S41). Then, the analysis unit 110 determines whether or not a path condition corresponding to the variable to be processed is stored in the execution data storage unit 104 (step S43). When it is determined that the path condition corresponding to the variable to be processed is not stored (step S43: No route), the analysis unit 110 stores the determination flag “−1” in association with the variable to be processed in the execution data. The data is stored in the unit 104 (step S45).

  On the other hand, when it is determined that a path condition corresponding to the variable to be processed is stored (step S43: Yes route), the analysis unit 110 performs an unprocessed path condition among the path conditions corresponding to the variable to be processed. One (hereinafter referred to as a path condition to be processed) is identified (step S47).

  Then, the analysis unit 110 identifies the specific value set for the processing target variable from the execution data storage unit 104, and determines whether the specific value satisfies the processing target path condition (step S49). When it is determined that the specific value set in the processing target variable satisfies the processing target path condition (step S49: Yes route), the analysis unit 110 sets the determination flag “true” in association with the processing target path condition. The data is stored in the execution data storage unit 104 (step S51). On the other hand, when it is determined that the specific value set in the processing target variable does not satisfy the processing target path condition (step S49: No route), the analysis unit 110 associates the determination flag “ "false" is stored in the execution data storage unit 104 (step S53).

  FIG. 15 shows an example of data stored in the execution data storage unit 104 when step S53 is performed. In the example of FIG. 15, a variable, a type, a specific value, a path condition, and a determination flag are stored.

  Then, the analysis unit 110 determines whether there is an unprocessed path condition for the variable to be processed (step S55). When it is determined that there is an unprocessed path condition (step S55: Yes route), the process returns to the process of step S47 in order to process the unprocessed path condition.

  On the other hand, when it is determined that there is no unprocessed path condition (step S55: No route), the analysis unit 110 determines whether there is an unprocessed variable in the execution data storage unit 104 (step S57). If it is determined that there is an unprocessed variable (step S57: Yes route), the process returns to step S41 to process the unprocessed variable.

  On the other hand, if it is determined that there is no unprocessed variable (step S57: No route), the analysis unit 110 stores in the execution data storage unit 104 the path condition associated with the determination flag “false”. Judgment is made (step S59). When it is determined that the path condition associated with the determination flag “false” is not stored in the execution data storage unit 104 (step S59: No route), the specific value setting process described later cannot be performed. Therefore, the process ends via the terminal A. On the other hand, when it is determined that the path condition associated with the determination flag “false” is stored in the execution data storage unit 104 (step S59: Yes route), the process returns to the original process.

  By performing the processing as described above, it becomes possible to specify a path condition that cannot be satisfied by the specific value set in the symbolic execution that has already been performed.

  Returning to the description of FIG. 6, the determination requesting unit 111 performs a specific value setting process (step S <b> 15). The specific value setting process will be described with reference to FIGS.

  First, the determination request unit 111 specifies one unprocessed variable (hereinafter referred to as a variable to be processed) from the execution data storage unit 104 (FIG. 16: step S71). Then, the determination request unit 111 determines whether or not the determination flag “−1” is set in the variable to be processed (step S73). That is, it is determined whether there is a path condition related to the variable to be processed. When it is determined that the determination flag “−1” is set in the variable to be processed (step S73: Yes route), the process proceeds to step S77.

  On the other hand, when it is determined that the determination flag “−1” is not set for the variable to be processed (step S <b> 73: No route), the determination request unit 111 determines that the determination flag “ It is determined whether “false” is set (step S75). When it is determined that the determination flag “false” is not set in the path condition related to the variable to be processed (step S75: No route), the determination request unit 111 determines the original specific value (the specific specified in step S3). Value) is stored in the satisfaction value storage unit 112 in association with the variable to be processed (step S77).

  On the other hand, when it is determined that the determination flag “false” is set in the path condition related to the variable to be processed (step S75: Yes route), the determination request unit 111 displays the variable to be processed and the type of the variable And the determination request | requirement containing the path condition whose determination flag is "false" is transmitted to the determination apparatus 5 (step S79).

  In addition, according to the process of step S79, the determination apparatus 5 performs the process which produces | generates the specific value which satisfies the received path condition. For example, when generating a specific value that satisfies the path condition “a> 0” for the variable a whose type is “int” (integer), the determination device 5 generates, for example, “1”. Then, the determination device 5 transmits the determination result including the generated specific value to the repeated execution support device 1.

  On the other hand, the determination request unit 111 of the repeated execution support device 1 receives the determination result including the generated specific value from the determination device 5 (step S81) and stores it in the sufficiency value storage unit 112 (step S83).

  FIG. 17 shows an example of data stored in the sufficiency value storage unit 112 when step S83 is performed. In the example of FIG. 17, variables, variable types, path conditions, and specific values are stored. Note that no data is stored in the path condition column for the variable for which the process of step S77 has been performed.

  Then, the determination request unit 111 determines whether there is an unprocessed variable in the execution data storage unit 104 (step S85). When it is determined that there is an unprocessed variable (step S85: Yes route), the process returns to the process of step S71 in order to perform the process on the unprocessed variable. On the other hand, when it is determined that there is no unprocessed variable (step S85: No route), the determination request unit 111 sets the execution data storage unit 104 with the variables, types, and specific values stored in the satisfaction value storage unit 112. Update (step S87). Then, the process returns to the original process.

  FIG. 18 shows an example of data stored in the execution data storage unit 104 when step S87 is performed. In the example of FIG. 18, variables, variable types, and specific values are stored.

  If symbolic execution is performed again using the specific values generated as described above, a path that could not be executed by symbolic execution already performed can be executed, and the code coverage rate can be increased. become.

  When the specific value setting process (S15) is performed, the process returns to step S5, and the process as described above is performed again using the newly set specific value. In the following, the process performed after the process returns to step S5 and before it is determined in step S11 that “branch coverage is 100%” will be briefly described.

  First, the execution pattern generation unit 105 generates an execution pattern for each variable stored in the execution data storage unit 104 (FIG. 18) and stores it in the driver storage unit 107 (step S5).

  FIG. 19 shows an example of data stored in the driver storage unit 107 when the process of step S5 is performed. The execution pattern in the first line is an execution pattern in which variable a is symbolized and specific value “1” (the specific value generated in step S15) is set in variable b. The execution pattern on the second line is an execution pattern in which the variable b is symbolized and a specific value “1” (the specific value generated in step S15) is set in the variable a.

  Then, the driver generation unit 106 generates a driver code corresponding to each execution pattern stored in the driver storage unit 107 (FIG. 19), and stores it in the driver storage unit 107 (step S7).

  FIG. 20 shows an example of data stored in the driver storage unit 107 when step S7 is performed. In the example of FIG. 20, an execution pattern and a driver code are stored. Here, the driver code 3 is generated for the execution pattern “int a = $, int b = 1”, and the driver code 4 is generated for the execution pattern “int a = 1, int b = $”. . FIG. 21 is a diagram illustrating an example of the driver code 3 and the driver code 4.

Then, the execution request unit 108 performs a coverage rate calculation process (step S9). The coverage rate calculation process is as described with reference to FIGS. Here, when symbolic execution is performed using the driver code 3, the branches B ₁ , B ₂ , B ₃ , B ₄ and B ₅ can be executed. If symbolic execution is performed using the driver code 4, branches B ₁ , B ₃ , B ₄ and B ₆ can be executed. When calculating the coverage rate again, as described above, the execution result of the symbolic execution already performed and the execution result of the symbolic execution performed this time are used. In the already executed symbolic execution, the branches B ₁ , B ₂ , B ₃ , B ₅ and B ₆ are executed, and in the symbolic execution executed this time, B ₄ is newly executed. Therefore, the branch coverage is 6/6 * 100 = 100 (%).

  Then, the analysis unit 110 determines whether the branch coverage is 100% (step S11). Here, since it is determined that the branch coverage is 100% (step S11: Yes route), the process ends through step S17.

  By performing the processing as described above, it is possible to efficiently perform a test such that the branch coverage satisfies the reference value using symbolic execution.

  Although one embodiment of the present technology has been described above, the present technology is not limited to this. For example, the functional block diagrams of the repeated execution support device 1 and the symbolic execution device 3 described above do not necessarily correspond to an actual program module configuration. The functions may be shared by a plurality of computers instead of one.

  Further, the configuration of each table described above is an example, and the configuration as described above is not necessarily required. Further, in the processing flow, the processing order can be changed if the processing result does not change. Further, it may be executed in parallel.

  In the example described above, the processing for setting the branch coverage to 100% has been described. However, the same processing can be applied to statement coverage, condition coverage, and the like.

  Further, the repeated execution support device 1, the symbolic execution device 3, and the determination device 5 may be integrated.

  The repetitive execution support device 1, symbolic execution device 3, and determination device 5 described above are computer devices, and as shown in FIG. 22, a memory 2501, a CPU 2503, a hard disk drive (HDD) 2505, and a display device. A display control unit 2507 connected to 2509, a drive device 2513 for the removable disk 2511, an input device 2515, and a communication control unit 2517 for connecting to a network are connected by a bus 2519. An operating system (OS) and an application program for executing the processing in this embodiment are stored in the HDD 2505, and are read from the HDD 2505 to the memory 2501 when executed by the CPU 2503. The CPU 2503 controls the display control unit 2507, the communication control unit 2517, and the drive device 2513 according to the processing content of the application program, and performs a predetermined operation. Further, data in the middle of processing is mainly stored in the memory 2501, but may be stored in the HDD 2505. In an embodiment of the present technology, an application program for performing the above-described processing is stored in a computer-readable removable disk 2511 and distributed, and installed from the drive device 2513 to the HDD 2505. In some cases, the HDD 2505 may be installed via a network such as the Internet and the communication control unit 2517. Such a computer apparatus realizes various functions as described above by organically cooperating hardware such as the CPU 2503 and the memory 2501 described above and programs such as the OS and application programs. .

  Note that the processing units such as the extraction unit 103 and the execution pattern generation unit 105 illustrated in FIG. 3 may be realized by a combination of the CPU 2503 and the program, that is, the CPU 2503 executing the program. More specifically, the CPU 2503 may function as a processing unit as described above by performing an operation according to a program stored in the HDD 2505 or the memory 2501.

  Each data storage unit such as the program storage unit 101 and the default value storage unit 102 illustrated in FIG. 3 may be realized as the memory 2501 or the HDD 2505 in FIG.

  The embodiments of the present technology described above are summarized as follows.

  This repetitive symbolic execution method is (A) Symbolic execution unit that executes symbolic execution Iterative symbolic execution while changing variables to be symbolized so as to cover all variables defined in the analysis target program (B) an acquisition step of acquiring a code coverage rate (for example, branch coverage or statement coverage) of the analysis target program from the symbolic execution unit and storing it in the execution result storage unit; A step of determining whether or not the code coverage rate stored in the execution result storage unit satisfies a predetermined criterion; and (D) when it is determined that the code coverage rate satisfies a predetermined criterion, the test of the analysis target program is completed Storing data representing this in the output data storage unit.

  In the method described above, instead of symbolizing all variables and executing symbolic execution at once as in the past, individual symbolic execution that has low coverage but can be processed at high speed is executed repeatedly. Yes. However, if the code coverage rate, which is the result of accumulating the coverage of individual symbolic executions, meets the predetermined criteria, it is sufficient as a test, and the symbolic execution is performed as if all variables were symbolized and executed at once. It is expected that the situation where an excessive test is performed in the execution is suppressed. Therefore, the test of the program is made efficient.

  Further, the acquisition step described above may include a step of acquiring path condition data obtained by symbolic execution in the first execution step from the symbolic execution unit and storing the data in the execution result storage unit. In the method described above, (E) for each path condition stored in the execution result storage unit, a specific value set in the variable is stored for each variable defined in the analysis target program. A determination step of identifying a specific value set in a variable related to the path condition from a data storage unit and determining whether the specified specific value satisfies a condition that the path condition is satisfied; (F) determination A generation step for generating a specific value that satisfies the path condition determined not to satisfy the condition in the step, and (G) a symbolic execution unit that covers all variables defined in the analysis target program Variables related to path conditions that are determined not to satisfy the conditions while changing the variables to be symbolized In the case of setting a value, a second execution step in which the specific value generated in the generation step is set and symbolic execution is repeatedly performed; (H) the execution result of the first execution step and the execution result of the second execution step; A cumulative code coverage rate that is a code coverage rate calculated by using the symbolic execution unit and storing it in the execution result storage unit; and (I) a cumulative code coverage rate stored in the execution result storage unit is A step of determining whether or not a predetermined standard is satisfied; and (J) when it is determined that the accumulated code coverage rate satisfies the predetermined standard, data indicating that the test of the analysis target program is completed is stored in the output data storage unit A step may be further included. In this way, a path that cannot be executed by the symbolic execution that has already been performed can be executed, so that the cumulative code coverage rate can be increased.

  Further, in the first execution step and the second execution step described above, one variable to be symbolized is set, and the variable to be symbolized is covered so as to cover all variables defined in the analysis target program. It may be changed. In this way, if there is one variable to be symbolized, it is possible to perform symbolic execution even for a program that includes a non-linear operation (for example, multiplication of variables).

  A program for causing a computer to perform the processing according to the above method can be created. The program can be a computer-readable storage medium such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, a hard disk, or the like. It is stored in a storage device. The intermediate processing result is temporarily stored in a storage device such as a main memory.

  The following supplementary notes are further disclosed with respect to the embodiments including the above examples.

(Appendix 1)
A first execution step in which a symbolic execution unit that performs symbolic execution repeatedly performs symbolic execution while changing variables to be symbolized so as to cover all variables defined in the analysis target program;
An acquisition step of acquiring the code coverage of the analysis target program from the symbolic execution unit and storing it in the execution result storage unit;
Determining whether the code coverage rate stored in the execution result storage unit satisfies a predetermined criterion;
When it is determined that the code coverage rate satisfies the predetermined criterion, storing data indicating that the test of the analysis target program is completed in an output data storage unit;
A symbolic execution method that is executed by a computer.

(Appendix 2)
The obtaining step comprises
Including acquiring path condition data obtained by symbolic execution in the first execution step from the symbolic execution unit and storing the data in the execution result storage unit;
For each of the path conditions stored in the execution result storage unit, from the data storage unit storing the specific value set for the variable for each variable defined in the analysis target program, related to the path condition Determining a specific value set in the variable to be determined, and determining whether the specified specific value satisfies a condition that the path condition is satisfied;
A generating step for generating a specific value satisfying the path condition determined not to satisfy the condition in the determining step;
For the symbolic execution unit, the variable to be symbolized is changed so as to cover all variables defined in the analysis target program, and the variable related to the path condition determined not to satisfy the condition is set. A second execution step for setting a specific value and setting the specific value generated in the generation step to perform symbolic execution repeatedly;
The cumulative code coverage, which is the code coverage calculated using the execution result of the first execution step and the execution result of the second execution step, is acquired from the symbolic execution unit and stored in the execution result storage unit. Steps,
Determining whether the cumulative code coverage rate stored in the execution result storage unit satisfies the predetermined criterion;
When it is determined that the cumulative code coverage rate satisfies the predetermined criterion, storing data indicating that the test of the analysis target program is completed in the output data storage unit;
The repetitive symbolic execution method according to appendix 1, further comprising:

(Appendix 3)
In the first execution step and the second execution step, there is one variable to be symbolized, and the variable to be symbolized is changed so as to cover all variables defined in the analysis target program. The iterative symbolic execution method according to supplementary note 2, characterized by:

(Appendix 4)
An execution unit that repeatedly performs symbolic execution while changing the variables to be symbolized so as to cover all the variables defined in the analysis target program with respect to the symbolic execution unit that performs symbolic execution,
An acquisition unit that acquires the code coverage of the analysis target program from the symbolic execution unit and stores the code coverage rate in an execution result storage unit;
It is determined whether the code coverage rate stored in the execution result storage unit satisfies a predetermined criterion, and when it is determined that the code coverage rate satisfies the predetermined criterion, the test of the analysis target program is completed A determination unit that stores data representing that in the output data storage unit;
A recursive symbolic execution device.

(Appendix 5)
A first execution step in which a symbolic execution unit that performs symbolic execution repeatedly performs symbolic execution while changing variables to be symbolized so as to cover all variables defined in the analysis target program;
An acquisition step of acquiring the code coverage of the analysis target program from the symbolic execution unit and storing it in the execution result storage unit;
Determining whether the code coverage rate stored in the execution result storage unit satisfies a predetermined criterion;
When it is determined that the code coverage rate satisfies the predetermined criterion, storing data indicating that the test of the analysis target program is completed in an output data storage unit;
Is a repeated symbolic execution program for causing a computer to execute.

DESCRIPTION OF SYMBOLS 1 Repetitive execution support apparatus 101 Program storage part 102 Default value storage part 103 Extraction part 104 Execution data storage part 105 Execution pattern generation part 106 Driver generation part 107 Driver storage part 108 Execution request part 109 Coverage rate storage part 110 Analysis part 111 Determination request Unit 112 Satisfaction value storage unit 113 Output data storage unit 114 Output unit 3 Symbolic execution device 31 Execution unit 32 Coverage rate calculation unit 5 Determination device

Claims (5)

A first execution step in which a symbolic execution unit that performs symbolic execution repeatedly performs symbolic execution while changing variables to be symbolized so as to cover all variables defined in the analysis target program;
An acquisition step of acquiring the code coverage of the analysis target program from the symbolic execution unit and storing it in the execution result storage unit;
Determining whether the code coverage rate stored in the execution result storage unit satisfies a predetermined criterion;
When it is determined that the code coverage rate satisfies the predetermined criterion, storing data indicating that the test of the analysis target program is completed in an output data storage unit;
A symbolic execution method that is executed by a computer. The obtaining step comprises
Including acquiring path condition data obtained by symbolic execution in the first execution step from the symbolic execution unit and storing the data in the execution result storage unit;
For each of the path conditions stored in the execution result storage unit, from the data storage unit storing the specific value set for the variable for each variable defined in the analysis target program, related to the path condition Determining a specific value set in the variable to be determined, and determining whether the specified specific value satisfies a condition that the path condition is satisfied;
A generating step for generating a specific value satisfying the path condition determined not to satisfy the condition in the determining step;
For the symbolic execution unit, the variable to be symbolized is changed so as to cover all variables defined in the analysis target program, and the variable related to the path condition determined not to satisfy the condition is set. A second execution step for setting a specific value and setting the specific value generated in the generation step to perform symbolic execution repeatedly;
The cumulative code coverage, which is the code coverage calculated using the execution result of the first execution step and the execution result of the second execution step, is acquired from the symbolic execution unit and stored in the execution result storage unit. Steps,
Determining whether the cumulative code coverage rate stored in the execution result storage unit satisfies the predetermined criterion;
When it is determined that the cumulative code coverage rate satisfies the predetermined criterion, storing data indicating that the test of the analysis target program is completed in the output data storage unit;
The repetitive symbolic execution method according to claim 1, further comprising: In the first execution step and the second execution step, there is one variable to be symbolized, and the variable to be symbolized is changed so as to cover all variables defined in the analysis target program. The iterative symbolic execution method according to claim 2. An execution unit that repeatedly performs symbolic execution while changing the variables to be symbolized so as to cover all the variables defined in the analysis target program with respect to the symbolic execution unit that performs symbolic execution,
An acquisition unit that acquires the code coverage of the analysis target program from the symbolic execution unit and stores the code coverage rate in an execution result storage unit;
It is determined whether the code coverage rate stored in the execution result storage unit satisfies a predetermined criterion, and when it is determined that the code coverage rate satisfies the predetermined criterion, the test of the analysis target program is completed A determination unit that stores data representing that in the output data storage unit;
A recursive symbolic execution device. A first execution step in which a symbolic execution unit that performs symbolic execution repeatedly performs symbolic execution while changing variables to be symbolized so as to cover all variables defined in the analysis target program;
An acquisition step of acquiring the code coverage of the analysis target program from the symbolic execution unit and storing it in the execution result storage unit;
Determining whether the code coverage rate stored in the execution result storage unit satisfies a predetermined criterion;
When it is determined that the code coverage rate satisfies the predetermined criterion, storing data indicating that the test of the analysis target program is completed in an output data storage unit;
Is a repeated symbolic execution program for causing a computer to execute.

Images