JPWO2013161195A1 - Program unit test support device - Google Patents

Abstract

The program unit test support apparatus 10 analyzes the path after the return from the lower function in the target function part, the syntax analysis unit 13 that identifies the part affected by the output variable value of the lower function in the target function, and the path And a stub function output analysis unit 14 that calculates a constraint that should be satisfied by the output variable value of the lower function as a path-dependent sub-post condition, and after the return from the lower function in the target function based on the path-dependent sub-post condition A target function input analysis unit 15 that calculates a constraint on an input value of a target function for executing a path as a path-dependent target precondition; a driver function that provides an input variable value that satisfies the path-dependent target precondition; and a path-dependent subordinate And a test case generation unit 16 that generates a stub function that outputs an output variable value that satisfies a condition.

Description

  The present invention relates to a program unit test support apparatus that supports a unit test of a program.

  A general program created in a high-level programming language such as C language is realized by a function calling another function. Hereinafter, a function that calls a specific function is called an upper function, and a function that is called from the specific function is called a lower function.

  Also, in a general unit test method for a program written in a high-level programming language, a function (driver function) that simulates a higher function of the function to be tested (target function) and a function that simulates a lower function of the target function At least one of the implementation of (stub function) is required.

  The driver function executes the target function by giving an input variable value that executes the behavior to be checked among several behaviors that the target function can execute, and checks that the expected behavior has been performed. Then, the execution result of the target function is compared with the expected result. Alternatively, the driver function outputs the execution result of the target function in order to make the operator confirm that the expected behavior has been performed.

  The stub function sets the return value and argument value so that the target function can continue executing the behavior that the target function wants to check after returning from the stub function. The return value and arguments that are set by the function are collectively called an output variable.

  In a unit test that takes into account the internal structure of the target function (a white box unit test), whether or not the test has been sufficiently performed is determined by whether or not the coverage standard has been achieved 100%. For example, in the decision coverage criteria, it is checked that each of the conditional branch statement and the iteration statement control expression is true and false. The value of division with the number of all control expressions doubled as the denominator and the number of control expressions that can be executed as true or false is the numerator, which is 1 (100%). Desired.

  In order to achieve the coverage standard in the unit test, the worker needs to give the target function the input variable value given by the driver function and the output variable value given by the stub function according to the behavior to be examined by the target function. Hereinafter, the driver function and the stub function are collectively referred to as a test program. Test programs such as driver functions and stub functions are generally created by an operator.

  The technique described in Patent Document 1 automatically generates a stub function that uses the constant value used for comparison as the output variable value when the target function changes the behavior by comparing the output variable value of the lower function with the constant. However, the technique described in Patent Document 1 does not consider the case where the target function compares the output variable value of the lower function with the variable.

  In a unit test that does not consider the internal structure of the target function (black box unit test), whether or not the test has been sufficiently performed is determined based on whether or not the case of the input value is exhausted with respect to the function specification of the target function. The function specification includes a precondition (pre-condition) that is a logical expression indicating a constraint on the input value of the function, information on variables for which the function sets values, and a postcondition (post) that indicates a constraint on the output value of the function. -Condition).

  In the following, regarding logical expressions, an expression that does not include the operators of logical sum and logical product is a term, an expression in which terms are connected only by logical product is a continuous clause, and a conjunctive theory is a form of expression that is connected only by logical sum. , Called disjunctive normal form (DNF). Since any logical expression can be expressed in the disjunctive standard form, the postcondition is assumed to be the disjunctive standard form.

  In Non-Patent Document 1, in a conjunctive clause of a postcondition, a product of terms including only an input variable is referred to as a guard condition, and a product of terms including an output variable is referred to as a definition condition (defining condition). If the precondition is P and each conjunctive clause of the postcondition is distinguished by the subscript i, and the conjunctive clause is composed of the logical product of the guard condition Gi and the definition condition Di, in Non-Patent Document 1, for each conjunctive clause, Considering a test condition that is a logical product (P∧Gi) of the precondition P and the guard condition Gi, an input value is generated for each test condition, thereby performing a test that exhausts the conjunctive clauses of the postcondition. That is, the concept of the technique described in Non-Patent Document 1 is that the target function should perform a specific behavior for each test condition, and the output variable value should satisfy Di as an expected result.

  Using the method described in Non-Patent Document 1, an input variable value that is expected to behave according to a conjunctive clause of the postcondition is given, and an output variable value of the target function is compared with the definition condition of the conjunctive clause, A driver function can be generated to check that the expected behavior has been performed. However, in Non-Patent Document 1, the input variable value of the target function necessary for creating the driver function is obtained, but no information is obtained regarding the output variable value of the lower function of the target function necessary for creating the stub function. I can't.

JP 2008-140263 A (paragraph 0039, paragraph 0040, FIG. 8 and FIG. 10)

Shaoying Liu and Shin Nakajima, A Decompositional Approach to Automatic Test Case Generation Based on Formal Specifications, NII Technical Report NII-2010-001E, January 2010, p.3

  The first problem is that, in the method for generating a stub function in the unit test described in Patent Document 1, the target function compares the output variable value of the lower function with the variable value to specify after the return from the lower function. When the execution path is selected, a stub function that selects the execution path cannot be generated. This is because the method described in Patent Document 1 considers only the case where the output variable value of the lower function is compared with a constant.

  The second problem is that in the method for generating a driver function in the unit test described in Non-Patent Document 1, the target function returns from the lower function by comparing the output variable value of the lower function with a constant value or a variable value. When a later specific execution path is selected, a driver function that selects the execution path cannot be generated. The reason is that in the method described in Non-Patent Document 1, the input variable value of the target function is determined only from the function specification without examining the path from the start position of the target function to the execution path after returning from the lower function. This is to obtain the expected result.

  Accordingly, an object of the present invention is to provide a unit test support apparatus for a program that can improve the degree of coverage in consideration of the internal structure of the program.

  The program unit test support apparatus according to the present invention is a function that simulates the operation of a driver function that gives an input variable value to a target function that is a target function of a program unit test and calls the target function, and a lower function that the target function calls. A program unit test support apparatus for supporting a program unit test performed using a stub function to be replaced with the lower function, wherein the parsing unit identifies a portion affected by the output variable value of the lower function in the target function Then, in the part of the target function, the path after return from the lower function is analyzed, and the constraint that the output variable value of the lower function should satisfy to execute the path is calculated as a path dependent sub post condition. Based on the stub function output analysis unit and the path-dependent sub-postcondition, A target function input analysis unit that calculates a constraint on an input value of the target function for executing the path after returning from the lower function as a path-dependent target precondition; and an input variable value that satisfies the path-dependent target precondition And a test case generation unit that generates a stub function that outputs an output variable value that satisfies the path-dependent sub-postage condition.

  The program unit test support method according to the present invention is a function that simulates the operation of a driver function that gives an input variable value to a target function that is a target function of a program unit test and calls the target function, and a lower function that the target function calls. A program unit test support method for supporting a program unit test performed using a stub function that is replaced with the lower function, wherein a portion affected by an output variable value of the lower function is specified in the target function, and the target In the part of the function, the path after the return from the subordinate function is analyzed, and the constraint that the output variable value of the subordinate function must satisfy to execute the path is calculated as a path dependent subordinate condition, and the path dependent Based on the sub-postconditions, the path after the return from the sub-function in the target function A driver function that calculates a constraint on the input value of the target function to be executed as a path-dependent target precondition and gives an input variable value that satisfies the path-dependent target precondition, and an output variable value that satisfies the path-dependent sub-postcondition A stub function that outputs is generated.

  The program unit test support program according to the present invention simulates the operation of a driver function that gives an input variable value to a target function that is a target function of the program unit test and calls the target function, and a lower function that the target function calls. A program unit test support program that executes a process for supporting a program unit test performed using a stub function that is a function and a stub function that is replaced with the lower function, and that causes a computer to output an output variable value of the lower function in the target function The structure analysis process for identifying the affected part, and the part after the return from the lower function in the part of the target function is analyzed, and the output variable value of the lower function should satisfy to execute the path Stub function output for calculating constraints as path-dependent sub-postconditions An object function that calculates, as a path-dependent target precondition, a restriction on an input value of the target function for executing the path after returning from the lower-level function in the target function based on the processing and the path-dependent sub-post condition Executing an input analysis process, a driver function that provides an input variable value that satisfies the path-dependent target pre-condition, and a test case generation process that generates a stub function that outputs an output variable value that satisfies the path-dependent sub-post condition It is characterized by.

  According to the present invention, it is possible to improve the degree of coverage in consideration of the internal structure of a program.

It is a block diagram which shows the structure of embodiment of the program unit test assistance apparatus by this invention. It is explanatory drawing which shows the example of the function (object function) of a program unit test object. It is a flowchart which shows operation | movement of embodiment of the program unit test assistance apparatus by this invention. It is explanatory drawing which shows the example of the control flow graph produced | generated by parsing the object function. It is explanatory drawing which shows the example of the call related information extracted from the control flow graph. It is explanatory drawing which shows the example of the dependency relationship information extracted from the control flow graph. It is a figure which shows the example of the rule for extracting dependency relationship information from a control flow graph. It is explanatory drawing which shows the example of the partial control flow graph which cut out the range which the output variable value of a low-order function affects from the control flow graph of the whole object function. It is explanatory drawing which shows the example of the information for every path | route (path | route information) in a partial control flow graph. It is explanatory drawing which shows the example of the route information which rewritten the variable by which an output variable is substituted directly or indirectly using the output variable. It is explanatory drawing which shows the example of the postcondition (path dependence subpostcondition) which a lower function should satisfy | fill for every path | route in a partial control flow graph. It is explanatory drawing which shows the example of the rule which rewrites a logical expression into a simple expression. It is explanatory drawing which shows the example which calculates a route dependence object precondition from a route dependence sub-postcondition. It is explanatory drawing which shows the example of the partial control flow graph which cut out from the start of a target function to the call of a subordinate function from the control flow graph of the whole object function. It is explanatory drawing which shows the example of the rule which calculates the weakest prior condition. It is explanatory drawing which shows the example of the input variable value of an object function, and the output variable value of a low-order function for every test case. It is explanatory drawing which shows the example of the driver function and stub function which were produced | generated for every test case. It is a flowchart which shows another example of operation | movement of embodiment of the program unit test assistance apparatus by this invention. It is explanatory drawing which shows another example of the driver function produced | generated about the whole test case, and a stub function. It is a block diagram which shows the structure of the principal part of the program unit test assistance apparatus by this invention.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a block diagram showing a configuration of an embodiment of a program unit test support apparatus 10 according to the present invention. As shown in FIG. 1, the program unit test support apparatus 10 of this embodiment includes an input / output device 11, a processing control unit 12, a syntax analysis unit 13, a stub function output analysis unit 14, a target function input analysis unit 15, and the like. The test case generation unit 16, the permanent storage unit 17, and the temporary storage unit 18 are provided. The input / output device 11, the processing control unit 12, the permanent storage unit 17, and the temporary storage unit 18 may be provided outside the program unit test support device 10.

  The program unit test support apparatus 10 according to the present embodiment performs unit tests on modules that are constituent units in a program described in a high-level programming language such as C language. In the following, description will be made using functions for the sake of simplicity. However, the program unit test support apparatus 10 can be applied to general program modules, and in the specification, functions in C language or the like are explicitly expressed. Except in this case, the functions in the present invention mean a broader concept of modules.

  FIG. 2 is an explanatory diagram showing an example of a function (target function) to be tested as a program unit test. A unit test target function (hereinafter referred to as a target function) applied to the program unit test support apparatus 10 of the present embodiment is a function in a program described in C language as exemplified in FIG. In the program described in FIG. 2, a function target having x and y as input variables and no output variable is defined. The function target is an example of a target function. The function “target” internally calls the function “foo”. The function foo is an example of a lower function of the target function.

  In the program shown in FIG. 2, a function specification is defined in a comment immediately before the function (a sentence described between “/ **” and “* /”). The function specification includes a condition that the upper function must satisfy at the start of the function (hereinafter referred to as a precondition), information on a variable whose value changes (hereinafter referred to as an output variable), and the function at the end of the function. Includes a condition to be satisfied (hereinafter referred to as a post-condition). In the program shown in FIG. 2, a logical expression following @pre in the comment is a precondition, and a logical expression following @post is a postcondition.

  Further, although not used in the program shown in FIG. 2, the output variable name following @param [out] is output variable information. In the postcondition of FIG. 2, the return value of the function is represented as reserved word__return. Since it is obvious that the return value is an output variable, it is not necessary to describe output variable information such as @param [out] __ return for the return value.

  The input / output device 11 is an interface between the program unit test support device 10 and the user, and includes an input device and an output device. The input / output device 11 is realized by, for example, a display, a keyboard, a mouse, and the like.

  The permanent storage unit 17 stores a unit test target program input via the input / output device 11. The target program includes the definition of the target function, the declaration of the lower function, and the function specification of each function. The permanent storage unit 17 stores a stub function and a driver function generated by the test case generation unit 16.

  The temporary storage unit 18 stores various types of information, which will be described later, generated from the target program in order to generate a stub function and a driver function. Such information becomes unnecessary after the stub function and the driver function are generated.

  The syntax analysis unit 13 parses the target function, creates a control flow graph representing the flow of processing, and outputs the control flow graph to the temporary storage unit 18. Further, the syntax analysis unit 13 extracts a position on the program (for example, a line number), call relationship information, and dependency relationship information regarding the function call from the control flow graph, and outputs it to the temporary storage unit 18. The call relation information is information for managing a set of a higher function that calls a target function and a lower function that is called from the target function. The dependency relationship information is information for managing the dependency relationship of the variable of the target function.

  The stub function output analysis unit 14 specifies a program execution path (hereinafter referred to as a path) selected by the output variable value in a lower function of the call relation information, and can execute the path. The post-condition (route-dependent sub-post condition) is calculated, and the calculated result is output to the temporary storage unit 18.

  The target function input analysis unit 15 traces the control flow graph from the calling position of the lower function to the start position of the target function in the opposite direction to the program execution, and based on the product of the path dependent lower postcondition and the lower function precondition. In consideration of substitution formulas and control formulas in the path traced in the opposite direction, a condition to be satisfied at the start point of the target function (hereinafter referred to as a path-dependent target weakest precondition) is calculated. Further, the target function input analysis unit 15 calculates a logical product (hereinafter referred to as a path dependent target precondition) of the path dependent target weakest precondition and the precondition of the target function. Then, the target function input analysis unit 15 outputs the path dependence target weakest precondition and the path dependence target precondition to the temporary storage unit 18.

  The test case generation unit 16 calculates a value that satisfies the path-dependent target precondition, and generates a driver function that gives this value to the target function as an input variable value. In addition, the test case generation unit 16 calculates a value that satisfies the path-dependent sub-postcondition corresponding to the path-dependent target precondition, and generates a stub function that uses this value as an output variable value. Then, the test case generation unit 16 outputs a set of the driver function and the stub function to the permanent storage unit 17 as a test case.

  Based on the instruction information input via the input / output device 11, the processing control unit 12 applies to the syntax analysis unit 13, the stub function output analysis unit 14, the target function input analysis unit 15, the test case generation unit 16, and the like. Take control.

  The processing control unit 12, the syntax analysis unit 13, the stub function output analysis unit 14, the target function input analysis unit 15, and the test case generation unit 16 execute processing according to a program, and a CPU (Central Processing Unit) in the computer It is realized by an arithmetic device such as a processing device. A program executed by the arithmetic device is stored in a storage device such as a hard disk, and when calculated, is stored in a temporary storage area such as a memory device. The permanent storage unit 17 is realized by a storage device such as a hard disk. The temporary storage unit 18 is realized by a storage device such as a memory device or a hard disk.

  Next, the operation of this embodiment will be described. FIG. 3 is a flowchart showing the operation of the program unit test support apparatus of this embodiment. With reference to FIG. 3, a flow until a test case of a unit test is generated using the function target defined in the program shown in FIG. 2 as a target function will be described.

  In step S201, the user specifies a unit test target function, a program including the definition of the target function and its function specification, and a program including a declaration of a lower function called from the target function and its function specification. The input / output device 11 inputs, for example, a program including the definition and function specification of the target function target shown in FIG. 2 and a program including the declaration of the lower function foo and the function specification that are called from the target. These programs are stored in the permanent storage unit 17.

  In step S202, the syntax analysis unit 13 parses the program code defining the target function, generates a control flow graph, and stores the control flow graph in the temporary storage unit 18. FIG. 4 is a control flow graph generated by parsing the target function target. In the control flow graph shown in FIG. 4, the start and end of processing are represented by rounded rectangular nodes, the execution of an expression is represented by a rectangular node (hereinafter referred to as an execution node), and acquisition of a value from the expression (hereinafter, expression Is referred to as a diamond node (hereinafter referred to as a determination node).

  In each node shown in FIG. 4, the position on the program indicated by the line number and the expression to be executed or determined are described in the form of “position: expression”. The arrow between the nodes indicates that the control of the arrowhead side node is executed after executing or determining the expression of the arrowhead side node. The value written on the arrow from the determination node indicates that the control of the next node is executed only when the value and the value indicating the result of determining the expression of the determination node are the same. If nothing is written in the expression of the execution node, control of the next node is executed without executing anything.

  In step S203, the syntax analysis unit 13 specifies a function call location in the target function using the control flow graph generated in step S202. Then, the syntax analysis unit 13 uses the combination of the position of the function call on the program, the upper function that is the target function calling side, and the lower function that is called from the target function as the call storage information as the temporary storage unit 18. Remember me. FIG. 5 is an explanatory diagram showing an example of call relation information extracted from the control flow graph. In the example shown in FIG. 5, the function target calls the function foo on the third line of the program.

  In step S204, the syntax analysis unit 13 extracts dependency relationship information. Specifically, the syntax analysis unit 13 traces the control flow graph generated in step S202 from the end node to the start node, regards a certain node as a dependency source node, and appears on the right side of the substitution expression in the dependency source node. The variable or variable appearing in the control expression is specified as the dependent variable. Further, the syntax analysis unit 13 traces the arrow backward from the dependency source node, and identifies the closest node from which the value of the dependency source variable is referred or set as the dependency destination node.

  FIG. 6 is an explanatory diagram illustrating an example of dependency relationship information extracted from the control flow graph. FIG. 7 is a diagram illustrating an example of rules for extracting dependency relationship information from the control flow graph. The syntax analysis unit 13 applies the dependency relationship extraction rule shown in FIG. 7 to each node, extracts dependency relationship information, and stores it in the temporary storage unit 18. For example, in the example of the control flow graph shown in FIG. 4, there is a determination node described as 6: z == y. When attention is paid to z among variables appearing in the control expression z == y, the determination node that traces one arrow in the reverse direction is 5: z <= y. Therefore, the syntax analysis unit 13 determines that z in the sixth line depends on z in the fifth line (dependency relationship of number 12 in FIG. 6) according to the rule of number 4 shown in FIG. The fact that the z of the eye depends on y in the fifth row (the dependency of number 11 in FIG. 6) is extracted as dependency information.

  In subsequent steps S210 to S212, the syntax analysis unit 13 selects one of the lower functions registered in the call relation information, and repeats the processing of steps S211 and S220 to S227. Since foo is registered as a lower function in the call relation information shown in FIG. 5, the syntax analysis unit 13 selects foo as the lower function, and performs the process of step S211.

  In step S211, the syntax analysis unit 13 sets the output variable of the selected lower function and the variable substituted with the output variable as the dependency destination variable from the dependency relationship information, the dependency type is control, and the dependency source variable is the dependency destination variable. Identify different dependencies. Then, the syntax analysis unit 13 sub-graphs (hereinafter, after return) from the control flow graph extracted in step S202 from the node that executes the call of the lower function to the node corresponding to the dependency source variable of the specified dependency relationship information. Extract as a partial control flow graph.

  Further, the syntax analysis unit 13 obtains a path from the terminal node of the extracted post-return partial control flow graph to the execution node that calls the lower function by tracing the arrow in the reverse direction. A procedure for obtaining a route will be described in detail with reference to FIG. In the dependency relationship of number 4 shown in FIG. 6, the return value of the lower function foo is substituted into the variable t. Furthermore, in the dependency relationship of number 6, the variable t is substituted for the variable z. That is, the variables to which the output variable value of the lower function foo is directly or indirectly substituted are t and z.

  Based on the dependency relationship information shown in FIG. 6, the syntax analysis unit 13 determines that the variable t and the variable z are dependent variables after the lower function foo is called, the dependent variable is different from the dependent variable, and the dependent type is control. As the dependency relationships, the dependency relationships of number 14, number 16, and number 18 are extracted. Then, the syntax analysis unit 13 obtains a control flow graph obtained by partially cutting the control flow graph of FIG. 4 from the execution node that calls the lower function foo to the node corresponding to the dependency source variable in the extracted dependency relationship. Extract as a partial control flow graph. FIG. 8 is an explanatory diagram illustrating an example of a partial control flow graph in which a range affected by the output variable value of the lower function is cut out from the control flow graph of the entire target function.

  As shown in FIG. 8, when the execution node that calls the function foo proceeds in the direction of the arrow, there are three terminal nodes, and three paths path-1, path-2, and path-3 to each terminal node are displayed. Exists. In the processing from step S220 to step S227, the processing from step S221 to step S226 is executed for each of the extracted routes. Hereinafter, the processing from step S221 to step S226 regarding path-1 shown in FIG. 8 will be described.

  In step S221, the stub function output analysis unit 14 relates to the path selected in step S220, at the return point from the lower function to the target function, the constraint condition that the output variable should satisfy, that is, the post function of the lower function depending on the path. The conditions (hereinafter referred to as path-dependent sub-post conditions) are calculated as described below. First, the stub function output analysis unit 14 extracts an execution node or a determination node related to a variable in which the output variable value of the lower function is directly or indirectly substituted from the partial control flow graph cut out in step S211. The position and expression on the program attached to the node are extracted for each route (hereinafter referred to as route information). The control expression is extracted including its determination result.

  For example, if the control expression is x == 0 and the value attached to the subsequent arrow is false (false), the stub function output analysis unit 14 obtains the expression (x == 0) == false. x! Replace with = 0. Further, the stub function output analysis unit 14 moves from the smaller position (line number) on the program to the larger position in the route information, and changes the variable of a certain expression to the nearest substitution expression at a position smaller than the expression. Repeat replacing on the right side. Finally, the stub function output analysis unit 14 extracts a control expression from the rewritten route information, takes a logical product of these, and corrects it to a simple expression using a rewrite rule prepared in advance.

  Hereinafter, an example in which the process of step S221 is applied to path-1 in FIG. 8 will be described. FIG. 9 is a diagram illustrating an example of route information in the partial control flow graph. In FIG. 9, the information in each rectangle represents “line number: expression”. Variables into which the output variable value of the lower function foo is directly or indirectly substituted are t and z. The stub function output analysis unit 14 extracts, from the nodes of the partial control flow graph shown in FIG. 8, expressions of nodes where t and z appear. As a result, path-1 path information as shown in FIG. 9 is obtained.

  FIG. 10 is an explanatory diagram illustrating an example of route information in which a variable to which an output variable is directly or indirectly substituted is rewritten using the output variable. In the path information of path-1 shown in FIG. 9, the assignment expression with the smallest position (line number) on the program is t = foo of number 3. The stub function output analysis unit 14 rewrites t appearing on the right side of the subsequent number 4 expression using the right side foo. Since the assignment expression with the next smallest position on the program is z = foo + 1, the stub function output analysis unit 14 rewrites z appearing in the subsequent numbers 5 and 6 using the right side foo + 1. As a result, the path-1 path information shown in FIG. 10 is obtained.

  FIG. 11 is an explanatory diagram illustrating an example of a post-condition (path-dependent sub-post condition) that should be satisfied by the sub-function for each path in the partial control flow graph. FIG. 12 is a diagram illustrating an example of a rule for rewriting a logical expression into a simple expression. In FIG. 12, l, m and n represent integer values or integer type variables or expressions, x and y represent variables or constants, e represents an expression, and e [y / x] appears in e. A formula in which x is replaced by y is represented. P and Q represent logical expressions, ∧ represents logical sum, ¬ represents logical negation, and ⇒ represents logical agreement.

  The stub function output analysis unit 14 calculates the logical product of the control expressions in the rewritten path-1 path information shown in FIG. 10, and as a result, foo + 1 <= y∧foo + 1 == y is obtained. The stub function output analysis unit 14 applies the rewrite rule of number 3 shown in FIG. 12 to this expression to obtain foo + 1 == y. Then, the stub function output analysis unit 14 rewrites the lower function name foo with __return indicating the return value. As a result, the path-1 subordinate post-condition __return + 1 == y of path-1 shown in FIG. 11 is obtained as a post condition of foo that executes the path path-1 after returning from the lower function foo.

  In step S222, the target function input analysis unit 15 calculates a logical product of one definition condition selected from the path-dependent sub-post condition obtained in step S221 and the post-condition (sub-post condition) of the sub-function. Rewrite to a simple expression using the rewrite rule If the return value __return remains, the target function input analysis unit 15 further rewrites the rewritten expression to true. The target function input analysis unit 15 calculates a logical product of the rewritten expression and the guard condition corresponding to the selected definition condition and the precondition of the lower function, and uses the rewrite rule in FIG. The rewritten formula obtains a precondition of a subordinate function dependent on the path (hereinafter referred to as a path dependent subprecondition).

  FIG. 13 is an explanatory diagram illustrating an example of calculating the route-dependent target precondition from the route-dependent sub-post condition. Hereinafter, with reference to the row immediately below the heading row in FIG. 13, an example of calculation in step S222 regarding the path path-1 in FIG. 11 will be described.

  The target function input analysis unit 15 calculates the logical product of the path-dependent path post-conditions __return + 1 == y of FIG. 11 in FIG. 11 and the definition condition __return == 1 of the sub-function foo of FIG. If the formula is simplified using the rewrite rule of 9, y == 2 is obtained. Next, the target function input analysis unit 15 calculates a logical product of the expression y == 2, the guard condition x == 0 and the pre-condition x> = 0 of foo, and the rewrite rule of number 3 in FIG. Using this to simplify the equation yields the path dependent subprecondition x == 0 && y == 2.

  In step S223, the target function input analysis unit 15 defines a constraint condition at the start point of the target function that reaches the state satisfying the path-dependent lower precondition obtained in step S222 (hereinafter referred to as a path-dependent target weakest precondition). Is output to the temporary storage unit 18. Hereinafter, the process of step S223 will be specifically described.

  FIG. 14 is an explanatory diagram showing an example in which a partial control flow graph from the start of the target function target to the call of the lower function foo is cut out from the control flow graph of the entire target function shown in FIG. FIG. 15 is an explanatory diagram illustrating an example of a rule for calculating the weakest precondition. In FIG. 15, the expression column represents an expression obtained by connecting an expression attached to the previous node and an expression established at the subsequent node with “;”. P and Q represent logical expressions, and Q [e / x] represents an expression in which x appearing in Q is replaced with e.

  In step S223, the target function input analysis unit 15 creates a partial control flow graph obtained by extracting from the control function flow graph of the target function from the start position of the target function to the calling position of the lower function, as shown in FIG. Then, the target function input analysis unit 15 traces the arrow in the reverse direction from the node that executes the call of the lower function in the partial control flow graph. Then, the target function input analysis unit 15 uses the path-dependent lower precondition as an initial expression and uses the expression attached to each node and the weakest precondition calculation rule as shown in FIG. The constraint condition that leads to the call is obtained, and this is repeated up to the starting node.

  Hereinafter, an example of calculation in step S223 related to the control flow graph of FIG. 14 will be described with reference to an example of a row immediately below the heading row of FIG. In FIG. 14, there is only one decision node between the call of the lower function and the start point, and the control expression is 0 <y (route information in FIG. 13). The target function input analysis unit 15 applies the number 2 in FIG. 15 to the sequence of the formulas obtained by connecting the control formula 0 <y and the path-dependent lower precondition x == 0 && y == 2 obtained in step S222. If the weakest precondition calculation rule is used, 0 <y && x == 0 && y == 2 is obtained. Furthermore, if the target function input analysis unit 15 simplifies the expression using the rewrite rules of number 15 and number 8 in FIG. 12, the path-dependent target weakest precondition x == 0 && y == for the path path-1. Get 2.

  In step S224, the target function input analysis unit 15 calculates a logical product of the path dependent target weakest precondition obtained in step S223 and the precondition of the target function, and outputs the logical product to the temporary storage unit 18 as the path dependent target precondition. To do. The target function input analysis unit 15 assigns one test case number if the path-dependent target precondition is not false. In the following, with respect to the row immediately below the heading row in FIG. 13, an example of calculating the route-dependent target precondition for the route path−1 in FIG. 11 is shown. The logical product of the path-dependent target weakest precondition x == 0 && y == 2 and the precondition x + y> 0 of the target function in FIG. 2 is x == 0 && y == 2 && x + y> 0. For this calculation result, the target function input analysis unit 15 assigns Tid-1 as a test case number.

  In step S225, the test case generation unit 16 sets the input variable value of the target function that satisfies the path-dependent target precondition obtained in step S224 and the lower-level function that satisfies the path-dependent sub-postcondition obtained in step S221. The output variable value is calculated using a general constraint satisfaction algorithm.

  FIG. 16 is an explanatory diagram illustrating an example of the input variable value of the target function and the output variable value of the lower function for each test case. The test case generation unit 16 obtains 0 and 2 as the values of the variables x and y satisfying the route dependence target precondition x == 0 && y == 2 && x + y> 0 for the test case number Tid−1, respectively. . Further, the test case generation unit 16 obtains 1 as the return value __return of the lower function foo that satisfies the path-dependent postcondition __return + 1 == y.

  In step S226, the test case generation unit 16 uses the input variable value of the target function obtained in step S225 and the output variable value of the lower function to give the input variable value and call the target function, and the lower function A stub function that outputs the output variable value is generated instead of. FIG. 17 is an explanatory diagram illustrating an example of a driver function and a stub function generated for each test case. FIG. 17 shows an example of generating a driver function and a stub function for the test case number Tid-1 shown in FIGS.

  Note that the generation of the test program in step S226 in FIG. 3 can be performed after a series of processing from step S210 to step S212. FIG. 18 is a flowchart showing another operation example of the embodiment of the program unit test support apparatus according to the present invention. FIG. 19 is an explanatory diagram showing another example of driver functions and stub functions generated for the entire test case. 18 are the same as the processes in steps S201 to S212 in FIG. 3, and the processes in steps S1820 to S1827 in FIG. 18 are the same as those in steps S220 to S225 and S227 in FIG. This is the same as the process.

  In the operation shown in FIG. 3, in step S226, the test case generation unit 16 generates a test program for each test case number as shown in FIG. 17, but in the operation shown in FIG. After a series of processes for each path, a test program is generated. As a result, when the operation shown in FIG. 18 is performed, the test case generation unit 16 can generate a test program in which all the test case numbers are collected as shown in FIG.

  According to the program unit test support apparatus of the present embodiment, when the target function selects a specific execution path after returning from the lower function by comparing the output variable value of the lower function with the variable value, the execution path is A stub function can be generated to select. The reason for this is that the program unit test support apparatus of this embodiment takes into account the case where the output variable value of the lower function is compared with the variable, and the post-condition of the lower function that the output variable value of the lower function should satisfy (path-dependent lower level). This is because a stub function is generated in which a value satisfying the path-dependent sub-post condition is calculated as an output variable value.

  Further, according to the program unit test support apparatus of this embodiment, when the target function selects a specific execution path after returning from the lower function by comparing the output variable value of the lower function with a constant value or a variable value. A driver function that selects the execution path can be generated. The reason for this is that the program unit test support apparatus of the present embodiment examines the path from the start point of the target function to the execution path after returning from the lower function, and executes the weakest precondition (path) Driver function with the value satisfying the logical product of the path-dependent target weakest precondition, the target function precondition, and the guard function of the target function as the input variable value to the target function. It is because it produces | generates.

  According to the program unit test support device of the present embodiment, the stub function and driver function as described above are generated, so that the work efficiency of the unit test of the program can be improved, and the coverage considering the internal structure of the program can be improved. .

  FIG. 20 is a block diagram showing the configuration of the main part of the program unit test support apparatus according to the present invention. As shown in FIG. 20, the program unit test support apparatus 10 according to the present invention provides a driver function that gives an input variable value to a target function that is a target function of the program unit test and calls the target function, and a lower function that the target function calls. Is a program unit test support device that supports a program unit test performed using a stub function that is a function that simulates the operation of the subordinate function and is replaced with the subordinate function, and an output variable of the subordinate function in the target function as a main component A structure analysis unit 13 that identifies a part affected by a value, and a constraint that an output variable value of a lower function must satisfy in order to analyze a path after returning from a lower function in the target function part and execute the path Stub function output analysis unit 14 that calculates the path-dependent sub-postcondition as a path-dependent sub-post condition, and The target function input analysis unit 15 that calculates a constraint on the input value of the target function for executing the path after returning from the lower-level function in the target function as a path-dependent target precondition, and an input variable that satisfies the path-dependent target precondition A driver function that provides a value, and a test case generation unit 16 that generates a stub function that outputs an output variable value that satisfies a path-dependent sub-post condition.

  In the above embodiment, the program unit test support apparatus as shown in the following (1) to (4) is also disclosed.

(1) A function that simulates the behavior of a driver function that gives an input variable value to a target function that is a target function of a program unit test and calls the target function, and a lower function that is called by the target function. A program unit test support apparatus (for example, the program unit test support apparatus 10) that supports a program unit test that is performed using a stub function that is used to identify a portion that is affected by an output variable value of a lower function in the target function A part (for example, the syntax analysis unit 13) and the target function part analyze the path after returning from the lower function, and the path dependent subordinate satisfies the constraints that the output variable value of the lower function must satisfy in order to execute the path A stub function output analysis unit (for example, stub function output analysis unit 14) that is calculated as a post-condition, and a path-dependent A target function input analysis unit (for example, a target function input analysis unit) that calculates, as a path-dependent target precondition, a constraint on an input value of a target function for executing a path after returning from a lower function in the target function based on a post-condition 15) and a test case generation unit (for example, the test case generation unit 16) that generates a driver function that provides an input variable value that satisfies the path-dependent target pre-condition and a stub function that outputs an output variable value that satisfies the path-dependent sub-post condition And a program unit test support device.

(2) In the program unit test support device, the syntax analysis unit includes call relationship information including a pair of a higher function that calls the target function and a lower function that is called from the target function, and dependency information that indicates the dependency of the variable in the target function May be extracted, and based on the call relationship information and the dependency relationship information, a portion that is affected by the output variable value of the lower function in the target function may be specified. According to such a program unit test support apparatus, even if there are a plurality of expressions depending on the lower function or the output variable value of the lower variable, it is possible to generate a test case that covers all the lower functions and paths.

(3) In the program unit test support apparatus, the stub function output analysis unit includes a determination expression for comparing the output variable of the lower function or a variable dependent on the output variable with another variable in the target function. When a route is selected based on the result of the above, the route dependent sub-post condition may be calculated based on the determination formula. According to such a program unit test support device, it is possible to generate a stub function that covers all paths even if a path is selected in the target function based on the result of the determination formula.

(4) In the program unit test support device, the target function input analysis unit is a constraint related to a path-dependent sub-post condition, a sub-precondition that is a constraint regarding the input value of a predefined sub-function, and an output value of the sub-function. Based on the sub-postconditions, the precondition of the subordinate function depending on the path is calculated as the path-dependent subprecondition, and the constraint condition at the start point of the target function that satisfies the path-dependent subprecondition is set to the path-dependent target weakest precondition. Even if it is configured to calculate the path-dependent target precondition by calculating the logical product of the path-dependent target weakest precondition and the target precondition that is the constraint on the input value of the target function. Good. According to such a program unit test support device, it is possible to generate a driver function corresponding to the stub function and satisfying the precondition of the target function depending on the path.

  This application claims the priority on the basis of Japanese application Japanese Patent Application No. 2012-101184 for which it applied on April 26, 2012, and takes in those the indications of all here.

  While the present invention has been described with reference to the embodiments, the present invention is not limited to the above embodiments. Various changes that can be understood by those skilled in the art can be made to the configuration and details of the present invention within the scope of the present invention.

Industrial applicability

  The program unit test support apparatus according to the present invention can be applied to a unit test using a driver function and a stub function of a program written in a high-level programming language.

DESCRIPTION OF SYMBOLS 10 Program unit test support apparatus 11 Input / output device 12 Processing control part 13 Syntax analysis part 14 Stub function output analysis part 15 Target function input analysis part 16 Test case generation part 17 Persistent storage part 18 Temporary storage part

Claims (6)

A driver function that gives an input variable value to the target function that is the target function of the program unit test and calls the target function, and a stub function that simulates the operation of the lower function that the target function calls and that is replaced with the lower function A program unit test support device for supporting program unit tests performed using
A structure analysis unit for identifying a portion affected by the output variable value of the lower function in the target function;
In the portion of the target function, a stub function that analyzes a route after returning from the lower function and calculates a constraint that should be satisfied by an output variable value of the lower function to execute the route as a route-dependent sub-post condition An output analyzer;
A target function input analysis unit that calculates, as a path dependent target precondition, a constraint on an input value of the target function for executing the path after returning from the lower function in the target function, based on the path dependent lower postcondition When,
A program comprising: a driver function that provides an input variable value that satisfies the path-dependent target pre-conditions; and a test case generation unit that generates a stub function that outputs an output variable value that satisfies the path-dependent sub-post conditions. Unit test support device. The structural analysis department
Call relationship information including a pair of a higher-level function that calls the target function and a lower-level function called from the target function, and dependency relationship information that indicates a dependency relationship of variables in the target function are extracted, and the call relationship information and the dependency relationship are extracted. The program unit test support apparatus according to claim 1, wherein a part of the target function that is affected by an output variable value of the lower function is specified based on information. The stub function output analysis unit
If the target function has a judgment expression that compares the output variable of the lower function or a variable that depends on the output variable with another variable, and the path is selected according to the result of the judgment expression, The program unit test support apparatus according to claim 1 or 2, wherein a path-dependent sub-post condition is calculated. The target function input analysis unit
Based on a path-dependent sub-post condition, a sub-pre-condition that is a constraint on the input value of the sub-function defined in advance, and a sub-post condition that is a constraint on the output value of the sub-function Calculate the condition as a route-dependent sub-precondition,
The constraint condition at the start point of the target function that satisfies the path-dependent sub-previous condition is calculated as the path-dependent target weakest pre-condition,
The path-dependent target precondition is calculated by calculating a logical product of the path-dependent target weakest precondition and a target precondition that is a constraint on the input value of the target function. The program unit test support device according to any one of the above. A driver function that gives an input variable value to the target function that is the target function of the program unit test and calls the target function, and a stub function that simulates the operation of the lower function that the target function calls and that is replaced with the lower function A program unit test support method for supporting a program unit test performed using
Identify a portion of the target function that is affected by the output variable value of the subordinate function;
In the part of the target function, analyze the path after the return from the lower function, and calculate a constraint that the output variable value of the lower function to satisfy the path to execute the path as a path-dependent sub-post condition,
Based on the path-dependent sub-post condition, a constraint on the input value of the target function for executing the path after returning from the sub-function in the target function is calculated as a path-dependent target pre-condition,
A program unit test support method, comprising: generating a driver function that provides an input variable value that satisfies the path-dependent target pre-condition and a stub function that outputs an output variable value satisfying the path-dependent sub-post condition. On the computer,
A driver function that gives an input variable value to the target function that is the target function of the program unit test and calls the target function, and a stub function that simulates the operation of the lower function that the target function calls and that is replaced with the lower function A program unit test support program for executing a process for supporting a program unit test performed using
On the computer,
A structural analysis process for identifying a portion affected by the output variable value of the lower function in the target function;
In the portion of the target function, a stub function that analyzes a route after returning from the lower function and calculates a constraint that should be satisfied by an output variable value of the lower function to execute the route as a route-dependent sub-post condition Output analysis processing,
Target function input analysis processing for calculating, as a path dependent target precondition, a constraint on an input value of the target function for executing the path after the return from the lower function in the target function based on the path dependent lower postcondition When,
Program unit test support program for executing a driver function that provides an input variable value that satisfies the path-dependent target pre-condition and a test case generation process that generates a stub function that outputs an output variable value that satisfies the path-dependent sub-post condition .

Images