Test case generation device and test case generation method

Abstract

To extract a more appropriate test case to improve test quality of a bug test of a program, without depending on knowledge or experience of a person in charge.SOLUTION: A test case generator (100) which generates a test item of a bug test implemented for a program comprises: a design data acquisition unit (110) which acquires design data including a source code of the program which is an object of the bug test; an analysis viewpoint setting unit (120) which sets an analysis viewpoint of each function included in the program on the basis of the design data; a determination value calculation unit (130) which calculates a determination value in terms of each analysis viewpoint for each function; and a test parameter extraction unit (140) which determines extraction completeness of a test parameter used for the bug test on the basis of the determination value, and extracts combination of the test parameters on the basis of the determined extraction completeness.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a test case generation device and a test case generation method, and in particular to a program Regarding the extraction of bug fix test items. [Background technology]

[0002] A technology for generating test cases to check whether a program works properly Patent Document 1 describes a method for generating test cases that output test cases by inputting specific conditions. The technology is disclosed.

[0003] Patent Document 2 also describes a method for extracting test cases by weighting the importance of the tests. The technique is disclosed. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent Publication No. 2021-163111 [Patent Document 2] Japanese Patent Application Publication No. 63-782321 Summary of the Invention [Problem to be solved by the invention]

[0005] In Patent Document 1, specific conditions are input and test cases are output, so that In addition, in Patent Document 2, the test results are inputted. Based on this, we determine the importance of test parameters, create test viewpoints, and create test cases. In these methods, the selection of test parameters and test cases depend on the knowledge and experience of the person in charge. In order to determine the extraction algorithm, the selection of test parameters and the test case extraction algorithm are insufficient. The problem of not being able to extract optimal test case combinations due to incorrect algorithm selection but be.

[0006] The present invention has been made to solve the above problems, and is based on the knowledge and experience of the person in charge. Extract more appropriate test cases and improve the quality of program bug testing without The purpose is to [Means for solving the problem]

[0007] In order to solve the above problems, the present invention has the configurations described in the claims. For example, it is a test case that generates test items for bug testing to be performed on a program. A source generator that generates design data including the source code of a program to be subjected to bug testing. a design data acquisition unit that acquires design data; and an analysis point setting unit for setting an analysis point of view for a function; and a judgment value for each of the functions from the viewpoint of each analysis point of view. a judgment value calculation unit that calculates a test parameter to be used in a bug test based on the judgment value; determining an extraction coverage of the test parameters; and determining a combination of the test parameters based on the determined extraction coverage. and a test parameter extraction unit that extracts the test parameter. [Effects of the Invention]

[0008] According to the present invention, more appropriate test cases can be extracted without relying on the knowledge or experience of the person in charge. This can improve the quality of program bug testing. The purpose, configuration, and effects of the present invention will be clarified in the following embodiments. [Brief explanation of the drawings]

[0009] [Figure 1]FIG. 1 is a hardware configuration diagram of a test case generation device. [Figure 2] FIG. 2 is a functional block diagram of a test case generation device. [Figure 3] FIG. 10 is a diagram showing the operational flow of the initial bug test. [Figure 4] 10A and 10B are diagrams showing data to be referenced or output in the initial bug test, where (a) shows key test items and test extraction conditions, and (b) shows extracted combination test parameters. [Figure 5] FIG. 10 is a diagram showing the operation flow of an additional test that is performed after the initial test or the additional test is executed. [Figure 6] The following diagrams show the data to be referenced or output in additional tests after test execution: (a) extracted test parameters + bugs detected after test execution table, (b) additional key test items and test extraction condition table, and (c) additional extracted combination test parameter table. [Figure 7] FIG. 2 is an explanatory diagram showing processing blocks of the test case generation device. [Figure 8] FIG. 10 is a diagram showing a calculation flow of a judgment value according to cyclomatic complexity. [Figure 9] 10A and 10B are diagrams showing tables relating to the calculation of judgment values ​​according to cyclomatic complexity, in which (a) is a cyclomatic complexity score conversion table, (b) is a cyclomatic complexity weighting table, and (c) is a cyclomatic complexity judgment value calculation result table for each function. [Figure 10] 10A and 10B are diagrams showing examples of source code correction tickets, where (a) shows an example of a source code correction ticket, and (b) shows an example of a recent bug fix. [Figure 11] FIG. 10 is a diagram showing a calculation flow of a judgment value according to the number of recent bug fixes. [Figure 12] The following figures show tables for calculating judgment values ​​according to the number of recent bug fixes, where (a) is a score conversion table for the number of bug fixes, (b) is a weighting table for the number of bug fixes, and (c) is a table showing the judgment value calculation results for each function for the number of recent bug fixes. [Figure 13]FIG. 10 is a diagram showing a calculation flow of a judgment value according to the density of process-specific bugs. [Figure 14] The figures show tables relating to the calculation of judgment values ​​according to the density of bugs by process, where (a) is a conversion table of the density of bugs by process, (b) is a weighting table of the density of bugs by process, and (c) is a table of the judgment value calculation results for each function of the density of bugs by process. [Figure 15] FIG. 10 is a diagram showing a calculation flow of a judgment value according to the level of bug density in past projects. [Figure 16] The figures show tables relating to the calculation of judgment values ​​according to the level of bug density in past projects, where (a) is a score conversion table for the level of bug density in past projects, (b) is a weighting table for the level of bug density in past projects, and (c) is a table showing the results of calculating judgment values ​​for each function of bug density in past projects. [Figure 17] FIG. 10 is a diagram showing the calculation flow of a judgment value according to the level of bug density in the specification based on the review minutes. [Figure 18] A diagram showing an example of review minutes. [Figure 19] The following figures show tables relating to the calculation of judgment values ​​according to the level of bug density in specifications based on review minutes, where (a) is a conversion table of bug density level based on review minutes, (b) is a weighting table of bug density level based on review minutes, and (c) is a table showing the calculation results of judgment values ​​for each function of bug density based on review minutes. [Figure 20] FIG. 10 is a diagram showing a flow for extracting test parameters from judgment values ​​for each analysis viewpoint. [Figure 21] 10A and 10B are tables related to function combination test item parameter method judgment, in which (a) is a weighting table based on analysis data for each function, and (b) is a table of judgment value totals for each function and test parameter extraction method. [Figure 22] Decision table for calculating judgment values ​​for each function and extracting test parameters. [Figure 23] FIG. 10 is a diagram showing a flow for extracting additional test parameters from bugs detected after test execution. [Figure 24]These tables relate to the flow of extracting additional test parameters from bugs detected after test execution, where (a) is a weight conversion table for retest results, (b) is a bug density weighting table for retest results, (c) is a conversion table for difference judgment values ​​and parameter extraction methods for each function, and (d) is a table of bug weights after test execution and parameter extraction methods for additional items. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The same reference numerals are used and duplicated explanations will be omitted.

[0011] <Overall configuration of the test case generator> The test case generation device according to this embodiment is a test case generation device for detecting bugs in a program. The user inputs the design data into the test case generator. When the design data is input to the test case generator, the test case generator generates tests to detect bugs based on the design data. The user can generate test parameters based on the test parameters. The test case is generated, the test is executed to extract the bugs, and the bugs are fixed. Repeat until no more bugs are detected.

[0012] FIG. 1 is a hardware configuration diagram of a test case generation device.

[0013] The test case generation device 100 includes a CPU (Central Processing Unit). nits) 101, RAM (Random Access Memory) 102, ROM (Read Only Memory) 103, HDD (Hard Disk Drive) e) 104, an input I / F 105, and an output I / F 106, which are connected via a bus 107. The input I / F 105 is configured with computers connected to each other. An input device 108 such as a keyboard or a mouse is connected to the output I / F 106. An output device 109 such as a printer or a server connection In addition, the test case generation device 100 The hardware configuration is not limited to the above, and may be configured by a combination of a control circuit and a storage device. This may be done.

[0014] FIG. 2 is a functional block diagram of the test case generation device.

[0015] The test case generation device 100 includes a design data acquisition unit 110, an analysis viewpoint setting unit 120, a judgment unit 130, and a The test case generation unit 130 includes a constant value calculation unit 130 and a test parameter extraction unit 140. The CPU 101 loads a program that realizes the functions of the synthesis device 100 into the RAM 102 and executes it. The processing content of each part will be described later.

[0016] The test case generation device 100 also includes a specification storage unit 171, a specification review minutes storage unit 172, and a specification review minutes storage unit 173. a source code storage unit 172, a source code correction ticket storage unit 173, a source code correction ticket storage unit 174, and various the The table storage unit 181, the judgment value storage unit 182, and the test parameter storage unit 183 are included. Each storage unit is formed in a storage area of ​​the RAM 102 or the HDD 104.

[0017] <Overall overview of bug testing> Program bug testing generally involves an initial bug test and subsequent additional tests. Includes additional bug tests including items.

[0018] <<First time operation flow>> Figure 3 shows the operation flow of the first bug test. Figure 4 shows the operation flow of the first bug test. FIG. 1 shows the data to be referenced or output. (a) shows the key test items and test extraction conditions. (b) is the extracted combination test parameter. Below is a rough outline of the initial bug test. The initial operation will be explained in accordance with the steps in Figure 3.

[0019] (1) Design data input includes "design document," "design document review minutes," and "source code "," "Source Code Correction Ticket," and "Source Code Commit Log" are prepared and A user inputs design data into the test case generation device 100 (S1). The "code commit log" is a necessary link between the source code and the source code modification ticket. This is important data.

[0020] The design data acquisition unit 110 stores the input design data in the specification storage unit 171, the specification recorder 172, and the specification recorder 173. View minutes storage unit 172, source code storage unit 173, source code correction ticket storage unit The data is stored in unit 174.

[0021] In (2), the analysis viewpoint setting unit 120 sets the analysis viewpoint for each analysis viewpoint of the design data (complexity of the source code, etc.). , the number of bug fixes recently made, the level of bug density by process, the level of bug density in past projects (These are the initial and additional tests.) In the additional test, each analysis point for bug extraction after the test is set (S 2).

[0022] The judgment value calculation unit 130 calculates the judgment value set for each function of the program that is the target of bug detection. Weighting is performed for each analysis point, and a judgment value for each function is calculated.

[0023] In (3), the test parameter extraction unit 140 extracts the “important test parameters” corresponding to the judgment values ​​for each function. Enter the test items and test item extraction conditions into the test parameter extraction tool and run it. The combined test parameters are output (S3).

[0024] In (4), the user selects function 1, function 2, and function 3 based on the "extracted combination test parameters." Create and execute a combination test item for function 3 (S4).

[0025] (3) The combination test items output in "Extracted combination test parameters" are items Since the test cannot be performed immediately by just extracting the eyes, the test items are listed in (4). This test will extract any remaining bugs, so the user can easily find them. Then, after the bug is fixed, we add a new program to extract the bug. Do the test.

[0026] <<Creating and executing additional test items after test execution>> Figure 5 shows the operation flow of the additional test that is performed after the initial test or additional test is executed. FIG. 6 is a diagram showing data to be referenced or output in an additional test after the test execution. (a) is the extracted test parameters + detected bug table after test execution, (b) is the additional (c) Test item and test extraction condition table, (d) Additional extraction combination test parameter table The initial operation will be explained below in the order of the steps in Figure 5.

[0027] In (11), the user checks for bugs in the test items performed based on the extracted test parameters. The extracted items are checked, and the design data acquisition unit 110 updates the design data (S1 1).

[0028] In (12), the analysis point setting unit 120 and the judgment value calculation unit 130 calculate the value calculated in step S2. The judgement value is then re-analyzed by adding the bugs detected after the test, and weighting is applied to each function. The test parameter extraction unit 140 calculates a fixed value based on the result and selects additional priority test items. Test item extraction conditions are output (S12). This allows the development team to By reflecting the results, analyzing the development history of each function, and adjusting the weighting according to the development history, ,Select functions with high test priority as priority items and determine bug test extraction algorithm. It is possible.

[0029] In (13), the test parameter extraction unit 140 extracts additional key test items and test items. Input the conditions into the test parameter extraction tool and execute it to extract additional combination test parameters. The data is output (S13).

[0030] In (14), the user selects function 1, function 2, and function 3 based on the "extracted combination test parameters." Create a test item for the combination of function 3 (S14). When the bug is detected, the test execution result is Repeat steps (12) to (14) until no more test item bugs are found. The bug information of the test execution results of the test cases extracted under the above conditions is By reflecting this and changing the weighting of the above analysis points, we can prioritize functions that have a high rate of bugs after testing. You can reconfigure the extraction algorithm based on the parameters and automatically add test cases. By repeating this process and filling in the missing extracted test cases, the project Test cases that improve the quality of test cases according to the quality situation can be extracted.

[0031] <Outline of the test case generator process> FIG. 7 is an explanatory diagram showing processing blocks of the test case generation device.

[0032] (1) Design data input The user inputs design data of the program to be tested to the test case generation device 100. The configuration data includes the design document, the minutes of the design document review, the source code, This includes the code correction ticket and source code commit log. This is a manual operation that the user performs on the test case generation device 100. stores the input design data in each storage area of ​​the HDD 104.

[0033] (21) "Design Data Analysis Perspective" The analysis viewpoint setting unit 120 is configured to set the complexity of the source code structure, the number of bugs fixed recently, and the like. "Number of bugs," "Bug density by process," "Bug density of past projects," and "Reviews" The analysis point is set as "high density of bugs in specifications based on meeting minutes." Another analysis point is to set "bug extraction after testing."

[0034] (22) Calculation of judgment value for each analysis point The judgment value calculation unit 130 calculates the "cyclomatic complexity (CCN)" and "bug fix count (number of times)" "," "Bug density by process (items / kstep)," "Bug density of past projects (items / ks step) and "Specification bug density (cases / kstep)". In the additional test, Bug extraction after implementation (items / kstep)" is quantified for each function from each analysis point of view, and The judgment value is calculated for each analysis point by taking into account the weighting of the above. More details will be provided later.

[0035] (23) Total the judgement value for each function The judgment value calculation unit 130 aggregates the judgment values ​​calculated for each analysis point for each function, and calculates the function The total value of the judgment values ​​for each test is calculated.

[0036] (24) Weighting based on analytical data for each function The judgment value calculation unit 130 judges the weighting factor taking into account the analysis data for each function.

[0037] (25) Calculation of judgment value for each function The judgment value calculation unit 130 calculates the judgment value of each function by multiplying the total value of the judgment values ​​by a weight for each function. Put out.

[0038] (26) Function combination test item parameter method judgment The test parameter extraction unit 140 calculates the importance of the test items for each function from the judgment value of each function. Furthermore, a "test parameter extraction method" is used to determine whether to cover or thin out the test results depending on the judgment value. In other words, determining the test parameter extraction method means determining the test parameter extraction method. This is synonymous with determining comprehensiveness.

[0039] (3) Run the parameter extraction tool The test parameter extraction unit 140 uses the extracted test parameters as a parameter extraction tool. The optimum test parameter combination is extracted by inputting the parameter into the parameter extraction tool. The tool is an existing tool.

[0040] From the above "Design Data Analysis Point of View Setting" to "Function Combination Test Item Parameter Method Judgment" The internal processing of the test case generation device 100 is then carried out until the optimal combination is determined. The matching test parameters are output.

[0041] (4) Creating test items and conducting tests The user creates test cases based on the optimal combination of test parameters, and Perform initial or additional bug testing on the program to be targeted for bug detection do.

[0042] (41) Test result bug detection Based on the results of the bug testing, bugs are identified and fixed, and the fix history is recorded.

[0043] <<(22) Specific examples of calculating judgment values ​​for each analysis perspective>> Analysis perspective 1: Cyclomatic complexity FIG. 8 is a diagram showing a calculation flow of a judgment value according to cyclomatic complexity. FIG. 1 is a diagram showing a table for calculating a judgment value according to cyclomatic complexity; (a) is a conversion table of cyclomatic complexity scores, (b) is a conversion table of cyclomatic complexity scores. (c) is the result of calculating the cyclomatic complexity for each function. This is a table. Cyclomatic complexity score conversion table and cyclomatic The complexity weighting table is stored in advance in the HDD 104 of the test case generation device 100. Figure 10 shows an example of a source code correction ticket. (a) shows the source code. (a) shows an example of a fix ticket, and (b) shows an example of a recent bug fix.

[0044] As shown in the cyclomatic complexity score conversion table in Figure 9(a), The higher the tick complexity, the more complex the program is, and the more likely bugs are to occur. Therefore, the higher the cyclomatic complexity, the higher the score will be given.

[0045] Also, as shown in the cyclomatic complexity weighting table in Figure 9(b), The weighting of cyclomatic complexity is based on the development of the function that calculates cyclomatic complexity. The development details of each function are obtained from the source code correction ticket. You will benefit.

[0046] The cyclomatic complexity weighting table shows that the more bugs a program has, the more likely it is to contain them. The weighting of "New Development" is high as a development stage where bugs may already have been fixed. The lowest weighting is given to "repurposed or unmodified" materials, which have the highest potential.

[0047] "Source code correction ticket" is a ticket that manages project management tasks and bugs. In the NET system, instruction data and bug fixes are issued when issuing instructions to modify source code. This is data that records the revision history of the

[0048] As shown in Figure 10(a), the source code correction ticket contains the correction order, bug details, etc. By referring to the source code correction ticket, you can check the source code correction history. The history and modifications of the source code are known, and the functions corresponding to the source code are evaluated in terms of cyclomatic complexity. It is possible to determine which of the five development stages specified in the weighting table it corresponds to. Cut.

[0049] As shown in Figure 10(b), an example of recent bug fix data is shown. For example, In 1, the number of bug fixes was high even in the fourth week of testing, meaning that many bugs occurred at the end of the test. Therefore, function 1 is relatively more comprehensive than the other functions. Tests using various parameter combinations are required.

[0050] As shown in Figure 8, the calculation process for the judgment value of a function using cyclomatic complexity as the analysis point is In this analysis, the analysis viewpoint setting unit 120 first analyzes the design data, more specifically the specifications and source code. The source code is acquired (S2211), and the acquired design data is linked to the source code for each function. (S2212).

[0051] The judgment value calculation unit 130 executes the complexity measurement tool for each source code and outputs the complexity (CCN). The data is then tallied for each function (S2213).

[0052] The judgment value calculation unit 130 converts the collected complexity into a "weight conversion table of cyclomatic complexity." The score is based on the "Cycromatic Complexity Weighting Table" Find it. (S2214)

[0053] The judgment value calculation unit 130 multiplies the calculated score by a weight, calculates a judgment value for each function, and outputs it. (S2215).

[0054] The judgment value calculation unit 130 repeats S2213 to S2216 for the number of functions, The judgment value calculation unit 130 creates a "calculation table for each function of the metric complexity." If the calculation of the cyclomatic complexity of the function has not been completed (S 2216: Yes), the process from step S2213 is repeated for other functions. Repeat the process for each function and judge the cyclomatic complexity of all functions. When the calculation of the fixed value is completed (S2216: No), the process ends.

[0055] Analysis point 2: Number of recent bug fixes Figure 11 shows the results of a recent G FIG. 10 is a diagram showing a calculation flow of a judgment value according to the number of corrections. 12 is the number of bars I went to recently. GFIG. 10 is a table showing calculation of a judgment value according to the number of times of correction. (a) is a conversion table of the number of bug fixes to the score, and (b) is a weighting table of the number of bug fixes. (c) is a table showing the results of the judgment value calculation for each function for the number of bug fixes recently performed.

[0056] "Recently" here means the past week or past from a certain point in time (such as the present). When you go back a month, how many times have you made corrections? point .

[0057] Figure 12(a) shows the recent G As shown in the conversion table of the number of revisions to the score, The more bugs that have been fixed, the higher the probability that the bug is included. The higher the score, the higher the score will be given.

[0058] Also, Figure 12(b) shows the recent G As shown in the weighting table of fix counts, The weighting is based on the content of the fix. The impact of the bug fix on other source code is The smaller the value, the smaller the weighting and the greater the impact it is expected to have. The more important the bug fix, the greater the weighting. For example, bugs that do not affect functionality The minimum weight is 1, and bug fixes caused by specification errors are also applied to source code that is not the target of the fix. Since there is a high possibility of an impact, the maximum weight of 5 is assigned.

[0059] figure 11 As shown in the figure, in the process of calculating the judgment value of a function using the number of recent bug fixes as the analysis viewpoint, the analysis viewpoint setting unit 120 first acquires design data, more specifically, specifications, source code, and source code correction tickets (S2221), and associates source code for each function from the acquired design data (S2222).

[0060] The judgment value calculation unit 130 counts the number of bugs recently found in the source code of each function ( S2223).

[0061] The judgment value calculation unit 130 calculates the total number of bugs based on the "bug fix count score conversion table." The scores are calculated and weighted based on the "Bug Fix Count Weighting Table." (S2224).

[0062] The judgment value calculation unit 130 calculates a judgment value for each function by multiplying the calculated score by a weight. , and output (S2225).

[0063] The judgment value calculation unit 130 performs steps S2223 to S2222 for the number of functions. 2 Repeat step 6 and select "Recently The judgment value calculation unit 130 calculates the number of bug fixes for each function. The calculation of the judgment value based on the number of bug fixes recently made for the function has not been completed. If (S2226: Yes), go to step S22 for other functions. 2 Repeat the process from step 3. On the other hand, by repeating the process for each function, we can calculate the number of recent bug fixes for all functions. When the calculation of the judgment value is completed (S2226: No), the process ends.

[0064] Analysis point 3: High density of bugs by process FIG. 13 is a diagram showing the calculation flow of the judgment value according to the density of bugs in each process. 4 is a diagram showing a table for calculating a judgment value according to the density of bugs in each process; (a) is a conversion table of the bug density by process, (b) is a weighted table of the bug density by process. (c) is a table showing the results of calculating the judgment value for each function of the bug density by process. The bug density score conversion table by process and the bug density weighting table by process are The data is stored in advance in the HDD 104 of the store case generation device 100.

[0065] As shown in the bug density score conversion table for each process in Figure 14(a), the bug density (cases / ks The higher the difference between the step and the bug density index, the more likely it is that a bug is contained. Give a high score.

[0066] As shown in Figure 14(b), the bug density weighting table for each stage of the source code Using the information obtained from the repair ticket, the percentage of defects that should be extracted in the previous process is calculated, and the percentage is The higher the value, the greater the weighting.

[0067] As shown in Figure 13, the calculation process of the judgment value of the function is performed based on the analysis point of the density of bugs in each process. In theory, first, the analysis viewpoint setting unit 120 analyzes design data, more specifically, specifications, specification reviews, Obtain meeting minutes, source code, and source code correction tickets (S2231) , take The source code for each function is linked from the obtained design data (S2232).

[0068] The judgment value calculation unit 130 counts the number of bugs by process in the source code of each function for each function ( S2233).

[0069] The judgment value calculation unit 130 divides the number of bugs by the number of steps in the source code of the function. Calculate the bug density (S2234).

[0070] The judgment value calculation unit 130 converts the aggregated bug density into a "process-specific bug density height score conversion table " and weighted based on the "Weighting table for bug density by process" (S2235).

[0071] The judgment value calculation unit 130 calculates a judgment value for each function by multiplying the calculated score by a weight. , and output (S2236).

[0072] The judgment value calculation unit 130 repeats S2233 to S2236 for the number of functions to obtain the "process-specific balance Create a score table for calculating the judgment value for each function of bug density. If the calculation of the judgment value based on the density of the The process from step S2233 is repeated for each function. Once the calculation of the judgment value based on the density of bugs by process for all functions is completed (S 2237: No) End processing.

[0073] Analysis point 4: High bug density in past projects Figure 15 shows the flow of calculating the judgment value according to the bug density of past projects. Figure 16 shows the table for calculating the judgment value according to the bug density of past projects. (a) is a conversion table of the bug density of past projects, and (b) is a conversion table of the bug density of past projects. b) is a weighted table of bug density in past projects, and (c) is a weighted table of bug density in past projects. This is a table showing the results of the bug density judgment value calculation for each function of the past project. The bug density conversion table and the weighting table for past projects are The data is stored in advance in the HDD 104 of the data generation device 100.

[0074] Figure 1 6 As shown in the bug density score conversion table for past projects in (a), The higher the difference between the bug density (items / kstep) and the bug density index, the more likely it is that a bug is included. Therefore, a relatively high score is given.

[0075] Also, Figure 1 6 As shown in the table of bug density weights for past projects in (b), ,We use information obtained from source code fix tickets to ,indicate the past test density for the scale. The difference between the target and the actual value is calculated, and the greater the difference, the greater the weighting.

[0076] Figure 1 5 As shown in Fig. 1, the function judgment value is calculated based on the density of bugs in each process. In theory, first, the analysis viewpoint setting unit 120 analyzes design data, more specifically, specifications, specification reviews, Obtain meeting minutes, source code, and source code correction tickets (S2241) and Link source code for each function from the acquired design data. (S2242).

[0077] The judgment value calculation unit 130 calculates the number of bugs in the source code of the function from past projects. The data is tallied for each period (S2243).

[0078] The judgment value calculation unit 130 divides the total number of bugs by the number of steps in the source code of the function. The bug density is calculated (S2244).

[0079] The judgment value calculation unit 130 calculates the aggregated bug density as a "high score of bug density of past projects" The scores are calculated based on the "conversion table" and the "weighting table of bug density in past projects" Weighting is based on "ru". (S2245).

[0080] The judgment value calculation unit 130 calculates a judgment value for each function by multiplying the calculated score by a weight. , and output (S2246).

[0081] The judgment value calculation unit 130 repeats S2243 to S2246 for the number of functions, Create a table of the results of the bug density calculation for each function of the project. If the calculation of the judgment value based on the bug density of past projects has not been completed (S2 247: Yes), the process from step S2243 is repeated for other functions. Repeat the process for each function to determine the bug density of past projects. When the calculation of the judgment value is completed (S2247: No), the process ends.

[0082] Analysis point 5: High bug density in specifications based on review minutes Figure 17 shows the calculation flow of the judgment value according to the level of bug density in the specification based on the review minutes. FIG. 18 is a diagram showing an example of review minutes. FIG. 19 is a diagram showing an example of review minutes. 1 is a table showing the calculation of a judgment value according to the level of bug density in the specification by a) is a conversion table of bug density scores based on review minutes, (b) is a review minutes (c) is the bug density function by review minutes. 10 is a table showing the results of calculation of the judgment value for each of the plurality of times.

[0083] The review minutes in Figure 18 are tickets. and and registered in the database.

[0084] The bug density score conversion table based on the review minutes in Fig. 19(a) and (b) The bug density weighting table based on the review minutes is stored in advance on the HDD 104. Ku.

[0085] As shown in the bug density score conversion table based on review minutes in Figure 19(a), The higher the difference between the bug density (items / kstep) and the bug density index, the more likely it is that a bug is included. Therefore, a relatively high score is given.

[0086] Also, as shown in the bug density weighting table based on review minutes in Figure 19(b), Next, the information obtained from the review minutes is used to assign weights according to the review findings.

[0087] As shown in Figure 17, the analysis was conducted based on the high bug density of the specifications in the review minutes. In the process of calculating the performance judgment value, the analysis viewpoint setting unit 120 first calculates the design data, more specifically, Obtain specifications, specification review minutes, source code, and source code correction tickets. (S22 5 1) Link source code for each function from the acquired design data (S225 2).

[0088] The judgment value calculation unit 130 refers to the minutes of the review of the specification of the source code of the function and calculates the bugs. Count by function do (S2253).

[0089] The judgment value calculation unit 130 divides the total number of bugs by the number of steps in the source code of the function. The bug density is calculated (S2254).

[0090] judgement The value calculation unit 130 calculates the bug density by converting the bug density into a score based on the review minutes. The scores are calculated based on the "Bug density weighting table based on review minutes" The weighting is performed based on the above (S2255).

[0091] The judgment value calculation unit 130 calculates a judgment value for each function by multiplying the calculated score by a weight. , and output (S2256).

[0092] The judgment value calculation unit 130 repeats S2253 to S2256 for the number of functions, and Create a table of bug density judgment values ​​calculated for each function based on the minutes. The calculation of the judgment value based on the bug density of the specification document based on the review minutes must be completed. If (S225 7 : Yes), repeat the process from step S2253 for other functions. On the other hand, the process is repeated for each function to create specifications for all functions based on review minutes. When the calculation of the judgment value based on the bug density is completed (S225 7 : No) End the process do.

[0093] <(26) Function combination test item parameter method judgment> Figure 20 shows the test parameters from the judgment values ​​for each analysis point of view. of This figure shows the flow to be extracted (corresponding to (26) Function Combination Test Item Parameter Method Judgment). Figure 21 shows tables related to function combination test item parameter method judgment, where (a) is a weighting table based on analysis data for each function, and (b) is a table showing the total judgment value for each function and the test parameter extraction method. Figure 22 shows a table for calculating the judgment value for each function and determining the test parameter extraction method.

[0094] The judgment value calculation unit 130 The judgment values ​​for each analysis point are totaled for each function (S261 ).

[0095] The judgment value calculation unit 130 , "Weighting by analytical data for each function" table The weighting for each function is set based on the analysis data for each function using the weighting (S262).

[0096] The judgment value calculation unit 130 ,“A method for calculating judgment values ​​for each function and extracting test parameters” The judgment value for each function is calculated using the "Determination of Function" table (S263).

[0097] The test parameter extraction unit 140 calculates the total judgment value for each function and the test parameter extraction method. " and "Calculation of judgment value for each function and determination of test parameter extraction method." A parameter extraction method is determined (S264).

[0098] The test parameter extraction unit 140 executes a test parameter extraction tool to extract test parameters. The data is extracted (S3).

[0099] <(4) Test item extraction flow> In the test item extraction flow, "Extract additional test parameters from bug detection after test execution" Figure 23 shows the process from detecting bugs after test execution to changing test parameters. Figure 24 shows the flow of extracting additional data from the bugs detected after the test execution. A table relating to the flow of additionally extracting test parameters, (a) is a table of the retest results Weight conversion table, (b) Bug density weight table of retest results, (c) per function (d) shows the difference judgment value and parameter extraction method conversion table, and (e) shows the weight of the bug after test execution. 10 is a parameter extraction method table for additional items.

[0100] The user selects the target program for bug fixes based on the parameters extracted in step (3). A bug test is performed on the program (S401).

[0101] If the bug test results in no bugs being detected (S402: No), the process ends. If the bug is found (S402: Yes), the user corrects the bug and sends it to the test case generation device 100. Enter the source code correction ticket that describes the bug detection and correction history. Acquire design data The unit 110 stores the input source code modification ticket in the source code modification ticket storage unit 112. Update record to be added to 74.

[0102] The judgment value calculation unit 130 counts up the number of bugs after the test for each function (S403).

[0103] The judgment value calculation unit 130 calculates the post-test bug density for each function (S404).

[0104] The judgment value calculation unit 130 calculates the weight conversion table for the retest result in accordance with “4-1” and “4-2.” The weighting is done for each function based on the "Bug density weighting table of retest results" (S405 ).

[0105] The test parameter extraction unit 140 performs the steps of "4-3 Difference judgment value and parameter extraction method for each function" and "4-3 Difference judgment value and parameter extraction method for each function." Based on the "Formula Conversion Table," "4-4 Bug Weights and Additional Item Parameters After Test Execution" The method for extracting test parameters for the additional items is determined (S406).

[0106] The test parameter extraction unit 140 adds 4- Add the test parameter extraction method to be added in 4, run the test parameter extraction tool, The missing test parameters are additionally extracted (see FIG. 6(c)) (S407).

[0107] According to this embodiment, in generating test cases, tickets, commit logs, source codes, Based on project data such as the code, design documents, and review minutes, the complexity of the source code is calculated. We set up analysis points such as the speed of bug fixes, bug density in each process, and rank the importance of each analysis point. In the test item extraction method, which weights the test items according to the development results of the project for each function, By analyzing the development history of each function and adjusting the weighting according to the development history, Select high-priority functions as priority items and create test cases to determine extraction algorithms. Generation can be performed.

[0108] In addition, the bug information from the test execution results of the test cases extracted under the above conditions is reflected, and the above analysis is performed. By changing the weight of the analysis viewpoint, functions with a high rate of bug release after testing were set as the priority parameters. Test case extraction automatically adds test cases by reconfiguring the extraction algorithm. By repeating this process and filling in the missing extracted test cases, the project The quality of test cases can be improved according to the quality situation.

[0109] The test case generation device 100 according to this embodiment generates test cases for each function based on design data. Since the test is judged based on the comprehensiveness of the test, it is no longer necessary to rely on the experience and sense of the person in charge of bug testing. Since bug testing can be done without relying on artificial abilities or experience, This makes it easier to perform necessary and sufficient bug testing.

[0110] In addition, if a bug is detected during the initial bug test and then fixed, the bug fix history will be reflected. By doing this, additional combination test parameters can be extracted (see Figure 6(c)). By adding combination test parameters along with bug fixes, additional bug test items can be added. Even in this case, it depends on the design data but does not depend on the user's knowledge, so it is objective. This allows for accurate and accurate bug testing.

[0111] The above-described embodiment does not limit the present invention, and modifications that do not deviate from the spirit of the present invention are also included. For example, the analysis viewpoint based on the design data may be part of the above, or may be based on the design data. Any analytical perspective based on data may be added. [Explanation of symbols]

[0112] 100: Test case generator 101: CPU 102: RAM 104: HDD 105: Input I / F 106: Output I / F 107: Bus 108: Input device 109: Output device 110: Design data acquisition unit 120: Analysis viewpoint setting section 130: Judgment value calculation unit 140: Test parameter extraction unit 171: Specification memory section 172: Specification review minutes storage section 173: Source code storage 174: Source code modification ticket storage 181: Table storage section 182: Judgment value storage unit 183: Test parameter memory section

Claims

1. A test case generator that generates test items for bug testing to be performed on a program And, Design data that includes the source code of the program to be tested for bugs. a data acquisition unit; Analysis viewpoints that set analysis viewpoints for each function included in the program based on the design data A setting section; a judgment value calculation unit that calculates a judgment value from each analysis viewpoint for each of the functions; Based on the judgment value, the extraction coverage of the test parameters to be used in the bug test is determined, and A test parameter extractor extracts a combination of the test parameters based on the determined extraction coverage. a data extraction unit; A test case generation device comprising:

2. The test case generation device according to claim 1 The judgment value calculation unit determining a judgment value for each of a plurality of analysis viewpoints for one function; A weight is assigned to each of the plurality of analysis points, and a judgment value from each analysis point is calculated based on the weight of the analysis point. The weightings applied to each of the above analysis points are multiplied, and the weighted judgment values ​​from each of the above analysis points are summed up. and calculating a total judgment value for the one function. The test parameter extraction unit determining the extraction coverage of the test parameters according to the total judgment value; A test case generation device characterized by:

3. The test case generation device according to claim 1 The analysis viewpoint setting unit analyzes the cyclomaticity of the source code associated with the function. complexity of the project, the number of recent bug fixes, the density of bugs in each stage, and bugs in past projects. The density of bugs and the number of bug fixes based on review minutes were analyzed. Used as an analytical perspective, A test case generation device characterized by:

4. A test case generator that generates test items for bug testing to be performed on a program A test case generation method executed by The step of acquiring design data including the source code of the program to be bug tested. Pu and, a step of setting an analysis viewpoint for each function included in the program based on the design data; and, calculating a judgment value from each analysis point of view for each of the functions; Based on the judgment value, the extraction coverage of the test parameters to be used in the bug test is determined, and extracting the combinations of test parameters based on the determined extraction coverage; A test case generation method comprising:

Images