KR20090104275A - Pairwise test case generation method based on module dependency and computer readable medium for recording program thereof - Google Patents

Abstract

PURPOSE: A method generating a test case considering a dependent relation between modules and a recording media storing a program are provided to express a dependent relation between the modules within a range which a number of test cases does not increased within the range. CONSTITUTION: A method generating a test case considering a dependent relation between modules is as follows. Two pair of test cases are generated(S100). PTMD(Pair wise Testing based on Module Dependency) test case which satisfied with a module dependent relation is generated by calling for one node function(S200). A proper test case set is generated by summing the PTMD test case and the two test case.

Description

TECHNICAL AND COMPUTER READABLE MEDIUM FOR RECORDING PROGRAM THEREOF}

The present invention relates to a method for generating test cases considering the dependencies between modules, and more particularly to a method for generating more reliable test cases using a modified two-pair test case algorithm considering the dependencies between system modules. .

In general, it is virtually impossible to test all the combinations of inputs a system can have and the values that each variable can have. Therefore, it is necessary to select a test case for testing a system among all input combinations. In the past, a pairwise test case generation method was used as a method of generating input combinations to be injected into the system.

The conventional method of generating a two-pair test case (see, for example, the document "A Test Generation Strategy for Pairwise testing" of "IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 1, JANUARY 2002") is based on the input variables of the system. For each pair, we create a test case so that all combinations appear in the test case. For example, if there are parameters A, B, C, A can be A ₁ , A ₂ , B can be B ₁ , B ₂ , C can have a value of C ₁ , C ₂ , then for (A, B) All pairs (A ₁ , B ₁ ), (A ₁ , B ₂ ), (A ₂ , B ₁ ), (A ₂ , B ₂ ) must all exist and all combinations of (A, C) ( A ₁ , C ₁ ), (A ₁ , C ₂ ), (A ₂ , C ₁ ), (A ₂ , C ₂ ) should appear. Similarly, all combinations (B ₁ , C ₁ ), (B ₁ , C ₂ ), (B ₂ , C ₁ ), (B ₂ , C ₂ ) for (B, C) must appear in the generated test case do. In other words, the next four test cases can satisfy these conditions.

(A ₁ , B ₁ , C ₁ ), (A ₁ , B ₂ , C ₂ ), (A ₂ , B ₁ , C ₂ ), (A ₂ , B ₂ , C ₁ )

The two-pair test case generation method is an efficient way to reduce all combinations of the system. However, since the test case is generated without considering the system characteristics such as the "dependency" between the modules in the system, the necessary test cases are omitted. May occur. For this reason, in the case of the conventional two-pair test case generation method (that is, a test case generation method that does not consider the "dependency" between modules), a test case that cannot detect an error that may have a fatal effect on the system May be generated.

Here, the "dependency" between internal modules of the system S means that the output value of one module becomes the input value of another module. This will be described with reference to FIG. 1.

FIG. 1 is a diagram for explaining a "dependency" between modules in a system. The system S of FIG. 1 has three input variables {X, Y, Z} and two internal modules OP ₁ and OP ₂ . Have X and Y are inputs of OP ₁ and W is output. Therefore, it can be expressed as W = OP ₁ (X, Y). If W and Z are inputs of OP ₂ , then OP ₁ and OP ₂ are said to be in a "dependency" with each other. A system having a "dependency" between these modules can be modeled in a tree form as shown in FIG. 1 and can be expressed as "S = (X XOR Y) AND Z". In FIG. 1, OP ₁ and OP ₂ are "XOR" and "AND" operators, respectively, and OP ₂ becomes a top node of the tree.

By the conventional two-pair test case generation method (see, for example, the document "A Test Generation Strategy for Pairwise testing" of "IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 1, JANUARY 2002") in the system of FIG. The result of generating a test case (two pair test case) is shown in Table 1 below.

TABLE 1

X Y W Z T T F T T F T F F T T F F F F T

However, in the case of testing the OP ₂ module of FIG. 1 using the two pair test case of [Table 1] generated by the conventional two pair test case generation method, (W, Z) = {(T, T) , (F, F)} Because the test cases are not included (ie, it does not consider that OP ₁ and OP ₂ are "depending on each other"), there is a problem in that reliable test results cannot be expected.

The present invention has been proposed to solve the above-described problems, and an object of the present invention is to provide a test case capable of expressing a dependency relationship between modules within a range in which the number of test cases does not increase significantly compared to a conventional two-pair test generation method. To generate.

In order to achieve the above object, the present invention comprises the steps of (A) generating a two-pair test case; (B) calling a 'ForOneNode' function to generate a 'pairwise testing based on module dependency' (PTMD) test case that satisfies the module dependency; And (C) combining the two pair test cases of step (A) and the 'PTI MD' test cases of step (B) to generate a complete set of test cases. The 'one node' function of step B) is

(B1) determining whether the node is a leaf;

(B2) recursively calling the 'four node' for all the child nodes of the non-leaf node to generate a 'PTI MD' test case for the child node;

(B3) generating two pair test cases using input variables of the non-leaf nodes; And

(B4) replacing the input variable of the two-pair test case generated using the input variable of the non-leaf node with the input variable of the child node of the non-leaf node; It provides a method for generating a test case taking into account the dependencies between the system modules, characterized in that to generate a 'PTI MD' test case that satisfies and / or a computer-readable recording medium recorded a program for performing the method .

According to a preferred embodiment, the 'one node' function of the step (B), after the step (B4), (B5) of the non-leaf node of the test cases for the child node of the non-leaf node The method may further include forcibly adding a test case that is not replaced with an input variable to the 'PTI MD' test case.

Hereinafter, a method of generating a test case in consideration of dependence between system modules according to the present invention and / or a computer-readable recording medium having recorded thereon a program for performing the method will be described in detail with reference to the accompanying drawings.

FIG. 2 is a flowchart illustrating a test case generation method in consideration of the dependency relationship between system modules of the present invention, and FIG. 3 is a diagram illustrating an algorithm of a program implementing the test case generation method of FIG. 2 in pseudo code. to be.

The test case generation method and / or algorithm for the program considering the dependency among the system modules of the present invention is applicable to the system S represented in the form of a tree.

First, terms used in the algorithm of FIGS. 2 and 3 are defined as follows.

nd represents a node. v _i (nd) represents the i th output of nd. Thus, if nd is the last node, it becomes the system's input parameter, and v _i (nd) is its i th value itself. N (nd) is the number of parameters the node has, and C _i represents the i th of a child node of nd. To represent the test case, P _i , which represents a combination of input parameters and values, is presented in order, with t = p1p2p3 ... For example, if test case t = (X, T) (Y, T) (Z, F), it indicates that the X, Y, Z parameter values are T, T, F, respectively. And output (nd, t) shows the output value when t is applied to node nd. PT (nd1, nd2, ...) represents a test case generated by a conventional Pairwise testcase generation algorithm.

2 and 3, the test case generation method in consideration of the dependency between the inventors of the system module, generating a large two-pair test case (S100); Generating a pairwise testing based on module dependency (PTMD) test case satisfying the module dependency by calling the 'ForOneNode' function (S200); And generating a complete set of test cases by combining the two pair test cases of step S100 and the 'P TMD' test cases of step S200 (S300) (see 302 of FIG. 3). . On the other hand, the step of generating the two-pair test case of the step S100 can be implemented by a pairwise test case (Pairwise test case) generation algorithm generally used in the prior art.

In addition, among the main functions of the test case generation method considering the dependency between the present inventors, the 'one node' function in step S200 may include determining whether node nd is a leaf (S202); Recursively calling the 'four node' for all child nodes Cn of the node nd other than the leaf, thereby generating a 'PTI M' test case for the child node Cn (S204); Generating two pair test cases using input variables of the node nd other than the leaf (S206); And replacing the input value of the two-pair test case generated using the input variable of the non-leaf node nd with the input variable of the child node Cn of the non-leaf node nd (S208). do. According to a preferred embodiment, the 'ForOneNode' function applied to the present invention is the input variable of the non-leaf node nd among the test cases for the child node Cn of the non-leaf node nd after the step S208. The method may further include forcibly adding a test case that is not replaced with the 'PTI MD' test case (S210).

In detail, determining whether the node nd constituting the 'one node' function is a leaf (S202) is performed when the node passed to an argument of the 'one node' function is a leaf node. Since the value that can have becomes the test case for the node, a process of making the value that the node nd has can be made as a test case list and returning it (see S203 of FIG. 2 and 304 of FIG. 3).

In addition, in step S204, the 'four node' test case is generated for the child node C n by recursively calling the 'four node' for all the child nodes C n other than the leaf. It is a process of generating a 'pairwise testing based on module dependency (PTMD)' test case for each of the child nodes belonging to the node nd passed into the function's argument (see 306 of FIG. 3).

In addition, the generating of the two-pair test case using the input variable of the non-leaf node nd (S206), for the non-leaf node among the nodes passed by the argument of the 'four node' function, the input variable of the node This is a process of generating a two-pair test case using a value that can have (see 308 of FIG. 3).

In operation S208, the input value of the two-pair test case generated using the input variable of the non-leaf node nd is replaced with the input variable of the child node Cn of the non-leaf node nd. Since the input value of nd is actually the output value of the child node of the node nd, the process of converting the input value of the node nd into the input value of the child node (see 310 of FIG. 3). The 'one node' function applied to the present invention converts the input value for the node nd into the input value of the actual system by the step S208.

In addition, forcibly adding a test case which is not replaced by an input variable of the non-leaf node nd among the test cases for the child node Cn of the non-leaf node nd to the 'PMT' test case (S210) ), If there are test cases for the child node Cn of the non-leaf node nd that do not perform the replacement process in step S208, the test case for the child node is not satisfied. In this case, the test case for which the replacement process is omitted among the test cases for the child node is forcibly added to the test case of node nd transferred to the argument of the 'one node' function (see 312 of FIG. 3).

The test case generation method considering the dependency between the inventors and the system module includes a test case generated by a conventional pairwise testcase generation algorithm in step S100, and the 'powon' according to the present invention in step S200. A complete set of test cases is generated by combining the 'PTI MD' test cases generated by the algorithm of 'ForOneNode' function (S300).

(Example)

According to the test case generation method (algorithm) considering the dependency between the system modules of the present invention, if the result value of the module is determined according to the value of the input variable, the result value of the module affects the next module again. Therefore, if the order of possible values that an input variable can have is changed, the type of test case and the number of test cases are changed. On the other hand, since the conventional pairwise test case generation method (algorithm) does not give meaning to the value of the input variable, the order variation of the input variable only affects the generation combination of the test case. It has no effect on the number of cases.

4 and 5A and 5B, an embodiment of a test generation method in consideration of dependency between the present inventors' system modules will be described. FIG. 4 is an example for explaining the present invention. FIG. 4 is a view illustrating boundary conditions and driving operations of each element (hereinafter, a module) having a height of three floors in which an elevator is installed, and FIGS. 5A and 5B are each module of FIG. Tree showing dependency on.

First, referring to FIG. 4, it is assumed that the height of a building on which an elevator to which the present invention is applied is set as three floors above the ground. In this case, the input variable of the door control module is' DoorReversal ',' CurrentFloor ',' DesiredFloor.f ',' DesiredFloor.d ',' Drive ',' DoorCycle ',' HallCall [floor, direction] ',' CarCall [floor] ',' DoorOpen ',' DoorOpen.old ',' DoorClose ',' DoorClose.old ',' CountDown 'and' CountDown.old '.

Here, 'DoorReversal' has a TRUE value when it is determined that there is an obstacle in the door by the sensor in the door. Otherwise it has a value of FALSE.

'CurrentFloor' refers to the floor where the car of the elevator is currently located. If the car is moving without stopping, it has an INVALID value. That is, it may have a value of INVALID, 1,2,3. 'DesiredFloor.f' and 'DesiredFloor.d' are used to indicate the floor the car should move and the direction to go to it. Therefore, 'DesiredFloor.f' may have a value of 1,2,3 and 'DesiredFloor.d' may have a value of UP, DOWN, STOP.

'Drive' is used to indicate whether the current car is moving or stopped. It can have MOVE and STOP values.

'DoorCycle' has TRUE if the operation door of the elevator door has been performed at least once, otherwise it has FALSE.

'HallCall [floor, direction]' is a variable used to indicate the input of up and down buttons installed in a hall, and has a value corresponding to UP, DOWN, and STOP for each floor. There is no STOP button, so it always has a value of FALSE. The top and bottom layers do not have UP and DOWN buttons, respectively, so they always have FALSE.

'CarCall [floor]' represents the value of the button inside the elevator. Each floor has TRUE and FALSE values. 'DoorOpen' and 'DoorClose' are TRUE if the door is fully open or closed, otherwise FALSE. The 'CountDown' value represents the dwelling timer value that should wait with the door open. If the 'CountDown' value is 0, it means that the timer has expired. Finally, 'DoorOpen.old', 'DoorClose.old', and 'CountDown.old' are used to represent 'DoorOpen', 'DoorClose' and 'CountDown' values before the current run cycle of the elevator system. Losing is a variable.

In FIG. 4, the specification of the elevator door control is shown by dividing it into a guard condition and an action when it is satisfied. The order of each boundary condition represents the order of execution, so the last one is the highest priority.

In order to draw a module dependency tree from FIG. 4, a total of seven boundary conditions may be divided into four categories, (C1, {C2, C3, C4}, C5, C6, and C7). Dividing {C2, C3, C4} into the same classification means that its Action is the same and the preceding part of the Guard Condition is the same as "CurrentFloor == DesiredFloor.f && Drive == STOP". This is because the remainder of the two boundary conditions can be changed to OR. The four modules expressed as described above are represented by a dependency tree as shown in FIG. 5A. Output values of each module are TRUE and FALSE.

5A is a Module Dependency Tree showing the priorities of five modules C1, (C2, C3, C4), C5, C6, and C7. OP ₃ accepts the output values of C1 and (C2, C3, C4), and outputs (C2, C3, C4) if (C2, C3, C4) is TRUE. If (C2, C3, C4) is FALSE and C1 is TRUE, C1 is output. If both input values are FALSE, INVALID value is output. OP ₀ , OP ₁ , and OP ₂ all receive OP _{n +1} input and C7, C6, C5 input, respectively. If C7, C6, and C5 are TRUE, priority is expressed by outputting C7, C6, C5 as an output. Otherwise, OP _{n + 1} is output as it is. Input variables needed to ensure that C1, C5, C6, and C7 satisfy the conditions are connected.

On the other hand, the (C2, C3, C4) module is more complicated than C1, C5, C6, C7. 5B is a tree representing a dependency between (C2, C3, C4) and input variables. There are 7 types of input variables, but 'CurrentFloor' is used for 3 different modules, so 9 types of input variables are represented in the tree. OP ₁₀ and OP ₇ are used to express the conditional expression "CurrentFloor == DesiredFloor.f && Drive == STOP" contained in C2, C3 and C4. And (C2, C3, C4) is an operator that outputs a TRUE value when the input values of OP ₄ and OP ₇ are satisfied, and a FALSE value otherwise. OP ₉ is used to express the "CarCall [CurrentFloor] == TRUE" clause in C4, while OP ₆ and OP ₈ indicate the portion of C3 except the "CurrentFloor == DesiredFloor.f && Drive == STOP" clause. The operator used to bet. Finally, OP ₄ and OP ₅ are used to represent OR operations.

5A and 5B described above, a test generation method considering a dependency relationship between system modules of the present invention is applied to the module dependency tree. At this time, it is assumed that the elevator consists of three floors, and accordingly, input variables' DoorReversal ',' CurrentFloor ',' DesiredFloor.f ',' DesiredFloor.d ',' Drive ',' DoorCycle ', and' HallCall [ floor, direction] ',' CarCall [floor] ',' DoorOpen ',' DoorOpen.old ',' DoorClose ',' DoorClose.old ',' CountDown 'and' CountDown.old 'are 2, 4, 3, It can have three, two, two, sixteen, eight, two, two, two, two, two, two variables. Therefore, there are 2,359,296 test cases of all combinations that can be created using input variables. At this time, 129 are generated when a test case is generated by using the "AllPairs" program, which is one of the conventional representative pairwise test case generation tools.

Meanwhile, in order to measure the number of test cases generated when the test case generation method (algorithm) (see the description of FIGS. 2 and 3) proposed in the present invention is used, the total order of input variable values is randomly calculated. A set of 500 different test cases was obtained. An average of 191.6 test cases were generated.

Since there are 128 pure test cases generated by the conventional "AllPairs" tool, the test case generation method of the present invention additionally adds an average of 63.6 test cases to reflect the dependencies between modules. You can see that it was created.

(Comparative Example)

By using the door control modules of the elevator shown in Fig. 4, the test case generated by the test case generation method (algorithm) (see the description of Figs. 2 and 3) proposed in the present invention is a conventional two-pair test case ( Compared with the test cases generated by the pairwise test case generation method (algorithm), the performance improvement is as follows.

First, a door control module of an elevator as shown in FIG. 4 is configured, 'Fault' is injected therein, and a test case generated by the test case generating method proposed by the present invention and a conventional two-pair test case generating method. It was checked whether the 'Fault' could be found when each test case generated by

The original module without 'Fault' is composed of a total of seven boundary conditions and actions (actions) described in FIG. In addition, three different rules were applied to the original module without 'Fault' to automatically create a module with 'Fault'.

 Only one module with 'Fault' has been changed from the original module. The first rule modifies a specific string included in the boundary condition or its action, creating a total of XXX 'Fault Injected' modules. The type of the replaced string is shown in [Table 2]. The reason for not converting "<", "<=", ">", "> =" strings in [Table 2] is that they do not appear in modules that do not contain 'Fault'.

[Table 2] String Substitution List

Source Destination  ==  ">", "! =", "<", "> =", "<=" || && && || 0 "1", "2", "3", "4" One "0", "2", "3", "4" 2 "0", "1", "3", "4"

The second way to inject 'Fault' is to change the order of the conditional statements in a given module, which is injected to test the priority of the conditional statements. We have listed the boundary conditions and their actions that have priorities and changed their order. Finally, a total of seven 'Fault Injected' modules were created by deleting one boundary condition from a total of seven boundary conditions. The total number of 'Fault injected' modules created using these three rules is 254.

   Next, a test case generated by the test case generation method (algorithm) proposed by the present invention (see the description of FIGS. 2 and 3) and a conventional pairwise test case generation method (algorithm) We experimented with how many 'Fault injected' modules were found by applying each generated test case.

Table 3 is a table summarizing the experimental results. "PTMD" and "Pairwise" respectively indicate the results obtained by using the test case generation method proposed by the present invention and each test case set generated by the "AllPairs" tool, which is a typical two-pair test case generation method, and "All Combination". "Shows the results of using all possible combinations of test cases as input variables.

Table 3 Experimental Results

PTMD Pairwise All Combination  Number of test cases  191.6  128  2,359,296  'Fault' Discovery Count  222.6  214.2  240

The test case generation method proposed in the present invention further generates a test case satisfying a module dependency in addition to the test case generated by the conventional pairwise test case generation method, and thus, the above [Table 3 As can be seen, more reliable test results can be expected than before.

Specifically, [Table 3], when using the test case generation method proposed in the present invention can detect the 'Fault' for the average 222.6 out of a total of 254, according to the conventional two-pair test case generation method In this case, an average of 214.2 'Faults' can be detected. Such performance means that when generating test cases by the present method and the conventional method, only 89.2% and 84.3% of 'Fault' can be found. However, when all test cases that can be combined using input variables are used, the number of 'Faults' found is also 240, which does not find all 'Faults'. The reason is that a module injected with 'Fault' can be made to produce the same result as before the 'Fault' was injected. For example, suppose you changed the sentence "if (DoorReversal == 1)" to "if (DoorReversal> = 1)". Since 'DoorReversal' can only have 0 and 1, the changed module is the same as the original module. You have no choice but to get the result. For this reason, 14 modules cannot be found even with all possible combinations of test cases (All Combination).

Therefore, it can be seen that the actual ratio of 'Fault' found by the test case generated by the test case generation method proposed in the present invention is 94.4% (the conventional method is 89.3%), and thus a fairly reliable test result can be expected.

Although the present invention has been described above with reference to embodiments of the present invention, the present invention is not limited to these embodiments, and various modifications and variations are possible within the spirit and scope defined by the claims. Will be self explanatory.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 is a diagram for explaining a “dependency” between modules in a conventional system.

Figure 2 is a flow chart for explaining a test case generation method in consideration of the dependency between the inventor system module.

3 is a diagram illustrating an algorithm of a program implementing the test case generation method of FIG. 2 in pseudo code; FIG.

4 is a view showing the boundary conditions and driving operation of each module of a three-story building in which an elevator is installed.

5a and 5b are trees showing the dependencies for each of the modules of FIG.

Claims (4)

(A) generating two pair test cases; (B) calling a 'ForOneNode' function to generate a 'pairwise testing based on module dependency' (PTMD) test case that satisfies the module dependency; And (C) combining the two pair test cases of step (A) and the 'PTI MD' test cases of step (B) to generate a complete set of test cases. The 'one node' function of step B) is (B1) determining whether the node is a leaf; (B2) recursively calling the 'four node' for all the child nodes of the non-leaf node to generate a 'PTI M' test case for the child node; (B3) generating two pair test cases using input variables of the non-leaf nodes; And (B4) replacing the input variable of the two-pair test case generated using the input variable of the non-leaf node with the input variable of the child node of the non-leaf node; A method for generating a test case in consideration of dependencies between system modules, characterized in that to generate a 'PTI MD' test case satisfying the. The method of claim 1, The 'one node' function of step (B) is, after the step (B4), (B5) further including forcibly adding a test case, which is not replaced with an input variable of the non-leaf node, among the test cases for the child node of the non-leaf node to the 'PTI MD' test case. A method for generating test cases that takes into account the dependencies between the system modules. (A) generating two pair test cases; (B) calling a 'ForOneNode' function to generate a 'pairwise testing based on module dependency' (PTMD) test case that satisfies the module dependency; And (C) combining the two pair test cases of step (A) and the 'PTI MD' test cases of step (B) to generate a complete set of test cases. The 'one node' function of step B) is (B1) determining whether the node is a leaf; (B2) recursively calling the 'four node' for all the child nodes of the non-leaf node to generate a 'PTI M' test case for the child node; (B3) generating two pair test cases using input variables of the non-leaf nodes; And (B4) replacing the input variable of the two-pair test case generated using the input variable of the non-leaf node with the input variable of the child node of the non-leaf node; A computer-readable recording medium having recorded thereon a program for performing a method of generating a test case in consideration of a dependency between system modules, wherein the test case satisfies a system module. The method of claim 3, wherein The 'one node' function of step (B) is, after the step (B4), (B5) further including forcibly adding a test case, which is not replaced with an input variable of the non-leaf node, among the test cases for the child node of the non-leaf node to the 'PTI MD' test case. A computer-readable recording medium having recorded thereon a program for performing a method for generating a test case taking into account the dependencies between system modules.

Images