Software test control device and software test control method

Abstract

To provide a software test control device and a software test control method, which can advance the release point of time of developed software.SOLUTION: A software test control device according to the present disclosure includes a test execution unit, a cumulative accumulation unit, a convergent point prediction unit, and a test case selection unit. The test execution unit tests software including multiple elements according to test cases associated with respective elements. The cumulative accumulation unit accumulates, for each element, software defects included in results of the test conducted by the test execution unit. The convergent point prediction unit predicts the convergent point of defects for each element based on cumulative defects that are the defects accumulated in the cumulative accumulation unit. The test case selection unit selects a test case based on the convergent point predicted by the convergent point prediction unit.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present disclosure relates to a software test control device and a software test control method for controlling software testing in software development. [Background technology]

[0002] In software development, it is important to estimate when the software can be released based on the testing status of the software under development. Conventionally, a technology has been disclosed for predicting the release time of software using a reliability model growth curve that shows the relationship between the cumulative testing time for the developed software and the defects found by the testing (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 6-19699 Summary of the Invention [Problem to be solved by the invention]

[0004] In software development, it is necessary to avoid delays in the planned release date and to efficiently accelerate the release date. However, while Patent Document 1 discloses how to predict the release date, it does not disclose how to efficiently accelerate the release date. Furthermore, Patent Document 1 looks at the software as a whole, not just in parts. Therefore, if there are many latent defects in some elements of the software, and testing including those elements has not progressed, the release date prediction may be incorrect.

[0005] The present disclosure has been made to solve such problems, and aims to provide a software test control device and a software test control method that can accelerate the release date of developed software. [Means for solving the problem]

[0006] In order to solve the above problems, the software test control device according to the present disclosure includes a test execution unit, an accumulation and storage unit, a convergence point prediction unit, and a test case selection unit. The test execution unit executes tests on software including multiple elements according to test cases associated with each element. The accumulation and storage unit accumulates software defects included in the test results executed by the test execution unit for each element. The convergence point prediction unit predicts the convergence point of the defects for each element based on the accumulated defects, which are the defects accumulated in the accumulation and storage unit. The test case selection unit selects test cases based on the convergence point predicted by the convergence point prediction unit. [Effects of the Invention]

[0007] According to the present disclosure, it is possible to accelerate the release of developed software. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a block diagram showing an example of the configuration of a software test control device according to a first embodiment. [Figure 2] 3 is an example of a test case list according to the first embodiment. [Figure 3] 3 is an example of a selected test case list according to the first embodiment. [Figure 4] FIG. 2 is a diagram showing an example of an element according to the first embodiment. [Figure 5] 4 is an example of a test result list according to the first embodiment. [Figure 6] 10 is an example of a defect result list according to the first embodiment. [Figure 7] 3 is an example of an accumulation table according to the first embodiment. [Figure 8] 3 is an example of an accumulation table according to the first embodiment. [Figure 9] 4 is a graph showing an example of a reliability model growth curve according to the first embodiment. [Figure 10] 3 is an example of a weighting table according to the first embodiment. [Figure 11] 3 is an example of a selected test case list according to the first embodiment. [Figure 12] 3 is an example of an accumulation table according to the first embodiment. [Figure 13] 4 is a flowchart showing an example of the operation of the software test control device according to the first embodiment. [Figure 14] 10 is a graph showing an example of a reliability model growth curve in the case where no control is performed according to the first embodiment. [Figure 15] 10 is a graph showing an example of a reliability model growth curve in the case where no control is performed according to the first embodiment. [Figure 16] 10 is a graph showing an example of a reliability model growth curve in the case where no control is performed according to the first embodiment. [Figure 17] 10 is a graph showing an example of a reliability model growth curve in the case where no control is performed according to the first embodiment. [Figure 18] 10 is a graph showing an example of a reliability model growth curve in the case where no control is performed according to the first embodiment. [Figure 19] 10 is a graph showing an example of a reliability model growth curve in the case where control is performed according to the first embodiment. [Figure 20] 10 is a graph showing an example of a reliability model growth curve in the case where control is performed according to the first embodiment. [Figure 21] 10 is a graph showing an example of a reliability model growth curve in the case where control is performed according to the first embodiment. [Figure 22] 10 is a graph showing an example of a reliability model growth curve in the case where control is performed according to the first embodiment. [Figure 23]10 is a graph showing an example of a reliability model growth curve in the case where control is performed according to the first embodiment. [Figure 24] 10 is an example of a weighting table according to the second embodiment. [Figure 25] 13 is an example of a test case list according to the third embodiment. [Figure 26] 13 is an example of a selected test case list according to the third embodiment. [Figure 27] 13 is an example of a weighting table according to the third embodiment. [Figure 28] 13 is an example of a selected test case list according to the third embodiment. [Figure 29] FIG. 10 is a diagram showing an example of an element according to the fourth embodiment. [Figure 30] FIG. 13 is a diagram showing an example of an element according to the fifth embodiment. [Figure 31] 13 is a table showing the relationship between product functions and components according to the fifth embodiment. [Figure 32] FIG. 1 is a diagram illustrating an example of a hardware configuration of a software test control device according to first to fifth embodiments. [Figure 33] FIG. 1 is a diagram illustrating an example of a hardware configuration of a software test control device according to first to fifth embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0009] <First Embodiment> FIG. 1 is a block diagram showing an example of the configuration of a software test control device according to the first embodiment.

[0010] As shown in FIG. 1, the software test control device includes a test case selection unit 101, a test implementation unit 102, a test result acquisition unit 103, a test result storage unit 104, a test result distribution unit 105, an accumulation storage unit 106, a reliability model growth curve creation unit 107, and a weighting calculation unit 108.

[0011] 1 may be provided in one device or distributed across multiple devices. Also, the test execution unit 102 may be performed by a person rather than by a terminal.

[0012] The test case selection unit 101 selects test cases to be tested from the test case list shown in Fig. 2, and creates a selected test case list shown in Fig. 3. In the following, "test" refers to a test to be performed on software under development.

[0013] The test case list shown in Figure 2 is a table that is prepared in advance and associates test cases with elements based on specifications and design documents related to software development. In the test case list, "Test Case No.", "Classification," "Content," "Time," and "Time for each element U1 to Un" are organized as one test case. "Content" indicates the test content. "Time" indicates the time for performing the test, which is further divided by element. For each test case c1 to c150, the time for performing the test is shown in the column for the element tested by that test case.

[0014] Fig. 4 is a diagram showing an example of elements. Components U1 to U4 shown in Fig. 4 constitute software. Note that Fig. 4 shows a case where the software is composed of four components, but this is not limited to this. The software may be composed of a plurality of components (n components). Components U1 to Un correspond to elements U1 to Un shown in Figs. 2 and 3.

[0015] In order to check the variation of defects for each element, the test case selection unit 101 selects test cases from a pre-prepared test case list so that each element U1 to Un has an equal test time up to a certain time Gg_t1, and creates a selected test case list. Note that the processing of the test case selection unit 101 after the time Gg_t1 will be described later.

[0016] The selected test case list shown in Figure 3 shows a list of test cases included in the tests performed up to time Gg_t1, with "Test No.", "Test Case No.", "Classification," "Content," "Time," and "Time for each element U1 to Un" organized for each selected test case. "Test No." indicates the serial number of the test that will actually be performed. In the selected test case list, the test cases are organized so that the test time is equal. In the example of Figure 3, the total time for each element U1 to Un is the same (Gg_t1 / n=10000 / 20=500).

[0017] The test execution unit 102 executes the test according to the selected test case list. Then, the test execution unit 102 checks the test result log and the preset expected values ​​of the test cases to determine whether the test is NG. Specifically, the test execution unit 102 determines the test result as NG if the test result log does not match the preset expected values ​​of the test cases.

[0018] The test result acquisition unit 103 acquires the "result of test NG judgment," "end time of executed test case," "defect number," "defect content," and "discovery time."

[0019] The test result accumulation unit 104 accumulates the information acquired by the test result acquisition unit 103 in a test result list shown in FIG. 5 and a defect result list shown in FIG.

[0020] The test result list shown in Figure 5 organizes the test results for one test case into "Test No.", "Test Case No.", "Classification," "Content," "Time," "Time for each element U1 to Un," "End Timing," "NG Verdict," and "Defect No." The "Defect No." indicates the serial number assigned to each defect discovered.

[0021] The test result accumulation unit 104 accumulates the information acquired by the test result acquisition unit 103 in an internal memory for each "test number." The test result accumulation unit 104 has an internal memory and writes and reads information to the memory. In the example of FIG. 5, if a defect occurs in "test number 5," the NG judgment for "test number 5" will be "x," and "bu1" will be displayed in the "defect number." By referring to the "defect number," the connection between the test result list shown in FIG. 5 and the defect result list shown in FIG. 6 can be seen.

[0022] The defect result list shown in Figure 6 organizes "Defect No.", "Defect Content," "Element," "Test Case No.", and "Discovery Time" into a single defect result. "Defect No." indicates the serial number of the defect that was discovered. "Defect Content" indicates information about the defect. "Test Case No." indicates the number of the test case that discovered the defect. "Discovery Time" indicates the time the defect was discovered. By referring to the defect result list, it is possible to identify which element has the defect. Note that by using the "Test Case No." shown for each "Defect No.", the discovery time can also be substituted with the end time of the test result list shown in Figure 5.

[0023] The test result distribution unit 105 distributes the test results accumulated in the test result accumulation unit 104 by element, and outputs the distributed test results to the accumulation accumulation units 1061 to 1064 assigned to the elements U1 to Un. The test result distribution unit 105 also outputs the test results of all elements accumulated in the test result accumulation unit 104 to the accumulation accumulation unit 1065.

[0024] For example, the test result allocation unit 105 allocates only the test results corresponding to the row indicating the end timing of element U1 from the test result list shown in Figure 5, and outputs the allocated test results to the cumulative storage unit 1061 corresponding to element U1.

[0025] Accumulation accumulation units 1061 to 1065 constitute accumulation accumulation unit 106. Each of accumulation accumulation units 1061 to 1064 accumulates the performance values ​​of the test results in the performance column of the accumulation list shown in Figures 7 and 8 so that the test results allocated by test result allocation unit 105 are accumulated. The accumulation accumulation unit 1065 will be described later.

[0026] The cumulative table shown in Figure 7 shows the actual and predicted values ​​for element U1, with "Timing," "Actual cumulative test time G1_t," "Actual cumulative number of defects G1_b," "Predicted cumulative test time G1_t," and "Predicted cumulative number of defects G1_b" organized by timing.

[0027] "Timing" indicates the timing for checking the test status, and is usually set periodically, such as every few hours or every few days. If there are times when testing is not performed, such as on holidays, you can skip those timings and omit rows with no test results. "Timing" can be set in advance, or it can be changed according to the progress of the test, adjusting it so that the test time is roughly even. Furthermore, in terms of recording necessary information about changes with less data, the timing can be shortened when the cumulative number of defects changes drastically, and lengthened when the cumulative number of defects changes slowly.

[0028] In the cumulative accumulation unit 1061, the test time of element U1 in the test result list shown in FIG. 7 up to each timing in the cumulative list is totaled using the time shown in the end timing column of the test results to which only those related to element U1 in the test result list shown in FIG. 5 are assigned, and the totaled time is organized in the cumulative test time G1_t column in the cumulative list.

[0029] In addition, the cumulative accumulation unit 1061 uses the time indicated in the discovery timing column in the row in the defect result list shown in Figure 6 to which only element U1-related items are assigned, to tally up the number of rows (number of defects) in the defect result list up to each timing in the cumulative list shown in Figure 7, and organizes them in the cumulative defect number G1_b column in the cumulative list.

[0030] In this way, the actual results (cumulative test time, cumulative number of defects) are accumulated up to the cumulative test time G1_t1 of the element U1, which corresponds to the range up to a certain time Gg_t1.

[0031] The accumulation table shown in Fig. 8 shows actual values ​​and predicted values ​​for the element U n. In the accumulation storage unit 1064, actual values ​​of the test results are stored in the actual value column in the accumulation table shown in Fig. 8, similar to the accumulation table shown in Fig. 7.

[0032] The reliability model growth curve creation units 1071 to 1075 constitute the reliability model growth curve creation unit 107 (convergence point prediction unit). Each of the reliability model growth curve creation units 1071 to 1074 creates a reliability model growth curve using the performance values ​​accumulated in each of the accumulation units 1061 to 1064, and predicts the accumulated test time and accumulated number of defects of each of the elements U1 to Un. The reliability model growth curve creation unit 1075 will be described later.

[0033] The reliability model growth curve creation unit 1071 uses the actual values ​​(cumulative test time G1_t, cumulative number of defects G1_b) accumulated in the accumulation storage unit 1061 to create an approximate reliability model growth curve, for example, by a method disclosed in Patent Document 1, and predicts the convergence point (predicted convergence time, predicted number of convergence defects) using the created reliability model growth curve.

[0034] Fig. 9 is a graph showing an example of a reliability model growth curve G1(t) for element U1. In Fig. 9, the horizontal axis represents the cumulative test time, and the vertical axis represents the cumulative number of defects. Furthermore, the actual values ​​(cumulative test time, cumulative number of defects) up to time G1_t1 in the actual results column in the accumulation list shown in Fig. 7 accumulated in the accumulation accumulation unit 1061 are indicated by black dots.

[0035] The cumulative test times for the actual results up to time G1_t1 are defined as G1_t(0) to G1_t(j). The cumulative number of defects for each cumulative test time G1_t(0) to G1_t(j) is defined as G1_b(0) to G1_b(j).

[0036] In the example of Figure 9, the actual values ​​(G1_t, G1_b) = {(G1_t(0), G1_b(0)), (G1_t(1), G1_b(1)), ..., (G1_t(j), G1_b(j))} up to the cumulative test time G1_t(j) are shown by black dots.

[0037] 9 is the reliability model growth curve G1(t) approximated using the actual values ​​(G1_t, G1_b). The logistic curve and Gompertz curve below are known as approximation formulas for the reliability model growth curve. Logistic curve: y=a / (1+b×exp(-cx)) Gompertz curve: y=c×exp(-a×exp(-bx)) Let y be the cumulative number of defects and x be the cumulative test time. Using (G1_t(0), G1_b(0)), ···, (G1_t(j), G1_b(j)) as the actual values ​​of (x, y), calculate the approximate formulas a and b.

[0038] The difference between the actual measured value and the approximate formula is calculated using the least squares method, and a and b are derived using a solution search GRG (Generalized Reduced Gradient) nonlinear, simplex LP, or evolutionary algorithm using Excel's Solver.

[0039] In these equations, the cumulative number of defects that converges in an infinite time is a, but since the time to achieve this is infinite, for example, "a-0.1", which is 10% lower than a, is the predicted convergence number of defects G1_yb, and the time at which "a-0.1" is reached is G1_yt, and these are the predicted convergence points. Figure 9 shows the convergence points (G1_yt, G1_yb).

[0040] The cumulative number of defects in the prediction column in the cumulative list shown in FIG. 7 is calculated by substituting the cumulative test time G1_t for t in the reliability model growth curve G1(t) created by the reliability model growth curve creation unit 1071.

[0041] The weight calculation unit 108 calculates weights using the predicted convergence times calculated for each element by the reliability model growth curve creation units 1071 to 1074. The weights are calculated by dividing the "remaining time obtained by subtracting the current cumulative test time from the predicted convergence time for each element" by the "total remaining time for all elements." If the convergence time is shorter than the current cumulative time and the remaining time is negative, the remaining time is set to "0."

[0042] 10 is a diagram showing an example of a weighting list. In the weighting list, "element," "estimated convergence time," "remaining time," "content," and "weighting" are organized for each element.

[0043] The weighting list lists the predicted convergence time for each element calculated by the reliability model growth curve creation units 1071 to 1074, and the remaining time obtained by subtracting the current cumulative test time from the predicted convergence time. The "weighting" is calculated by dividing the "remaining time for each element" by the "total remaining time for all elements." Here, the element with the longer remaining time is assigned a larger weighting value.

[0044] The test case selection unit 101 selects test cases from time Gg_t1 onward in accordance with the weights calculated by the weight calculation unit .

[0045] FIG. 11 shows an example of a selected test case list, which lists test cases selected according to weighting and included in the test performed from time Gg_t1 to time Gg_t2. If the test is performed until time Gg_t2, the total test time is "Gg_t2 - Gg_t1." This total test time is multiplied by the weighting to calculate the test time for each element.

[0046] Select test cases so that the total test time for each element is within the calculated total. The order of test cases is set in advance, and the selection of test cases is completed before the total test time for each element is exceeded.

[0047] In this way, by increasing the test time for an element with a larger remaining time that is delaying convergence to the convergence point, it is possible to further accelerate convergence.

[0048] The accumulation storage unit 1065 accumulates the performance values ​​in the performance column in the accumulation list shown in FIG. 12 using information related to all elements U1 to Un in the test result list shown in FIG. 5 accumulated in the test result storage unit 104 and the overall information of the defect result list shown in FIG. 6.

[0049] The reliability model growth curve creation unit 1075 creates a reliability model growth curve Gg(t) using the actual values ​​in the cumulative table shown in Fig. 12, and calculates the predicted values ​​of the prediction column in the cumulative table shown in Fig. 12. This makes it possible to predict the overall convergence status of the software, as in the conventional case.

[0050] FIG. 13 is a flowchart showing an example of the operation of the software test control device.

[0051] In step S101, the test case selection unit 101 selects test cases so that the test time is uniform for each element between time 0 and Gg_t1.

[0052] In step S102, the timing for accumulating the test results for each element is set. The timing corresponds to each timing in the timing column in the accumulation list shown in Fig. 12. Here, Ts = start time, Te = Gg_t1, timing setting "TS(0)...TS(m)", and i = 0.

[0053] In step S103, the test execution unit 102 executes the test according to the selected test case list. The test results executed by the test execution unit 102 are acquired by the test result acquisition unit 103 and stored in the test result storage unit 104.

[0054] In step S104, it is determined whether the time t measured after the start of the test has reached the set timing TS(i). If the time t has reached the timing TS(i), the process proceeds to step S105. On the other hand, if the time t has not reached the timing TS(i), the process returns to step S103.

[0055] In step S105, each of the accumulation units 1061 to 1064 accumulates performance values ​​in the cumulative test time column and the cumulative number of defects column of the performance data for the corresponding element in the accumulation table. Furthermore, the accumulation unit 1065 accumulates performance values ​​in the cumulative test time column and the cumulative number of defects column of the performance data for all elements in the accumulation table.

[0056] In step S106, each of the reliability model growth curve creating units 1071 to 1074 creates a reliability model growth curve for the corresponding element. Also, the reliability model growth curve creating unit 1075 creates a reliability model growth curve for all elements.

[0057] In step S107, it is determined whether all elements have converged. If all elements have converged, the operation in Fig. 13 ends. On the other hand, if all elements have not converged, the process proceeds to step S108.

[0058] In step S108, it is determined whether the time t measured after the start of the test has reached the set timing Te. If the time t has reached the timing Te, the process proceeds to step S109. On the other hand, if the time t has not reached the timing Te, the process returns to step S103.

[0059] In step S109, the weight calculation unit 108 calculates the weight from the convergence point of the reliability model growth curve.

[0060] In step S110, the next timing is set. Here, Ts=Gg_t1 and Te=Gg_t2. The test case selection unit 101 selects test cases by changing the test time according to the weighting of each element. Then, the process returns to step S103.

[0061] FIG. 13 shows an operation that is repeated until convergence occurs, but the end of the operation may be determined when Te exceeds a certain time.

[0062] 14 to 18 are graphs showing examples of reliability model growth curves in the case of no control. In FIGS. 14 to 18, the horizontal axis indicates the cumulative test time, and the vertical axis indicates the cumulative number of defects. Here, "in the case of no control" refers to the case where the test case selection unit 101 selects test cases without considering weighting (i.e., the test cases are selected so that the test time for each element is equalized). FIGS. 14 to 18 show the case of no control between time 0 and Gg_t1 and between time Gg_t1 and Gg_t2.

[0063] Fig. 14 shows the reliability model growth curve G1(t) created by the reliability model growth curve creation unit 1071 for the element U1. Fig. 15 shows the reliability model growth curve G2(t) created by the reliability model growth curve creation unit 1072 for the element U2. Fig. 16 shows the reliability model growth curve G3(t) created by the reliability model growth curve creation unit 1073 for the element U3. Fig. 17 shows the reliability model growth curve Gn(t) created by the reliability model growth curve creation unit 1074 for the element Un. Fig. 18 shows the reliability model growth curve Gg(t) created by the reliability model growth curve creation unit 1075 for all the elements U1 to Un.

[0064] In Figures 14 to 18, the test time for each element is the same. Therefore, if there are n elements, the test time is Gg_t1 / n = G1_t1 = G2_t1 = Gn_t1. In this way, tests are performed for each element using the same test time between times 0 and Gg_t1, and in Figures 14 to 18, the reliability model growth curve created using the actual test values ​​up to time Gg_t1 is shown by the solid line.

[0065] In the reliability model growth curve G1(t) shown in FIG. 14, the predicted convergence time G1_yt is shorter than the time G1_t2.

[0066] In the reliability model growth curve G2(t) shown in FIG. 15, the predicted convergence time G2_yt is the same as the time G2_t1, and convergence occurs at the time G2_t1.

[0067] In the reliability model growth curve G3(t) shown in FIG. 16, the predicted convergence time G3_yt is longer than the time G3_t2.

[0068] In the reliability model growth curve Gn(t) shown in FIG. 17, the predicted convergence time Gn_yt is shorter than the time Gn_t1, and convergence occurs at the time Gn_t1.

[0069] In the reliability model growth curve Gg(t) shown in FIG. 18, the predicted convergence time Gg_yt is longer than the time Gg_t2.

[0070] After conducting the tests from time 0 to Gg_t1, the tests from time Gg_t1 to Gg_t2 are similarly conducted by selecting test cases so that the test time for each element is equal. The test time in this case is (Gg_t2-Gg_t1) / n=(G1_t2-G1_t1)=(G2_t2-G2_t1)···=(Gn_t2-Gn_t1). The test results (dashed lines in Figures 14 to 18) appear to be generally in line with the predictions of the reliability model growth curve.

[0071] 19 to 23 are graphs showing examples of reliability model growth curves in the case of control. In FIGS. 19 to 23, the horizontal axis indicates the cumulative test time, and the vertical axis indicates the cumulative number of defects. Here, "in the case of control" refers to a case where the test case selection unit 101 selects test cases taking weighting into consideration. In FIGS. 19 to 23, tests similar to those in the "case without control" described above are performed between times 0 and Gg_t1, and tests in the "case with control" are performed between times Gg_t1 and Gg_t2.

[0072] Fig. 19 shows the reliability model growth curve G1(t) created by the reliability model growth curve creation unit 1071 for the element U1. Fig. 20 shows the reliability model growth curve G2(t) created by the reliability model growth curve creation unit 1072 for the element U2. Fig. 21 shows the reliability model growth curve G3(t) created by the reliability model growth curve creation unit 1073 for the element U3. Fig. 22 shows the reliability model growth curve Gn(t) created by the reliability model growth curve creation unit 1074 for the element Un. Fig. 23 shows the reliability model growth curve Gg(t) created by the reliability model growth curve creation unit 1075 for all the elements U1 to Un.

[0073] The weighting calculation unit 108 calculates weightings G1_h to Gn_h for each of the elements U1 to Un using the predicted convergence times G1_yt to Gn_yt obtained from the reliability model growth curves G1(t) to Gn(t) for each of the elements U1 to Un between time 0 and Gg_t1.

[0074] The test case selection unit 101 changes the test time for each element according to the weights G1_h to Gn_h calculated by the weight calculation unit 108. Specifically, the test case selection unit 101 allocates the total test time (Gg_t2-Gg_t1) to each element as follows according to the weights G1_h to Gn_h: (G1_t2-G1_t1)=(Gg_t2-Gg_t1)×G1_h (G2_t2-G2_t1)=(Gg_t2-Gg_t1)×G2_h (G3_t2-G3_t1)=(Gg_t2-Gg_t1)×G3_h (Gn_t2-Gn_t1)=(Gg_t2-Gg_t1)×Gn_h

[0075] The test case selection unit 101 selects test cases so that the test time for each element is calculated as described above. Then, the test execution unit 102 executes the test according to the test cases selected by the test case selection unit 101 as follows. For the element U1, the test execution unit 102 executes the test from the predicted convergence time G1_yt until time G1_t2 (see FIG. 19). For element U2, the test implementation unit 102 ends the test at time G2_t1=G2_t2 because convergence has occurred (see FIG. 20). For the element U3, the test execution unit 102 executes the test for a longer time (G3_t1 to G3_t2) than in the case of no control (time 0 to G3_t1), but does not execute the test until the predicted convergence time G3_yt (see FIG. 21). For the element Un, the test implementation unit 102 ends the test at time Gn_t1=Gn_t2 because convergence has occurred (see FIG. 22).

[0076] As described above, the overall convergence time can be shortened by shortening the test time for elements that converge quickly and lengthening the test time for elements that converge slowly. FIG. 23 shows the reliability model growth curve for all elements in the case with control (solid line in the figure) and the reliability model growth curve for all elements in the case without control (dashed line in the figure, corresponding to FIG. 18). As shown in FIG. 23, the overall reliability model growth curve converges faster in the case with control than in the case without control, and the predicted convergence time Gg_yt is shorter. In this way, according to the first embodiment, it is possible to accelerate the release of developed software.

[0077] <Embodiment 2> In the first embodiment, the weight calculation unit 108 calculates the weight using the predicted convergence time obtained from the reliability model growth curve. In the second embodiment, the weight calculation unit 108 calculates the weight using the predicted number of convergence failures obtained from the reliability model growth curve. Since the other configurations and operations are the same as those in the first embodiment, detailed description thereof will be omitted here.

[0078] 24 is a diagram showing an example of a weighting list according to embodiment 2. In the weighting list, "elements," "number of predicted convergence defects," "number of detected defects," "number of remaining defects," "contents," and "weighting" are organized for each element.

[0079] The weight calculation unit 108 calculates the "number of remaining defects" for each element by subtracting the "current number of detected defects (actual value of the cumulative number of defects)" from the "predicted number of converged defects." Then, the weight calculation unit 108 calculates "weights G1_h to Gn_h" by dividing the "number of remaining defects for each element" by the "total number of remaining defects for each element."

[0080] As in the first embodiment, the test case selection unit 101 selects test cases according to the weights calculated by the weight calculation unit 108 (time 0 to Gg_t1, in the case of "with control"). The test execution unit 102 executes tests according to the test cases selected by the test case selection unit 101.

[0081] As described above, by increasing the test time for elements with a large number of remaining defects, convergence can be accelerated. In other words, according to the second embodiment, it is possible to accelerate the release of developed software.

[0082] In the early stages of testing, the convergence point of the reliability model growth curve may become infinity, making it impossible to create a model. In this case, a previously predicted number of defects may be used as a substitute for the predicted convergence number of defects. A commonly known method for predicting the number of defects is to use the defect density per scale or defect density per function accumulated in past software developments by an organization, taking into account the scale of the current software development.

[0083] <Third Embodiment> In the first embodiment, a case where one test case is associated with one element has been described. In the third embodiment, one test case is associated with multiple elements. The other configurations and operations are the same as those in the first embodiment, so detailed descriptions are omitted here.

[0084] FIG. 25 is a diagram showing an example of a test case list according to the third embodiment.

[0085] In the test case list shown in Figure 25, the test time is allocated to multiple elements associated with each test case. Methods for allocating test time to each element include proportional allocation, allocation using the size of each element (development scale (KL) or number of functions), and allocation using the probability of defect occurrence (complexity of element or skill of worker).

[0086] FIG. 26 is a diagram showing an example of a selected test case list.

[0087] The test case selection unit 101 selects test cases so that the test time for each element is equal between time 0 and Gg_t1. The test case selection method is to select test cases from the prepared tests in the order U1, U2, U3, ... starting from the row with the longest time for each of the elements U1 and Un, thereby obtaining test cases with roughly equal test times.

[0088] The test implementation unit 102 implements tests according to the test cases in the selected test case list shown in Fig. 26. Then, the weight calculation unit 108 calculates weights for each element using the reliability model growth curve created by the reliability model growth curve creation unit 107. Fig. 27 is a diagram showing an example of the weight list. Thereafter, the test case selection unit 101 selects test cases according to the weights. Fig. 28 is a diagram showing an example of the selected test case list.

[0089] As a result, even when a plurality of elements are associated with one test case, the same effects as those of the first embodiment can be obtained.

[0090] <Fourth Embodiment> FIG. 29 is a diagram illustrating an example of an element according to the fourth embodiment.

[0091] As shown in Fig. 29, the software is composed of components U1, U3, and U5, and connection sections U2 and U4. Connection section U2 connects components U1 and U3. Connection section U4 connects components U3 and U5. Components U1, U3, and U5, connection section U2, and connection section U4 in Fig. 29 correspond to elements U1 to U4.

[0092] 29 shows a case where the software is composed of three components and two connection units, but the present invention is not limited to this. The software may be composed of multiple components and multiple connection units.

[0093] As mentioned above, by separating the parts that are prone to problems from the component, problems can be resolved more quickly.

[0094] <Fifth Embodiment> FIG. 30 is a diagram illustrating an example of an element according to the fifth embodiment.

[0095] As shown in Fig. 30, the software is made up of product functions U1 to U4, which correspond to elements U1 to U4.

[0096] 30 shows a case where the software is composed of four product functions, but the present invention is not limited to this. The software may be composed of multiple product functions.

[0097] FIG. 31 is a table showing the relationship between product functions and components.

[0098] As shown in Figure 31, multiple components are assigned to one product function. By accelerating the convergence of the product function, the convergence of the components can be accelerated.

[0099] For example, as shown in Figure 25, when multiple elements are associated with one test case, creating a table showing these relationships and organizing the test results becomes complicated. On the other hand, the table shown in Figure 31 makes it easy to understand the relationship between test cases and elements, making it easy to select test cases. Ultimately, the component with the problem must be identified, but by creating the table shown in Figure 31, and then using it after narrowing down the product functions with the problem to a certain extent, it becomes easier to find the component with the problem, and the problem can be resolved more quickly.

[0100] <Sixth Embodiment> In the first embodiment, the case where the test case selection unit 101 changes the test time for each element according to the weighting has been described. In the sixth embodiment, the test case selection unit 101 changes the number of test cases including each element according to the weighting. Since the other configurations and operations are the same as those in the first embodiment, detailed description thereof will be omitted here.

[0101] The sixth embodiment is effective when it is difficult to measure the test time for each element, and provides the same effects as the first embodiment.

[0102] <Hardware configuration> The functions of the test case selection unit 101, test implementation unit 102, test result acquisition unit 103, test result storage unit 104, test result allocation unit 105, cumulative storage unit 106, reliability model growth curve creation unit 107, and weight calculation unit 108 in the software test control device described in the first embodiment are realized by processing circuits. That is, the software test control device includes a processing circuit for selecting test cases, conducting tests, acquiring test results, accumulating the test results, allocating the test results to each element, accumulating the test results for each element, creating a reliability model growth curve from the test results of each element, and calculating weights from the convergence point of the reliability model growth curve. The processing circuit may be dedicated hardware or a processor (also referred to as a CPU, central processing unit, processing unit, arithmetic unit, microprocessor, microcomputer, or DSP (Digital Signal Processor)) that executes a program stored in a memory.

[0103] 32 , when the processing circuit is dedicated hardware, the processing circuit 201 may be, for example, a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination thereof. The functions of the test case selection unit 101, the test execution unit 102, the test result acquisition unit 103, the test result storage unit 104, the test result distribution unit 105, the accumulation storage unit 106, the reliability model growth curve creation unit 107, and the weight calculation unit 108 may be realized individually by the processing circuit 201, or these functions may be realized collectively by a single processing circuit 201.

[0104] When the processing circuit 201 is the processor 202 shown in FIG. 33 , the functions of the test case selection unit 101, the test implementation unit 102, the test result acquisition unit 103, the test result storage unit 104, the test result allocation unit 105, the cumulative storage unit 106, the reliability model growth curve creation unit 107, and the weight calculation unit 108 are realized by software, firmware, or a combination of software and firmware. The software or firmware is written as a program and stored in the memory 203. The processor 202 realizes each function by reading and executing the program recorded in the memory 203. That is, the software test control device includes the memory 203 for storing a program that ultimately executes the steps of selecting a test case, implementing a test, acquiring test results, accumulating the test results, allocating the test results to each element, accumulating the test results for each element, creating a reliability model growth curve from the test results of each element, and calculating weights from the convergence point of the reliability model growth curve. These programs can also be said to cause a computer to execute the procedures or methods of the test case selection unit 101, test implementation unit 102, test result acquisition unit 103, test result storage unit 104, test result distribution unit 105, cumulative storage unit 106, reliability model growth curve creation unit 107, and weight calculation unit 108. Here, the memory may be, for example, a non-volatile or volatile semiconductor memory such as a random access memory (RAM), a read-only memory (ROM), a flash memory, an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM), a magnetic disk, a flexible disk, an optical disk, a compact disk, a digital versatile disk (DVD), or any storage medium that will be used in the future.

[0105] It is also possible to realize some of the functions of the test case selection unit 101, the test implementation unit 102, the test result acquisition unit 103, the test result storage unit 104, the test result distribution unit 105, the cumulative storage unit 106, the reliability model growth curve creation unit 107, and the weight calculation unit 108 by using dedicated hardware and other functions by using software or firmware.

[0106] Thus, the processing circuitry can implement each of the above-described functions through hardware, software, firmware, or a combination thereof.

[0107] Within the scope of the present disclosure, the embodiments can be freely combined, modified, or omitted as appropriate.

[0108] <Additional Notes> Various aspects of the present disclosure are summarized below as appendices.

[0109] (Appendix 1) a test execution unit that executes testing of software including a plurality of elements in accordance with test cases associated with each of the elements; an accumulation unit that accumulates and stores defects of the software included in the test results executed by the test execution unit for each of the elements; a convergence point prediction unit that predicts a convergence point of the defect for each of the elements based on the accumulated defect that is the defect accumulated in the accumulation accumulation unit; a test case selection unit that selects the test case based on the convergence point predicted by the convergence point prediction unit; A software test control device comprising: (Appendix 2) 2. The software test control device according to claim 1, wherein the convergence point prediction unit predicts, as the convergence point, a predicted convergence time indicating a time at which the fault will converge. (Appendix 3) The software test control device according to claim 1, wherein the convergence point prediction unit predicts a predicted convergence failure number indicating the number of points at which the failure will converge. (Appendix 4) 2. The software test control device according to claim 1, wherein the test case selection unit selects the test case according to a test time for each element. (Appendix 5) 2. The software test control device according to claim 1, wherein the test case selection unit selects the test case according to the number of test cases. (Appendix 6) the test cases are associated with the plurality of elements; 6. The software test control device according to claim 1, wherein the convergence point prediction unit predicts the convergence point for each of the elements associated with the test case. (Appendix 7) 7. The software test control device according to any one of claims 1 to 6, wherein the elements include a plurality of components that constitute the software and an interface unit that connects the components. (Appendix 8) A software test control device as described in any one of appendices 1 to 6, wherein the elements include functions of a product on which the software is to be executed. (Appendix 9) testing software comprising a plurality of elements according to test cases associated with each of said elements; Accumulating and storing defects in the software included in the test results for each of the elements; predicting a convergence point of the defects for each of the elements based on accumulated defects, which are the accumulated defects; The software test control method selects the test cases based on the predicted convergence point. [Explanation of symbols]

[0110] 101 test case selection unit, 102 test implementation unit, 103 test result acquisition unit, 104 test result storage unit, 105 test result distribution unit, 106 accumulation storage unit, 107 reliability model growth curve creation unit, 108 weighting calculation unit, 201 processing circuit, 202 processor, 203 memory, 1061, 1062, 1063, 1064, 1065 accumulation storage unit, 1071, 1072, 1073, 1074, 1075 reliability model growth curve creation unit.

Claims

1. a test execution unit that executes testing of software including a plurality of elements in accordance with test cases associated with each of the elements; an accumulation unit that accumulates and stores defects of the software included in the test results executed by the test execution unit for each of the elements; a convergence point prediction unit that predicts a convergence point of the defect for each of the elements based on the accumulated defect that is the defect accumulated in the accumulation accumulation unit; a test case selection unit that selects the test case based on the convergence point predicted by the convergence point prediction unit; A software test control device comprising:

2. The software test control device according to claim 1 , wherein the convergence point predicting unit predicts, as the convergence point, a predicted convergence time indicating a time at which the fault will converge.

3. The software test control device according to claim 1 , wherein the convergence point predicting unit predicts a number of converged failures indicating the number of times at which the failures will converge.

4. The software test control device according to claim 1 , wherein the test case selection unit selects the test case according to a test time for each of the elements.

5. The software test control device according to claim 1 , wherein the test case selection unit selects the test case depending on the number of the test cases.

6. the test cases are associated with the plurality of elements; The software test control device according to claim 1 , wherein the convergence point prediction unit predicts the convergence point for each of the elements associated with the test case.

7. 6. The software test control device according to claim 1, wherein the elements include a plurality of components that constitute the software, and an interface unit that connects the components.

8. testing software comprising a plurality of elements according to test cases associated with each of said elements; Accumulating and storing defects in the software included in the test results for each of the elements; predicting a convergence point of the defects for each of the elements based on accumulated defects, which are the accumulated defects; The software test control method selects the test cases based on the predicted convergence point.

Images