JP5755861B2 - Test case generation apparatus, test case generation method, and test case generation program - Google Patents

Description

  The present invention relates to a test case generation device, a test case generation method, and a test case generation program.

  In software development, software testing is performed to check whether a product on which the software is installed satisfies the specifications or to check the quality of the product. This test is an important step.

  There is a white box test as a test based on the analysis of the internal structure of the software. The white box test is a test for confirming whether or not the software to be tested functions normally based on knowledge about the internal structure of the software to be tested.

  One of the white box tests is a pass test. The path test is a technique for testing based on test data such that all code in a program is executed. In the path test, a path, that is, a control flow path is selected from the test target software, and the path is tested. Specifically, in the pass test, the test target software is executed after the input value and preconditions for the test target software are determined in advance. Then, it is determined whether or not the software to be tested functions normally by determining whether or not the test result satisfies the expected result and the post-condition. The path test is also called a control flow test.

  The path test method is a basic method for testing software. For example, Non-Patent Document 1 and Non-Patent Document 2 describe a path test method.

  When performing a path test, a test case including a selected path, an input value and a precondition for executing the path, and an expected result and a postcondition are determined in advance.

  Non-Patent Document 1 and Non-Patent Document 2 disclose a method in which a person performs path test design. Patent Documents 1 and 2 disclose examples of systems that automate the design of the path test.

Boris Visor, “Software Testing Techniques”, Nikkei BP Publishing Center, February 25, 1994, pp. 49-97 Lee Copeland, “First-time Software Testing Techniques”, Nikkei Business Publications, November 7, 2005, pp. 125-148

JP 2008-299502 A Japanese Patent Laid-Open No. 2004-220269

  In the path test design as described above, there is an infeasible path that cannot be executed even if the selected path is combined and set with any input value. In software such as an information system, a path is selected by using a variable representing the meaning of a flag, and there are usually many branch points due to flag conditions in a program.

  When a certain flag is unchanged during a certain process, the flag cannot branch to the true side under a certain branch condition, and the flag cannot branch to the false side under another branch. Such a path is called an infeasible path. When an infeasible path is included in a test case, there is a problem that test efficiency decreases.

  In any of the above prior art documents, there is a problem that an infeasible path is included in the test case.

  The present invention has been made in view of the above problems, and has as its main object to provide a test case generation device, a test case generation method, and a test case generation program that improve the test efficiency of a computer program represented by source code. To do.

  The test case generation device according to the present invention extracts, from the input source code, a path indicating a flow when the computer program represented by the source code is executed as a test case, and a determination included in the extracted path Based on extraction means for extracting a condition and the extracted determination condition, it is determined whether or not the path is executable. If it is determined that the path is not executable, the path is excluded from the test case. Determination means.

  The test case generation method according to the present invention extracts, as a test case, a path indicating a flow when a computer program represented by the source code is executed from the input source code, and a determination included in the extracted path Extracting a condition, determining whether or not the path is executable based on the extracted determination condition, and removing the path from the test case when it is determined that the path is not executable .

  This object is also achieved by a computer program for realizing the test case generation apparatus having the above-described configurations and the corresponding method by a computer, and a computer-readable storage medium storing the computer program. Is done.

  According to the present invention, it is possible to improve the test efficiency of the computer program represented by the source code.

It is a block diagram which shows the structure of the test case production | generation apparatus which concerns on the 1st Embodiment of this invention. It is a figure which shows the hardware constitutions of the test case production | generation apparatus which concerns on the 1st Embodiment of this invention. It is a flowchart which shows operation | movement of the test case production | generation apparatus which concerns on the 1st Embodiment of this invention. It is a figure which shows the specific example of the test case produced | generated by the test case production | generation apparatus which concerns on the 1st Embodiment of this invention. It is a figure which shows the specific example of the test case produced | generated by the test case production | generation apparatus which concerns on the 2nd Embodiment of this invention. It is a figure which shows the specific example of the test case produced | generated by the test case production | generation apparatus which concerns on the 3rd Embodiment of this invention. It is a block diagram which shows the structure of the test case production | generation apparatus which concerns on the 4th Embodiment of this invention.

First Embodiment Next, an embodiment of the present invention will be described in detail with reference to the drawings.

  FIG. 1 is a block diagram showing a configuration of a test case generation apparatus 10 according to the first embodiment of the present invention. As illustrated in FIG. 1, the test case generation device 10 includes an input unit 11, a path analysis unit 12, a predicate normalization unit 13, an feasibility determination unit 14, a path analysis result storage unit 15, and an output unit 16.

  The test case generation device 10 in FIG. 1 has a hardware configuration shown in FIG. 2 when implemented by a computer. The configuration shown in FIG. 2 includes a CPU (Central Processing Unit) 40, a storage medium 41 such as a memory, and a program 42 included in the storage medium 41. The CPU 40 of the test case generation apparatus 10 controls the overall operation of the test case generation apparatus 10 by executing various software programs (computer programs). In this embodiment and other embodiments described below, the CPU 40 executes a software program for each function (each unit) included in the test case generation device 10 described below while appropriately referring to a storage medium 41 such as a memory. To do.

  More specifically, the CPU 40 executes software programs such as the input unit 11 and the path analysis unit 12 included in the test case generation apparatus 10 while appropriately referring to a storage medium 41 such as a memory.

  An outline of the test case generation device 10 will be described.

  The input unit 11 reads the source code and notifies the path analysis unit 12 of the read source code. The input unit 11 has a function of reading source code stored in a hard disk storage medium such as the source code storage unit 20. The input unit 11 may have a function of reading source code via a network.

  The path analysis unit 12 receives the source code from the input unit 11 and extracts all possible paths as a processing flow from the received source code. A path represents a flow when a computer program represented by a source code is executed, and is information indicating which part of the source code passes when the computer program is executed.

  The path analysis unit 12 extracts a predicate in a conditional branch that controls the path from the extracted path. The predicate in the conditional branch for controlling the path is information indicating a determination condition at a location where the branch is caused by the condition in the source code (details will be described later with reference to FIG. 4). The path analysis unit 12 stores the extracted path and predicate in the path analysis result storage unit 15.

  The predicate normalization unit 13 reads the predicate from the path analysis result storage unit 15, normalizes the read predicate, and saves it in the path analysis result storage unit 15 again. Here, normalization of the predicate is to change only the expression without changing the meaning of the predicate so that the predicates can be compared with each other (details will be described later with reference to FIG. 4).

  The feasibility determination unit 14 reads the path and the normalized predicate included in the path from the path analysis result storage unit 15 and determines whether the path is executable. Specifically, the feasibility determination unit 14 reads two normalized predicates included in the path and compares them. Then, the feasibility determination unit 14 determines whether or not the meanings of the two predicates are the same, or whether or not the other is not possible when one is satisfied, and based on the determination result Determine if the path is executable.

  If the two predicates cannot be satisfied at the same time in the execution flow, the feasibility determination unit 14 determines that the path including these predicates is not executable. The feasibility determination unit 14 notifies the output unit 16 of a set of paths excluding paths determined to be unexecutable as test cases.

  The output unit 16 outputs a test case that does not include an infeasible path obtained by the feasibility determination unit 14. The output unit 16 has a function of accumulating results in a storage medium such as a hard disk such as the test case storage unit 30. Further, the output unit 16 may have various output forms such as outputting a test case on a screen or via a network.

  FIG. 3 is a flowchart showing the operation of the test case generation apparatus 10. FIG. 4 is a diagram illustrating a specific example of a test case generated by the test case generation apparatus 10. The operation of the test case generation device 10 will be described with reference to FIGS.

  When generating the test case, the input unit 11 of the test case generation apparatus 10 reads the source code from the source code storage unit 20 and notifies the path analysis unit 12 of the read source code. When the path analysis unit 12 acquires the source code from the input unit 11, the path analysis unit 12 extracts all paths or a set of paths under a certain specified condition from the source code, and stores the extracted paths in the path analysis result. The data is stored in the unit 15 (step S101).

  For example, a case where the source code is as shown in FIG. 4 will be described. The source code 51 shows the following contents. That is, first, process 1 is executed. Next, there is a conditional branch “if” statement having “x> 0” as the predicate A, and the process 2 is executed when the predicate A is true, and the process 3 is executed when the predicate A is false. Next, process 4 is executed. Next, there is a conditional branch “if” statement having the same “x> 0” as predicate A as predicate B, and processing 5 is executed when predicate B is true, and processing 6 is performed when predicate B is false. Is executed. Next, process 7 is executed.

The path analysis unit 12 extracts all possible paths from the source code 51 as an execution flow. That is,
As pass 1, 1 (A true) 24 (B true) 57
As pass 2, 1 (A false) 34 (B true) 57
As pass 3, 1 (A true) 24 (B false) 67
As pass 4, 1 (A false) 34 (B false) 67
Extract the path. In the path notation, “1” to “7” represent process names, and “A” and “B” represent predicate names. The notation “true / false” after the predicate indicates that the predicate is true or false. Processing is performed in the order of the above description. The path analysis unit 12 stores the extracted path in the path analysis result storage unit 15.

  Next, the path analysis unit 12 extracts a predicate from the extracted path (step S102). That is, the path analysis unit 12 first extracts a predicate from the path 1. “X> 0” is extracted as the predicate A, and “x> 0” is extracted as the predicate B. The path analysis unit 12 stores the extracted predicates A and B in the path analysis result storage unit 15.

  Subsequently, the predicate normalization unit 13 normalizes the predicate stored by the path analysis unit 12, and stores the result in the path analysis result storage unit 15 (step S103). That is, the predicate normalization unit 13 normalizes the predicate A to “x> 0” and the predicate B to “x> 0”, respectively, and determines that the predicate A and the predicate B are equivalent ( recognize. Then, the predicate normalization unit 13 saves the normalized result and the predicate A and the predicate B are equivalent in the path analysis result storage unit 15.

  Subsequently, the feasibility determination unit 14 determines whether or not the path is executable based on the normalized predicate stored in the path analysis result storage unit 15 and outputs the determination result to the output unit 16 ( Step S104).

  Here, as shown in FIG. 4, predicate A and predicate B are equivalent. Therefore, the cases where “predicate A is true” and “predicate B is false” and “predicate A is false” and “predicate B is true” are not satisfied. Therefore, the feasibility determination unit 14 determines that a path including such a condition is an infeasible path, and excludes the path from the set of paths stored in the path analysis result storage unit 15. The result is output to the output unit 16 as a test case. In this case, the non-executable paths are path 2 and path 3. Therefore, the feasibility determination unit 14 outputs a set of paths including the path 1 and the path 4 to the output unit 16 as a test case.

  As described above, according to the first embodiment, the path analysis unit 12 of the test case generation apparatus 10 extracts a path from the source code, extracts a predicate from the extracted path, and predicate normalization unit 13 Normalizes the extracted predicates. Then, the feasibility determination unit 14 determines whether or not the path is executable based on the normalized predicate. The feasibility determination unit 14 outputs a set of paths excluding non-executable paths as a test case. Since the present embodiment has the above-described configuration, it is possible to obtain an effect that it is not necessary for the tester to determine whether the test case can be executed before the test is performed. In addition, since it is possible to exclude non-executable paths from the test cases, the number of test cases is reduced, and the test efficiency of the computer program represented by the source code can be improved.

  In the first embodiment and each of the following embodiments, determining the relationship between predicates is not limited to being performed by the predicate normalization unit 13 but is performed by the feasibility determination unit 14. Also good.

Second Embodiment In the second embodiment, another example in which a test case is generated by the test case generation apparatus 10 described in the first embodiment will be described.

  FIG. 5 is a diagram illustrating a specific example of a test case generated by the test case generation apparatus 10. The source code 52 shown in FIG. 5 is the same as the source code 51 shown in FIG. 4 except that the contents of the predicates A and B are different. That is, here, the predicate A is “x> 1” and the predicate B is “0 <x−1”.

  The test case generation device 10 performs an operation similar to the operation illustrated in FIG. That is, the path analysis unit 12 acquires the source code 52 from the input unit 11, extracts a path from the source code 52, and stores the extracted path in the path analysis result storage unit 15. Here, the path analysis unit 12 extracts the same path 1-4 as in the first embodiment.

  Subsequently, the path analysis unit 12 extracts a predicate from the extracted path and stores the extracted predicate in the path analysis result storage unit 15. Here, the path analysis unit 12 extracts “x> 1” as the predicate A and “0 <x−1” as the predicate B, and stores them in the path analysis result storage unit 15.

  Subsequently, the predicate normalization unit 13 normalizes the predicate stored by the path analysis unit 12 and stores the result in the path analysis result storage unit 15. That is, the predicate normalization unit 13 normalizes the predicate A such as “x> 1” and the predicate B such that “x> 1”, and recognizes that the predicate A and the predicate B are equivalent. . Then, the predicate normalization unit 13 saves the normalized result and the predicate A and the predicate B are equivalent in the path analysis result storage unit 15.

  Subsequently, the feasibility determination unit 14 determines whether or not the path is executable based on the normalized predicate stored in the path analysis result storage unit 15, and outputs the determination result to the output unit 16.

  Here, as in the first embodiment, predicate A and predicate B are equivalent. Therefore, the cases where “predicate A is true” and “predicate B is false” and “predicate A is false” and “predicate B is true” are not satisfied. Therefore, the feasibility determination unit 14 determines that a path including such a condition is an infeasible path and saves the path in the path analysis result storage unit 15 as in the first embodiment. Those excluded from the set of paths are output to the output unit 16 as test cases. That is, the feasibility determination unit 14 outputs the path 1 and the path 4 obtained by excluding the path 2 and the path 3 from the set of paths to the output unit 16 as a test case.

  As described above, according to the second embodiment, as in the first embodiment, the path analysis unit 12 of the test case generation device 10 extracts a path from the source code and extracts the path from the extracted path. The predicate is extracted, and the predicate normalization unit 13 normalizes the extracted predicate. Then, the feasibility determination unit 14 determines whether or not the path is executable based on the normalized predicate. The feasibility determination unit 14 outputs a set of paths excluding non-executable paths as a test case. Since the present embodiment has the above-described configuration, it is possible to obtain an effect that it is not necessary for the tester to determine whether the test case can be executed before the test is performed. In addition, since it is possible to exclude non-executable paths from the test cases, the number of test cases is reduced, and the test efficiency of the computer program represented by the source code can be improved.

Third Embodiment In the third embodiment, another example in which a test case is generated by the test case generation apparatus 10 described in the first embodiment will be described.

  FIG. 6 is a diagram illustrating a specific example of a test case generated by the test case generation apparatus 10. The source code 53 shown in FIG. 6 is the same as the source code 51 except that the contents of the predicate A and the predicate B are different from the source code 51 shown in FIG. That is, here, the predicate A is x> 0 and the predicate B is x <= 0.

  The test case generation device 10 performs an operation similar to the operation illustrated in FIG. That is, the path analysis unit 12 acquires the source code 52 from the input unit 11, extracts a path from the source code 52, and stores the extracted path in the path analysis result storage unit 15. Here, the path analysis unit 12 extracts the same path 1-4 as in the first embodiment.

  Subsequently, the path analysis unit 12 extracts a predicate from the extracted path and stores the extracted predicate in the path analysis result storage unit 15. Here, the path analysis unit 12 extracts x> 0 as the predicate A and x <= 0 as the predicate B, and stores them in the path analysis result storage unit 15.

  Subsequently, the predicate normalization unit 13 normalizes the predicate stored by the path analysis unit 12 and stores the result in the path analysis result storage unit 15. That is, the predicate normalization unit 13 normalizes the predicate A as “x> 0” and the predicate B as “x <= 0”, respectively, and the negation of the predicate A is equivalent to the predicate B. Recognize Then, the predicate normalization unit 13 stores in the path analysis result storage unit 15 the normalized result and the negation of the predicate A and the predicate B are equivalent.

  Subsequently, the feasibility determination unit 14 determines whether or not the path is executable based on the normalized predicate stored in the path analysis result storage unit 15, and outputs the determination result to the output unit 16.

  Here, the negation of predicate A and predicate B are equivalent. Thus, since predicate A and predicate B are mutually exclusive, the cases where “predicate A is true” and “predicate B is true” and “predicate A is false” and “predicate B is false” do not hold. . Therefore, the feasibility determination unit 14 determines that a path including such a condition is an infeasible path, and excludes the path from the set of paths stored in the path analysis result storage unit 15. The result is output to the output unit 16 as a test case. That is, the feasibility determination unit 14 outputs the path 2 and the path 3 obtained by excluding the path 1 and the path 4 from the set of paths to the output unit 16 as a test case.

  As described above, according to the third embodiment, as in the first embodiment, the path analysis unit 12 of the test case generation device 10 extracts a path from the source code, and from the extracted path. The predicate is extracted, and the predicate normalization unit 13 normalizes the extracted predicate. Then, the feasibility determination unit 14 determines whether or not the path is executable based on the normalized predicate. The feasibility determination unit 14 outputs a set of paths excluding non-executable paths as a test case. Since the present embodiment has the above-described configuration, it is possible to obtain an effect that it is not necessary for the tester to determine whether the test case can be executed before the test is performed. In addition, since it is possible to exclude non-executable paths from the test cases, the number of test cases is reduced, and the test efficiency of the computer program represented by the source code can be improved.

Fourth Embodiment FIG. 7 is a block diagram showing a configuration of a test case generation device 60 according to a fourth embodiment of the present invention. As shown in FIG. 7, the test case generation device 60 includes an extraction unit 61 and a determination unit 62.

  The extraction unit 61 extracts, from the input source code, a path indicating a flow when the computer program represented by the source code is executed as a test case, and extracts a determination condition included in the extracted path. The determination unit 62 determines whether or not the path is executable based on the extracted determination condition. If it is determined that the path is not executable, the path is excluded from the test case.

  The extraction unit 61 corresponds to the path analysis unit 12 of the first embodiment, and the determination unit 62 corresponds to the predicate normalization unit 13 and the feasibility determination unit 14 of the first embodiment.

  As described above, according to the fourth embodiment, since the test case generation device 60 has the above configuration, it is possible to improve the test efficiency of the computer program represented by the source code.

  The present invention can be applied to uses such as a test case generation apparatus that generates a test case in a test in software development, and a program for realizing the test case generation apparatus on a computer. The test case generation function includes the test case generation function for hardware in hardware development, the test case generation function for models in model-based development, and the test case generation function for logical description languages such as business logic and business processes. It can also be applied to.

DESCRIPTION OF SYMBOLS 10 Test case production | generation apparatus 11 Input part 12 Path analysis part 13 Predicate normalization part 14 Executability determination part 15 Path analysis result memory | storage part 16 Output part 20 Source code memory | storage part 30 Test case memory | storage part 40 CPU
41 Storage Medium 42 Program 60 Test Case Generation Device 61 Extraction Unit 62 Determination Unit

Claims (3)

An extraction means for extracting, as a test case, a path indicating a flow when the computer program represented by the source code is executed from the input source code, and extracting a determination condition included in the extracted path;
Normalizing means for normalizing the judgment condition extracted by the extracting means;
A determination unit that determines whether or not the path is executable based on the determination condition normalized by the normalization unit; and when the path is determined not to be executable, a determination unit that excludes the path from the test case; equipped with a,
The determination unit includes a plurality of determination conditions normalized by the normalization unit, a path that does not hold when the plurality of determination conditions are equivalent to each other, and the plurality of determination conditions are mutually exclusive. A test case generation device that determines that a path that does not hold in the case is not executable and excludes the path from the test case. From the input source code, a path indicating a flow when the computer program represented by the source code is executed is extracted as a test case, and a determination condition included in the extracted path is extracted.
  Normalizing the extracted judgment condition;
  Based on the normalized determination condition, determine whether or not the path is executable, and if it is determined that the path is not executable, exclude the path from the test case,
  In determining whether the path can be executed, among the paths including the plurality of normalized determination conditions, a path that is not satisfied when the plurality of determination conditions are equivalent to each other, and the plurality of determinations A test case generation method that determines that a path that does not hold when the conditions are mutually exclusive is not executable and excludes the path from the test case. An extraction process for extracting a path indicating a flow when the computer program represented by the source code is executed as a test case from the input source code, and extracting a determination condition included in the extracted path;
  Normalization processing for normalizing the extracted judgment condition;
  Based on the normalized determination condition, it is determined whether or not the path is executable, and when it is determined that the path is not executable, a determination process of excluding the path from the test case;
  In the determination process, among the paths including the plurality of normalized determination conditions, a path that is not satisfied when the plurality of determination conditions are equivalent to each other, and a path that is not satisfied when the plurality of determination conditions are mutually exclusive A test case generation program for causing a computer to execute a process of determining that a pass is not executable and excluding it from the test case.

Images