JP2011257947A - Method, apparatus and program for preparing test plan - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prepare an effective test plan under internal and external restrictions on a project.SOLUTION: The test plan preparation apparatus includes: a test case priority calculation part 102 that multiplies a quality risk value by a complexity value related to a test case to calculate implementation priority between each test cases by giving priority to a larger multiplication value; a test man-hour calculation part 103 that calculates required man hours by applying a scale and a complexity of the test case to a man-hour prediction model expression; a test plan calculation part 104 that prepares a test plan by allocating manpower resources required for the test case, and calculates an execution order of the test case which meets a predetermined deadline in accordance with handling processes determined in advance based on a pattern of a constraint when a test completion time indicated by a test milestone that defines a test case partial group to be implemented by the deadline in accordance with the constraint exceeds the deadline, to update test plan data; and a test plan display part 105 for displaying data on the test plan.

Description

  The present invention relates to a test plan creation method, a test plan creation device, and a test plan creation program. Specifically, the present invention relates to a test planning technique for improving the quality and reliability of a software system, The present invention relates to a technique that enables an efficient test plan to be created under constraints.

  With the recent advancement of software systems, the number of software test cases to be implemented has become enormous. A test planning method that focuses on the execution order of test cases, such as preferentially planning test cases with a high possibility of occurrence of defects, can be said to be an effective means corresponding to the present situation.

  As a software system test planning technique, for example, a module quality information setting step for setting quality information for each program module of the software system, and a module defect detection man-hour prediction step for predicting a defect detection man-hour of the program module from the quality information A module / specification item correspondence setting process for setting a module / specification item correspondence relationship information indicating a correspondence relationship between the module and a specification item extracted from the specification of the software system, the defect detection man-hour and the module Specification item defect detection man-hour prediction process for predicting specification item defect detection man-hours from specification item correspondence information, and a test for allocating test resources that can be used for testing the software system based on the specification item defect detection man-hours plan Test planning support method characterized by comprising a test plan generation step of generating (see Patent Document 1) it has been proposed.

  In addition, a test technique (see Non-Patent Document 1) that reduces the quality risk at an early stage of a given test period has been proposed, in which an annoyance to a customer when a defect occurs in a product is regarded as a quality risk. In this test technology, the nuisance level is defined as the product of “the degree of influence on customers when a defect occurs” and “the probability of occurrence of a defect”, and the quality risk is defined as “test case is executed. It is defined as “the risk that a failure will occur if there is none”. In addition, it is possible to reach the quality target in a short period of time by setting an acceptable quality risk position as a quality target and preferentially planning test cases with high quality risk.

Japanese Patent Laid-Open No. 2003-256206

“Risk Based Testing Practice Methods and Considerations from Application Examples—Ensuring Required Quality in a Short Time” (Ishida et al., Software Testing Symposium 2008 Tokyo Proceedings)

  On the other hand, test cases have become more complicated as software systems become more sophisticated. For this reason, a special device (for example, a device at a mounting destination, etc., which has a limited period of time available for testing) may be used for the test. In addition, due to the timing of product shipment, etc., there are many cases where a preliminary test is partially performed at the customer site.

  In such a case, it is necessary to devise a test plan that takes into account constraints outside the project, such as the period during which a special device can be used and various deadlines stipulated by the customer's test plan. In addition, it is necessary to complete the test case to be executed by a predetermined time period and ensure the quality in accordance with the period during which the special device can be used and the test plan of the customer.

  However, as a real problem, it is often difficult to execute a test case as planned due to man-hour restrictions for executing the test case. For this reason, it is also necessary to deal with constraints reduction, such as negotiations with customers to postpone the test deadline. In this way, it is necessary to determine the constraints inside and outside the project, to minimize the impact on the outside of the project under various constraints, and to develop an efficient test plan.

  On the other hand, no prior art has been proposed that shows such a solution based on this viewpoint. Therefore, an object of the present invention is to provide a technique that enables an efficient test plan to be created under constraints inside and outside the project.

  The test plan creation method of the present invention that solves the above-mentioned problems is characterized in that a computer device that creates a test plan for a software system executes the following processing.

  That is, for each test case for which data is stored in advance in the storage means, the computer apparatus has a complexity indicating the value of the quality risk that is the probability of occurrence of a defect related to the test case and the complexity of the configuration of the subsystem program included in the test case A process of multiplying the value of the degree and calculating the execution priority between the test cases with the higher multiplication value as the higher priority is stored in the storage unit.

  In addition, the computer device performs processing for calculating each man-hour required for executing each test case and storing it in a storage unit by applying each test case size and complexity data to a predetermined man-hour prediction model formula. Execute.

  In addition, the computer device reads the man-hours of each test case from the storage means, assigns the manpower resources necessary for the man-hours in order from the test case having the highest execution priority, generates a test plan, and stores it in the storage means Execute the process.

  In addition, the computer device reads test milestone data defining a subset of test cases to be executed by a predetermined time according to the constraints inside and outside the project in the test plan, from the storage means storing the data, When the test execution completion time of the test case set specified by the test milestone exceeds the predetermined time limit, the execution order of the test cases that achieve the predetermined time limit is determined according to the contents of the corresponding processing according to the pattern of the constraint condition. A process of calculating and updating test plan data is executed.

  Further, the computer device executes a process of reading the test plan data from the storage means and displaying it on the output device.

  The test plan creation device of the present invention is a computer device that creates a test plan for a software system, and includes the following functional units.

  That is, for each test case that holds data in advance in the storage means, the test plan creation device calculates the quality risk value that is the probability of occurrence of a defect related to the test case and the complexity of the configuration of the subsystem program included in the test case. A test case priority calculation unit that multiplies the value of the complexity shown and calculates an execution priority between the test cases by assuming that the multiplication value is high and that the priority is high, and stores it in the storage unit. Yes.

  Further, the test plan creation device applies each data of the scale and complexity of the test case to a predetermined man-hour prediction model formula, calculates the man-hour required for executing each test case, and stores it in the storage means. And a test man-hour calculation unit.

  Further, the test plan creation device reads the man-hours of each test case from the storage means, generates the test plan by assigning the manpower resources necessary for the man-hours in order from the test case having the highest execution priority, and the storage means The test milestone data defining a subset of the test cases to be executed by the predetermined time according to the constraints inside and outside the project in the test plan is read from the storage means storing the test milestone, When the test execution completion time of the test case set specified by the above exceeds the predetermined time limit, the execution order of the test cases that achieve the predetermined time limit is calculated according to the corresponding processing contents determined in advance according to the pattern of the constraint condition A test plan calculation unit for updating test plan data is provided.

  In addition, the test plan creation device includes a test plan display unit that reads test plan data from the storage unit and displays the data on the output device.

  In addition, the test plan creation program of the present invention causes a computer device that creates a test plan for a software system to execute the following processing.

  That is, the test plan creation program stores a quality risk value that is a defect occurrence probability related to a test case, and a subsystem program included in the test case for each test case for which data is stored in advance in a storage unit in a computer device. A process of multiplying a complexity value indicating the complexity of the configuration, calculating an execution priority between the test cases with a higher multiplication value as a higher priority, and storing it in the storage means; Applying each data of scale and complexity to a predetermined man-hour prediction model formula, calculating the man-hours necessary for executing each test case and storing them in the storage means, and storing the man-hours of each test case The test plan is generated by assigning the manpower resources necessary for the man-hours in order from the test case with the highest execution priority. The data stored in the storage means and the test milestone data defining the subset of test cases to be executed by the predetermined time according to the constraints inside and outside the project in the test plan, from the storage means storing the data When the test execution completion time of the test case set specified by the test milestone exceeds the predetermined time limit, the execution of the test case that achieves the predetermined time limit according to the processing contents predetermined according to the pattern of the constraint condition A process of calculating the order and updating the test plan data, and a process of reading the test plan data from the storage means and displaying them on the output device are executed.

  According to the present invention, an efficient test plan can be created under constraints inside and outside the project.

It is a figure which shows the structural example of the test plan preparation apparatus in this embodiment. It is a figure which shows the example of data of the subsystem design quality in this embodiment. It is a figure which shows the example of data of the subsystem quality performance in this embodiment. It is a figure which shows the example of test case data in this embodiment. It is a figure which shows the structural example of the subsystem program in this embodiment. It is a figure which shows the example of the subsystem call relationship in this embodiment. It is a figure which shows the example of the quality condition of the subsystem program in this embodiment. It is a figure which shows the quality risk calculation example of the subsystem program in this embodiment. It is a figure which shows the process flow example 1 of the test plan preparation method of this embodiment. It is a figure which shows the example of data of the test execution man-hour record in this embodiment. It is a figure which shows the example of a subsystem call relationship in this embodiment. It is a figure which shows the process flow example 2 of the test plan preparation method of this embodiment. It is a figure which shows the process flow example 3 of the test plan preparation method of this embodiment. It is a figure which shows the example of test milestone data in this embodiment. It is a figure which shows the example of a test case structure in this embodiment. It is a figure which shows the example of a relationship between the attribute value pattern of the test milestone in this embodiment, and corresponding content. It is a figure which shows the conceptual example of the test milestone postponement in this embodiment. It is a figure which shows the conceptual example of the test case deletion in this embodiment. It is a figure which shows the example of a concept of the man-hour addition in this embodiment. It is a figure which shows the process flow example 4 of the test plan preparation method of this embodiment. It is a figure which shows the process flow example 5 of the test plan preparation method of this embodiment. It is a figure which shows the process flow example 6 of the test plan preparation method of this embodiment. It is a figure which shows the processing flow example 7 of the test plan preparation method of this embodiment. It is a figure which shows the process flow example 8 of the test plan preparation method of this embodiment. It is a figure which shows the process flow example 9 of the test plan preparation method of this embodiment. It is a figure which shows the example 1 of a display in this embodiment. It is a figure which shows the example 2 of a display in this embodiment. It is a figure which shows the example 3 of a display in this embodiment. It is a figure which shows the example 4 of a display in this embodiment. It is a figure which shows the structural example of the test plan preparation apparatus in other embodiment. It is a figure which shows the example of a processing flow of the test plan preparation method in other embodiment.

--- Example of device configuration ---
Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a diagram illustrating a configuration example of a test plan creation apparatus according to the present embodiment. A test plan creation apparatus 101 (hereinafter, processing apparatus 101) shown in FIG. 1 is a computer system that enables an efficient test plan to be created under constraints inside and outside a project. As this processing apparatus 101, a computer such as a server can be assumed. Therefore, as a matter of course, the processing device 101 includes a non-volatile storage means (such as a hard disk drive) that holds various programs and data, a volatile memory (such as a RAM) that serves as a temporary read destination of execution data and programs, A CPU that reads and executes programs from a storage device, and an interface that handles data input / output processing with an input device such as a keyboard and a mouse and an output device such as a display are provided. Each of the functional units 102 to 106 to be described later can be said to be functional units realized by the CPU of the processing device 101 executing a corresponding program stored in the storage unit. The storage means stores subsystem design quality 107, subsystem program 108, test case 109, test milestone 110, program plan 111, subsystem quality record 112, and test execution process record 113. (As long as the processing device 101 is accessible, the location of the storage means such as other devices in the network is not limited).

  Subsequently, functional units included in the processing apparatus 101 will be described. The processing device 101 includes, for each test case that holds data in advance in storage means provided in the processing device itself or storage means that can be accessed via a network, a quality risk value that is a failure occurrence probability related to the test case, and a test Means for multiplying the complexity value indicating the complexity of the configuration of the subsystem program included in the case, and calculating the execution priority between the test cases by setting the higher multiplication value as the higher priority. Is provided with a test case priority calculation unit 102.

  More specifically, the test case priority calculation unit 102 includes a subsystem design quality 107 describing quality information at the design stage in the sub test program 108 constituting the test case 109 to be tested, and a test in the past. Each data of the subsystem quality record 112 storing the quality record in the subsystem program 108 is read from the storage means storing the data, and the subsystem attribute and the quality of the subsystem program 108 indicated by the subsystem quality record 107 are read. A regression analysis is performed on the correlation with the actual result to generate a quality prediction model formula 307, and the subsystem attribute value indicated by the subsystem design quality 107 is applied to the quality prediction model formula 307, so that the corresponding subsystem program 108 Predict the quality value of the A quality risk is calculated by applying the quality value of the subsystem program 108 to a predetermined calculation formula according to the configuration of the subsystem program in FIG. 7, and the quality risk value and the subsystem program 108 included in the test case 109 are calculated. Is multiplied by a complexity value indicating the complexity of the configuration, and an execution priority between the respective test cases is calculated and stored in the storage means, assuming that a higher multiplication value has a higher priority.

  Here, data used by the test case priority calculation unit 102 described above will be described. FIG. 2 is a diagram showing an example of data of the subsystem design quality 107 in the present embodiment. The subsystem design quality 107 is a table in which quality information related to a design document for creating a subsystem program to be developed is recorded. In this table, the subsystem design document 201 is a column for recording the name of the subsystem design document. The defect density 202 is a column for recording a value obtained by normalizing the number of defects detected by reviewing the corresponding subsystem design document for each scale unit of the corresponding subsystem design document. The review man-hour density 203 is a column for recording a value obtained by normalizing the man-hours subjected to the review to values per scale unit of the corresponding subsystem design document. The subsystem program 204 is a column for recording the name of the subsystem program created from the corresponding subsystem design document. In addition, the correspondence between the subsystem design document and the subsystem program is defined by the values in each column of the subsystem design document 201 and the subsystem program 204, and the traceability between the two is ensured. be able to. The scale 205 is a column for recording the scale of the subsystem program.

  FIG. 3 is a diagram showing a data example of the subsystem quality record 112 in the present embodiment. The subsystem quality record 112 is a table in which information indicating whether or not a failure has occurred as a result of testing the subsystem program with respect to the subsystem design quality 107 is recorded. The table structure has a structure in which a column for recording the subsystem program quality 305 and a column for the quality prediction model formula 307 are added to the table for the subsystem design quality 107.

  The quality prediction model formula 307 is a formula showing the correlation between the subsystem design quality and the subsystem program 108 obtained by statistically processing the data accumulated in the subsystem quality record 112. This equation is obtained, for example, by performing regression analysis on the correlation between the subsystem attributes (eg, defect density, review man-hour density) indicated by the subsystem quality results 107 and the quality results of the subsystem program 108. The subsystem quality prediction model formula 307 is updated by reflecting the recording result of the subsystem design quality 107 as needed.

  FIG. 4 is a diagram illustrating an example of data of the test case 109 in the present embodiment. The test case 109 is a table that records information on individual tests to be performed. In this table, the test case 401 is a column in which the name of the test case is described. The subsystem configuration 402 is a column in which the configuration of the subsystem program 108 executed in the corresponding test case is described. In one test case, since a plurality of subsystem programs 108 are executed in various orders, it is necessary to define a calling relationship between the subsystem programs. Therefore, as the value of the subsystem configuration 402, the data of the subsystem call relation 409 for defining the call relation between the subsystem programs (previously provided in the storage means) is referred to.

  FIG. 5 shows a structural example 501 of the calling relationship of the subsystem program 108 in a certain test case, and FIG. 6 shows an example of the subsystem calling relationship 409 corresponding to the structural example 501. By defining the called subsystem program as the parent program in the two subsystem programs in the calling relationship, the configuration of a series of test cases can be expressed. In the table of the subsystem call relation 409 shown in FIG. 6, the test case 601 is a column in which the test case name is described. The subsystem program 602 is a column in which names of individual subsystem programs constituting the corresponding test case are described. The parent program 603 is a column describing which subsystem program the corresponding subsystem program is called from. By defining the calling relationship between the subsystem programs in this way, it is possible to express a configuration with a branch as shown in the calling relationship structure example 501 of the subsystem program 108 in FIG. The subsystem program quality 605 is a column in which the probability of occurrence of a malfunction by executing each subsystem program 108 is described. The value of the subsystem program quality 605 can be uniquely calculated by using the quality prediction model equation 307.

  Returning to the description of FIG. In the test case 109, the complexity 403 is a column in which a value obtained by quantifying the complexity of the configuration of the subsystem program 108 in the test case indicated by the subsystem call relation 409 is set. In general, there is “circular complexity” as an index for evaluating the complexity of a program. This cyclic complexity is obtained by calculating the number of paths that are linearly independent in the program calling relationship as shown in FIG. As the value of the complexity 403, an evaluation result obtained by such a generally used cyclic complexity method is applied.

  The quality risk 404 is a column in which the probability of occurrence of a defect as a test case is described. The quality risk 404 can be calculated from the configuration of the subsystem program 108 constituting each test case and the failure occurrence probability of each subsystem program 108. For example, the test case priority calculation unit 102 calculates the quality risk by applying the quality value of the subsystem program 108 to a predetermined calculation formula according to the configuration of the subsystem program in the corresponding test case.

  A specific conceptual example of quality risk calculation is shown in FIG. Assume that there is a test case having a calling relationship 701 of the subsystem program 108 as shown in FIG. In this call relationship 701, each box indicates a subsystem program name on the left side of “:” and a value of subsystem program quality on the right side.

  Here, assuming that P (x) is the probability of occurrence of a malfunction in the subsystem program x, the quality risk value can be obtained from the call relationship 701 as shown in the equation 801 shown in FIG. Here, “Prog-B” and “Prog-C” are branched from “Prog-A”. In such a case, there is no problem with either “Prog-B” or “Prog-C”. Quality risk can be considered as the “event after event”. As a result, as shown in Expression 801, the quality risk value regarding the test case in which the subsystem programs have the calling relationship 701 can be calculated as “0.664”.

  Also, in the test case 109 of FIG. 4, the priority 405 is a column in which the execution priority between the test cases recorded in the test case 109 is described. The value of the priority 405 is a result of sorting the values obtained by multiplying the values of the complexity 403 and the quality risk 403 in descending order. This is based on the idea that the subsystem program 108 with a higher value of the complexity 403 is more likely to have a defect at the time of creation, and the higher the value of the quality risk 403, the more likely to be a problem. Here, it shows that the priority which should be implemented as a test case is so high that the value of the priority 405 is small.

  Further, the man-hour 406 is a predicted man-hour value necessary for executing the test case, calculated by the man-hour prediction model formula 1006 (see FIG. 10). Since the person in charge 407 and the execution order 408 are determined by the processing of the test plan calculation unit 104, details will be described later.

  Further, the processing apparatus 101 applies each data of the test case size and complexity to a predetermined man-hour prediction model formula (formula 1006 in FIG. 10), and calculates man-hours necessary for executing each test case. And a test man-hour calculation unit 103 that stores the data in the storage unit.

  The test man-hour calculating unit 103 reads out the test man-hour performance of the test case from the storage means in which it is stored, and performs a regression analysis on the correlation between the scale and complexity of the test case indicated by the man-hour performance and the execution man-hour. To generate a man-hour prediction model formula (formula 1006 in FIG. 10), and apply each data of the scale and complexity of the test case to be tested to the man-hour prediction model formula to execute each test case. The necessary man-hours may be calculated and stored in the storage means.

  Here, the data of the test execution man-hour record 113 used for the man-hour calculation process will be described. FIG. 10 is a diagram illustrating a data example of the test execution man-hour record 113 in the present embodiment. In the test execution man-hour record 113, the test case 1001 is a column for recording names of test cases executed in the past. Further, the subsystem configuration 1002 indicates the configuration of the subsystem program 108 in the test case 1001, and the calling relationship between the subsystem programs is associated with the subsystem calling relationship 1007. As illustrated in FIG. 11, the configuration of the subsystem call relationship 1007 is the same as the configuration of the subsystem call relationship 409 described above.

  In the table of the test execution man-hour record 113, the complexity 1003 is a column for recording the complexity in the test case 1001. The scale 1004 is a column for describing the scale as a test case, and the total value of the scale 1104 of the subsystem program 108 recorded in the subsystem call relation 1007 associated with the subsystem configuration 1002 is described. The execution man-hour 1005 is a column in which the actual value of the execution man-hour of the corresponding test case 1001 is described. Further, the man-hour prediction model formula 1006 is a formula showing the correlation between the test case and the test execution man-hour obtained by statistically processing the data accumulated in the test execution man-hour record 113. As described above, This is an equation obtained with the same idea as the quality prediction model equation 307. The man-hour prediction model formula 1006 is updated by reflecting the execution result of the test case 109 as needed.

  Further, the processing apparatus 101 reads out the man-hours of each test case from the storage means, assigns personnel resources necessary for the man-hours in order from the test case having the highest execution priority, generates a test plan, and stores it in the storage means Then, test milestone data defining a subset of test cases to be executed by a predetermined time according to the constraints inside and outside the project in the test plan is read from the storage means storing the data, and the test milestone defines When the test execution completion time of the set of test cases to be exceeded exceeds the predetermined time limit, a test plan is calculated by calculating the execution order of test cases that achieve the predetermined time limit according to the content of corresponding processing determined in advance according to the constraint condition pattern Is provided with a test plan calculation unit 104 for updating the data.

  The processing device 101 stores, in the storage means, a quality attribute that defines whether or not the quality status to be secured according to a test case to be performed in the test milestone can be changed as a constraint on the test milestone, and a time limit of the test milestone. It is preferable to have data of a time limit attribute that defines whether or not to change the data and a man-hour attribute that defines whether or not to add personnel resources during the execution period of the test milestone.

  In this case, when the test execution completion time of the test case set specified by the test milestone exceeds the predetermined time limit, the test plan calculation unit 104 determines that each value of the quality attribute, time limit attribute, and man-hour attribute of the test milestone is It is assumed that the execution order of the test cases that achieve the predetermined time limit is calculated and the test plan data is updated in accordance with the contents of corresponding processing predetermined according to the possible patterns.

  The test plan calculation unit 104 takes the values of the quality attribute, the time limit attribute, and the man-hour attribute of the test milestone when the test execution completion time of the test case set specified by the test milestone exceeds the predetermined time limit. A plurality of test case execution orders that achieve the predetermined time limit may be calculated in accordance with a plurality of predetermined processing contents according to possible patterns, and a plurality of test plan data may be generated and stored in the storage means.

  The processing apparatus 101 further includes a test plan display unit 105 that reads test plan data from storage means and displays the data on an output device. The test plan display unit 105 may read data of a plurality of test plans from the storage unit and display them on the output device.

  In addition, the processing apparatus 101 receives a test plan acceptance / selection instruction from the user via a predetermined input device regarding the test plan displayed by the test plan display unit 105 on the output device, and the final result by the user. A test plan information input unit 106 may be provided that stores the test plan in response to the determination instruction in the storage unit.

  Details of the processing contents of the test man-hour calculation unit 103, the test plan calculation unit 104, the test plan display unit 105, and the test plan information input unit 106 described above will be described in a processing flow example described later.

  In addition, various data and tables used by the processing apparatus 101 of the present embodiment are stored in a non-volatile storage means such as a hard disk drive provided in the processing apparatus itself or available via a network.

--- Processing flow example 1 ---
Hereinafter, the actual procedure of the test plan creation method according to the present embodiment will be described with reference to the drawings. Various operations corresponding to the test plan creation method described below are realized by, for example, a program that is read into the memory or the like of the processing apparatus 101 and executed (of course, by an electronic circuit or the like that implements necessary functions). Also good). And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

  FIG. 9 is a diagram showing a processing flow example 1 of the test plan creation method of the present embodiment. Here, a processing flow executed by the test case priority calculation unit 102 will be described. In this case, first, the test case priority calculation unit 102 selects one test case (for example, in ascending order of names, and so on) from the test case 109 of the storage unit (step 901).

  Further, the test case priority calculation unit 102 selects one subsystem program from the subsystem call relation 409 corresponding to the test case selected in step 901 (step 902). For example, it is assumed that the subsystem program “Prog-1” is selected for the test case “TN”.

  Subsequently, the test case priority calculation unit 102 stores the subsystem design document corresponding to the subsystem program “Prog-1” in the table of the subsystem design quality 107 in FIG. 2 using the name of the subsystem program as a key. Search is performed (step 903). In the case of the subsystem design quality 107 in FIG. 2, the subsystem design document corresponding to the subsystem program “Prog-1” can be searched for “Doc-1”.

  Further, the test case priority calculation unit 102 extracts each value of the defect density 202 and the review man-hour density 203 of the subsystem design document “Doc-1” from the subsystem design quality 107 (step 904). Similarly, in the example of FIG. 2, the defect density 202 can be extracted as “0.75” and the review man-hour density 203 can be extracted as “30.5”.

  Next, the test case priority calculation unit 102 applies the respective values of the defect density and the review man-hour density to the quality prediction model equation 307, so that the corresponding subsystem program (“Prog-1” in the above example) A quality predicted value is calculated and recorded in the column of subsystem program quality 605 in the table of subsystem call relation 409 (step 905). The generation of the quality prediction model formula 307 is as described above.

  Here, when there is a subsystem program other than the subsystem program in the corresponding test case (step 906: Yes), the test case priority calculation unit 102 returns to step 902 and repeats the operation. Through the processing so far, the quality of all subsystem programs included in the test case can be obtained.

  Next, the test case priority calculation unit 102 performs a probability calculation (as described above) as shown in Expression 801 from the configuration of the subsystem program quality and the subsystem call relationship 409 of the test case, The test case quality risk is calculated and recorded in the quality risk 404 column in the test case 109 table (step 907).

  Further, the test case priority calculation unit 102 calculates the complexity based on the configuration of the subsystem call relation 409 of the test case, and records it in the column of the complexity 403 in the test case 109 table (step 908). When a test case other than the test case exists in the test case 109 table (step 909: Yes), the test case priority calculation unit 102 returns the process to step 901 and repeats the operation.

  Finally, the test case priority calculation unit 102 sorts the test cases in the descending order of the multiplication values based on the multiplication values of the respective values of the complexity 403 and the quality risk 404 of each test case in the test case 109 table. The ranking is recorded, and the ranking is recorded in the priority 405 column as the priority of the test case (step 910).

--- Processing flow example 2 ---
Next, a processing flow of the test man-hour calculation unit 103 will be described. FIG. 12 is a diagram showing a processing flow example 2 of the test plan creation method of the present embodiment. In this case, first, the test manhour calculation unit 103 selects one test case from the table of test cases 109 (step 1201).

  Further, the test man-hour calculating unit 103 acquires information on the scale 604 of each subsystem program 108 as a constituent element from the information on the subsystem call relation 409 associated with the test case selected in Step 1201, and the scales thereof. The value of 604 is added together to calculate the scale of the test case (step 1202).

  Subsequently, the test man-hour calculation unit 103 acquires the value of the complexity 403 of the test case from the table of the test case 109 (Step 1203). The test man-hour calculation unit 103 applies the respective values of the scale of the test case and the complexity of the test case to the man-hour prediction model equation 1006 to calculate the prediction man-hour of the test case, and in the test case 109 table, It records in the column of the man-hour 406 regarding the corresponding test case (step 1204). If there is something other than the test case for obtaining the value of the man-hour 406 (step 1205: Yes), the test man-hour calculating unit 103 returns the process to step 1201 and repeats the operation.

--- Processing flow example 3 ---
Next, an overall processing flow of test plan calculation by the test plan calculation unit 104 will be described. FIG. 13 is a diagram showing a processing flow example 3 of the test plan creation method of the present embodiment. In this case, first, the test plan calculation unit 104 selects, from among the test cases described in the test case 109 table, the value of the execution order 408 that is undecided and the highest value of the priority 405 (step 1301). ).

  Next, the test plan calculation unit 104 acquires the value of the man-hour 406 for the corresponding test case selected in step 1301 (step 1302), and for example, the project for the test case so that the execution period is minimized. The person in charge (personal resource) registered in the plan 111 is assigned and recorded in the field of the person in charge 407 of the corresponding test case in the test case 109 (step 1303).

  Further, the test plan calculation unit 104 determines the execution order of the test cases to which the person in charge is assigned in step 1303, and records them in the column of the execution order 408 corresponding to the corresponding case in the test case 109 (step 1304). . As an example of determining the execution order, for example, a method of ordering from the smallest priority 405 value can be assumed. If there is something other than the test case that requires the execution order 408 (step 1305: Yes), the test plan calculation unit 104 returns the process to step 1301, and repeats the operation. Thus, the data group in which the execution order and the person in charge are determined for each test case can be a test plan.

  Although not specifically shown in the drawing, the project plan 111 describes data such as a person assigned to each software system development project for which a test plan is to be performed, a name of a test case that the person in charge is responsible for, and an execution period. The table is held in advance in the storage means. Therefore, when assigning a person in charge for a test case, the test plan calculation unit 104 selects a person whose person in charge includes a test case execution period from the table of the project plan 111. . In addition, when assigning a person in charge so that the implementation period is minimized, among those who have a vacant period that includes the test case implementation period, the date that the vacancy period includes is the most common on the start date of the test case implementation period. The closest one will be selected.

  Incidentally, the processing flow of the test plan calculation unit 104 shown in FIG. 13 is calculated in consideration of minimizing the period of the entire test process. On the other hand, if a period during which the special equipment can be used for testing is specified by the customer during the test process, or if it is necessary to deliver in advance according to the customer's circumstances, these Test cases need to be implemented in consideration of constraints.

  Therefore, in this embodiment, the concept of test milestone 110 is newly introduced. The test milestone 110 defines various constraint situations such as a period for using a device for performing a test and a deadline for advance delivery to a customer. More specifically, the data defines a subset of test cases to be executed by a predetermined time according to the constraints inside and outside the project in the test plan.

  FIG. 14 is a diagram illustrating an example of data of the test milestone 110 in the present embodiment. In the test milestone table illustrated in this figure, a test milestone 1401 is a column for recording the name of the corresponding test milestone. The test case 1402 is a column that defines a set of test cases to be executed at the corresponding test milestone, and its substance is defined in the test case configuration 1407. In the test case configuration 1407 shown in FIG. 15, the test milestone name 1501 is a column for recording the name of the corresponding test milestone. In the test case list 1502 that follows this, all the test cases to be executed in the corresponding test milestone are shown. This is a column for recording names.

  Further, in the table shown in FIG. 14, a time limit 1403 is a time limit for completion of the test given to the corresponding test milestone. The quality attribute 1404 is one of the attributes of the test milestone, and defines whether or not the quality target level can be changed. Here, the quality target refers to a state in which all planned test cases are executed, and defects in the test cases are extracted and countermeasures are taken. Changing the quality target means a state in which there are some test cases that are not implemented.

  Further, in the table shown in FIG. 14, a time limit attribute 1405 is one of the attributes of the test milestone, and defines whether or not the time limit of the test milestone can be changed. The man-hour attribute 1406 is one of the attributes of the test milestone. In order to achieve the test milestone deadline, a person in charge newly assigned from another project is assigned in addition to the person in charge described in the project plan 111. Defines whether or not It is assumed that a new assignable person in charge has a free period = a period in which a test case can be assigned is at least within the test milestone deadline.

  In the processing apparatus 101 according to the present embodiment, in order to achieve the maximum goal of the test case included in the test milestone, the corresponding processing is performed for each of the three attribute value patterns of the quality attribute 1404, the time limit attribute 1405, and the man-hour attribute 1406. The contents are defined and stored in advance by storage means or a program. “Contents of handling process” is shown below.

  FIG. 16 is a diagram showing an example of the relationship between the attribute value pattern of the test milestone and the corresponding contents in the present embodiment. Each pattern shown in FIG. 16 is a conditional branch pattern when the processing apparatus 101 executes the flows shown in FIGS. Corresponding content corresponding to each pattern is processing content executed by the processing apparatus 101 after the conditional branch (= described in the program as these conditional branch and processing corresponding thereto). Alternatively, the table shown in FIG. 16 may be held in a predetermined storage device by the processing apparatus 101 and used by referring to the processes shown in FIGS.

  In the example of the correspondence relationship shown in FIG. 16, in addition to the three attributes (quality, deadline, and man-hour) of the test milestone, an additional condition 1601 is defined. This is so considered that the time limit of other test milestones is not affected by the response described later (= contents of response processing). In the example of FIG. 16, nine “correspondences” are described. Further, the contents of this correspondence are composed of four patterns. The first pattern is to postpone the test milestone deadline (1602). The second pattern deletes the test case included in the test milestone (1603). The third is to achieve test milestone quality and deadline by adding man-hours (1604). The last four are difficult to solve with these three measures, and present both the one that extends the test milestone deadline and the one that deletes the test case as a proposal that can achieve the maximum goal. Decision making is made by the project manager (1605).

  Next, the concept of the four corresponding processing patterns will be described with reference to the drawings. 17 is a conceptual example of test milestone postponement in the present embodiment, FIG. 18 is a conceptual example of test case deletion in the present embodiment, and FIG. 19 is a diagram illustrating a conceptual example of man-hour addition in the present embodiment. In the example shown in FIG. 17, the test cases “T-3” and “T-4” have not achieved the test milestone time limit “M1”. Therefore, the test milestone deadline “M1” is postponed in accordance with the deadline of the test case “T-4”.

  In the example shown in FIG. 18, the test milestone deadline “M1” is achieved by deleting the test case “T-3” that has not achieved the test milestone deadline “M1”. Further, in the case of the example shown in FIG. 19, for the test case “T-4” that has not achieved the test milestone deadline “M1”, a new charge “X” is assigned instead of the charge “A” so far. The test milestone deadline “M1” has been achieved.

--- Processing flow example 4 ---
Next, a process flow for creating a test plan in consideration of the correspondence of the attribute value indicated by the test milestone to the constraint pattern by the test plan calculation unit 104 will be described. FIG. 20 is a diagram showing a processing flow example 4 of the test plan creation method of the present embodiment.

  In this case, first, the test plan calculation unit 104 selects one test milestone from the test milestone table 110 (step 2001). Further, the test plan calculation unit 104 calculates the execution completion deadline of all test cases from the test case configuration 1407 corresponding to the test milestone (2202) and compares it with the test milestone deadline 1403 (step 2003). In step 2202, the execution completion deadline of all test cases is calculated by, for example, identifying the corresponding test case from the test case table 109 using the name of each test case indicated by the test case configuration 1407 as a key. Each value of the execution order 408 is extracted. Then, for example, the required number of days for test execution is calculated by multiplying the value of the man-hour 406 of each test case by the number of work days per unit man-hour (such as a predetermined specified value). If the required number of days for each test case is added together for each test case execution order (of course, the execution period is overlapped between test cases = excluding the period of execution in parallel) An implementation completion deadline can be calculated.

  On the other hand, in the comparison process of step 2003, if the execution completion deadline of all test cases does not exceed the deadline of the test milestone (step 2003: Yes), the test plan calculation unit 104 advances the process to step 2007.

  On the other hand, if the execution completion deadline of all test cases exceeds the deadline of the test milestone (step 2003: No), the test plan calculation unit 104, for example, among the test cases that are due to the deadline of the test milestone, Test cases not included in the test case configuration 1407 are changed to the order after the expiration date of the test milestone (2004). After the movement of the test case, the test plan calculation unit 104 rearranges the test cases included in the test case configuration 1407 so as to minimize the deadline (2005). If the deadline of the test case group after the rearrangement does not exceed the deadline of the test milestone (step 2006: Yes), the test plan calculation unit 104 proceeds with the process to step 2007, while if it has exceeded (step 2006: No), it moves to the processing flow X. In step 2007, the test plan calculation unit 104 determines whether there is a test milestone to be processed other than the test milestone. If there is another test milestone (step 2007: Yes), the test plan calculation unit 104 returns the process to step 2001 and repeats the operation.

--- Processing flow example 5 ---
FIG. 21 is a diagram showing a processing flow example 5 of the test plan creation method of the present embodiment. This processing flow example is a processing flow X in which the test plan calculation unit 104 evaluates the attribute value of the test milestone and distributes the correspondence contents, and expresses the relationship between the constraint pattern illustrated in FIG. 16 and the correspondence contents as a processing flow. Will be.

  In this case, with respect to the test milestone selected in Step 2001 of the processing flow example 4, the quality attribute 1404, the time limit attribute 1405, and the man-hour attribute 1406 are acquired from the table of the corresponding test milestone (Step 2101).

  First, the test plan calculation unit 104 determines true / false regarding the quality attribute = “changeable” and the term attribute = “changeable” for each attribute value obtained in step 2101 (step 2102). Here, if it can be determined to be “true” (step 2102: Yes), the test plan calculation unit 104 advances the process to step 2103, and if “false” (step 2102: No), the process advances to step 2104.

  In step 2103, the test plan calculation unit 104 checks whether the change of the test milestone deadline has an effect on the deadlines of other test milestones. If there is an influence (step 2103: Yes), the process proceeds to the process flow B. If there is no influence (step 2103: No), the process proceeds to process flow A. Whether the test milestone deadline affects other test milestone deadlines, for example, the person in charge of the test case of the test milestone extended the duration of the test milestone, and as a result If you were planning to be in charge of a test case for a milestone, but it would be difficult to do so, you can check the execution period of the test case against the assigned period of each person in charge.

  On the other hand, in step 2104, the test plan calculation unit 104 determines whether the attribute value is true or false regarding the quality attribute = “unchangeable” and the term attribute = “changeable”. If it is determined to be “true” (step 2104: Yes), the test plan calculation unit 104 advances the process to step 2105. If it is “false” (step 2104: No), the process advances to step 2107. .

  In step 2105, the test plan calculation unit 104 checks whether the change in the test milestone deadline has an effect on the deadlines of other test milestones. If there is an influence (step 2105: Yes), the process proceeds to step 2105. Go to 2106. On the other hand, if there is no influence (step 2105: No), the process proceeds to process flow A.

  In step 2106, the test plan calculation unit 104 checks the man-hour attribute among the attribute values. If the value is “man-hour can be added” (step 2106: Yes), the process proceeds to the processing flow C. On the other hand, if the man-hour addition is “impossible” (step 2106: No), the process proceeds to process flow D.

  In step 2107, the test plan calculation unit 104 determines true / false regarding the attribute value with respect to quality attribute = “changeable” and term attribute = “unchangeable”, and if it is “true” (step 2107). : Yes), the process proceeds to step 2108. On the other hand, if “false” (step 2107: No), the process proceeds to step 2109.

  In step 2108, the test plan calculation unit 104 checks the man-hour attribute among the attribute values. If the man-hour attribute is “possible to add man-hour” (step 2108: Yes), the process proceeds to the process flow C and may be “impossible”. If (step 2108: No), the process proceeds to process flow B.

  In step 2109, the attribute value condition is in the state of quality attribute = “cannot be changed” and term attribute = “cannot be changed”. Here, the test plan calculation unit 104 checks the man-hour attribute of the attribute values, and if “man-hour addition is possible” (step 2109: Yes), the process proceeds to processing flow C, and if it is “impossible” (step 2109). : No), proceed to process flow D. The processing flows A to D will be described with the following processing flow examples.

--- Processing flow example 6 ---
FIG. 22 is a diagram showing a processing flow example 6 of the test plan creation method of the present embodiment. This flow is a processing flow A in the case where the test plan calculation unit 104 postpones the test milestone deadline. Here, the test plan calculation unit 104 sets all test case execution completion deadlines included in the test milestone as the deadline for the test milestone selected in step 2001 in the processing flow example 1 (step 2201). The result is displayed on the output device via the test plan display unit 105 (2202), and the processing flow Y is started.

--- Processing flow example 7 ---
FIG. 23 is a diagram showing a processing flow example 7 of the test plan creation method of the present embodiment. This flow is a processing flow B when the test plan calculation unit 104 deletes a test case included in a test milestone. In this case, first, the test plan calculation unit 104 selects and deletes the test case with the lowest priority from the corresponding test case configuration 1407 for the test milestone selected in step 2001 in the processing flow example 1 ( Step 2301).

  Subsequently, the test plan calculation unit 104 calculates an execution completion deadline for all test cases included in the test case configuration 1407 after the test case deletion process (step 2302), and compares this execution completion deadline with the deadline of the test milestone. (Step 2303). If the execution completion time limit does not exceed the test milestone time limit (step 2303: Yes), the test plan calculation unit 104 advances the processing to step 2304. On the other hand, when the execution completion deadline exceeds the test milestone deadline (step 2303: No), the test plan calculation unit 104 returns the process to step 2301 to further delete the test case.

  Further, in step 2304, the test plan calculation unit 104 updates the test case 109 by the test case deletion in step 2301 and the influence range of the test milestone 110 (for the data such as the execution order such as the test execution deadline, FIG. The corresponding table in FIG. 4 or the like is updated), and the result (eg, the result after deleting “T-6” in the upper part of FIG. 26 and the result of deleting “T-6” in the lower part) is output via the test plan display unit 105. (Step 2305), and the processing flow Y is started.

--- Processing flow example 8 ----
FIG. 24 is a diagram showing a processing flow example 8 of the test plan creation method of the present embodiment. This flow is a processing flow C in which the test plan calculation unit 104 executes a retest plan by adding man-hours. In this case, the test plan calculation unit 104 has the highest priority regarding the test milestone selected in step 2001 in the processing flow example 1 from the test case configuration 1407 corresponding to the test milestone that has not been reassigned. A test case having a high value is selected (step 2401).

  Further, the test plan calculation unit 104 acquires the value of the man-hour 406 for the test case selected in the step 2401 (step 2402). In addition, for example, in addition to the person in charge assigned to the project in the project plan 111, the person in charge of the person in charge that can be added (the person in charge with an unassigned free period) including persons in charge of other projects. Is grasped (step 2403).

  The test plan calculation unit 104 assigns a person in charge to the test case selected in step 2401 so that the deadline is minimized (step 2404). The method for assigning the person in charge to minimize the deadline has already been described in the processing flow example 3 (the same applies to other processing flow examples). Further, the test plan calculation unit 104 determines whether the test case deadline when the person in charge is assigned in step 2404 exceeds the test milestone deadline, and if the test case deadline does not exceed the test milestone deadline ( Step 2405: Yes), the process proceeds to Step 2406. On the other hand, if the deadline of the test case exceeds the deadline of the test milestone (step 2405: No), the test plan calculation unit 104 returns the process to step 2401, and repeats the operation.

  In step 2406, the test plan calculation unit 104 updates the influence range of the test case and the test milestone generated by the person-in-charge assignment in step 2404 (2406). The update process of the influence range is the same as that described in the processing flow example 7. Further, the test plan calculation unit 104 displays the test plan data reflecting the processing result in the step 2406 on the output device via the test plan display unit 105 (step 2407), and proceeds to the processing flow Y.

--- Processing flow example 9 ---
FIG. 25 is a diagram showing a processing flow example 9 of the test plan creation method of the present embodiment. This flow is a processing flow D in which the test plan calculation unit 104 changes a test milestone deadline or deletes a test case. That is, this processing flow D is a combination of both processing flow A and processing flow B. Therefore, in this case, the test plan calculation unit 104 performs the above-described steps 2201 and 2202 (step 2501), and subsequently executes steps 2301 to 2305 (step 2502), and then proceeds to the processing flow Y. . Since Step 2201, Step 2202, and Step 2301 to Step 2305 have already been described, description thereof will be omitted here.

---- Display example ---
FIG. 26 to FIG. 29 show examples of test plan display by the test plan display unit 105. FIG. 26 is an example of the result display of the entire test plan. In this display, an area 2601 indicates a test plan before the test milestone attribute value evaluation is performed, and an area 2602 indicates the attribute value evaluation of the test milestone. As a result, the test plan reflecting the result of the corresponding contents according to the attribute value pattern is shown. The test plan display unit 105 reads each data related to the test milestone 110 and the test case 109 defined by the test milestone 110 as data of each test plan from the storage unit, sets the data as predetermined initial screen data, and sets the area 2601, Screen data corresponding to 2602 is generated and displayed on the output device. Hereinafter, as for the data displayed by the test plan display unit 105, the corresponding data is extracted from the storage means as described above, set to predetermined initial screen data, and necessary screen data is generated. Further, since a plurality of correspondences may occur depending on the state of the attribute value of each test milestone, the test plan is displayed for each correspondence case.

  An area 2601 in FIG. 26 indicates that neither the test milestone “M1” nor the test milestone “M2” has been achieved (the date indicated by Δ on the time axis in the area). For test milestone “M1”, test case “T3” has expired, and for test milestone “M2”, test case “T6” has expired.

  On the other hand, in the area 2602, by the process of the test plan calculation unit 104, the deadline of the test milestone “M1” can be postponed and the deadline of the test milestone “M2” can be achieved by deleting the test case “T-6”. It shows that.

  Note that the test plan display unit 105 can extract not only the view of the entire test plan as shown in FIG. 26 but also data for each test milestone from the storage means, and can also display the view. Such a view change process is handled by the test plan display unit 105 in accordance with a user instruction (view selection instruction for the entire test plan or for each test milestone) received by the test plan information input unit 106 via the input device. To do.

  FIG. 27 shows a display example of a test plan in units of test milestones. In this display, an area 2701 indicates the state of the test milestone before the evaluation of the attribute value of the test milestone (= relationship between the test case set included in the test milestone and the deadline of the test milestone). In the lower part of the area 2701, an attribute display 2702 is arranged, and each value of the quality attribute, the time limit attribute, and the man-hour attribute in the test milestone is displayed. Further, the time limit display 2703 also displays the time limit of the test milestone.

  On the other hand, the area 2704 displays the state of the test milestone after the test plan calculation unit 104 evaluates the attribute value of the test milestone. When a plurality of correspondences are possible depending on the attribute value of the test milestone, as shown in the figure, for example, tabs 2074a to 2074c corresponding to each correspondence result are displayed so as to be clickable, and the user-desired correspondence result is displayed. Good.

  Further, in the area 2704, the correspondence display 2705 displays each state related to the deletion of the test case, the change of the test milestone deadline, and the change of the man-hour by the processing of the test plan calculation unit 104. The detail button 2706 is a button for displaying detailed information of each state of the correspondence display 2705 on a separate screen. FIG. 28 shows a display example of detailed information of a test case to be deleted, which is displayed when a detailed button related to “delete test case” is pressed among the detailed buttons 2706. In this case, the view 2801 extracts and displays information about the test case that has been deleted from the test case 109 of the storage means. A display button 2802 displays the subsystem configuration of the test case on another screen, and FIG. 29 shows a configuration example of another screen. As shown on a screen 2901 in FIG. 29, the test plan display unit 105 refers to the subsystem call relationship 409 corresponding to the test case and displays it as a tree diagram (such as an existing tree diagram generation program). Can be used). Similarly, when the display button 2902 of the screen 2901 is pressed, the test plan display unit 105 displays the detailed information of the corresponding subsystem program 108 on the screen. At this time, the test plan display unit 105 extracts necessary information as the subsystem program information with reference to the subsystem design quality 107 and displays it on the screen.

  On the other hand, in the area 2704 of FIG. 27, a time limit 2707 is a column for displaying the time limit of the test milestone after the test plan calculation unit 104 evaluates the attribute value of the test milestone. In addition, the selection 2708 and the cancellation 2709 are whether the response presented by the processing of the test plan calculation unit 104 = the response specified by performing the attribute value evaluation of the test milestone is finally reflected in the test plan. An interface that receives instructions. The user = project manager makes a final decision based on various views displayed by the test plan display unit 105. Here, the test plan calculation unit 104 stores the test plan corresponding to the response determined and selected by the user in the storage unit.

--- Other embodiments ---
In the embodiment described above, a situation where a test plan is newly created is mainly assumed. However, as the test progresses, various issues arise in the project, and the project plan may need to be changed accordingly. In that case, the test plan may be affected. If the impact is not accurately grasped, it may affect product quality and development deadline. Therefore, in the following embodiment, the test plan is also changed according to the update of the project plan.
FIG. 30 is a diagram illustrating a configuration example of a processing device 3001 which is a test plan creation device according to another embodiment. The processing apparatus 3001 in this embodiment has substantially the same configuration as the processing apparatus 101 in the above embodiment. The difference from the processing apparatus 101 is that a project plan monitoring unit 3002 is provided. The project plan monitoring unit 3002 detects a data change in the project plan 111 related to the software system, re-executes at least one of the processes for the test plan, and regenerates the test plan.

  FIG. 31 is a diagram illustrating a processing flow example of a test plan creation method according to another embodiment. This flow is a processing flow of the project plan monitoring unit 3002. In this case, the project plan monitoring unit 3002 first monitors the data update of the project plan 111 in the storage unit and detects the data update. For example, it is assumed that a general monitoring program for detecting data update is arranged in the storage means. When this monitoring program detects data update, it notifies the project plan monitoring unit 3002 to that effect.

  When the data update of the project plan 111 is detected in this way (step 3101), the project plan monitoring unit 3002 checks the influence points on the test case 109 and the test milestone 110 (step 3102). For example, the test case 109 and the test milestone 110 affected by the change of the project plan 111 are removed from the charge when the person in charge of the test case in the project plan 111 moves to another department. When the person in charge of the test case or the test milestone that includes it is absent, the test case execution period, the assignment status of each person in charge, and the like can be checked.

  In this way, the project plan monitoring unit 3002 confirms whether or not there is an affected part due to the change in the project plan 111 (step 3103), and if there is an affected part (step 3103: Yes), activates the test plan calculation unit 104. Then, the test plan is re-executed (step 3104). On the other hand, if the affected part does not exist (step 3103: No), the project plan monitoring unit 3002 ends the process.

  Although the best mode for carrying out the present invention has been specifically described above, the present invention is not limited to this, and various modifications can be made without departing from the scope of the invention.

  According to the present embodiment, a test milestone is set, a set of test cases to be executed within the time limit is defined, and a necessary response is executed according to the constraint pattern. As a result, a test plan that takes into account the achievement targets for individual events that occur within the test process (= events that are internal and external restrictions such as the use of special equipment and customer's advance delivery, and can be defined by test milestones) It becomes possible to plan.

  Moreover, it is possible to define restrictions on quality, time limit, and man-hour as attribute information of test milestones. By preparing countermeasures for the test plan in accordance with such attribute information patterns, it is possible to flexibly and efficiently formulate a test plan that takes into account the constraints occurring inside and outside the project.

  Therefore, an efficient test plan can be created under the constraints inside and outside the project.

  In addition, at least the following is clarified by the description of the present specification. That is, in the test plan creation method, the computer device, in the storage means, as a constraint condition related to the test milestone, a quality attribute that defines whether or not the quality status to be secured by the test case to be performed in the test milestone, Test execution of the test case set specified by the test milestone, which has each data of the time limit attribute that defines whether or not to change the deadline of the test milestone and the manhour attribute that defines whether or not to add personnel resources during the execution period of the test milestone When the completion time exceeds the predetermined time limit, a test case that achieves the predetermined time limit according to the corresponding processing content determined in advance according to the patterns that the values of the quality attribute, time limit attribute, and man-hour attribute of the test milestone can take Calculate the execution order of the test plan To update the data, it may be.

  Further, in the test plan creation method, the computer device, when the test execution completion time of the test case set specified by the test milestone exceeds the predetermined time limit, each of the quality attribute, the time limit attribute, and the man-hour attribute of the test milestone A plurality of test case execution orders that achieve the predetermined deadline are calculated according to a plurality of predetermined processing contents according to patterns that can be taken by the value, and a plurality of test plan data are generated and stored in the storage means. Good.

  In the test plan creation method, the computer device may read data of a plurality of test plans from a storage unit and display them on an output device.

  Further, in the test plan creation method, the computer apparatus includes a subsystem design quality describing quality information at a design stage in a sub test program constituting a test case to be tested, and a subsystem program tested in the past. Each subsystem quality record data storing the quality record is read from the storage means storing the data, and regression analysis is performed on the correlation between the subsystem attribute indicated by the subsystem quality record and the quality record of the subsystem program. A quality prediction model formula is generated, and the subsystem attribute value indicated by the subsystem design quality is applied to the quality prediction model formula to predict the quality value of the corresponding subsystem program, and the subsystem program in the corresponding test case Formulas determined in advance according to the composition of A quality risk is calculated by applying the quality value of the subsystem program, the quality risk value is multiplied by a complexity value indicating the complexity of the configuration of the subsystem program included in the test case, and the multiplication is performed. The execution priority between the test cases may be calculated and stored in the storage unit with the higher value as the higher priority.

  Further, in the test plan creation method, the computer device reads out the test effort performance record from the storage means in which it is stored, and regresses the correlation between the scale and complexity of the test case indicated by the performance record and the performance effort. Analyze to generate a man-hour prediction model formula, and apply the data of the scale and complexity of the test case to be tested to the man-hour prediction model formula to calculate the man-hours required to execute each test case. It may be calculated and stored in the storage means.

  In the test plan creation method, the computer device stores project plan data relating to the software system in a storage unit, detects a change in the project plan in the storage unit, and performs at least one of the processes. The test plan may be regenerated by re-execution.

101 Processing device (test plan creation device)
102 Test Case Priority Calculation Unit 103 Test Effort Calculation Unit 104 Test Plan Calculation Unit 105 Test Plan Display Unit 106 Test Plan Information Input Unit 107 Subsystem Design Quality 108 Subsystem Program 109 Test Case 110 Test Milestone 111 Project Plan 112 Subsystem Quality Result 113 Test execution time

Claims (9)

A computer device for creating a test plan for a software system,
For each test case for which data is stored in advance in the storage means, multiply the quality risk value, which is the probability of occurrence of a defect related to the test case, by the complexity value indicating the complexity of the configuration of the subsystem program included in the test case A process of calculating an execution priority between the test cases by assuming that the multiplication value is high and having a high priority, and storing it in the storage means;
Applying each test case size and complexity data to a given man-hour prediction model formula, calculating the man-hours necessary to implement each test case and storing them in the storage means;
The process of reading the man-hours of each test case from the storage means, assigning the manpower resources necessary for the man-hours in order from the test case having the highest execution priority, generating a test plan, and storing in the storage means;
Test milestone data defining a subset of test cases to be executed by a predetermined time according to the constraints inside and outside the project in the test plan is read from the storage means storing the test milestone, and the test specified by the test milestone When the test execution completion time of the case set exceeds the predetermined time limit, the test plan data is calculated by calculating the execution order of the test cases that achieve the predetermined time limit according to the content of the predetermined processing according to the constraint condition pattern The process of updating
A process of reading test plan data from the storage means and displaying it on the output device;
The test plan creation method characterized by performing. The computer device includes:
In the storage means, as a constraint condition related to the test milestone, a quality attribute that defines whether or not the quality status to be secured according to a test case to be executed in the test milestone and a time limit attribute that defines whether or not the test milestone can be changed And man-hour attribute data defining whether or not to add personnel resources during the test milestone implementation period,
When the test execution completion time of the test case set specified by the test milestone exceeds the predetermined time limit, the corresponding processing determined in advance according to the patterns that each value of the quality attribute, time limit attribute, and man-hour attribute of the test milestone can take According to the content, the execution order of the test cases that achieve the predetermined deadline is calculated and the test plan data is updated.
The test plan creation method according to claim 1, wherein: The computer device includes:
When the test execution completion time of the test case set specified by the test milestone exceeds the predetermined time limit, a plurality of predetermined values are set according to patterns that each value of the quality attribute, the time limit attribute, and the man-hour attribute of the test milestone can take. 3. The test plan creation method according to claim 2, wherein a plurality of test case execution orders that achieve the predetermined time limit are calculated in accordance with the contents of corresponding processing, and a plurality of test plan data are generated and stored in the storage means. . The computer device includes:
4. The test plan creation method according to claim 3, wherein data of a plurality of test plans is read from the storage means and displayed on the output device. The computer device includes:
Subsystem design quality that describes the quality information at the design stage in the subtest program that constitutes the test case to be tested, and subsystem quality performance data that stores the quality performance in the previously tested subsystem program The data is read from the storage means in which it is stored, a regression analysis is performed on the correlation between the subsystem attribute indicated by the subsystem quality record and the quality record of the subsystem program to generate a quality prediction model expression, and the quality prediction model expression By applying the subsystem attribute value indicated by the subsystem design quality, the quality value of the corresponding subsystem program is predicted, and the sub-program is calculated according to a predetermined calculation formula according to the configuration of the subsystem program in the corresponding test case. Apply quality values from system programs to reduce quality risk And multiplying the quality risk value by the complexity value indicating the complexity of the configuration of the subsystem program included in the test case, and assigning a higher multiplication value to a higher priority The execution priority between the two is calculated and stored in the storage means,
The test plan creation method according to claim 1, wherein: The computer device includes:
Read the test effort performance record from the storage means in which it is stored, and perform regression analysis on the correlation between the scale and complexity of the test case indicated by the performance record and the performance, and generate a process prediction model formula. Apply each data of the scale and complexity of the test case to be tested to the man-hour prediction model formula, calculate the man-hours necessary to execute each test case, and store it in the storage means.
The test plan creation method according to claim 1, wherein: The computer device includes:
Project plan data relating to a software system is stored in a storage means, a change in the project plan in the storage means is detected, and at least one of the processes is re-executed to regenerate a test plan. The test plan creation method according to claim 1. A computer device for creating a test plan for a software system;
For each test case for which data is stored in advance in the storage means, multiply the quality risk value, which is the probability of occurrence of a defect related to the test case, by the complexity value indicating the complexity of the configuration of the subsystem program included in the test case A test case priority calculation unit that calculates an execution priority between the test cases as a high priority for the product having a high multiplication value, and stores it in a storage unit;
Applying each test case size and complexity data to a predetermined man-hour prediction model formula, calculating the man-hours required to implement each test case and storing them in the storage means,
Read the man-hours of each test case from the storage means, assign the manpower resources necessary for the man-hours in order from the test case with the highest execution priority, generate a test plan, store it in the storage means, Test milestone data that defines a subset of test cases to be executed by a predetermined time according to the constraints inside and outside the project is read from the storage means storing the test milestone, and the test case set specified by the test milestone is executed. When the completion time exceeds the predetermined time limit, the test plan data is updated by calculating the execution order of the test cases that achieve the predetermined time limit according to the content of the predetermined processing according to the pattern of the constraint condition A plan calculation unit;
A test plan display unit for reading test plan data from the storage means and displaying the test plan data on the output device;
A test plan creation device comprising: To a computer device that creates a test plan for a software system,
For each test case for which data is stored in advance in the storage means, multiply the quality risk value, which is the probability of occurrence of a defect related to the test case, by the complexity value indicating the complexity of the configuration of the subsystem program included in the test case A process of calculating an execution priority between the test cases by assuming that the multiplication value is high and having a high priority, and storing it in the storage means;
Applying each test case size and complexity data to a given man-hour prediction model formula, calculating the man-hours necessary to implement each test case and storing them in the storage means;
The process of reading the man-hours of each test case from the storage means, assigning the manpower resources necessary for the man-hours in order from the test case having the highest execution priority, generating a test plan, and storing in the storage means;
Test milestone data defining a subset of test cases to be executed by a predetermined time according to the constraints inside and outside the project in the test plan is read from the storage means storing the test milestone, and the test specified by the test milestone When the test execution completion time of the case set exceeds the predetermined time limit, the test plan data is calculated by calculating the execution order of the test cases that achieve the predetermined time limit according to the content of the predetermined processing according to the constraint condition pattern The process of updating
A process of reading test plan data from the storage means and displaying it on the output device;
A test plan creation program characterized in that