JP2010072883A - Program verification apparatus, program verification method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To indicate the possibility of errors in assumption that provides the operational context of a program to be examined, in the verification of a program using model examination techniques where a program and assertions are inputs. <P>SOLUTION: A program verification apparatus measures as a degree of exhaustiveness a range verified by model examination techniques using such an existing technique as embedding arrival confirmation codes in portions of conditional branching, and indicates the measuring result together with the verification result, thereby indicating the possibility of an assumption error to an operator. If the degree of exhaustiveness is less than 100% (i.e., there exists unexamined branching), a determination is made that there is the possibility that the assumption is erroneous. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a program verification apparatus, and more particularly to a program verification apparatus using a model checking technique.

  In order to verify the correctness of the program, a comprehensive search of the state space is one of the techniques for checking for run-time errors such as null pointer references, array boundary violations, or division by zero, and user-defined assertion violations. There is program verification using model checking technology.

  When the open system is verified using the model checking technique, it is important to correctly perform the environment modeling because the external environment modeling that gives the operation context of the verification target system greatly affects the verification accuracy and the verification performance. Even in the verification of a program using the model checking technique, an external environment modeling is practically indispensable because a program, particularly a partial program composed of functions, modules, etc., is basically an open system.

  As a method for modeling the external environment of the verification target program, a method is generally used in which a condition (precondition) that is a premise at the time of execution of the verification target program is defined as an assumption.

  For example, in Non-Patent Document 1, an assumption (denoted as “assumtion” in the document) is used in a technique for constructing a model checking environment of a Java (registered trademark) program.

  In program verification using model checking technology, the assumptions that give the operation context of the program to be checked (mainly the conditions that limit the range of input to the program) and restrictions on the behavior of the program to be checked are defined as assertions. In order to confirm the correctness, reviews are conventionally performed mainly by verification workers (hereinafter referred to as workers) and related parties. For this reason, the assumptions included in the assertion may be missed, and correct verification results may not be obtained.

  As a method for solving this problem in Non-Patent Document 2 and Non-Patent Document 3, a problem that is erroneously detected due to an erroneous weak assumption (a condition that limits the input range to be weak) that is output as part of the verification result. Attention has been given to a technique for correcting an erroneous weak assumption in the verification process (hereinafter referred to as CEGER). However, in this method (CEGER), it is known that there is a false strong assumption (a condition that strongly restricts the input range) that causes a problem to be overlooked, and the assumption cannot be corrected.

  For example, consider a case where program verification of a divide-by-zero error using a model checking technique is performed on the C language program shown in FIG.

  Since the model checking technique exhaustively searches and checks the state space, if the combination of the program execution location and the value of all variables at that time is defined as a state, the possible combinations of all variable values, and , All execution paths reachable by the combination can be inspected. Further, since the input from the outside is treated as an undetermined arbitrary value, the function arguments n1, n2, and a are treated as arbitrary values in the program. In this case, the arbitrary value is a value from the minimum value “INT_MIN” to the maximum value “INT_MAX”.

  In this program, since the conditions in the comments on the first to fifth lines are premised, the condition “n1 == 0 || n1 == 1” for the argument n1 is correct as the assumption given as the operation context. When program verification is performed using this assumption, a divide-by-zero error at y on the 26th line due to a setting error of the value of the local variable y on the 22nd line is detected. Although there is division by the local variable x on the 25th line, a value other than 0 is always set to x under the above assumption, so no division by zero error is detected.

  On the other hand, if a weak assumption, for example, “n1> = 0” is given by mistake, and if the value of n1 is a positive value other than 1, the value of x remains initialized to 0. Since the 25th line is reached, a divide-by-zero error occurring there is also detected as a problem. In CEGER, when it is determined that the detected problem is a false detection, an operator can analyze the cause of the false detection and correct the assumption based on the analysis result.

  However, if a wrong assumption is given, for example, “(n1 == 0 || n1 == 1) && n2> = 0”, n2 does not become a negative value. Since the execution path that reaches the “else” clause is not checked, the zero division error on the 25th line that may occur originally is not detected as a problem. In this case, the assumption cannot be corrected because there is no clue to know the assumption error from the verification result alone.

As a related technique, Japanese Patent Application Laid-Open No. 2008-071135 (Patent Document 1) discloses a verification processing apparatus.
In this related technique, the model check checks all states and all paths in the state transition diagram (state transition graph), and determines whether or not there is a state or transition path having a specified feature. In the verification processing device using model checking, the operation of the data processing system to be verified is converted into a state transition graph, and the function specifications of the data processing system to be verified are the characteristics of the state or transition path on the state transition graph. Convert to At this time, a state transition graph of the data processing system to be verified is acquired, a request to the data processing system is acquired, and a coverage index indicating an operation that should be included in the verification range of the data processing system is acquired. Whether the acquired state transition graph satisfies the request is verified, the coverage of the state transition graph is measured corresponding to the acquired coverage index, and the result is output.

O. Tkachuk, M.M. B. Dwyer, and C.D. S. Pasareanu. “Automated Environment Generation for Software Model Checking.” In Proceedings of the 18th IEEE International Conferencing on Automated Software Eng. 2003. <Http: // ti. arc. nasa. gov / m / pub / 598h / 0598% 20 (Tkachuk). pdf> A. Gupta, "From Hardware Verification to Software Verification: Re-use and Re-learn", Hardware and Software: Verification and Testing, Third International Haifa Verification Conference, HVC 2007, Haifa, Israel, October 23-25, 2007. Proceedings, pp. 14-15 Presentation materials <http: // www. Haifa. ibm. com / Workshops / verification2007 / present / Aarti_Gupta_keynote_web. pdf> JP 2008-071135 A

  When performing a model check of a program using assumptions, if the assumption is incorrect, the verification result is also incorrect. Specifically, when an erroneous weak assumption is used, a part that does not become a problem is detected as a problem, and when an incorrect strong assumption is used, a part that is originally a problem is not detected as a problem. That is, “false detection” and “missing” occur. Therefore, in order to obtain a correct verification result by model checking, it is necessary to correctly define assumptions before or during the verification process.

  The program verification device of the present invention embeds a verification target program, a secondary storage device that stores information on assumptions given as an operation context of the verification target program, and a code for arrival confirmation at a conditional branch location of the verification target program And a central processing unit that measures the verified range as the coverage, outputs the measurement result together with the verification result, and indicates the possibility of an assumed error given as the operation context of the verification target program.

  In the program verification method of the present invention, the step of referring to the verification target program and the information related to the assumption given as the operation context of the verification target program, and verification by embedding the code for arrival confirmation in the conditional branch location of the verification target program, Measuring the verified range as the coverage, outputting the measurement result together with the verification result, and indicating the possibility of a hypothetical error given as the operation context of the verification target program.

  The program of the present invention is verified by embedding a verification target program and a step of referring to information about an assumption given as an operation context of the verification target program, and by embeding a code for confirming arrival at a conditional branch location of the verification target program. This is a program for causing a computer to execute a step of measuring a range as a coverage, outputting a measurement result together with a verification result, and indicating a possibility of an assumed error given as an operation context of the verification target program.

  In this way, by measuring the range verified by the model checking technology using existing technology such as embedding the arrival confirmation code at the conditional branch location, and showing the measurement result together with the verification result, Indicates the possibility of incorrect assumptions. If the coverage is less than 100%, that is, if there is an unchecked branch, the assumption may be incorrect.

  For example, program verification is performed on the C language program shown in FIG. 1 using the assumption that “(n1 == 0 || n1 == 1) && n2> = 0”, and the verification result is “no problem”. The coverage is 86% (numerical value in “decision coverage”). As a result, the operator knows that there is a possibility that the assumption is incorrect.

  In the verification of a program using model checking technology, it is possible to clearly define the possibility of an assumption error used in the program verification and to correctly define the assumption.

Hereinafter, a first embodiment of the present invention will be described with reference to the accompanying drawings.
As shown in FIG. 2, the program verification apparatus according to the present embodiment includes a central processing unit 10, a secondary storage device 20, an input device 30, and an output device 40.

  The central processing unit 10 includes a program input unit 11, an assertion input unit 12, a model checking unit 13, and a coverage measuring unit 14.

  The secondary storage device 20 includes a program storage unit 21 and an assertion storage unit 22.

  The program input unit 11 reads the verification target program from the input device 30 and stores it in the program storage unit 21 of the secondary storage device 20.

  The assertion input unit 12 reads an assertion defined by a user such as an operator from the input device 30 and stores it in the assertion storage unit 22 of the secondary storage device 20.

  The model checking unit 13 reads the verification target program from the program storage unit 21, reads the assumption given as the operation context of the verification target program from the assertion storage unit 22, performs exhaustive verification on a predefined error, and outputs The verification result is output to the device 40.

  The coverage measuring unit 14 reads the verification target program from the program storage unit 21, embeds an arrival confirmation code in the conditional branch location, reads the assumption given as the operation context of the verification target program from the assertion storage unit 22, and performs model checking The arrival at the conditional branch location is confirmed using the unit 13, the coverage is calculated from the confirmation result, and the assumption, the coverage, and information about the reached / unreached location are output to the output device 40. At this time, when the coverage level is less than 100% and there is an unexamined branch, the coverage level measurement unit 14 determines that there is a possibility that the assumption is incorrect, and outputs information indicating that fact. You may do it.

  The program storage unit 21 stores a verification target program.

  The assertion storage unit 22 stores an assertion including an assumption given as an operation context of the verification target program.

  As an example of the central processing unit 10, a processing unit such as a CPU (Central Processing Unit) or a microprocessor (microprocessor), or a semiconductor integrated circuit (Integrated Circuit (IC)) having a similar function can be considered. The program input unit 11, the assertion input unit 12, the model checking unit 13, and the coverage measuring unit 14 may be programs for causing a computer to execute each function. However, actually, it is not limited to these examples.

  Examples of the secondary storage device 20 include a semiconductor storage device such as a memory, an external storage device (storage) such as a hard disk, or a storage medium (media). However, actually, it is not limited to these examples.

  Examples of the input device 30 include a keyboard, a keypad, a keypad on the screen, a touch panel, a tablet, or a reading device such as a storage medium (media). Alternatively, the input device 30 may be an interface (I / F) for acquiring information from an external input device or storage device. However, actually, it is not limited to these examples.

  As an example of the output device 40, a display device such as an LCD (Liquid Crystal Display), a PDP (Plasma Display), an organic EL display (Organic Electroluminescence Display), or a projection device such as a projector that projects display contents on a wall or a screen, a display A printing device such as a printer that prints the contents on a sheet or the like can be considered. Alternatively, the output device 40 may be an interface for outputting information to an external display device or storage device. However, actually, it is not limited to these examples.

  Next, operations performed by the central processing unit 10 will be described in detail using actual data with reference to the flowchart of FIG. Here, with respect to the C language program shown in FIG. 1, the program verification of the divide-by-zero error is performed using the assumption that “(n1 == 0 || n1 == 1) && n2> = 0”. .

(1) Step ST1
First, the program input unit 11 reads the verification target program from the input device 30 and stores it in the program storage 131 of the secondary storage device 20. Here, the program input unit 11 reads the C language program shown in FIG. 1 from the input device 30 and stores it in the program storage 131 of the secondary storage device 20.

(2) Step ST2
The assertion input unit 12 reads the assertion defined by the user from the input device 30 and stores it in the assertion storage unit 22 of the secondary storage device 20. Here, the assertion input unit 12 reads from the input device 30 an assertion consisting only of the assumption “(n1 == 0 || n1 == 1) &&n2> = 0”, and stores the assertion memory of the secondary storage device 20 Stored in the unit 22.

(3) Step ST3
Next, the model checking unit 13 reads the verification target program from the program storage unit 21 and reads the assumptions given as the operation context of the verification target program from the assertion storage unit 22 and performs exhaustive verification on predefined errors. . Here, the model checking unit 13 reads the verification target program stored in the program storage unit 21, reads the assumption stored in the assertion storage unit 22, performs exhaustive verification on the division by zero error, and displays “no problem” To get the result.

(4) Step ST4
The coverage measuring unit 14 reads the program to be verified from the program storage unit 21, embeds a code for confirmation of arrival in a format that depends on the specifications and implementation of the model checking unit 13 in the conditional branch, and makes an assumption from the assertion storage unit 22. Read and confirm the arrival at the conditional branch using the model checking unit 13, and calculate the coverage from the result. Here, the coverage measuring unit 14 reads the verification target program from the program storage unit 21 and embeds the arrival confirmation code in the conditional branch location to create a program as shown in FIG. It is assumed that the code for arrival confirmation is an assertion description (ASSERT (0) or the like) that is necessarily not established. The model checking unit 13 performs model checking for each assertion description and confirms arrival of the verification target program at the conditional branch point. At this time, the model checking unit 13 determines that it is reached if the assertion is not established, and is not reached if it is not detected. In this case, when the model checking unit 13 confirms the arrival at the conditional branch point, it is understood that “11th, 15th, 18th, 20th, 26th and 29th lines” are reached, and “the 32nd line” is not reached. Therefore, the coverage is calculated as “86%” from the result. That is, the model checking unit 13 out of the seven conditional branch points “11, 15, 18, 20, 26, 29, and 32nd line” has six conditional branch points “11, 15, 18, 20, 26, 29”. Since the “line” is reached, the coverage is calculated as “(6 ÷ 7) × 100≈86%”.

(5) Step ST5
Finally, the coverage measuring unit 14 outputs the assumptions used for the verification, the calculated coverage, and information on the reached / not reached locations to the output device 40, and the model checking unit 13 outputs the verified results. Output to the device 40 and end. Here, the coverage level measurement unit 14 assumes the assumption “(n1 == 0 || n1 == 1) &&n2> = 0” used for the verification, the calculated coverage level “86%”, and the unreached location As a result of the verification, the model checking unit 13 outputs “no problem” to the output device 40, and the process ends.

  Since the degree of coverage output to the output device 40 is less than 100%, the worker may have an error in the input assumption “(n1 == 0 || n1 == 1) && n2> = 0” I understand that there is.

  The first effect of the present invention is that an assumption error used for program verification is not overlooked. The reason is that it is possible to indicate a possibility that the worker has an error in the assumption that the coverage is displayed together with the assumption used in the verification.

  The second effect of the present invention is that a non-reachable code (dead code) can be detected. The reason is that, as a result of careful examination of the hypothesis in which the possibility of error is pointed out, if it is found that there is no error in the hypothesis, a branch point indicated as a non-reachable point can be determined as a non-reachable code.

The second embodiment of the present invention will be described below.
In the configuration of the apparatus shown in FIG. 2, the input device 112, the program input unit 11, and the assertion input unit 12 may be omitted. For example, when the verification target program and the assertion are stored in advance in the secondary storage device 20 such as when the secondary storage device 20 is used as a repository, the central processing unit 10 stores the verification target program and the assertion. Read directly from the next storage device 20. In this case, the central processing unit 10 directly reads the verification target program and the assertion directly from the secondary storage device 20 based on the presetting or in response to a user operation.

The third embodiment of the present invention will be described below.
In the configuration of the apparatus illustrated in FIG. 2, the coverage degree measurement unit 14 may not be separated from the model checking unit 13 and may be integrated. In that case, the integrated model checking unit 13 performs all of step ST3, step ST4, and step ST5 in the flowchart of FIG.

The fourth embodiment of the present invention will be described below.
In the flowchart shown in FIG. 3, the model checking process in step ST3 may be omitted. In this case, in step ST5, the verification result cannot be output, and it is possible to indicate the possibility of an erroneous strong assumption depending on the degree of coverage, but it is not possible to indicate the possibility of an erroneous weak assumption that causes a false detection of a problem. That is, CEGER cannot be performed. Further, the model checking process in step ST3 and the coverage degree measuring process in step ST4 may be performed in reverse or in parallel.

  As described above, the present invention makes it possible to indicate the possibility of a hypothetical error that gives the operation context of a program to be tested in the verification of a program using the model checking technique with the program and assertion as inputs.

  The present invention can be applied to uses such as correction of assumptions in program verification using model checking technology and detection of program defects.

  As mentioned above, although embodiment of this invention was explained in full detail, actually it is not restricted to said embodiment, Even if there is a change of the range which does not deviate from the summary of this invention, it is contained in this invention.

FIG. 1 is a diagram illustrating an example of a verification target program. FIG. 2 is a diagram illustrating a configuration example of the program verification apparatus according to the first embodiment of the present invention. FIG. 3 is a flowchart showing the operation of the central processing unit. FIG. 4 is a diagram illustrating an example of a program in which a code for confirming arrival at a conditional branch location is embedded.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... Central processing unit 11 ... Program input part 12 ... Statement input part 13 ... Model check part 14 ... Coverage degree measurement part 20 ... Secondary storage device 21 ... Program storage part 22 ... Statement storage part 30 ... Input device 40 ... Output device

Claims (15)

A secondary storage device that stores information about a verification target program and assumptions given as an operation context of the verification target program;
A verification code is embedded and verified at the conditional branch location of the verification target program, the verified range is measured as the coverage, the measurement result is output together with the verification result, and given as the operation context of the verification target program A program verification apparatus comprising: a central processing unit that indicates a possibility of an assumption error. The program verification device according to claim 1,
The secondary storage device
Program storage means for storing the verification target program;
An assertion storage means for storing an assertion including an assumption given as an operation context of the verification target program. The program verification device according to claim 2,
The central processing unit is
A model checking unit that reads the verification target program from the program storage unit, reads the assumption from the assertion storage unit, performs exhaustive verification on a predefined error, and outputs a verification result;
Read the verification target program from the program storage means, embed an assertion description that is always unsatisfied as a code for confirming arrival at the conditional branch location of the verification target program, read the assumption from the assertion storage means, and A program verification comprising: a coverage degree measuring means for confirming the arrival at the conditional branch location, calculating the coverage level from the confirmation result, and outputting the assumption, the coverage level, and the information of the reached / unreached location apparatus. The program verification device according to claim 3,
The central processing unit is
A program input means for reading a verification target program input from an external means and storing it in the program storage means;
A program verification apparatus, further comprising an assertion input unit that reads an assertion defined by a user and stores the assertion in the assertion storage unit. The program verification device according to any one of claims 1 to 4,
The central processing unit determines that there is a possibility of an error in the assumption when the coverage is less than 100% and there is an unexamined branch. Referring to information on a verification target program and assumptions given as an operation context of the verification target program;
A verification code is embedded and verified at the conditional branch location of the verification target program, the verified range is measured as the coverage, the measurement result is output together with the verification result, and given as the operation context of the verification target program A program verification method comprising the steps of indicating a possible hypothesis error. The program verification method according to claim 6,
Holding the program to be verified;
Holding a statement including an assumption given as an operation context of the program to be verified. The program verification method according to claim 7, wherein:
Reading the verification target program, reading the assumption, performing a comprehensive verification on a predefined error, and outputting a verification result;
Read the program to be verified, embed an assertion description that is always not satisfied as a code for confirming arrival at the conditional branch location of the verification target program, read the assumption, and reach the conditional branch location of the verification target program The program verification method further includes the steps of: calculating the coverage from the confirmation result, and outputting the assumption, the coverage, and information on the reached / unreached location. The program verification method according to claim 8, comprising:
Reading a verification target program input from the outside and storing it in a secondary storage device;
Reading the assertion defined by the user and storing it in the secondary storage device. A program verification method according to any one of claims 6 to 9, comprising:
The program verification method further comprising the step of determining that there is a possibility of an error in the assumption when the coverage is less than 100% and there is an unchecked branch. Referring to information on a verification target program and assumptions given as an operation context of the verification target program;
A verification code is embedded and verified at the conditional branch location of the verification target program, the verified range is measured as the coverage, the measurement result is output together with the verification result, and given as the operation context of the verification target program A program that causes a computer to execute a step that indicates the possibility of a false assumption. The program according to claim 11,
Holding the program to be verified;
A program for causing a computer to further execute a step of holding an assertion including an assumption given as an operation context of the verification target program. A program according to claim 12,
Reading the verification target program, reading the assumption, performing a comprehensive verification on a predefined error, and outputting a verification result;
Read the program to be verified, embed an assertion description that is always not satisfied as a code for confirming arrival at the conditional branch location of the verification target program, read the assumption, and reach the conditional branch location of the verification target program , Calculating the degree of coverage from the confirmation result, and outputting the information on the assumption, the degree of coverage, and the reached / unreached location information. The program according to claim 13,
Reading a verification target program input from the outside and storing it in a secondary storage device;
A program for causing a computer to further execute a step of reading a statement defined by a user and storing it in the secondary storage device. The program according to any one of claims 11 to 14,
A program for causing a computer to further execute a step of determining that there is a possibility of an error in the assumption when the coverage is less than 100% and there is an unexamined branch.

Images