WO2016170937A1 - テスト自動化装置、テスト自動化方法及びテスト自動化プログラム - Google Patents

テスト自動化装置、テスト自動化方法及びテスト自動化プログラム Download PDF

Info

Publication number
WO2016170937A1
WO2016170937A1 PCT/JP2016/060213 JP2016060213W WO2016170937A1 WO 2016170937 A1 WO2016170937 A1 WO 2016170937A1 JP 2016060213 W JP2016060213 W JP 2016060213W WO 2016170937 A1 WO2016170937 A1 WO 2016170937A1
Authority
WO
WIPO (PCT)
Prior art keywords
test
test case
path
factor
result
Prior art date
Application number
PCT/JP2016/060213
Other languages
English (en)
French (fr)
Inventor
克希 小林
進也 田口
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to JP2017514040A priority Critical patent/JP6143993B2/ja
Publication of WO2016170937A1 publication Critical patent/WO2016170937A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software

Definitions

  • the present invention relates to a test automation device, a test automation method, and a test automation program.
  • Non-Patent Document 1 the operation of software is represented by a UML (Uniform Modeling Language) activity diagram, and test cases are automatically generated based on the degree to which the paths from the start to the end in the activity diagram are covered.
  • UML Uniform Modeling Language
  • the orthogonal table is a method for enumerating test cases by automatically combining possible values of data that affects the operation of the test target, such as the function and parameters of the test target.
  • this orthogonal table has been improved and processing that has been difficult with the orthogonal table, such as the elimination of data that cannot be combined with data values, the increase in the number of data and the types of possible values, etc.
  • a HAYST method that realizes the above has been proposed.
  • Patent Document 1 discloses a method for comprehensively generating test cases by examining combinations of input values and output values of data that affect the operation of a test target.
  • a test case of the combination is generated, and the generated test case is added.
  • a diagram describing the operation of software such as a flowchart or a state machine diagram
  • a processing route in the model is referred to as a path.
  • the “coverage rate” represents the ratio of the number of listed paths out of the total number of paths in the model.
  • the “defect location” represents a position where a defect exists on the path.
  • the “defect information” represents details of the defect including the defect location, the type of defect, data related to the defect, and the like.
  • the types of defects are, for example, defects that generate unexpected values, model structural defects, and the like.
  • the method of Non-Patent Document 1 focuses on only the path coverage when generating test cases.
  • a test case that covers a path is generated without considering a portion in which a defect on the code may exist. Therefore, when a defect is detected, a comprehensive test must be performed again. Therefore, there is a problem that the efficiency of the test is lowered.
  • the method using the orthogonal table of Non-Patent Document 2 generates a test case so as to increase only the number of data combinations without using defect information. Therefore, in the method of Non-Patent Document 2, there is a problem that it is difficult to generate a test case so as to add only a combination of portions that are highly likely to have defects.
  • the method of Patent Document 1 does not disclose the use of defect information, and the method of Patent Document 1 has a problem that it is difficult to generate a test case that focuses on a defective portion and its periphery. .
  • An object of the present invention is to realize an efficient and effective software test by automatic test case generation using path coverage and defect information, and automatic test execution.
  • the test automation device is: A model representing a software processing flow is acquired, a path representing the software processing path and a factor used in the software processing are extracted from the model, and an analysis including the extracted path and the factor is extracted. A flow analysis unit that outputs the results; An analysis result storage unit for storing the analysis result; Using the path and the factor included in the analysis result, a test case generation unit that generates a test case in which a value is set for the factor so as to branch cover the path as a branch coverage test case; A test execution unit that executes a test of the software using the branch coverage test case generated by the test case generation unit, and outputs the execution result as a test result; A result determination unit that determines whether or not a test case needs to be added using the test result output by the test execution unit.
  • the test case generation unit generates a test case in which a value is set for a factor so as to cover and cover the path as a branch coverage test case, and the result determination unit includes the branch coverage test case. Because it is determined whether or not a test case needs to be added using the test results of the test executed using, it is possible to determine whether or not a test case needs to be added through an efficient test, which is efficient and effective. There is an effect that the test can be automatically executed.
  • FIG. 1 is a block configuration diagram of a test automation apparatus according to Embodiment 1.
  • FIG. FIG. 3 is a flowchart showing the operation of the test automation method and test automation processing of the test automation apparatus according to the first embodiment.
  • FIG. 6 is a diagram illustrating an operation example of flow analysis processing by a flow analysis unit according to the first embodiment. The figure which shows the operation example of the branch coverage test case production
  • FIG. FIG. 6 is a diagram showing an example of coverage rate information according to the first embodiment.
  • FIG. 6 is a diagram showing an example of test execution processing by the test execution unit according to the first embodiment.
  • FIG. 6 is a diagram illustrating an example of a test result generated by a test execution process according to the first embodiment.
  • UML is a unified modeling language, that is, a unified modeling language.
  • a state machine diagram is synonymous with a state transition diagram, a state chart, and a state machine diagram.
  • the flow is a flow of processing representing the operation of the software, and the sequence of transitions between the two states in the state machine diagram from the start to the end of the flowchart corresponds to the flow.
  • a path is a path of each process that constitutes a flow.
  • the model is an abstract concept indicating the operation of software.
  • a model including a visual representation of the operation using a diagram is referred to as a model.
  • the model includes a flowchart and a state machine diagram.
  • Branch coverage is to test all the branches on the flow once.
  • Condition coverage is to test all the conditions related to the branch on the flow once.
  • Path coverage is testing all combinations of branches on the flow. Route coverage is the most powerful coverage criterion.
  • Factors are data that affect the processing of variables, parameters, states, etc. to be tested.
  • the level is a value that the factor can take. For example, when temperature is a factor, the level has values such as 0 degrees and 10 degrees.
  • FIG. *** Explanation of configuration *** FIG. 1 is a block configuration diagram of a test automation apparatus 100 according to the present embodiment.
  • the test automation apparatus 100 includes a flow analysis unit 120, a test case generation unit 130, a test execution unit 140, and a result determination unit 150.
  • the test automation apparatus 100 includes an analysis result storage unit 160 that stores the analysis result 161, a test case storage unit 170 that stores the test case information 171, an coverage rate storage unit 180 that stores the coverage rate information 181, and test result information 191.
  • the test result storage unit 190 is stored.
  • a model 200 is input to the test automation apparatus 100.
  • the model 200 represents the flow of software processing, and is a diagram that can analyze software operations such as flowcharts and state machine diagrams.
  • the flow analysis unit 120 acquires the model 200, and extracts a path 121 representing a software processing path and a factor 122 used in the software processing from the model 200.
  • the flow analysis unit 120 extracts the path 121 from the input model 200 and acquires the factor 122 on each path 121.
  • the flow analysis unit 120 outputs an analysis result 161 including the path 121 and the factor 122.
  • the analysis result storage unit 160 stores the analysis result 161.
  • the test case generation unit 130 uses the path 121 and the factor 122 included in the analysis result 161 to generate a test case 131 in which a value is set in the factor 122 so as to cover the path 121 as a branch covering test case 1311. . That is, the test case generation unit 130 sets a value for the factor 122 based on branch coverage from the obtained path 121, and generates a test case 131.
  • the test case generation unit 130 stores test case information 171 including the generated test case 131 in the test case storage unit 170.
  • the test case generation unit 130 stores the coverage rate information 181 including the condition coverage rate indicating the rate of coverage of the test cases 131 for each path in the coverage rate storage unit 180.
  • the test execution unit 140 executes a software test using the branch coverage test case 1311 generated by the test case generation unit 130 and outputs the execution result as a test result 141.
  • the test execution unit 140 executes a test using the test case 131 generated by the test case generation unit 130.
  • the test result storage unit 190 stores the test result 141 output by the test execution unit 140 as test result information 191.
  • the result determination unit 150 uses the test result 141 output by the test execution unit 140 to determine whether or not a test case needs to be added.
  • the result determination unit 150 analyzes the test result 141 based on defect information that is defect information and a condition coverage rate, and determines whether or not a test case needs to be added.
  • the result determination unit 150 outputs a determination result 151 indicating whether or not a test case needs to be added to the test case generation unit 130.
  • the test case generation unit 130 When the determination result 151 indicates that it is necessary to add a test case, the test case generation unit 130, for example, performs an additional test that focuses on the periphery of the defective part by changing the criterion of the condition coverage rate. Generate a case. Thereafter, the test automation apparatus 100 executes the test execution unit 140 and the result determination unit 150 again. When the determination result 151 indicates that the test case is not added, the test automation apparatus 100 ends the process.
  • FIG. 2 is a flowchart showing the operation of the test automation method and test automation processing S100 of the test automation apparatus 100 according to the present embodiment. The operation of the test automation process S100 will be described with reference to FIG.
  • the flow analysis unit 120 acquires the model 200 representing the software processing flow, extracts the path 121 representing the software processing path and the factor 122 used in the software processing from the model 200, and passes the path 121 and the factor.
  • the flow analysis process S110 for outputting the analysis result 161 including the data 122 is executed.
  • the flow analysis unit 120 extracts a path 121 from the model 200.
  • the flow analysis unit 120 acquires the factor 122 in the model 200 based on the extracted path 121.
  • FIG. 3 shows an example of the software model 200 input to the flow analysis unit 120 and the paths 121 and factors 122 included in the analysis result 161 output from the flow analysis unit 120.
  • the flow analysis unit 120 extracts the path 121 from the software model 200 to be tested.
  • the flow analysis unit 120 extracts the path 1, the path 2, and the path 3 as the path 121 from the flowchart that is the software model 200.
  • the path 121 is a path on the model 200 that is followed when the software operates.
  • Each path includes information regarding operations such as the contents of processing performed by the software and the condition of branching. For example, the information regarding the operation is “stores a value in a variable” in the case of processing content, and “branches the processing when the temperature as a factor is less than 0 degrees or greater than 0 degrees” for a branch condition. Etc.
  • the flow analysis unit 120 acquires the factor 122 in the model 200 by referring to the information on the branch condition in the branch on each path.
  • the flow analysis unit 120 acquires variables a and c as the factor 122 from the branch 1 of the path 1.
  • the flow analysis unit 120 acquires the variable b as the factor 122 from the branch 2 of the path 2.
  • the flow analysis unit 120 performs such an operation in each path and acquires all the factors 122 in the model 200.
  • the extracted path is held in a form in which a class of objects, structures, and the like whose members are information about factors and actions are represented by a series of data such as an array and a list.
  • the flow analysis unit 120 extracts the path 121, the number of paths becomes enormous in the route coverage that covers all combinations of branches. For this reason, the flow analysis unit 120 extracts paths by branch coverage that can suppress the number of paths more than route coverage and can test all branches.
  • a flowchart is used as the software model 200.
  • other models such as a state machine diagram can be analyzed.
  • this embodiment can be applied.
  • the flow analysis unit 120 sets an arbitrary start point and end point as the operation to be tested, and extracts a path so that all transitions from the start point to the end point pass once.
  • test case generation unit 130 uses the path 121 and the factor 122 included in the analysis result 161 to branch the test case 131 in which a value is set in the factor 122 so that the path 121 is branched and covered.
  • the test case generation process S120 generated as follows is executed.
  • the test case generation unit 130 determines the coverage criteria. If the current process is a process immediately after the flow analysis process S110, the test case generation unit 130 determines that the coverage criterion is branch coverage, and proceeds to the branch coverage test case generation process S122. Further, if the current process is a process immediately after the test result determination process S140 described later, the test case generation unit 130 determines that the coverage criterion is condition coverage, and proceeds to the additional test case generation process S123.
  • the branch coverage test case generation process S122 the test case generation unit 130 generates a branch coverage test case 1311 by enumerating the levels so as to satisfy the operation of the path for each factor acquired from the path using the branch coverage as the coverage criterion. .
  • the test case generation unit 130 In the additional test case generation processing S123, the test case generation unit 130 generates a condition coverage test case 1312 by listing the levels so as to satisfy the path operation for each factor acquired from the path using the condition coverage as the coverage criterion.
  • the test case generation unit 130 sets a level at which each path can operate from the start to the end for the factor on each path extracted by the flow analysis unit 120.
  • the test case generation unit 130 lists the levels of all factors set so that each path can operate from the start to the end.
  • the test case generation unit 130 sets the test case 131 as a list of all factor levels.
  • the test case generation unit 130 executes such processing at all branches on the path.
  • the test case generation unit 130 enumerates the levels of all factors by setting an arbitrary value x for factors that do not appear in the branch.
  • FIG. 4 shows an operation example in which the values of variables a, b, and c as factors are listed and the test case 131 is generated for the paths 1 to 3 obtained in the flow analysis process S110 shown in FIG.
  • FIG. 4 shows an operation example in which the test case generation unit 130 generates the test case 131 using the branch coverage as the coverage criterion.
  • variables a and c at branch 1 are related to the operation.
  • variables a and c in branch 1 and variable b in branch 2 are related to the operation.
  • the condition for branching as in path 1 is when the variable a or c is 0 or less, but in order to cover branches in path 1, either the variable a or c may be 0. Therefore, the test case generation unit 130 generates a test case in which only the variable a is 0 and the variable c is 1. In addition, the test case generation unit 130 sets an arbitrary value x for the variable c.
  • (a, b, c) (0, x, 1) (x is an arbitrary value), (1, 1, 1), (1, 1, as test case 131 by the test case generation process S120. 0,1) is automatically generated. This is the end of the description of the branch coverage test case generation process S122.
  • the branch coverage test case generation process S122 described above is a process in which the test case generation unit 130 generates the branch coverage test case 1311 using the branch coverage as the coverage criterion.
  • the coverage criteria are the following two types, and the test case generation unit 130 automatically lists the levels so that the coverage rate in the coverage criteria satisfies a preset threshold value.
  • the method of selecting the threshold that should be satisfied by the coverage rate in the coverage standard is arbitrary.
  • Branch coverage is used during the test case generation process S120 immediately after the flow analysis process S110. However, when using branch coverage, there is no branch in each path, so branch coverage is always 100%. For this reason, it is not necessary to consider the coverage rate (hereinafter referred to as the branch coverage rate) when the coverage criterion is branch coverage.
  • Condition coverage is used after the result determination process S140 described later. If all the branch conditions are not tested, the coverage rate (hereinafter referred to as the condition coverage rate) when the condition coverage is the coverage criterion is less than 100%.
  • condition coverage As described above, by changing the coverage criteria, one test is performed on one path in branch coverage, whereas in 100% condition coverage, all combinations of factor levels related to branching are tested. This makes it possible to test in more detail when condition coverage is the coverage criterion than when branch coverage is the coverage criterion. Therefore, in the test automation apparatus 100 according to the present embodiment, when adding a test case, it is possible to generate a test case that can focus on the periphery of the defective part by using condition coverage.
  • test case generation unit 130 records the condition coverage rate of the factor 122 when the test case 131 for testing each path is generated in the coverage rate information 181.
  • FIG. 5 is a diagram showing an example of the coverage rate information 181 according to the present embodiment.
  • FIG. 5 shows the coverage rate information 181 set during the branch coverage test case generation process S122.
  • the condition coverage ratio of (a, c) in branch 1 is (1/3) ⁇ 100 ⁇ 33.33%.
  • branch 1 of path 2 (a, c) has only one (1, 1), so the condition coverage is 100%.
  • the test case generation unit 130 stores the condition coverage rate 1811 in each path in the coverage rate information 181. Details of the additional test case generation process S123 when the coverage criterion is condition coverage will be described later.
  • test execution unit 140 executes a test execution process S130 for executing a test using the test case 131.
  • the test execution unit 140 outputs a test result 141 as an execution result.
  • test execution process S130 performed by the test execution unit 140 according to this embodiment will be described in detail with reference to FIG.
  • the test execution unit 140 executes a software test using the branch coverage test case 1311 generated by the test case generation process S120, and outputs the execution result as the test result 141. Note that the test case 131 described below is the branch coverage test case 1311, but the same processing is performed even in the condition coverage test case 1312.
  • the test execution unit 140 sets the value of each variable of each test case included in the test case information 171 to each variable, and sequentially executes processing on the path. Since each test case is generated based on a path, the execution process of each path always passes on each path as shown in FIG. As shown in the execution process of pass 1 in FIG. 6, if a defect occurs during the execution of the test, the process is interrupted. Examples of defects that may occur during the execution of the test by the test execution unit 140 are “the variable set in the process using the variable was an unexpected value”, “the result obtained after the process using the variable is expected "Related to the level of factors listed as test cases", and related to the structure of the model 200 such as an infinite loop.
  • the test execution unit 140 records the software operation defect detected in each test case as a test result 141 for each corresponding path.
  • the test execution unit 140 includes the occurrence position 1411 where the defect has occurred in the test result 141.
  • FIG. 7 is an example of the test result 141 generated by the test execution process S130 according to the present embodiment.
  • the operation example of FIG. 6 shows a case where a defect hidden in the path 1 is detected during the execution of the test in the execution process of the path 1.
  • the test execution unit 140 records information on the detected defect in the test result 141.
  • an occurrence position 1411 indicating a defect occurrence location and a defect type are set.
  • the generation position 1411 information such as which conditional branch is detected after is set.
  • information such as that detected after branch 1 is set in the generation position 1411.
  • information such as whether it is related to a factor level or a model structure is set in the type of defect.
  • information such as an infinite loop is set as the defect type.
  • the result determination unit 150 executes a result determination process S140 that determines whether or not a test case needs to be added, using the test result 141 output by the test execution process S130.
  • the result determination unit 150 determines whether it is necessary to add a test case based on the coverage rate information 181 and the test result 141.
  • the result determination unit 150 determines whether each path has a defect based on the test result 141. If it is determined that all the paths are not defective, the result determination unit 150 ends the process. If it is determined that there is a defect, the result determination unit 150 proceeds to S142.
  • the result determination unit 150 determines whether or not condition coverage is possible for a specific factor in the path determined to have a defect. When it is determined that condition coverage is impossible, the result determination unit 150 ends the process. If it is determined that condition coverage is possible, the result determination unit 150 returns the process to the test case generation process S120. Based on the occurrence position 1411 included in the test result 141, the result determination unit 150 extracts a factor related to the defect among the factors 122 as the defect-related factor 1221. The result determination unit 150 determines whether or not the extracted defect-related factor 1221 is covered by conditions, and determines that it is necessary to add a test case when it is determined that the defect-related factors 1221 are not covered by conditions.
  • FIG. 8 shows an operation example of the result determination process S140 and the additional test case generation process S123 after the result determination process S140 according to the present embodiment. An example of the operation of the result determination process S140 will be described in detail with reference to FIGS.
  • the result determination unit 150 determines the necessity of adding a test case with the following algorithm.
  • the result determination unit 150 refers to the test result 141 and determines whether a defect is detected in one or more paths. If a defect is detected, the result determination unit 150 proceeds to S142.
  • the result determination unit 150 determines that a defect has been detected in the corresponding path when information regarding the defect is set in the generation position 1411 of the test result 141 and the defect type illustrated in FIG.
  • the result determination unit 150 determines whether a specific factor among the listed factors, that is, the defect-related factor 1221 satisfies the condition coverage.
  • the specific factor that is, the defect-related factor 1221 is related to the factor directly related to the detected defect, which is a factor related to the defect, factors related to some of the defect locations on the path, and the defect. It refers to a regular factor that correlates with a factor.
  • the result determination unit 150 determines to add a test case for the defect-related factor 1221 and returns to the test case generation process S120.
  • the result determination unit 150 refers to the defect information in the test result 141 of pass 1 and determines that the branch 1 related to the variables a and c exists in the process immediately before the defective part. Therefore, the result determination unit 150 confirms whether the values of the variables a and c can be added as new test cases using the variables a and c as the defect-related factors 1221.
  • the result determination unit 150 refers to the coverage rate information 181 and compares the condition coverage rate of the branch 1 in the path 1 with a threshold value to determine whether it is possible to add test cases for the variables a and c. That is, the result determination unit 150 determines whether or not the defect-related factor 1221 among the factors 122 is covered by the condition based on the condition coverage rate. Note that an appropriate value is set in advance as the threshold value.
  • the result determination unit 150 acquires the condition coverage rate 33.33% of the branch 1 in the path 1 from the coverage rate information 181. The result determination unit 150 determines that the test cases of the variables a and c can be newly added for the branch 1 in the path 1 because the acquired condition coverage rate 33.33% is lower than the threshold value 100%.
  • the result determination unit 150 determines that a new test case of variables a and c can be added for pass 1 and a test case is to be added.
  • the result determination unit 150 outputs a determination result 151 including the type of path to which the test case is added and the defect-related factor 1221 to the test case generation unit 130.
  • the determination result 151 having the path type as path 1 and the defect-related factor 1221 as variables a and c is output to the test case generation unit 130.
  • the feedback method to the test case generation unit 130 by the result determination unit 150 does not have to use the determination result 151 described above.
  • a flag indicating addition of a test case may be provided in a storage area shared by the result determination unit 150 and the test case generation unit 130. Any method may be used as long as the determination result can be fed back from the result determination unit 150 to the test case generation unit 130.
  • the test case generation unit 130 determines the coverage criteria. As described above, if the current process is a process immediately after the flow analysis process S110, the test case generation unit 130 determines that the coverage criterion is branch coverage, and proceeds to the branch coverage test case generation process S122. If the current process is a process after the result determination process S140, the test case generation unit 130 determines that the coverage criterion is condition coverage, and proceeds to the additional test case generation process S123. Here, the test case generation unit 130 acquires the determination result 151 output from the result determination unit 150, determines from the determination result 151 that the process is subsequent to the result determination process S140, and proceeds to the additional test case generation process S123. move on.
  • the test case generation unit 130 sets a condition-coverage test case 1312 in which a value is set for the defect-related factor so that the condition coverage rate of the defect-related factor 1221 satisfies the threshold. Is generated. Further, the test case generation unit 130 generates the condition coverage test case 1312 and records the condition coverage rate of the defect-related factor 1221 in the coverage rate information 181.
  • test case generation unit 130 determines a value for the factor related to the detected defect among the listed factors, that is, the defect-related factor 1221 by determining the value based on the condition coverage.
  • a test case 1312 is generated.
  • the test case generation unit 130 extracts the branch 1 variables a and c related to the defect from the path 1 where the defect is detected as the defect-related factor 1221, and generates a new test case. Show.
  • the test case generation unit 130 lists the test cases so as to cover the conditions.
  • the test case generation unit 130 acquires the path 1 as the path where the defect has occurred and the variables a and c as the specific factors from the determination result 151.
  • test case generation unit 130 adds the newly generated test cases 4 and 5 to the test case information 171 that already includes the test cases 1 to 3.
  • Test cases 4 and 5 are condition-coverage test cases 1312 for intensively testing branch 1 of path 1.
  • the test case generation unit 130 updates the condition coverage rate for each path. For example, the test case generation unit 130 changes the branch 1 in the path 1 from the condition coverage rate of 33.33% to 100%. This is the end of the description of the additional test case generation process S123.
  • the test automation apparatus 100 executes the test execution process S130 and the result determination process S140 again.
  • the test automation apparatus 100 repeats the above processing until it becomes impossible to cover conditions for factors related to defects. This is the end of the description of the test automation process of the test automation apparatus 100 according to the present embodiment.
  • the threshold is 10 It may be less than 0%.
  • the test case generation unit 130 may first determine the test cases by covering the conditions so as to satisfy the condition coverage rate of 80%. If a defect occurs even in a test case determined at a condition coverage rate of 80%, in the next additional test case generation process S123, the test case generation unit 130 increases the condition coverage rate from 80% to 100% for testing. Cases may be generated. Specifically, in the additional test case generation process S123, the test case generation unit 130 determines the test case 4 by covering the conditions so that the condition coverage rate satisfies the threshold of 80%.
  • the test case generation unit 130 determines the test case 5 by increasing the condition coverage rate from 80% to 100% in the next additional test case generation process S123. To do. As described above, the test case generation unit 130 may generate the test cases by gradually increasing the condition coverage rate.
  • the factor related to the defect may be only the variable b of the branch 2 immediately before the defect, or may be the variables a and c of the branch 1 and the variable b of the branch 2.
  • variables a, b, and c are selected as factors related to defects.
  • the coverage rate threshold is 100%.
  • the test case generation unit 130 may generate a test case by setting both the condition coverage ratios of the branch 1 and the branch 2 to 100%.
  • the test case generation unit 130 may generate a test case without increasing the condition coverage of the branch 1 factor added normally and increasing the condition coverage of the branch 1 factor related to the defect. That is, the test case generation unit 130 determines the variable b assuming that the condition coverage rate of branch 2 related to the defect is 100% of the threshold, and the condition coverage rate of branch 1 added normally is set in the coverage rate information 181.
  • the variables a and c may be determined while maintaining 33.33%.
  • test case generation unit 130 increases the condition coverage rate of the branch 2 factor related to the defect to a threshold value of 100%, and reduces the condition coverage rate of the normally added branch 1 to less than the branch 2 condition coverage rate of 100%. Cases may be generated. In this way, by manipulating the condition coverage rate according to the degree related to the defect, it is possible to determine a test case in detail, and to perform an efficient and effective software test.
  • the test automation apparatus includes the flow analysis unit that extracts paths and factors from the model, and the test case generation unit that generates test cases so as to cover and branch from the paths.
  • the test automation apparatus includes a test execution unit that executes a test using the generated test case, and a test result determination unit that determines whether to add a test case based on defect information. Therefore, according to the test automation apparatus according to the present embodiment, it is possible to make an additional determination of a test case based on defect information, so that an efficient and effective test can be executed.
  • paths are extracted from a given model so as to pass through all branches once or more, and factors in the model are enumerated, so that test case generation is efficient. Can be done automatically.
  • test case generation unit after the processing of the flow analysis unit, the level is determined based on the branch coverage for the factors enumerated from each path, and the test case is generated. Cases can be generated more efficiently.
  • test case generation unit after the processing of the result determination unit, a value is determined based on condition coverage for a factor related to the defect, and a test case is generated. It is possible to generate a test case that focuses on the points related to the.
  • each level of the test case is given to each factor on the path, and the process is sequentially executed.
  • the position information is recorded. Therefore, it is possible to accurately select a factor related to the defect.
  • the result evaluation unit it is verified whether there is a path in which a defect is detected. If there is a path, it is verified whether a factor related to the defect satisfies the condition coverage, and the condition is covered. If not, it is determined that a new test case is added, so that an efficient and effective test case can be generated.
  • test case generation unit when the result determination unit determines to add a test case, the test case generation unit returns to the test case generation unit again. After the generation, the test execution unit and result determination unit are executed, and this process is repeated until it is determined that no test case is to be added, so that efficient and effective testing can be focused on the factors related to defects. .
  • test case generation unit According to the test case generation unit according to the present embodiment, a test case can be generated while operating the condition coverage rate according to the degree related to the defect, so that the test case can be determined finely and efficiently. And effective software testing.
  • the test automation device automatically executes the test using the test case newly added by the test execution unit.
  • the test automation apparatus repeats the processing cycle from the test case generation unit to the result determination unit until it is determined that no test case is added.
  • the test automation apparatus makes it possible to focus tests around the defective part by feeding back defect information and generating a test case. And effective software testing can be realized.
  • Embodiment 2 differs from the first embodiment from the first embodiment from the first embodiment.
  • the same reference numerals are given to the same components as those described in the first embodiment, and the description thereof is omitted.
  • the test case generation unit 130 when adding a test case after the processing of the result determination unit 150, uses condition coverage as a coverage criterion. However, in the present embodiment, if a test case that covers the operation in more detail than the test case that is generated immediately after the processing of the flow analysis unit 120 can be generated, the test case generation unit 130 includes the coverage criteria other than condition coverage. A test case may be generated using
  • FIG. 9 is a diagram for explaining the additional test case generation process S123a after the result determination process S140 in the test automation process S100 according to the present embodiment.
  • the additional test case generation processing S123a according to the present embodiment generates an additional test case using route coverage.
  • FIG. 9 shows an example of route coverage when a defect is detected by the instruction 2 on the model 200.
  • the result determination unit 150 verifies whether the path from the instruction several times before the occurrence position 1411 that is the defect portion to the instruction 2 is covered.
  • the number of instructions to cover before is arbitrarily set. That is, based on the generation position 1411 included in the test result 141, the result determination unit 150 has a path that connects the first instruction executed before the generation position 1411 and the second instruction executed after the generation position 1411. It is determined whether the route is covered.
  • the result determination unit 150 determines that a test case needs to be added when it is determined that the route connecting the first command and the second command is not covered.
  • instruction 1 is an example of the first instruction
  • instruction 2 is an example of the second instruction.
  • the result determination unit 150 verifies instruction 1 to instruction 2. As a result, if the route from instruction 1 to instruction 2 is not covered, the result determination unit 150 determines that a test case is added and outputs a test case addition determination result 151 to the test case generation unit.
  • the test case generation unit 130 covers the route connecting the instruction 1 and the instruction 2 by covering the route.
  • the path 1512 is extracted.
  • the test case generation unit 130 extracts the inter-instruction factor 1513 used in each path of the inter-instruction path 1512 and includes the inter-instruction path 1512 and the inter-instruction factor 1513 as the path 121 and the factor 122 in the analysis result 161. Thereafter, as described in the first embodiment, the test automation apparatus 100 executes a test while adding a test case for each path if necessary.
  • the test case generation unit 130 comprehensively extracts paths from the instruction 1 to the instruction 2. Assume that the test case generation unit 130 extracts the five paths (A) to (E) of FIG. The test case generation unit 130 acquires the inter-instruction factor 1513 on each of the obtained paths (A) to (E), and determines the level of each factor of the inter-instruction factor 1513. At this time, the test case generation unit 130 may generate a test case in each path using branch coverage as a coverage criterion. Alternatively, the test case generation unit 130 may generate a test case in each path using condition coverage as a coverage criterion. The test case generation unit 130 newly generates a test case in each pass as described in the first embodiment, and adds the test case to the test case information 171. This is the end of the description of the additional test case generation process S123a.
  • the test case generation unit can generate a test case based on the causal relationship of the operation by using path coverage, and efficient and effective software. The test is realized.
  • Embodiment 3 FIG. In the present embodiment, differences from Embodiments 1 and 2 will be mainly described. In the present embodiment, the same components as those described in the first and second embodiments are denoted by the same reference numerals, and the description thereof is omitted.
  • the test automation apparatus 100 generates an additional test case that focuses on the periphery of the defective part.
  • a case will be described in which a test case is generated so that not only a defective part but also a part where a model has been corrected or a process has been added, so that its periphery is intensively tested. This is because defects are generally likely to occur in the vicinity of a partial change of the model such as modification of the model or addition of processing to the model.
  • the test case is generated by covering the path between some instructions before and after the process that has been corrected or added.
  • the configuration of the test automation apparatus 100 according to the present embodiment is the same as that of FIG. 1 described in the first embodiment. Note that, when the software model 200 is corrected and added, the software model 200 includes a change position 1412 that is information indicating a location where the software is additionally corrected.
  • FIG. 10 is a diagram for explaining the result determination process S140a and the additional test case generation process S123b in the test automation process S100 according to the present embodiment.
  • the result determination unit 150 detects the occurrence of a defect and detects whether there is a portion where correction is added in each pass. As shown in FIG. 10, it is assumed that the modification is added to the instruction 3 between the instruction 1 and the instruction 2 of the model 200.
  • the result determination unit 150 verifies whether the path is covered from the instruction several before the correction addition part to the instruction after several.
  • the number of instructions before and after the instruction is arbitrarily set.
  • the flow analysis unit 120 acquires the model 200 including the position where the software is changed as the changed position 1412.
  • the result determination unit 150 determines whether or not the route connecting the third command executed before the change position 1412 included in the model 200 and the fourth command executed after the change position 1412 is covered.
  • the result determination unit 150 determines that the test case needs to be added when it is determined that the route connecting the third command and the fourth command is not covered.
  • instruction 1 is an example of the third instruction
  • instruction 2 is an example of the fourth instruction.
  • the result determination unit 150 verifies from the instruction 1 to the instruction 2. As a result, if the route from instruction 1 to instruction 2 is not covered, the result determination unit 150 determines that a test case is added, and outputs a test case addition determination result 151 to the test case generation unit 130.
  • the test case generation unit 130 covers the route connecting the third command and the fourth command.
  • the path extracted by this is referred to as an inter-instruction path 1512.
  • the test case generation unit 130 extracts the inter-instruction factor 1513 used in each path of the inter-instruction path 1512 and includes the inter-instruction path 1512 and the inter-instruction factor 1513 as the path 121 and the factor 122 in the analysis result 161. Thereafter, as described in the first embodiment, the test automation apparatus 100 executes a test while adding a test case for each path if necessary.
  • the test case generation unit 130 comprehensively extracts paths from the instruction 1 to the instruction 2. Assume that the test case generation unit 130 extracts the five paths (A) to (E) of FIG. The test case generation unit 130 acquires the inter-instruction factor 1513 on each of the obtained paths (A) to (E), and determines the level of each factor of the inter-instruction factor 1513. At this time, the test case generation unit 130 may generate a test case in each path using branch coverage as a coverage criterion. Alternatively, the test case generation unit 130 may generate a test case in each path using condition coverage as a coverage criterion. The test case generation unit 130 newly generates a test case in each pass as described in the first embodiment, and adds the test case to the test case information 171. This is the end of the description of the additional test case generation process S123b.
  • a test case capable of testing a place where a defect on the model may occur by using not only a defect but also correction or additional information. Provides efficient and effective software testing.
  • the test automation device is a computer.
  • the test automation apparatus includes hardware such as a processor 901, an auxiliary storage device 902, a memory 903, a communication device 904, an input interface 905, and a display interface 906.
  • the processor 901 is connected to other hardware via the signal line 910, and controls these other hardware.
  • the input interface 905 is connected to the input device 907.
  • the display interface 906 is connected to the display 908.
  • the processor 901 is an IC (Integrated Circuit) that performs processing.
  • the processor 901 is, for example, a CPU, a DSP (Digital Signal Processor), or a GPU.
  • the auxiliary storage device 902 is, for example, a ROM (Read Only Memory), a flash memory, or an HDD (Hard Disk Drive).
  • the auxiliary storage device 902 is a device that holds a created software model, a program that realizes the function of the test automation device, and an output file of test results.
  • the memory 903 is, for example, a RAM (Random Access Memory).
  • the memory 903 stores a program execution file, a model of software to be tested, an analysis result that is a program execution result by the processor 901, a test case, a test result, and a coverage rate.
  • the communication device 904 includes a receiver 9041 that receives data and a transmitter 9042 that transmits data.
  • the communication device 904 is, for example, a communication chip or a NIC (Network Interface Card).
  • the input interface 905 is a port to which the cable 911 of the input device 907 is connected.
  • the input interface 905 is, for example, a USB (Universal Serial Bus) terminal.
  • the display interface 906 is a port to which the cable 912 of the display 908 is connected.
  • the display interface 906 is, for example, a USB terminal or an HDMI (registered trademark) (High Definition Multimedia Interface) terminal.
  • the input device 907 is, for example, a mouse, a keyboard, or a touch panel.
  • a program is executed by input from the input device 907.
  • the display 908 is, for example, an LCD (Liquid Crystal Display). The output result is confirmed on the display 908.
  • the auxiliary storage device 902 stores a program that realizes the flow analysis unit, the test case generation unit, the test execution unit, and the result determination unit shown in the block configuration diagram described above.
  • the flow analysis unit, the test case generation unit, the test execution unit, and the result determination unit are collectively referred to as “parts”.
  • the program that realizes the function of the “unit” described above is also referred to as a test automation program.
  • the program that realizes the function of “unit” may be a single program or a plurality of programs. This program is loaded into the memory 903, read into the processor 901, and executed by the processor 901.
  • auxiliary storage device 902 also stores an OS (Operating System). Then, at least a part of the OS is loaded into the memory 903, and the processor 901 executes a program that realizes the function of “unit” while executing the OS.
  • OS Operating System
  • test automation apparatus may include a plurality of processors 901.
  • a plurality of processors 901 may execute a program for realizing the function of “unit” in cooperation with each other.
  • information, data, signal values, and variable values indicating the processing results of the “unit” are stored as files in the memory 903, the auxiliary storage device 902, or a register or cache memory in the processor 901.
  • circuitry may be provided as “circuitry”. Further, “part” may be read as “circuit”, “process”, “procedure”, or “processing”. Further, “processing” may be read as “circuit”, “process”, “procedure”, or “part”. “Circuit” and “Circuitry” include not only the processor 901 but also other types of processing circuits such as a logic IC or GA (Gate Array) or ASIC (Application Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array). It is a concept to include.
  • GA Gate Array
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • a program product is a storage medium, a storage device, or the like on which a program that realizes the function described as a “part” is recorded. It is what you are loading.
  • the test automation apparatus is configured as a function block in which the flow analysis unit, the test case generation unit, the test execution unit, and the result determination unit are independent of each other.
  • the test automation apparatus may not have the above-described configuration, and the configuration of the test automation apparatus is arbitrary.
  • the test case generation unit and the result determination unit may be a single functional block.
  • the functional blocks of the test automation device are arbitrary as long as the functions described in the above embodiments can be realized.
  • the test automation apparatus may be configured by any other combination of these functional blocks or an arbitrary block configuration.
  • the test automation device may be a test automation system including a plurality of devices instead of a single device.
  • Embodiments 1 to 3 have been described, a plurality of these three embodiments may be partially combined. Alternatively, one of these three embodiments may be partially implemented. In addition, these three embodiments may be implemented in any combination as a whole or in part. In addition, said embodiment is an essentially preferable illustration, Comprising: It does not intend restrict
  • test automation device 120 flow analysis unit, 121 path, 122 factor, 131 test case, 130 test case generation unit, 140 test execution unit, 141 test result, 150 result determination unit, 151 determination result, 160 analysis result storage unit, 161 analysis result, 170 test case storage unit, 171 test case information, 180 coverage rate storage unit, 181 coverage rate information, 190 test result storage unit, 191 test result information, 200 model, 901 processor, 902 auxiliary storage device, 903 memory , 904 communication device, 905 input interface, 906 display interface, 907 input device, 908 display, 910 signal line, 911, 912 cable, 9041 receiver, 9042 Transmitter, 1221 defect-related factor, 1311 branch coverage test case, 1312 condition coverage test case, 1411 occurrence position, 1412 change position, 1512 inter-instruction path, 1513 inter-instruction factor, 1811 condition coverage rate, S100 test automation process, S110 flow Analysis processing, S120 test case generation processing, S122 branch coverage test case generation processing, S123, S123a, S123

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

効率的かつ効果的なテストを自動的に実行することができるテスト自動化装置を提供する。モデル(200)からパス(121)と因子(122)とを抽出し、パス(121)と因子(122)とを含む解析結果(161)を出力するフロー解析部(120)と、パス(121)と因子(122)とを用いて、パス(121)を分岐網羅するようにテストケース(131)を分岐網羅テストケース(1311)として生成するテストケース生成部(130)と、分岐網羅テストケース(1311)を用いてソフトウェアのテストを実行し、実行した結果をテスト結果(141)として出力するテスト実行部(140)と、テスト結果(141)を用いて、テストケースの追加の要否を判定する結果判定部(150)とを備える。

Description

テスト自動化装置、テスト自動化方法及びテスト自動化プログラム
 本発明は、テスト自動化装置、テスト自動化方法及びテスト自動化プログラムに関する。
 ソフトウェアのテストを自動化する手法が種々提案されている。ソフトウェアのテストでは、テスト対象の動作に関係する機能、条件、及びパラメータ等を設定したデータ、すなわちテストケースが作成される。そして、ソフトウェアのテストは、作成されたテストケースを用いてプログラムを実行し、結果を評価するという過程で実施される。
 従来、テストは手動で行われていた。しかし、ソフトウェアの大規模化、複雑化に伴い、テストに要する時間及び労力が増大し、欠陥の見落としが発生するようになった。このような背景の下、テストを効率的かつ効果的に行うための手法が提案されてきた。
 非特許文献1では、ソフトウェアの動作をUML(Uniformed Modeling Language)のアクティビティ図で表し、アクティビティ図における開始から終了までのパスを網羅する度合いを基準としてテストケースを自動生成している。
 また、直交表は、テスト対象の機能及びパラメータ等、テスト対象の動作に影響するデータの取り得る値を自動的に組み合わせることにより、テストケースを列挙する手法である。
 非特許文献2では、この直交表を改良し、データの値で組み合わせが不可能なものの排除、データ数の増加及び取り得る値の種類の増加への対応等、直交表で困難であった処理を実現したHAYST法が提案されている。
 また、特許文献1では、テスト対象の動作に影響するデータの入力値と出力値との組み合わせを調べ、網羅的にテストケースを生成する手法が開示されている。特許文献1の手法は、さらに、出力しうる値に対応した入力値の組み合わせがテストケースに含まれなかった場合、その組み合わせのテストケースを生成し、生成したテストケースを追加する。
特開2014-186407号公報
Debasish Kundu and Debasis Samanta,"A Novel Approach to Generate Test Cases from UML Activity Diagrams,"Journal of Object Technology,vol.8,No.3,pp.65-83,2009. 山本訓稔,秋山浩一,"直交表を利用したソフトウェアテスト―HAYST法―,"ソフトウェアシンポジウム 2004,pp.13-17,2004.
 以下の説明において、フローチャートやステートマシン図等、ソフトウェアの動作を記述する図をモデルと称する。また、モデルにおける処理の経路をパスと称する。
 「網羅率」とは、モデルにおけるパスの総数のうち、列挙されているパスの数の割合を
表すものとする。また、「欠陥箇所」とは、パス上の欠陥が存在する位置を表すものとする。また、「欠陥の情報」とは、欠陥箇所を含め、欠陥の種類、欠陥に関係しているデータ等、欠陥の詳細を表すものとする。欠陥の種類は、例えば、予期しない値が発生する欠陥、モデルの構造的な欠陥等である。
 一般に、ソフトウェアの欠陥は、コードに変更を加えた部分に発生しやすい。また、欠陥が検出された場合、その周囲にも欠陥が潜んでいる可能性が高い。よって、ソフトウェアの品質保証のためには網羅率のみならず検出した欠陥も評価し、欠陥の情報に基づいてテストケースを生成するのが望ましい。しかしながら、従来手法ではテストケースの生成に欠陥の情報を用いることができないという課題がある。
 非特許文献1の手法は、テストケース生成の際、パスの網羅率のみに着目している。非特許文献1の手法では、コード上の欠陥が存在する可能性のある部分を考慮せずにパスを網羅したテストケースを生成するため、欠陥を検出したら再び網羅したテストを行わなければならない。よって、テストの効率が低下するという課題がある。
 非特許文献2の直交表を用いた手法も非特許文献1の手法と同様に、欠陥の情報を用いずデータの組み合わせ数のみを高めるようにテストケースを生成する。よって、非特許文献2の手法では、欠陥が潜む可能性が高い部分の組み合わせのみを追加するようにテストケースを生成することは困難であるという課題がある。
 さらに、特許文献1の手法も欠陥の情報の利用については開示しておらず、特許文献1の手法では欠陥箇所とその周辺を重点的にテストするテストケースの生成は困難であるという課題がある。
 本発明は、パスの網羅率と欠陥の情報とを用いたテストケース自動生成、及びテスト自動実行による効率的かつ効果的なソフトウェアのテストの実現を目的としている。
 本発明に係るテスト自動化装置は、
 ソフトウェアの処理の流れを表すモデルを取得し、前記モデルから前記ソフトウェアの処理の経路を表すパスと、前記ソフトウェアの処理で用いられる因子とを抽出し、抽出した前記パスと前記因子とを含む解析結果を出力するフロー解析部と、
 前記解析結果を記憶する解析結果記憶部と、
 前記解析結果に含まれる前記パスと前記因子とを用いて、前記パスを分岐網羅するように前記因子に値を設定したテストケースを分岐網羅テストケースとして生成するテストケース生成部と、
 前記テストケース生成部により生成された前記分岐網羅テストケースを用いて前記ソフトウェアのテストを実行し、実行した結果をテスト結果として出力するテスト実行部と、
 前記テスト実行部により出力された前記テスト結果を用いて、テストケースの追加の要否を判定する結果判定部とを備える。
 本発明に係るテスト自動化装置によれば、テストケース生成部が、パスを分岐網羅するように因子に値を設定したテストケースを分岐網羅テストケースとして生成し、結果判定部が、分岐網羅テストケースを用いてテストを実行したテスト結果を用いて、テストケースの追加の要否を判定するので、効率的なテストによりテストケースの追加の要否を判定することができ、効率的かつ効果的なテストを自動的に実行することができるという効果を奏する。
実施の形態1に係るテスト自動化装置のブロック構成図。 実施の形態1に係るテスト自動化装置のテスト自動化方法、テスト自動化処理の動作を示すフロー図。 実施の形態1に係るフロー解析部によるフロー解析処理の動作例を示す図。 実施の形態1に係るテストケース生成部による分岐網羅テストケース生成処理の動作例を示す図。 実施の形態1に係る網羅率情報の一例を示す図。 実施の形態1に係るテスト実行部によるテスト実行処理の動作例を示す図。 実施の形態1に係るテスト実行処理により生成されたテスト結果の一例を示す図。 実施の形態1に係る結果判定処理及び追加テストケース生成処理の動作例を示す図。 実施の形態2に係る結果判定処理及び追加テストケース生成処理の動作例を示す図。 実施の形態3に係る結果判定処理及び追加テストケース生成処理の動作例を示す図。 テスト自動化装置のハードウェア構成図。
 まず、以下の実施の形態の説明で用いる語句について説明する。
 UMLとは、Unified Modeling Language、すなわち統一モデリング言語である。
 ステートマシン図は、状態遷移図、ステートチャート、状態機械図と同義である。
 フローは、ソフトウェアの動作を表す処理の流れであり、フローチャートの開始から終了まで、ステートマシン図の2状態間の遷移の並び等がフローに相当する。
 パスは、フローを構成する一つ一つの処理の経路である。
 モデルは、ソフトウェアの動作を示す抽象的な概念であり、特に以下の実施の形態では図を用いて動作を視覚的に表現したものを含めてモデルと呼ぶ。モデルには、フローチャートやステートマシン図等が含まれる。
 分岐網羅とは、フロー上の全ての分岐を一度は通過するようにテストすることである。
 条件網羅とは、フロー上の分岐に関する条件を全て一度はテストすることである。
 経路網羅とは、フロー上の全ての分岐の組合せをテストすることである。経路網羅は最も強力な網羅基準となる。
 因子は、テスト対象となる変数、パラメータ、状態等の処理に影響するデータである。
 水準は、因子が取り得る値である。例えば、温度を因子とすると、水準は0度、10度等の値がある。
 実施の形態1.
***構成の説明***
 図1は、本実施の形態に係るテスト自動化装置100のブロック構成図である。
 図1に示すように、テスト自動化装置100は、フロー解析部120、テストケース生成部130、テスト実行部140、結果判定部150を備える。また、テスト自動化装置100は、解析結果161を記憶する解析結果記憶部160、テストケース情報171を記憶するテストケース記憶部170、網羅率情報181を記憶する網羅率記憶部180、テスト結果情報191を記憶するテスト結果記憶部190を備える。
 テスト自動化装置100には、モデル200が入力される。
 モデル200は、ソフトウェアの処理の流れを表すものであり、フローチャートやステートマシン図等のソフトウェアの動作を解析可能な図である。
 フロー解析部120は、モデル200を取得し、モデル200からソフトウェアの処理
の経路を表すパス121と、ソフトウェアの処理で用いられる因子122とを抽出する。フロー解析部120は、入力されたモデル200からパス121を抽出し、各パス121上の因子122を取得する。フロー解析部120は、パス121及び因子122を含む解析結果161を出力する。
 解析結果記憶部160は、解析結果161を記憶する。
 テストケース生成部130は、解析結果161に含まれるパス121と因子122とを用いて、パス121を分岐網羅するように因子122に値を設定したテストケース131を分岐網羅テストケース1311として生成する。すなわち、テストケース生成部130は、得られたパス121から分岐網羅を基準に因子122に値を設定し、テストケース131を生成する。テストケース生成部130は、生成したテストケース131を含むテストケース情報171をテストケース記憶部170に記憶する。また、テストケース生成部130は、パス毎のテストケース131が条件網羅する割合を表す条件網羅率を含む網羅率情報181を網羅率記憶部180に記憶する。
 テスト実行部140は、テストケース生成部130により生成された分岐網羅テストケース1311を用いてソフトウェアのテストを実行し、実行した結果をテスト結果141として出力する。
 テスト実行部140は、テストケース生成部130により生成されたテストケース131を用いてテストを実行する。
 テスト結果記憶部190は、テスト実行部140により出力されたテスト結果141をテスト結果情報191として記憶する。
 結果判定部150は、テスト実行部140により出力されたテスト結果141を用いて、テストケースの追加の要否を判定する。
 結果判定部150は、テスト結果141を、欠陥の情報である欠陥情報と条件網羅率とに基づいて分析し、テストケースの追加の要否を判定する。結果判定部150は、テストケースの追加の要否の判定結果151をテストケース生成部130に出力する。
 判定結果151がテストケースの追加を要することを示す場合、テストケース生成部130は、例えば、条件網羅率の基準を変更することで、欠陥箇所の周辺を重点的にテストするような追加のテストケースを生成する。テスト自動化装置100は、その後、再びテスト実行部140、結果判定部150を実行する。
 判定結果151がテストケースを追加しないことを示す場合、テスト自動化装置100は処理を終了する。
***動作の説明***
 図2は、本実施の形態に係るテスト自動化装置100のテスト自動化方法、テスト自動化処理S100の動作を示すフロー図である。
 図2を用いて、テスト自動化処理S100の動作について説明する。
<フロー解析処理S110>
 フロー解析部120は、ソフトウェアの処理の流れを表すモデル200を取得し、モデル200からソフトウェアの処理の経路を表すパス121と、ソフトウェアの処理で用いられる因子122とを抽出し、パス121と因子122とを含む解析結果161を出力するフロー解析処理S110を実行する。
 S111において、フロー解析部120は、モデル200からパス121を抽出する。
 S112において、フロー解析部120は、抽出したパス121に基づいて、モデル200内の因子122を取得する。
 図3を用いて、本実施の形態に係るフロー解析部120によるフロー解析処理S110の動作について詳しく説明する。
 図3は、フロー解析部120に入力されるソフトウェアのモデル200と、フロー解析部120から出力される解析結果161に含まれるパス121及び因子122の例を示す。フロー解析部120は、テスト対象のソフトウェアのモデル200からパス121を抽出する。
 図3の動作例では、フロー解析部120は、ソフトウェアのモデル200であるフローチャートからパス1、パス2、パス3をパス121として抽出している。パス121は、ソフトウェアが動作する際に辿るモデル200上の経路である。各パスには、ソフトウェアが行う処理内容、分岐における分岐の条件等の動作に関する情報が含まれる。動作に関する情報は、例えば、処理内容であれば「変数に値を格納する」、分岐の条件であれば「因子である温度が0度未満の場合と0度以上の場合で処理を分岐する」等の情報である。
 次に、フロー解析部120は、各パス上の分岐における分岐の条件の情報を参照し、モデル200内の因子122を取得する。
 図3の動作例では、フロー解析部120は、パス1の分岐1から変数a,cを因子122として取得する。また、フロー解析部120は、パス2の分岐2から変数bを因子122として取得する。フロー解析部120は、このような動作を各パスで行い、モデル200内の因子122をすべて取得する。
 抽出したパスは、因子や動作に関する情報等をメンバとするようなクラスのオブジェクトや構造体等を配列やリスト等の一連のデータで表した形式として保持される。
 フロー解析部120がパス121を抽出する際、全ての分岐の組み合わせを網羅する経路網羅ではパス数が膨大となる。このため、フロー解析部120は、経路網羅よりもパス数を抑制でき、なおかつ全ての分岐をテストできる分岐網羅でパスを抽出する。
 なお、図3の動作例では、ソフトウェアのモデル200としてフローチャートを用いているが、上述したように、動作開始から目的の処理までのフローを解析可能であれば、ステートマシン図等、他のモデルでも本実施の形態は適用可能である。ステートマシン図の場合、フロー解析部120は、任意の始点と終点をテスト対象の動作として設定し、始点から終点までの全ての遷移を一度は通るようにパスを抽出する。
<テストケース生成処理S120>
 次に、テストケース生成部130は、解析結果161に含まれるパス121と因子122とを用いて、パス121を分岐網羅するように因子122に値を設定したテストケース131を分岐網羅テストケース1311として生成するテストケース生成処理S120を実行する。
 S121において、テストケース生成部130は、網羅基準の判定を実行する。
 テストケース生成部130は、現在の処理がフロー解析処理S110の直後の処理ならば、網羅基準は分岐網羅であると判定し、分岐網羅テストケース生成処理S122に進む。また、テストケース生成部130は、現在の処理が後述するテスト結果判定処理S140の直後の処理ならば、網羅基準は条件網羅であると判定し、追加テストケース生成処理S123に進む。
 分岐網羅テストケース生成処理S122において、テストケース生成部130は、分岐網羅を網羅基準として、パスから取得した各因子についてパスの動作を満たすように水準を列挙し、分岐網羅テストケース1311を生成する。
 追加テストケース生成処理S123において、テストケース生成部130は、条件網羅を網羅基準として、パスから取得した各因子についてパスの動作を満たすように水準を列挙し、条件網羅テストケース1312を生成する。
 テストケース生成部130は、フロー解析部120により抽出された各パス上の因子に対し、各パスが開始から終了まで動作可能となるような水準を設定する。テストケース生成部130は、各パスが開始から終了まで動作可能となるように設定した全ての因子の水準を列挙する。テストケース生成部130は、このように全ての因子の水準を列挙したものをテストケース131とする。
 テストケース生成部130は、分岐の際に処理対象のパスを通るように因子の水準を設定する。例えば、パス1が処理対象のパスの場合、パス1の分岐1では変数aまたはcのいずれかが0以下であれば分岐1を通過できる。そこで、テストケース生成部130は、分岐1を通過するための条件を満たす値として(a,c)=(1,0)と設定する。テストケース生成部130は、このような処理をパス上の全ての分岐で実行する。また、テストケース生成部130は、分岐に表れない因子については任意の値xを設定することで、全ての因子の水準を列挙する。
<分岐網羅テストケース生成処理S122>
 図4を用いて、本実施の形態に係るテストケース生成部130による分岐網羅テストケース生成処理S122の動作について説明する。
 図4は、図3に示すフロー解析処理S110で得られたパス1~パス3に対し、因子である変数a,b,cの値を列挙し、テストケース131を生成する動作例である。図4では、テストケース生成部130が分岐網羅を網羅基準としてテストケース131を生成する動作例を示している。
 図4に示すように、パス1では分岐1における変数a,cが動作に関係している。パス2、パス3では、分岐1における変数a,c及び分岐2における変数bが動作に関係している。
 まず、パス1のように分岐するための条件は変数aまたはcが0以下の場合であるが、パス1において分岐網羅するためには変数aまたはcのいずれか一方が0であれば良い。したがって、テストケース生成部130は、変数aのみを0、変数cを1としたテストケースを生成する。また、テストケース生成部130は、変数cについては任意の値xを設定する。よって、テストケース生成部130は、パス1をテストするテストケース1として(a,b,c)=(0,x,1)(xは任意の値)を生成する。
 パス2では変数a,cはともに0より大でなければならないため、a=1,c=1となる。また、パス2では変数bに関してはb>0である。よって、テストケース生成部130は、パス2をテストするテストケース2として(a,b,c)=(1,1,1)を生成する。
 パス3では変数a,cはともに0より大でなければならないため、a=1,c=1となる。また、パス3では変数bに関してはb≦0である。よって、テストケース生成部130は、パス3をテストするテストケース3として(a,b,c)=(1,0,1)を生成する。
 以上のように、テストケース生成処理S120により、テストケース131として(a,b,c)=(0,x,1)(xは任意の値),(1,1,1),(1,0,1)が自動生成される。
 以上で、分岐網羅テストケース生成処理S122の説明を終わる。
 上記の分岐網羅テストケース生成処理S122は、テストケース生成部130が分岐網羅を網羅基準として分岐網羅テストケース1311を生成する処理であった。
 ただし、テストケース生成部130による水準の列挙の仕方は、使用する網羅基準によって変化する。網羅基準は以下の2通りであり、テストケース生成部130は、網羅基準における網羅率が、予め設定された閾値を満たすように自動で水準を列挙する。網羅基準における網羅率が満たすべき閾値の選び方は任意とする。
 以下に2通りの網羅基準について説明する。
(1)フロー解析処理S110直後のテストケース生成処理S120時には分岐網羅を用いる。ただし、分岐網羅を用いる場合、各パスに分岐は存在しないので分岐網羅は必ず100%になる。このため、網羅基準が分岐網羅の場合の網羅率(以下、分岐網羅率とする)は考慮しなくてもよい。
(2)後述する結果判定処理S140後には条件網羅を用いる。分岐の条件をすべてテストしない場合、条件網羅を網羅基準とした場合の網羅率(以下、条件網羅率とする)は100%未満になる。例えば、分岐の条件が「a≦0、または、c≦0」であるとき、水準に境界値を用いる場合このパスを通るテストケースには、(a,c)=(0,1),(0,0),(1,0)の3通りがある。この中の2つを用いると条件網羅率は2/3≒67%となる。このため、条件網羅率が満たすべき閾値を50%とすると、テストケース生成部130は、条件網羅率を満たすために上記3通りのテストケースからランダムに2つ選択する。また、条件網羅率が満たすべき閾値を100%とすると、テストケース生成部130は、条件網羅率を満たすために上記3通りのテストケースの全てを選択する。
 以上のように、網羅基準を変更することで、分岐網羅ではひとつのパス上で1通りのテストを行うのに対し、100%の条件網羅では分岐に関わる因子の水準の組合せを全てテストする。これにより、条件網羅を網羅基準とした場合、分岐網羅を網羅基準とした場合よりも詳細にテストすることが可能である。したがって、本実施の形態に係るテスト自動化装置100では、テストケースを追加する時には条件網羅を用いることで、欠陥箇所の周辺を重点的にテスト可能なテストケースを生成できる。
 さらに、テストケース生成処理S120についての説明を続ける。
 テストケース生成部130は、各パスをテストするテストケース131を生成した際の因子122の条件網羅率を網羅率情報181に記録しておく。
 図5は、本実施の形態に係る網羅率情報181の一例を示す図である。図5では、分岐網羅テストケース生成処理S122時に設定される網羅率情報181を示している。
 上記(1)の分岐網羅でテストケースを生成した場合、パス1の分岐1では3通りの(a,c)=(0,1),(0,0),(1,0)から1つを選択する。このため、分岐1における(a,c)の条件網羅率は、(1/3)×100≒33.33%となる。パス2の分岐1では(a,c)は(1,1)の1通りしかないため条件網羅率は100%となる。パス2の分岐2ではbはb=1の1通りしかないため条件網羅率は100%である。
 このように、テストケース生成部130は、各パスにおける条件網羅率1811を網羅率情報181に記憶する。
 網羅基準を条件網羅とした場合の追加テストケース生成処理S123の詳細については後述する。
<テスト実行処理S130>
 次に、テスト実行部140は、テストケース131を用いてテストを実行するテスト実行処理S130を実行する。テスト実行部140は、実行の結果としてテスト結果141を出力する。
 図6を用いて、本実施の形態に係るテスト実行部140によるテスト実行処理S130の動作について詳しく説明する。
 テスト実行部140は、テストケース生成処理S120により生成された分岐網羅テストケース1311を用いてソフトウェアのテストを実行し、実行した結果をテスト結果141として出力する。なお、以下で説明するテストケース131は分岐網羅テストケース
1311であるが、条件網羅テストケース1312であっても同様の処理である。
 テスト実行部140は、テストケース情報171に含まれる各テストケースのそれぞれの変数の値を各変数に設定し、パス上の処理を逐次実行する。各テストケースはパスを基準に生成されているため、図6に示すように各パスの実行処理は必ず各パス上を通過する。図6のパス1の実行処理に示すように、テストの実行中に欠陥が発生した場合、処理が中断する。
 テスト実行部140によるテストの実行中に発生しうる欠陥の例として、「変数を用いた処理において設定した変数が予期しない値であった」、「変数を用いた処理の後に得られる結果が予期しないものであった」等、テストケースとして列挙された因子の水準に関するものや、無限ループ等、モデル200の構造に関するものが挙げられる。
 テスト実行部140は、各テストケースで検出されたソフトウェアの動作の欠陥を、対応するパス毎にテスト結果141として記録する。テスト実行部140は、テストの実行中に欠陥が発生した場合、テスト結果141に欠陥が発生した発生位置1411を含める。
 図7は、本実施の形態に係るテスト実行処理S130により生成されたテスト結果141の一例である。
 図6の動作例では、パス1の実行処理において、パス1上に潜んでいた欠陥が、テスト実行中に検出された場合を示している。このとき、テスト実行部140は、検出された欠陥の情報をテスト結果141に記録する。
 欠陥の情報には、欠陥発生個所を示す発生位置1411、欠陥の種別が設定される。発生位置1411には、どの条件分岐の後に検出されたか等の情報が設定される。図7に示すように、発生位置1411には、分岐1の後に検出された等の情報が設定される。また、欠陥の種別には、因子の水準に関するものか、モデルの構造に関するものか等の情報が設定される。図7に示すように、欠陥の種別には、無限ループ等の情報が設定される。
<結果判定処理S140>
 結果判定部150は、テスト実行処理S130により出力されたテスト結果141を用いて、テストケースの追加の要否を判定する結果判定処理S140を実行する。結果判定部150は、網羅率情報181とテスト結果141とに基づいて、テストケースの追加が必要か否かを判定する。
 S141において、結果判定部150は、テスト結果141に基づいて、各パスに欠陥があるか否かを判定する。全てのパスに欠陥が無いと判定した場合、結果判定部150は、処理を終了する。欠陥が有ると判定した場合、結果判定部150は、S142に進む。
 S142において、結果判定部150は、欠陥が有ると判定したパスにおいて、特定の因子について条件網羅が可能であるか否かを判定する。条件網羅が不可能と判定した場合、結果判定部150は、処理を終了する。条件網羅が可能と判定した場合、結果判定部150は、テストケース生成処理S120に処理を戻す。
 結果判定部150は、テスト結果141に含まれる発生位置1411に基づいて、因子122のうち欠陥に関わる因子を欠陥関連因子1221として抽出する。結果判定部150は、抽出した欠陥関連因子1221が条件網羅されたか否かを判定し、欠陥関連因子1221が条件網羅されていないと判定した場合にテストケースの追加を要すると判定する。
 図8では、本実施の形態に係る結果判定処理S140及び結果判定処理S140後の追加テストケース生成処理S123の動作例を示す。図2及び図7,8を用いて、結果判定
処理S140の動作例について詳しく説明する。
 結果判定部150は、以下のようなアルゴリズムでテストケースの追加の必要性を判定する。
 S141において、結果判定部150は、テスト結果141を参照し、1つ以上のパスに欠陥が検出されているか判定する。欠陥が検出されていれば、結果判定部150は、S142に進む。結果判定部150は、図7に示すテスト結果141の発生位置1411及び欠陥の種別に欠陥に関する情報が設定されている場合に、該当のパスに欠陥が検出されたと判定する。
 S142において、結果判定部150は、列挙された因子のうち特定の因子、すなわち欠陥関連因子1221が条件網羅を満たしているか否かを判定する。特定の因子、すなわち欠陥関連因子1221とは、欠陥に関わる因子である、検出された欠陥に直接関係する因子の他、パス上における欠陥箇所の幾つか前後にある因子、および欠陥に関係している因子と相関がある有則な因子等を指すものとする。
 欠陥関連因子1221が条件網羅を満たしていないと判定した場合、結果判定部150は、欠陥関連因子1221についてテストケースを追加すると判定し、テストケース生成処理S120に戻る。
 図8の動作例では、結果判定部150は、パス1のテスト結果141における欠陥の情報を参照し、欠陥箇所のひとつ前の処理に変数a,cに関する分岐1が存在すると判定する。そこで、結果判定部150は、変数a,cを欠陥関連因子1221として、変数a,cの値が新たなテストケースとして追加可能か確認する。結果判定部150は、網羅率情報181を参照し、パス1における分岐1の条件網羅率と閾値とを比較し、変数a,cのテストケースを追加可能であるか否かを判定する。つまり、結果判定部150は、条件網羅率に基づいて、因子122のうちの欠陥関連因子1221が条件網羅されているか否かを判定する。なお、閾値には、予め適切な値が設定されているものとする。
 ここで、閾値が100%であるとする。結果判定部150は、網羅率情報181からパス1における分岐1の条件網羅率33.33%を取得する。結果判定部150は、取得した条件網羅率33.33%が閾値100%よりも低いため、パス1における分岐1に関して新たに変数a,cのテストケースを追加可能であると判定する。
 上述した分岐網羅テストケース生成処理S122では、分岐網羅のみを基準にしていたため、パス1をテストするテストケースでは変数a,cの条件を網羅していない。したがって、結果判定部150は、パス1に関して新たに変数a,cのテストケースを追加可能であり、テストケースを追加すると判定する。
 結果判定部150は、テストケースを追加するパスの種別と欠陥関連因子1221とを含む判定結果151をテストケース生成部130に出力する。図8の動作例では、パスの種別をパス1、欠陥関連因子1221を変数a,cとする判定結果151をテストケース生成部130に出力する。なお、結果判定部150によるテストケース生成部130へのフィードバックの方法は、上記の判定結果151を用いるものでなくてもよい。例えば、テストケースの追加を表すフラグを結果判定部150とテストケース生成部130とで共有する記憶領域に設けてもよい。結果判定部150からテストケース生成部130へ判定結果をフィードバックすることができれば、どのような方法でも構わない。
<追加テストケース生成処理S123>
 次に、図2及び図7,8を用いて、追加テストケース生成処理S123について説明する。
 S121において、テストケース生成部130は、網羅基準を判定する。上述したように、テストケース生成部130は、現在の処理がフロー解析処理S110の直後の処理ならば、網羅基準は分岐網羅であると判定し、分岐網羅テストケース生成処理S122に進む。また、テストケース生成部130は、現在の処理が結果判定処理S140の後の処理ならば、網羅基準は条件網羅であると判定し、追加テストケース生成処理S123に進む。
 ここでは、テストケース生成部130は、結果判定部150から出力された判定結果151を取得し、判定結果151から結果判定処理S140の後の処理であると判定し、追加テストケース生成処理S123に進む。
 結果判定部によりテストケースの追加を要すると判定された場合、テストケース生成部130は、欠陥関連因子1221の条件網羅率が閾値を満たすように欠陥関連因子に値を設定した条件網羅テストケース1312を生成する。また、テストケース生成部130は、条件網羅テストケース1312を生成すると共に、欠陥関連因子1221の条件網羅率を網羅率情報181に記録する。
 追加テストケース生成処理S123では、テストケース生成部130は、列挙された因子のうち、検出された欠陥に関わる因子、すなわち欠陥関連因子1221に対し、条件網羅を基準に値を決定して条件網羅テストケース1312を生成する。
 図8の動作例では、テストケース生成部130は、欠陥が検出されたパス1から欠陥に関わる分岐1の変数a,cを欠陥関連因子1221として抽出し、新たなテストケースを生成する処理を示している。
 テストケース生成部130は、条件網羅するようにテストケースを列挙する。テストケース生成部130は、欠陥が発生したパスとしてパス1、特定の因子として変数a,cを判定結果151から取得する。
 テストケース生成部130は、分岐網羅テストケース生成処理S122において既に変数a,cに対して(a,c)=(0,1)を与えている。これらは分岐網羅を基準に決定した値であるが、結果判定部150後の処理の場合、変数a,cは条件網羅を基準に決定される。条件網羅するためには、変数a,cの値がa=1およびc=0の場合と、a=c=0の場合とに関してもテストケースとする必要がある。したがって、テストケース生成部130は、(a,c)=(0,0),(1,0)となるテストケース4,5を生成し、元のテストケース情報171に追加する。
 図8に示すように、テストケース生成部130は、既にテストケース1~3を含むテストケース情報171に、新たに生成したテストケース4,5を追加する。テストケース4,5は、パス1の分岐1を重点的にテストするための条件網羅テストケース1312である。
 また、テストケース生成部130は、パス毎の条件網羅率を更新する。例えば、テストケース生成部130は、パス1における分岐1が条件網羅率33.33%だったものを100%に変更する。
 以上で、追加テストケース生成処理S123についての説明を終わる。
 テスト自動化装置100は、再び、テスト実行処理S130、結果判定処理S140を実行する。テスト自動化装置100は、欠陥に関わる因子について条件網羅ができなくなるまで上記処理を繰り返す。
 以上で、本実施の形態に係るテスト自動化装置100のテスト自動化処理についての説明を終わる。
 なお、上記の説明では、閾値が100%の場合について説明した。しかし、閾値は10
0%未満でもよい。
 例えば閾値が80%の場合、追加テストケース生成処理S123では、テストケース生成部130は、まず条件網羅率80%を満たすように条件網羅してテストケースを決定してもよい。条件網羅率80%で決定したテストケースにおいても欠陥が発生した場合には、次の追加テストケース生成処理S123では、テストケース生成部130は、条件網羅率を80%から100%に上げてテストケースを生成してもよい。
 具体的には、テストケース生成部130は、追加テストケース生成処理S123において、条件網羅率が閾値80%を満たすように条件網羅してテストケース4を決定する。そしてテスト実行部140によるテスト実行処理により欠陥が発生した場合、テストケース生成部130は、次の追加テストケース生成処理S123において、条件網羅率を80%から100%に上げてテストケース5を決定する。このように、テストケース生成部130は、段階的に条件網羅率を上げてテストケースを生成するようにしてもよい。
 また、上記の説明では、パス1の分岐1の後で欠陥が発生した例について説明したため、欠陥に関わる因子を分岐1の変数a,cのみとした。しかし、以下の説明では、図6のパス2の実行処理における点線に示すように、欠陥がパス2の分岐2の後に発生した場合について説明する。この場合、欠陥に関わる因子は、欠陥の直前の分岐2の変数bのみとしてもよいし、分岐1の変数a,c及び分岐2の変数bとしてもよい。
 ここでは、欠陥に関わる因子として変数a,b,cを選択するものとする。また、網羅率の閾値は100%であるものとする。
 追加テストケース生成処理S123において、テストケース生成部130は、分岐1と分岐2の条件網羅率を共に100%として、テストケースを生成してもよい。あるいは、テストケース生成部130は、欠陥に関わる分岐2の因子の条件網羅率は上げて、正常に追加した分岐1の条件網羅率は上げずにテストケースを生成してもよい。すなわち、テストケース生成部130は、欠陥に関わる分岐2の条件網羅率は閾値の100%として変数bを決定し、正常に追加した分岐1の条件網羅率は網羅率情報181に設定されている33.33%のままで変数a,cを決定してもよい。あるいは、テストケース生成部130は、欠陥に関わる分岐2の因子の条件網羅率は閾値100%まで上げ、正常に追加した分岐1の条件網羅率は分岐2の条件網羅率100%より下げてテストケースを生成してもよい。
 このように、条件網羅率を欠陥に関わる度合いにより操作することで、きめ細かくテストケースを決定することができ、効率的かつ効果的なソフトウェアのテストを行うことができる。
***本実施の形態の効果の説明***
 以上のように、本実施の形態に係るテスト自動化装置は、モデルからパスと因子を抽出するフロー解析部と、パスから分岐網羅するようにテストケースを生成するテストケース生成部を備える。また、テスト自動化装置は、生成されたテストケースを用いてテストを実行するテスト実行部と、欠陥の情報に基づきテストケースの追加の判断を行うテスト結果判定部とを備える。よって、本実施の形態に係るテスト自動化装置よれば、欠陥の情報に基づきテストケースの追加の判断を行うことができるので、効率的かつ効果的なテストを実行することができる。
 また、本実施の形態に係るフロー解析部によれば、与えられたモデルから全ての分岐を一度以上通過するようにパスを抽出し、モデル内の因子を列挙するので、テストケースの生成を効率的に行うことができる。
 また、本実施の形態に係るテストケース生成部によれば、フロー解析部の処理後、各パスから列挙した因子に対して分岐網羅を基準に水準を決定し、テストケースを生成するの
で、テストケースの生成をより効率的に行うことができる。
 また、本実施の形態に係るテストケース生成部によれば、結果判定部の処理後、欠陥に関わる因子に対し、条件網羅を基準に値を決定し、テストケースを生成するので、モデルにおいて欠陥に関わる箇所を重点的にテストするテストケースを生成することができる。
 また、本実施の形態に係るテスト実行部によれば、テストケースの各水準をそれぞれパス上の因子に与えて処理を逐次実行し、欠陥が検出されたらその位置情報を記録するので、位置情報から欠陥に関わる因子を的確に選択することができる。
 また、本実施の形態に係る結果評価部によれば、欠陥が検出されたパスが存在するか検証し、存在した場合、欠陥に関わる因子が条件網羅を満たしていないか検証し、条件網羅していなければ、新たなテストケースを追加すると判断するので、効率的かつ効果的なテストケースを生成することができる。
 また、本実施の形態に係るテストケース生成部、テスト実行部、結果判定部によれば、結果判定部でテストケースの追加を行うと判断した場合、再びテストケース生成部に戻り、テストケースを生成した後にテスト実行部、結果判定部を実行し、テストケースを追加しないと判定するまでこの処理を繰り返すので、効率的かつ効果的なテストを欠陥に関わる因子について重点的に実行することができる。
 また、本実施の形態に係るテストケース生成部によれば、条件網羅率を欠陥に関わる度合いにより操作しながらテストケースを生成することができるので、きめ細かくテストケースを決定することができ、効率的かつ効果的なソフトウェアのテストを行うことができる。
 以上のように、本実施の形態に係るテスト自動化装置は、テストケース追加後は、再びテスト実行部にて新たに追加されたテストケースを用いてテストの自動実行を行う。テスト自動化装置は、このようなテストケース生成部から結果判定部までの処理のサイクルを、テストケースの追加を行わないと判断するまで繰り返す。このように、本実施の形態に係るテスト自動化装置は、本アイデアは欠陥の情報をフィードバックしてテストケースを生成することで、欠陥箇所の周辺の重点的なテストを可能にしており、より効率的かつ効果的なソフトウェアのテストを実現することができる。
 実施の形態2.
 本実施の形態では、主に、実施の形態1と異なる点について説明する。
 本実施の形態において、実施の形態1で説明した構成と同様の構成には同一の符号を付し、その説明を省略する。
 上記の実施の形態1では、結果判定部150の処理後にテストケースを追加する際、テストケース生成部130は網羅基準として条件網羅を用いていた。しかし、本実施の形態では、フロー解析部120の処理直後に生成されるテストケースよりも詳細に動作を網羅したテストケースを生成可能であれば、テストケース生成部130は条件網羅以外の網羅基準を用いてテストケースを生成してもよい。
***構成の説明***
 本実施の形態に係るテスト自動化装置100の構成は、実施の形態1で説明した図1と同様である。
***動作の説明***
 図9は、本実施の形態に係るテスト自動化処理S100において結果判定処理S140後の追加テストケース生成処理S123aを説明する図である。
 本実施の形態に係る追加テストケース生成処理S123aは、経路網羅を用いて追加のテストケースを生成する。
 図9では、モデル200上の命令2で欠陥が検出されている場合の経路網羅の例を示している。命令2で欠陥が検出されたとき、結果判定部150は、欠陥箇所である発生位置1411の幾つか前の命令から命令2まで経路網羅されているか検証する。何命令前から網羅するかは任意で設定する。
 すなわち、結果判定部150は、テスト結果141に含まれる発生位置1411に基づいて、発生位置1411より前に実行される第1命令と発生位置1411より後に実行される第2命令とを結ぶ経路が経路網羅されたか否かを判定する。結果判定部150は、第1命令と第2命令とを結ぶ経路が経路網羅されていないと判定した場合にテストケースの追加を要すると判定する。なお、図9において命令1は第1命令の例であり、命令2は第2命令の例である。
 図9では、結果判定部150は、命令1から命令2までを検証している。その結果、結果判定部150は、命令1から命令2までを経路網羅されていなければ、テストケース追加と判定し、テストケース追加の判定結果151をテストケース生成部に出力する。
 テストケース生成部130は、結果判定部150により命令1と命令2とを結ぶ経路が経路網羅されていないと判定された場合、命令1と命令2とを結ぶ経路を経路網羅することにより命令間パス1512を抽出する。また、テストケース生成部130は、命令間パス1512の各パスにおいて用いられる命令間因子1513を抽出し、命令間パス1512と命令間因子1513とをパス121と因子122として解析結果161に含める。その後、テスト自動化装置100は、実施の形態1で説明したように、各パスについて必要であればテストケースを追加しつつテストを実行する。
 テストケース生成部130は、命令1から命令2までのパスを網羅的に抽出する。テストケース生成部130は、図9の(A)~(E)の5つのパスを命令間パス1512として抽出したものとする。テストケース生成部130は、得られた(A)~(E)の各パス上の命令間因子1513を取得し、命令間因子1513の各因子の水準を決定する。このとき、テストケース生成部130は、各パスにおいて、分岐網羅を網羅基準としてテストケースを生成してもよい。あるいは、テストケース生成部130は、各パスにおいて、条件網羅を網羅基準としてテストケースを生成してもよい。
 テストケース生成部130は、各パスにおいて、実施の形態1で説明したように新たにテストケースを生成し、テストケース情報171に追加する。
 以上で、追加テストケース生成処理S123aの説明を終わる。
***本実施の形態の効果の説明***
 以上のように、本実施の形態に係るテスト自動化装置によれば、テストケース生成部が経路網羅を用いることで動作の因果関係に基づいてテストケースを生成可能となり、効率的かつ効果的なソフトウェアのテストが実現する。
 実施の形態3.
 本実施の形態では、主に、実施の形態1,2と異なる点について説明する。
 本実施の形態において、実施の形態1,2で説明した構成と同様の構成には同一の符号を付し、その説明を省略する。
 上記の実施の形態1,2に係るテスト自動化装置100は、欠陥箇所の周辺を重点的に
テストする追加のテストケースを生成するものであった。本実施の形態では、欠陥の箇所のみならず、モデルの修正や処理の追加を行った箇所についても同様に、その周辺を重点的にテストするようにテストケースを生成する場合について説明する。これは、一般にモデルの修正やモデルへの処理の追加等、モデルの部分的な変更を行った場合、その周辺に欠陥が発生しやすいとされているためである。テストケースの生成は、修正または追加を行った処理の幾つか前後の命令の間を経路網羅することで実現する。
***構成の説明***
 本実施の形態に係るテスト自動化装置100の構成は、実施の形態1で説明した図1と同様である。
 なお、ソフトウェアのモデル200は、そのソフトウェアを修正追加した場合、追加修正した箇所を示す情報である変更位置1412が含まれているものとする。
***動作の説明***
 図10は、本実施の形態に係るテスト自動化処理S100において結果判定処理S140a及び追加テストケース生成処理S123bを説明する図である。
 結果判定処理S140aにおいて、結果判定部150は、各パスにおいて、欠陥の発生を検知すると共に修正追加を行った箇所があるか否かを検知する。
 図10に示すように、モデル200の命令1から命令2の間の命令3に修正追加を行ったものとする。
 命令3で修正追加が検出されたとき、結果判定部150は、修正追加箇所の幾つか前の命令から幾つか後の命令まで経路網羅されているか検証する。何命令前から何命令後まで網羅するかは任意で設定する。
 フロー解析部120は、ソフトウェアが変更された位置を変更位置1412として含むモデル200を取得する。
 結果判定部150は、モデル200に含まれる変更位置1412より前に実行される第3命令と変更位置1412より後に実行される第4命令とを結ぶ経路が経路網羅されたか否かを判定する。結果判定部150は、第3命令と第4命令とを結ぶ経路が経路網羅されていないと判定した場合にテストケースの追加を要すると判定する。図10において命令1は第3命令の例であり、命令2は第4命令の例である。
 結果判定部150は、命令1から命令2までを検証している。その結果、結果判定部150は、命令1から命令2までを経路網羅されていなければ、テストケース追加と判定し、テストケース追加の判定結果151をテストケース生成部130に出力する。
 テストケース生成部130は、結果判定部150により第3命令と第4命令とを結ぶ経路が経路網羅されていないと判定された場合、第3命令と第4命令とを結ぶ経路を経路網羅することにより抽出されるパスを命令間パス1512とする。また、テストケース生成部130は、命令間パス1512の各パスにおいて用いられる命令間因子1513を抽出し、命令間パス1512と命令間因子1513とをパス121と因子122として解析結果161に含める。その後、テスト自動化装置100は、実施の形態1で説明したように、各パスについて必要であればテストケースを追加しつつテストを実行する。
 テストケース生成部130は、命令1から命令2までのパスを網羅的に抽出する。テストケース生成部130は、図10の(A)~(E)の5つのパスを命令間パス1512として抽出したものとする。テストケース生成部130は、得られた(A)~(E)の各パス上の命令間因子1513を取得し、命令間因子1513の各因子の水準を決定する。このとき、テストケース生成部130は、各パスにおいて、分岐網羅を網羅基準としてテス
トケースを生成してもよい。あるいは、テストケース生成部130は、各パスにおいて、条件網羅を網羅基準としてテストケースを生成してもよい。
 テストケース生成部130は、各パスにおいて、実施の形態1で説明したように新たにテストケースを生成し、テストケース情報171に追加する。
 以上で、追加テストケース生成処理S123bの説明を終わる。
***本実施の形態の効果の説明***
 以上のように、本実施の形態に係るテスト自動化装置によれば、欠陥のみならず修正または追加の情報も用いることで、モデル上の欠陥が発生する可能性のある箇所についてテスト可能なテストケースが得られるため、効率的かつ効果的なソフトウェアのテストが実現する。
 次に、図1及び図11を用いて、本実施の形態に係るテスト自動化装置のハードウェア構成の一例について説明する。
 テスト自動化装置はコンピュータである。
 テスト自動化装置は、プロセッサ901、補助記憶装置902、メモリ903、通信装置904、入力インタフェース905、ディスプレイインタフェース906といったハードウェアを備える。
 プロセッサ901は、信号線910を介して他のハードウェアと接続され、これら他のハードウェアを制御する。
 入力インタフェース905は、入力装置907に接続されている。
 ディスプレイインタフェース906は、ディスプレイ908に接続されている。
 プロセッサ901は、プロセッシングを行うIC(Integrated Circuit)である。
 プロセッサ901は、例えば、CPU、DSP(Digital Signal Processor)、GPUである。
 補助記憶装置902は、例えば、ROM(Read Only Memory)、フラッシュメモリ、HDD(Hard Disk Drive)である。補助記憶装置902は、作成したソフトウェアのモデルやテスト自動化装置の機能を実現するプログラム、テスト結果の出力ファイルを保持しておく装置である。
 メモリ903は、例えば、RAM(Random Access Memory)である。メモリ903は、プログラムの実行ファイルやテスト対象となるソフトウェアのモデル、プロセッサ901によるプログラムの実行結果である解析結果、テストケース、テスト結果及び網羅率を記憶する。
 通信装置904は、データを受信するレシーバー9041及びデータを送信するトランスミッター9042を含む。
 通信装置904は、例えば、通信チップ又はNIC(Network Interface Card)である。
 入力インタフェース905は、入力装置907のケーブル911が接続されるポートである。
 入力インタフェース905は、例えば、USB(Universal Serial Bus)端子である。
 ディスプレイインタフェース906は、ディスプレイ908のケーブル912が接続されるポートである。
 ディスプレイインタフェース906は、例えば、USB端子又はHDMI(登録商標)(High Definition Multimedia Interface)端子である。
 入力装置907は、例えば、マウス、キーボード又はタッチパネルである。入力装置907からの入力によりプログラムが実行される。
 ディスプレイ908は、例えば、LCD(Liquid Crystal Display)である。出力結果をディスプレイ908により確認する。
 補助記憶装置902には、上述したブロック構成図に示すフロー解析部、テストケース生成部、テスト実行部、結果判定部を実現するプログラムが記憶されている。以下、フロー解析部、テストケース生成部、テスト実行部、結果判定部をまとめて「部」と表記する。
 上述した「部」の機能を実現するプログラムは、テスト自動化プログラムとも称される。「部」の機能を実現するプログラムは、1つのプログラムであってもよいし、複数のプログラムから構成されていてもよい。
 このプログラムは、メモリ903にロードされ、プロセッサ901に読み込まれ、プロセッサ901によって実行される。
 更に、補助記憶装置902には、OS(Operating System)も記憶されている。
 そして、OSの少なくとも一部がメモリ903にロードされ、プロセッサ901はOSを実行しながら、「部」の機能を実現するプログラムを実行する。
 図11では、1つのプロセッサ901が図示されているが、テスト自動化装置が複数のプロセッサ901を備えていてもよい。
 そして、複数のプロセッサ901が「部」の機能を実現するプログラムを連携して実行してもよい。
 また、「部」の処理の結果を示す情報やデータや信号値や変数値が、メモリ903、補助記憶装置902、又は、プロセッサ901内のレジスタ又はキャッシュメモリにファイルとして記憶される。
 「部」を「サーキットリー」で提供してもよい。
 また、「部」を「回路」又は「工程」又は「手順」又は「処理」に読み替えてもよい。また、「処理」を「回路」又は「工程」又は「手順」又は「部」に読み替えてもよい。
 「回路」及び「サーキットリー」は、プロセッサ901だけでなく、ロジックIC又はGA(Gate Array)又はASIC(Application Specific Integrated Circuit)又はFPGA(Field-Programmable Gate Array)といった他の種類の処理回路をも包含する概念である。
 なお、プログラムプロダクトと称されるものは、「部」として説明している機能を実現するプログラムが記録された記憶媒体、記憶装置などであり、見た目の形式に関わらず、コンピュータ読み取り可能なプログラムをロードしているものである。
 上記の実施の形態では、フロー解析部、テストケース生成部、テスト実行部、結果判定部がそれぞれ独立した機能ブロックとしてテスト自動化装置を構成している。しかし、テスト自動化装置は上記のような構成でなくてもよく、テスト自動化装置の構成は任意である。
 例えば、テストケース生成部と結果判定部とを1つの機能ブロックとしてもよい。テスト自動化装置の機能ブロックは、上記の実施の形態で説明した機能を実現することができれば、任意である。これらの機能ブロックを、他のどのような組み合わせ、あるいは任意のブロック構成でテスト自動化装置を構成しても構わない。
 また、上述したように、テスト自動化装置は1つの装置でなく、複数の装置から構成さ
れたテスト自動化システムでもよい。
 また、実施の形態1から3について説明したが、これらの3つの実施の形態のうち、複数を部分的に組み合わせて実施しても構わない。あるいは、これらの3つの実施の形態のうち、1つの実施の形態を部分的に実施しても構わない。その他、これらの3つの実施の形態を、全体としてあるいは部分的に、どのように組み合わせて実施しても構わない。
 なお、上記の実施の形態は、本質的に好ましい例示であって、本発明、その適用物や用途の範囲を制限することを意図するものではなく、必要に応じて種々の変更が可能である。
 100 テスト自動化装置、120 フロー解析部、121 パス、122 因子、131 テストケース、130 テストケース生成部、140 テスト実行部、141 テスト結果、150 結果判定部、151 判定結果、160 解析結果記憶部、161 解析結果、170 テストケース記憶部、171 テストケース情報、180 網羅率記憶部、181 網羅率情報、190 テスト結果記憶部、191 テスト結果情報、200 モデル、901 プロセッサ、902 補助記憶装置、903 メモリ、904 通信装置、905 入力インタフェース、906 ディスプレイインタフェース、907 入力装置、908 ディスプレイ、910 信号線、911,912 ケーブル、9041 レシーバー、9042 トランスミッター、1221 欠陥関連因子、1311 分岐網羅テストケース、1312 条件網羅テストケース、1411 発生位置、1412 変更位置、1512 命令間パス、1513 命令間因子、1811 条件網羅率、S100 テスト自動化処理、S110 フロー解析処理、S120 テストケース生成処理、S122 分岐網羅テストケース生成処理、S123,S123a,S123b 追加テストケース生成処理、S130 テスト実行処理、S140,S140a 結果判定処理。

Claims (10)

  1.  ソフトウェアの処理の流れを表すモデルを取得し、前記モデルから前記ソフトウェアの処理の経路を表すパスと、前記ソフトウェアの処理で用いられる因子とを抽出し、抽出した前記パスと前記因子とを含む解析結果を出力するフロー解析部と、
     前記解析結果を記憶する解析結果記憶部と、
     前記解析結果に含まれる前記パスと前記因子とを用いて、前記パスを分岐網羅するように前記因子に値を設定したテストケースを分岐網羅テストケースとして生成するテストケース生成部と、
     前記テストケース生成部により生成された前記分岐網羅テストケースを用いて前記ソフトウェアのテストを実行し、実行した結果をテスト結果として出力するテスト実行部と、
     前記テスト実行部により出力された前記テスト結果を用いて、テストケースの追加の要否を判定する結果判定部と
    を備えるテスト自動化装置。
  2.  前記テスト実行部は、
     前記分岐網羅テストケースを用いた前記ソフトウェアのテストを実行中に欠陥が発生した場合、前記テスト結果に前記欠陥が発生した発生位置を含め、
     前記結果判定部は、
     前記テスト結果に含まれる前記発生位置に基づいて、前記因子のうち前記欠陥に関わる因子を欠陥関連因子として抽出し、抽出した前記欠陥関連因子が条件網羅されたか否かを判定し、前記欠陥関連因子が条件網羅されていないと判定した場合に前記テストケースの追加を要すると判定する請求項1に記載のテスト自動化装置。
  3.  前記テストケース生成部は、
     前記結果判定部により前記テストケースの追加を要すると判定された場合、前記欠陥関連因子の条件網羅率が閾値を満たすように前記欠陥関連因子に値を設定した条件網羅テストケースを生成する請求項2に記載のテスト自動化装置。
  4.  前記テストケース生成部は、
     前記分岐網羅テストケースを生成すると共に、前記因子の条件網羅率を記憶装置に記憶し、
     前記結果判定部は、
     前記因子の条件網羅率に基づいて、前記因子のうちの前記欠陥関連因子が条件網羅されているか否かを判定する請求項3に記載のテスト自動化装置。
  5.  前記結果判定部は、
     前記テスト結果に含まれる前記発生位置に基づいて、前記発生位置より前に実行される第1命令と前記発生位置より後に実行される第2命令とを結ぶ経路が経路網羅されたか否かを判定し、前記第1命令と前記第2命令とを結ぶ経路が経路網羅されていないと判定した場合に前記テストケースの追加を要すると判定する請求項2から4のいずれか1項に記載のテスト自動化装置。
  6.  前記テストケース生成部は、
     前記結果判定部により前記第1命令と前記第2命令とを結ぶ経路が経路網羅されていないと判定された場合、前記第1命令と前記第2命令とを結ぶ経路を経路網羅することにより命令間パスを抽出すると共に、前記命令間パスにおいて用いられる命令間因子を抽出し、前記命令間パスと前記命令間因子とを前記パスと前記因子として前記解析結果に含める請求項5に記載のテスト自動化装置。
  7.  前記フロー解析部は、
     前記ソフトウェアが変更された位置を変更位置として含む前記モデルを取得し、
     前記結果判定部は、
     前記モデルに含まれる前記変更位置より前に実行される第3命令と前記発生位置より後に実行される第4命令とを結ぶ経路が経路網羅されたか否かを判定し、前記第3命令と前記第4命令とを結ぶ経路が経路網羅されていないと判定した場合に前記テストケースの追加を要すると判定する請求項6に記載のテスト自動化装置。
  8.  前記テストケース生成部は、
     前記結果判定部により前記第3命令と前記第4命令とを結ぶ経路が経路網羅されていないと判定された場合、前記第3命令と前記第4命令とを結ぶ経路を経路網羅することにより抽出されるパスを前記命令間パスとする請求項7に記載のテスト自動化装置。
  9.  フロー解析部が、ソフトウェアの処理の流れを表すモデルを取得し、前記モデルから前記ソフトウェアの処理の経路を表すパスと、前記ソフトウェアの処理で用いられる因子とを抽出し、抽出した前記パスと前記因子とを含む解析結果を出力し、
     テストケース生成部が、前記解析結果に含まれる前記パスと前記因子とを用いて、前記パスを分岐網羅するように前記因子に値を設定したテストケースを分岐網羅テストケースとして生成し、
     テスト実行部が、前記テストケース生成部により生成された前記分岐網羅テストケースを用いて前記ソフトウェアのテストを実行し、実行した結果をテスト結果として出力し、
     結果判定部が、前記テスト実行部により出力された前記テスト結果を用いて、テストケースの追加の要否を判定するテスト自動化方法。
  10.  ソフトウェアの処理の流れを表すモデルを取得し、前記モデルから前記ソフトウェアの処理の経路を表すパスと、前記ソフトウェアの処理で用いられる因子とを抽出し、抽出した前記パスと前記因子とを含む解析結果を出力するフロー解析処理と、
     前記解析結果に含まれる前記パスと前記因子とを用いて、前記パスを分岐網羅するように前記因子に値を設定したテストケースを分岐網羅テストケースとして生成するテストケース生成処理と、
     前記テストケース生成処理により生成された前記分岐網羅テストケースを用いて前記ソフトウェアのテストを実行し、実行した結果をテスト結果として出力するテスト実行処理と、
     前記テスト実行処理により出力された前記テスト結果を用いて、テストケースの追加の要否を判定する結果判定処理と
    をコンピュータに実行させるテスト自動化プログラム。
PCT/JP2016/060213 2015-04-20 2016-03-29 テスト自動化装置、テスト自動化方法及びテスト自動化プログラム WO2016170937A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017514040A JP6143993B2 (ja) 2015-04-20 2016-03-29 テスト自動化装置、テスト自動化方法及びテスト自動化プログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2015-086281 2015-04-20
JP2015086281 2015-04-20

Publications (1)

Publication Number Publication Date
WO2016170937A1 true WO2016170937A1 (ja) 2016-10-27

Family

ID=57143008

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/060213 WO2016170937A1 (ja) 2015-04-20 2016-03-29 テスト自動化装置、テスト自動化方法及びテスト自動化プログラム

Country Status (2)

Country Link
JP (1) JP6143993B2 (ja)
WO (1) WO2016170937A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109828911A (zh) * 2018-12-26 2019-05-31 北京仁科互动网络技术有限公司 一种测试方法和装置
CN112685283A (zh) * 2019-10-17 2021-04-20 拉扎斯网络科技(上海)有限公司 测试校验方法、装置、电子设备及计算机可读存储介质
CN112685322A (zh) * 2021-01-12 2021-04-20 武汉思普崚技术有限公司 一种客制化测试方法、装置及系统
CN113010424A (zh) * 2021-03-17 2021-06-22 平安壹钱包电子商务有限公司 接口自动化测试处理方法、系统、计算机设备与存储介质
CN114615695A (zh) * 2022-03-18 2022-06-10 机械工业仪器仪表综合技术经济研究所 一种5g工业终端模拟装置及测试方法
US11994977B2 (en) 2019-03-25 2024-05-28 Mitsubishi Electric Corporation Test case generation apparatus, test case generation method, and computer readable medium

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013077124A (ja) * 2011-09-30 2013-04-25 Hitachi Ltd ソフトウェアテストケース生成装置

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013077124A (ja) * 2011-09-30 2013-04-25 Hitachi Ltd ソフトウェアテストケース生成装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109828911A (zh) * 2018-12-26 2019-05-31 北京仁科互动网络技术有限公司 一种测试方法和装置
US11994977B2 (en) 2019-03-25 2024-05-28 Mitsubishi Electric Corporation Test case generation apparatus, test case generation method, and computer readable medium
CN112685283A (zh) * 2019-10-17 2021-04-20 拉扎斯网络科技(上海)有限公司 测试校验方法、装置、电子设备及计算机可读存储介质
CN112685322A (zh) * 2021-01-12 2021-04-20 武汉思普崚技术有限公司 一种客制化测试方法、装置及系统
CN112685322B (zh) * 2021-01-12 2022-10-04 武汉思普崚技术有限公司 一种客制化测试方法、装置及系统
CN113010424A (zh) * 2021-03-17 2021-06-22 平安壹钱包电子商务有限公司 接口自动化测试处理方法、系统、计算机设备与存储介质
CN113010424B (zh) * 2021-03-17 2024-04-02 平安壹钱包电子商务有限公司 接口自动化测试处理方法、系统、计算机设备与存储介质
CN114615695A (zh) * 2022-03-18 2022-06-10 机械工业仪器仪表综合技术经济研究所 一种5g工业终端模拟装置及测试方法

Also Published As

Publication number Publication date
JP6143993B2 (ja) 2017-06-07
JPWO2016170937A1 (ja) 2017-06-29

Similar Documents

Publication Publication Date Title
JP6143993B2 (ja) テスト自動化装置、テスト自動化方法及びテスト自動化プログラム
US10671516B2 (en) Method, device, and computer program product for testing code
US20150007148A1 (en) Identifying Test Cases Based on Changed Test Code
JP2006024006A (ja) テストケース生成装置、テストケース生成プログラム、モデルベース開発プログラム、ソースコード生成妥当性診断装置、ソースコード生成妥当性診断プログラム、およびモデルベース開発方法。
US20090019315A1 (en) Automated software testing via multi-channel remote computing
JP2016115175A (ja) ソフトウェアテスト装置およびソフトウェアテストプログラム
JP2019101581A (ja) ソフトウェア品質判定装置、ソフトウェア品質判定方法、及びソフトウェア品質判定プログラム
JP2009294846A (ja) テストケース生成装置、テストケース生成プログラム、およびテストケース生成方法
JP7077909B2 (ja) デッドコード解析プログラム、デッドコード解析方法及びデッドコード解析装置
US7774668B2 (en) System and method for detecting non-reproducible pseudo-random test cases
JP2009277110A (ja) ソフトウェア試験及び開発支援装置並びに当該装置用プログラム
JP7215501B2 (ja) 依存関係検出装置および依存関係検出方法
JP6878707B2 (ja) 試験装置、試験方法および試験プログラム
US9734458B2 (en) Predicting outcome based on input
JP2009134360A (ja) モデル検査システム、モデル検査方法およびモデル検査用プログラム
US20100306745A1 (en) Efficient Code Instrumentation
JP5595304B2 (ja) プログラム試験装置、プログラム試験装置のプログラム試験方法およびプログラム試験プログラム
US20150026523A1 (en) Debugging method and computer program product
JP6320269B2 (ja) ソフトウェア試験支援装置およびソフトウェア試験支援プログラム
JP2013152667A (ja) 操作画面の試験シナリオ生成装置、試験シナリオ生成方法およびプログラム
JP2012059202A (ja) テストケース生成装置、テストケース生成方法およびテストケース生成プログラム
JP2021117666A (ja) コード検査ツール、コード検査方法
JP2011180850A (ja) モデル生成装置、モデル生成方法およびモデル生成プログラム
JP2014232428A (ja) テスト実行支援装置、テストシステム、テスト実行方法、及び、テスト実行支援プログラム
US8555226B1 (en) Automatic verification of dependency

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16782959

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017514040

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16782959

Country of ref document: EP

Kind code of ref document: A1