JP6320269B2 - Software test support apparatus and software test support program - Google Patents

Description

  The present invention relates to a software test support apparatus and a software test support program for calculating a test necessity degree indicating a degree of necessity of performing a test on a function realized by a module included in a software program.

Generally, when it is necessary to add functions or correct defects in software, the software is changed and a regression test is performed. This regression test is a test performed on the entire software, including a test that has already been performed.
However, when the software is large-scale, the number of test items for the regression test becomes enormous. Therefore, in practice, the number of regression test items is reduced by selecting the regression test items.
In software development including software changes, various information such as change history, failure status, failure history, coverage rate data, and person-in-charge technical information are managed to improve software quality.

Patent Document 1 discloses a technique for selecting test items using correction history information.
Patent Document 2 discloses a technique for evaluating a test item using a failure occurrence date and time, a failure occurrence frequency, and a module complexity.
However, in these technologies, various kinds of information managed in software development are not fully utilized. In addition, time series changes in the degree of necessity are not considered for each test item.

JP 2008-129661 A Japanese Patent Laid-Open No. 06-131214

  An object of the present invention is to make it possible to calculate a test necessity level indicating a degree of necessity of performing a test on a function realized by a module included in a software program.

The software test support apparatus of the present invention
A person-in-charge list file including a person-in-charge identifier of a person in charge of developing at least one of the modules included in the software program; a module person-in-charge file that associates a person-in-charge identifier with the module identifier of the module included in the software program; A file storage unit that stores a defect amount file that associates a defect amount that is the amount of a defect that has occurred in a module with a module identifier;
For each person identifier included in the person-in-charge list file, a module identifier is selected from the module person-in-charge file, a defect amount associated with the selected module identifier is selected from the defect amount file, and based on the selected defect amount And a person-in-charge technical value calculation unit for calculating a person-in-charge technical value representing the technical ability of the person in charge.

  According to the present invention, a person-in-charge technical value of a person in charge of module development can be calculated as an index value for calculating the degree of necessity for testing.

2 is a functional configuration diagram of a software test support device 100 according to Embodiment 1. FIG. 6 is a diagram illustrating an example of a person-in-charge list file 181 according to Embodiment 1. FIG. 6 is a diagram illustrating an example of a module charge file 182 according to Embodiment 1. FIG. 6 is a diagram illustrating an example of a defect amount file 183 according to Embodiment 1. FIG. 6 is a diagram illustrating an example of a module list file 184 according to Embodiment 1. FIG. 6 is a diagram illustrating an example of a work period file 185 according to Embodiment 1. FIG. It is a figure which shows an example of the change work file 186 in Embodiment 1. FIG. It is a figure which shows an example of the malfunction information file 187 in Embodiment 1. FIG. 6 is a diagram illustrating an example of a function coverage rate file 188 according to Embodiment 1. FIG. 6 is a diagram illustrating an example of a change history file 189 according to Embodiment 1. FIG. 6 is a diagram illustrating an example of a test necessity file 191 in Embodiment 1. FIG. 6 is a diagram illustrating an example of a test necessity order file 199 according to Embodiment 1. FIG. 3 is a flowchart showing the operation of the software test support apparatus 100 in the first embodiment. 2 is a hardware configuration diagram of a software test support device 100 according to Embodiment 1. FIG. 1 is a configuration diagram of a software test support system 200 in Embodiment 1. FIG. 6 is a functional configuration diagram of a software test support device 100 according to Embodiment 2. FIG. 10 is a diagram illustrating an example of an index value file 192 according to Embodiment 2. FIG. It is a figure which shows an example of the test necessity log | history file 193 in Embodiment 2. FIG. 10 is a flowchart showing the operation of the software test support apparatus 100 in the second embodiment.

Embodiment 1 FIG.
A description will be given of a mode of calculating a test necessity level indicating a degree of necessity of performing a test on a function realized by a module included in a software program.

*** Explanation of configuration ***
FIG. 1 is a functional configuration diagram of the software test support apparatus 100 according to the first embodiment.
A functional configuration of the software test support apparatus 100 according to the first embodiment will be described with reference to FIG. However, the functional configuration of the software test support apparatus 100 may not be the same as the functional configuration illustrated in FIG.

The software test support apparatus 100 calculates the test necessity for each module included in the software program.
The test necessity indicates the degree to which a test for the function realized by the module needs to be performed.

The software test support apparatus 100 includes a person-in-charge technical value calculation unit 110, a change work density calculation unit 120, a defect amount calculation unit 130, a module coverage rate calculation unit 131, a change frequency calculation unit 132, and a change rate calculation unit. 133.
The software test support apparatus 100 includes a test necessity calculation unit 140, a test necessity order output unit 150, and a file storage unit 190.

The file storage unit 190 stores data used, generated or input / output by the software test support apparatus 100. A file is an example of data.
For example, the file storage unit 190 stores a person-in-charge list file 181, a module person-in-charge file 182, and a defect amount file 183.
Here, the person-in-charge list file 181, the module person-in-charge file 182, and the defect amount file 183 will be described.

FIG. 2 is a diagram illustrating an example of the person-in-charge list file 181 according to the first embodiment.
The person-in-charge list file 181 in the first embodiment will be described with reference to FIG.
The person-in-charge list file 181 includes a person-in-charge identifier of a person in charge of developing at least one of the modules included in the software program. The person in charge identifier identifies the person in charge.
The person-in-charge list file 181 in FIG. 2 indicates that there is a person in charge identified by the person-in-charge identifier named Kou and a person in charge identified by the person-in-charge identifier named Miya.
The person in charge identified by the person-in-charge identifier Kou is called person-in-charge Kou, and the person in charge identified by the person-in-charge identifier Miya is called person-in-charge Miya.

FIG. 3 is a diagram illustrating an example of the module charge file 182 according to the first embodiment.
The module charge file 182 in the first embodiment will be described with reference to FIG.
The module person in charge file 182 associates the person in charge identifier with the module identifier of the module included in the software program. The module identifier identifies the module.
The module responsible file 182 in FIG. 3 indicates that the person in charge Kou is responsible for developing the position sensor reading module and the warning display module. The module charge file 182 indicates that the person in charge Miya is responsible for the movement control module.

FIG. 4 is a diagram showing an example of the defect amount file 183 in the first embodiment.
An example of the defect amount file 183 in the first embodiment will be described with reference to FIG.
The defect amount file 183 associates a defect amount that is the amount of a defect that has occurred in a module with a module identifier. A malfunction is also called a bug or failure.
The defect amount file 183 in FIG. 4 indicates that the defect amount of the position sensor reading module is 10, the defect amount of the warning display module is 6, and the defect amount of the movement control module is 7.
For example, the defect amount is the number of defects that have occurred, in particular, the number of defects that have occurred during the defect target period.
The defect amount file 183 is generated by the defect amount calculation unit 130. However, the defect amount file 183 may be generated in advance without using the defect amount file 183.

Returning to FIG. 1, the description of the file storage unit 190 is continued.
For example, the file storage unit 190 stores a module list file 184, a work period file 185, and a changed work file 186.
Here, the module list file 184, the work period file 185, and the change work file 186 will be described.

FIG. 5 is a diagram illustrating an example of the module list file 184 according to the first embodiment.
The module list file 184 in the first embodiment will be described with reference to FIG.
The module list file 184 includes module identifiers of modules included in the software program.
The module list file 184 in FIG. 5 associates the file identifier of the source code file in which the source code of the module is described with the function identifier of the function used in the module, with the module identifier. The file identifier identifies the source code file. The function identifier identifies the function.
For example, the file identifier of the source code file of the position sensor reading module is SCfile001.
The position sensor reading module uses a readPosition function, a setParameter function, and a resetParameter function. The XXX function is a function identified by a function identifier “XXX”.

FIG. 6 is a diagram illustrating an example of the work period file 185 according to the first embodiment.
The work period file 185 in the first embodiment will be described with reference to FIG.
The work period file 185 indicates a work period for each version of the software program.
The work period file 185 in FIG. 6 associates a work period with a version identifier.
The version identifier identifies the version of the software program. Each time the software program is revised, the version identifier is updated.
The work period is a period required for the change work for changing the module included in the software program.
For example, the working period of the version of the software program identified by Ver 1.2 is three months from April 1, 2014 to July 31, 2014.

FIG. 7 is a diagram illustrating an example of the change work file 186 according to the first embodiment.
The change work file 186 according to the first embodiment will be described with reference to FIG.
The change work file 186 associates the module identifier of the changed module with the change work amount required for the change work in which the module was changed and work period selection information used for selecting the work period in which the change work was performed.
In the changed work file 186 in FIG. 7, the changed work identifier, the work period selection information, and the module identifier are associated with the changed work identifier. The change work identifier identifies the change work.
For example, the work period selection information indicates the date when the unit test of the module performed after the module change work is completed. The unit test is a test performed for each module. On the other hand, a test performed on a software program generated by combining a plurality of modules is called a combination test.
For example, the work period during which the change work for changing chattering prevention specifications is performed is three months from April 1, 2014 to July 31, 2014 in the work period shown in FIG. This work period is a work period immediately before August 17, 2014 indicated by the work period selection information for changing chattering prevention specifications shown in FIG.

Returning to FIG. 1, the description of the file storage unit 190 is continued.
For example, the file storage unit 190 stores a defect information file 187, a function coverage rate file 188, and a change history file 189.
Here, the defect information file 187, the function coverage rate file 188, and the change history file 189 will be described.

FIG. 8 is a diagram showing an example of the defect information file 187 in the first embodiment.
The defect information file 187 in the first embodiment will be described with reference to FIG.
The defect information file 187 associates a defect identifier that identifies a defect that has occurred with a module identifier that identifies the module in which the defect has occurred, with the date on which the defect has occurred.
For example, the defect information file 187 in FIG. 8 indicates that a problem of sensor error detection occurred on the position sensor reading module on August 2, 2014.

FIG. 9 is a diagram illustrating an example of the function coverage rate file 188 according to the first embodiment.
The function coverage rate file 188 in the first embodiment will be described with reference to FIG.
The function coverage rate file 188 associates function coverage rate data with a function identifier.
For example, the function coverage rate data includes a function instruction coverage rate, a function branch coverage rate, and a function condition coverage rate.
The instruction coverage of a function is the ratio of tested instruction sentences among the instruction sentences included in the function. C0 written in the column of the instruction coverage is a code meaning the instruction coverage.
The branch coverage rate of a function is the ratio of tested branch instruction statements among the branch instruction statements included in the function. A branch instruction statement is an instruction statement of a branch instruction. C1 written in the column of the branch coverage is a code meaning the branch coverage.
The condition coverage rate of a function is the ratio of the tested branch condition among the branch conditions included in the branch instruction statement included in the function. C2 written in the column of the condition coverage rate is a code meaning a conditional branch rate.
For example, the instruction coverage rate, branch coverage rate, and condition coverage rate of the readPosition function are 80%, 90%, and 70%.

FIG. 10 is a diagram illustrating an example of the change history file 189 according to the first embodiment.
The change history file 189 in the first embodiment will be described with reference to FIG.
The change history file 189 associates the file identifier of the source code file in which the module source code is described with the change date when the module source code is changed.
The change history file 189 in FIG. 10 indicates that the source code file SCfile001 has been changed on May 1, 2014. The source code file XXX is a source code file identified by a file identifier XXX.

Returning to FIG. 1, the description of the file storage unit 190 is continued.
For example, the file storage unit 190 stores a source code file group 180, a test necessity file 191 and a test necessity order file 199.
The source code file group 180 includes module source code files included in the software program. The source code files included in the source code file group 180 are identified by the version identifier of the software program and the module identifier of the module.
Here, the test necessity file 191 and the test necessity order file 199 will be described.

FIG. 11 is a diagram illustrating an example of the test necessity file 191 according to the first embodiment.
The test necessity file 191 in the first embodiment will be described with reference to FIG.
The test necessity file 191 includes a test necessity for each module included in the software program.
The test necessity file 191 in FIG. 11 associates the person-in-charge technical value, the change work density, the defect amount, the module coverage rate data, the change frequency, the change rate, and the test necessity with the module identifier.
The person-in-charge technical value is an index value representing the technical ability of the person in charge, and is calculated by the person-in-charge technical value calculation unit 110.
The changed work density is an index value representing the changed work amount per unit period, and is calculated by the changed work density calculation unit 120.
The defect amount is the amount of the defect amount that has occurred in the module, and is calculated by the defect amount calculation unit 130.
The module coverage ratio data includes a module instruction coverage ratio (C0), a module branch coverage ratio (C1), and a module condition coverage ratio (C2). The module coverage rate data is generated by the module coverage rate calculation unit 131.
The change frequency is the number of times the module source code file has been changed in the change target period, and is calculated by the change frequency calculation unit 132.
The change rate is the ratio of the source code that is different from the source code described in the previous source code file in the source code described in the current source code file, and is calculated by the change rate calculation unit 133.
The test necessity level is calculated by the test necessity level calculation unit 140 based on at least one index value of the person-in-charge technical value, change work density, defect amount, module coverage rate, change frequency, and change rate.

FIG. 12 is a diagram illustrating an example of the test necessity order file 199 according to the first embodiment.
An example of the test necessity order file 199 according to the first embodiment will be described with reference to FIG.
The test necessity order file 199 shows module identifiers in order of test necessity.
The test necessity order file 199 in FIG. 12 indicates that the test necessity is higher in the order of the movement control module, the warning display module, and the position sensor reading module.

Returning to FIG. 1, the description of the functional configuration of the software test support apparatus 100 will be continued.
The person-in-charge technical value calculation unit 110 selects a module identifier from the module person-in-charge file 182 for each person-in-charge identifier included in the person-in-charge list file 181.
The person-in-charge technical value calculation unit 110 selects a defect amount associated with the selected module identifier from the defect amount file 183.
The person-in-charge technical value calculation unit 110 calculates a person-in-charge technical value representing the technical ability of the person in charge based on the selected defect amount.
The person-in-charge technical value calculation unit 110 sets the calculated person-in-charge technical value in the test necessity file 191 in association with the same module identifier as the module identifier selected from the module charge file 182.

The changed work density calculation unit 120 selects a changed work amount and work period selection information from the changed work file 186 for each module identifier included in the module list file 184.
The changed work density calculation unit 120 selects a work period from the work period file 185 based on the selected work period selection information.
The changed work density calculation unit 120 calculates a changed work density representing the changed work amount per unit period based on the selected work period and the selected changed work amount.
The changed work density calculation unit 120 sets the calculated changed work density in the test necessity file 191 in association with the module identifier.

The defect amount calculation unit 130 is a defect that is the amount of a defect that has occurred in the module identified by the module identifier based on the number of module identifiers included in the defect information file 187 for each module identifier included in the module list file 184. Calculate the amount.
The defect amount calculation unit 130 sets the calculated defect amount in the test necessity file 191 in association with the module identifier.
The defect amount calculation unit 130 sets the defect amount in the defect amount file 183 in association with the module identifier.

The module coverage rate calculation unit 131 selects a function identifier from the module list file 184 for each module identifier included in the module list file 184.
The module coverage ratio calculation unit 131 selects function coverage ratio data associated with the same function identifier as the selected function identifier from the function coverage ratio file 188.
The module coverage ratio calculation unit 131 calculates a module instruction coverage ratio, a module branch coverage ratio, and a module condition coverage ratio based on the selected function coverage ratio data. The instruction coverage of a module is the ratio of tested instruction sentences out of the instruction sentences included in the module. The module branch coverage ratio is the ratio of tested instruction statements among the branch instruction statements included in the module. The module condition coverage ratio is the ratio of the tested branch condition among the branch conditions included in the branch instruction statement included in the module. For example, an instruction statement included in a module means an instruction statement included in a function used by the module, and a branch instruction statement included in the module means a branch instruction statement included in a function used by the module.
The module coverage ratio calculation unit 131 generates module coverage ratio data including a module instruction coverage ratio, a module branch coverage ratio, and a module condition coverage ratio.
The module coverage rate calculation unit 131 sets module coverage rate data in the test necessity file 191 in association with the module identifier.

The change frequency calculation unit 132 selects a file identifier from the module list file 184 for each module identifier included in the module list file 184.
The change frequency calculation unit 132 calculates the number of selected file identifiers associated with the change date within the change target period among the file identifiers included in the change history file 189 as the change frequency. The change target period is a predetermined period.
The change frequency calculation unit 132 sets the calculated change frequency in the test necessity file 191 in association with the module identifier.

The change rate calculation unit 133 selects a file identifier from the module list file 184 for each module identifier included in the module list file 184.
The change rate calculation unit 133 selects a current version identifier that is a version identifier of the current version of the software program and a previous version identifier that is a version identifier of the previous version of the software program from the work period file 185.
The change rate calculation unit 133 selects from the source code file group 180 a current source code file that is a source code file identified by the selected file identifier and the selected current version identifier.
The change rate calculation unit 133 selects from the source code file group 180 a previous source code file that is a source code file identified by the selected file identifier and the selected previous version identifier.
The change rate calculation unit 133 calculates a change rate, which is a ratio of the source code of a portion different from the source code described in the previous source code file among the source codes described in the current source code file.
The change rate calculation unit 133 sets the calculated change rate in the test necessity file 191 in association with the module identifier.

The test necessity degree calculation unit 140 tests at least one of the index values of the person-in-charge technical value, change work density, defect amount, module coverage rate data, change frequency, and change rate for each module identifier included in the module list file 184. Select from the necessity file 191.
The test necessity degree calculation unit 140 calculates a test necessity degree that represents an index of a test for a function realized by the module, using the selected index value.
The test necessity calculation unit 140 sets the calculated test necessity in the test necessity file 191 in association with the module identifier.
For example, the test necessity calculation unit 140 selects the person-in-charge technical value calculated by the person-in-charge technical value calculation unit 110 for each module identifier included in the module list file 184 from the test necessity degree file 191, and selects the person in charge Calculate the necessity of the test using the technical values.
For example, the test necessity calculation unit 140 selects the change work density calculated by the change work density calculation unit 120 for each module identifier included in the module list file 184 from the test necessity file 191, and selects the selected change work density. Use to calculate the test necessity.

  The test necessity order output unit 150 arranges the module identifiers included in the module list file 184 in the test necessity order, generates the test necessity order file 199, and outputs the test necessity order file 199.

*** Explanation of operation ***
FIG. 13 is a flowchart showing the operation of the software test support apparatus 100 according to the first embodiment.
The operation of software test support apparatus 100 in the first embodiment will be described with reference to FIG. However, the operation of the software test support apparatus 100 may not be the same as the operation described based on FIG. For example, the processing order may be changed. For example, a part of the processing may be deleted or a new processing may be added.

  In S101, the defect amount calculation unit 130 performs the following processing for each module identifier included in the module list file 184. In S101, one module identifier that is a processing target is referred to as a target module identifier. See FIG. 5 for the module list file 184.

The defect amount calculation unit 130 calculates the defect amount based on the number of target module identifiers included in the defect information file 187. See FIG. 8 for the defect information file 187.
For example, the defect amount calculated by the defect amount calculation unit 130 is the number of all target module identifiers included in the defect information file 187.
For example, the defect amount calculated by the defect amount calculation unit 130 is the number of target module identifiers associated with occurrence dates within the defect target period among the target module identifiers included in the defect information file 187. The defect target period is a predetermined period. For example, the defect target period is a certain period such as the past three months.

The defect amount calculation unit 130 sets the defect amount in the test necessity file 191 in association with the target module identifier. See FIG. 11 for the test necessity file 191.
The defect amount calculation unit 130 sets the defect amount in the defect amount file 183 in association with the target module identifier. See FIG. 4 for the defect amount file 183.
After S101, the process proceeds to S110.

  In step S <b> 110, the person-in-charge technical value calculation unit 110 performs the following process for each person-in-charge identifier included in the person-in-charge list file 181. In S110, one person identifier to be processed is referred to as a target person identifier. See FIG. 2 for the person-in-charge list file 181.

The person-in-charge technical value calculation unit 110 selects a module identifier associated with the target person-in-charge identifier from the module person in charge file 182. In S110, the selected module identifier is referred to as a target module identifier. In the module charge file 182 of FIG. 3, when the target person identifier is Kou, the target module identifier is a position sensor reading module and a warning display module.
The person-in-charge technical value calculation unit 110 selects a defect amount associated with the target module identifier from the defect amount file 183. In S110, the selected defect amount is referred to as a target defect amount. In the defect amount file 183 in FIG. 4, when the target module identifiers are the position sensor reading module and the warning display module, the target defect amounts are 10 and 6.
The person-in-charge technical value calculator 110 calculates a person-in-charge technical value based on the target defect amount. For example, the person-in-charge technical value is an average value or a total amount of the target defect amounts. When the target defect amounts are 10 and 6, the person-in-charge technical value that is the average value of the target defect amounts is 8.
The person-in-charge technical value calculation unit 110 sets the person-in-charge technical value in the test necessity file 191 in association with the target module identifier. See FIG. 11 for the test necessity file 191.
After S110, the process proceeds to S120.

  In S <b> 120, the changed work density calculation unit 120 performs the following process for each module identifier included in the module list file 184. In S120, one module identifier to be processed is referred to as a target module identifier.

The changed work density calculation unit 120 selects the changed work amount and work period selection information associated with the target module identifier from the changed work file 186. In S120, the selected changed work amount is called a target work amount, and the selected work period selection information is called target selection information. In the changed work file 186 of FIG. 7, when the target module identifier is a position sensor reading module, the target work amounts are 40 and 25, and the target selection information is August 17, 2014. When the target module identifier is a movement control module, the amount of change work associated with the movement control module is 15. However, this change work amount is associated with two module identifiers of the movement control module and the warning display module. Therefore, the target work amount is 7.5, which is a value obtained by dividing the changed work amount by the number of module identifiers. However, the change work amount does not have to be equally distributed to each module identifier.
The changed work density calculation unit 120 selects a work period from the work period file 185 based on the target selection information. In S120, the selected work period is referred to as a target work period. For example, the target work period is a work period immediately before the work date indicated by the target selection information. In the work period file 185 of FIG. 6, when the target selection information is August 17, 2014, the target work period is from April 1, 2014 to July 31, 2014.
The changed work density calculation unit 120 calculates the changed work density based on the target work period and the target work amount. For example, the changed work density is a total target work amount per month. When the target workload is 40 and 25, the total target workload is 65. When the target work period is 3 months, the changed work density, which is the total target work amount per month, is 22. This changed work density is a value obtained by dividing the target work amount by the target work period. However, the value after the decimal point is rounded up.
The changed work density calculation unit 120 sets the changed work density in the test necessity file 191 in association with the target module identifier. See FIG. 11 for the test necessity file 191.
After S120, the process proceeds to S131.

  In S131, the module coverage rate calculation unit 131 performs the following processing for each module identifier included in the module list file 184. In S131, one module identifier to be processed is referred to as a target module identifier.

The module coverage rate calculation unit 131 selects a function identifier associated with the target module identifier from the module list file 184. In S131, the function identifier selected is referred to as a target function identifier. In the module list file 184 of FIG. 5, when the target module identifier is a position sensor reading module, the target function identifiers are readPosition, setParameter, and resetParameter.
The module coverage ratio calculation unit 131 selects function coverage ratio data associated with the target function identifier from the function coverage ratio file 188. The function coverage rate data selected in S131 is referred to as target coverage rate data. In the function coverage rate file 188 of FIG. 9, when the target function identifier is readPosition, the instruction coverage rate of 80%, the branch coverage rate of 90%, and the condition coverage rate of 70% are the target coverage rate data.
The module coverage rate calculation unit 131 calculates the instruction coverage rate, branch coverage rate, and condition coverage rate included in the module coverage rate data based on the instruction coverage rate, branch coverage rate, and condition coverage rate included in the target coverage rate data. . For example, the instruction coverage ratio included in the module coverage ratio data is calculated by calculating an instruction coverage ratio calculation formula in which the instruction coverage ratio included in the target coverage ratio data is substituted. The instruction coverage ratio calculation formula is a calculation formula for calculating the instruction coverage ratio included in the module coverage ratio data. The instruction coverage ratio calculation formula includes an instruction coverage ratio variable in which the instruction coverage ratio included in the target coverage ratio data is substituted. The branch coverage rate and condition coverage rate included in the module coverage rate data are calculated by calculating a branch coverage rate calculation formula and a condition coverage rate calculation formula in the same manner as the instruction coverage rate included in the module coverage rate data. For example, if there are 12 branch instructions and 6 of them are being tested, the branch coverage is 50 percent.
The module coverage rate calculation unit 131 sets module coverage rate data in the test necessity file 191 in association with the target module identifier. See FIG. 11 for the test necessity file 191.
After S131, the process proceeds to S132.

  In S <b> 132, the change frequency calculation unit 132 performs the following process for each module identifier included in the module list file 184. In S132, one module identifier to be processed is referred to as a target module identifier.

The change frequency calculation unit 132 selects a file identifier associated with the target module identifier from the module list file 184. In S132, the selected file identifier is referred to as a target file identifier.
The change frequency calculation unit 132 calculates the number of target file identifiers associated with the change date within the change target period among the file identifiers included in the change history file 189 as the change frequency. The change target period is a predetermined period. For example, the change target period is a certain period such as the past three months.
The change frequency calculating unit 132 sets the change frequency in the test necessity file 191 in association with the target module identifier. See FIG. 11 for the test necessity file 191.
After S132, the process proceeds to S133.

  In S <b> 133, the change rate calculation unit 133 performs the following process for each module identifier included in the module list file 184. In S133, one module identifier to be processed is referred to as a target module identifier.

The change rate calculation unit 133 selects a file identifier associated with the target module identifier from the module list file 184. In S133, the selected file identifier is referred to as a target file identifier. In the module list file 184 of FIG. 5, when the target module identifier is a position sensor reading module, the target file identifier is SCfile001.
The change rate calculation unit 133 selects the version identifier of the current version of the software program and the version identifier of the previous version of the software program from the work period file 185. In S133, the version identifier of the current version is referred to as the current version identifier, and the version identifier of the previous version is referred to as the previous version identifier. In the work period file 185 of FIG. 6, the current version identifier is Ver1.2, and the previous version identifier is Ver1.1.
The change rate calculation unit 133 selects a current source code file that is a source code file identified by the target file identifier and the current version identifier from the source code file group 180.
The change rate calculation unit 133 selects from the source code file group 180 a previous source code file that is a source code file identified by the target file identifier and the previous version identifier.
The change rate calculation unit 133 calculates a change rate, which is a ratio of the source code of a portion different from the source code described in the previous source code file among the source codes described in the current source code file.
The change rate calculation unit 133 sets the change rate in the test necessity file 191 in association with the target module identifier. See FIG. 11 for the test necessity file 191.
After S133, the process proceeds to S140.

  In S140, the test necessity calculation unit 140 performs the following processing for each module identifier included in the module list file 184. In S140, one module identifier to be processed is referred to as a target module identifier.

  The test necessity calculation unit 140 selects from the test necessity file 191 index values such as a person-in-charge technical value, change work density, defect amount, module coverage rate data, change frequency, and change rate associated with the target module identifier. . However, the test necessity calculation unit 140 may select at least one of these index values. See FIG. 11 for the test necessity file 191. The index value selected in S140 is referred to as a target index value.

  The test necessity calculation unit 140 calculates the test necessity using the target index value. For example, the test necessity is calculated by calculating a test necessity calculation formula in which each target index value is substituted. The test necessity calculation formula is a calculation formula for calculating the test necessity, and includes an index value variable into which each target index value is substituted. The test necessity is a total value of the index values for weighting.

The test necessity calculation unit 140 calculates the following test necessity.
The lower the technician level, the higher the need for testing. A module developed by a person with low technical skills incorporates many problems and is considered to be prone to problems. Such modules require sufficient testing.
The higher the change work density, the higher the need for testing. The shorter the working time, the less consideration is required. And it is thought that the module which examination is insufficient has many malfunctions built in, and a malfunction is easy to generate | occur | produce. Such modules require sufficient testing.
The greater the amount of defects, the higher the need for testing. Modules that have had many problems so far have many problems built in, and it is likely that problems will continue to occur in the future. Such modules require sufficient testing.
The lower the coverage rate, the higher the need for testing. A module with a low coverage rate is considered to be prone to defects because defects have not been sufficiently removed. Such modules require sufficient testing.
The higher the frequency of change, the higher the need for testing. It is considered that a module with a high change frequency is likely to have many defects and is likely to cause defects. Such modules require sufficient testing.
The higher the change rate, the higher the need for testing. It is considered that a module with a high change rate is likely to incorporate many defects and easily generate defects. Such modules require sufficient testing.

The test necessity degree calculation unit 140 sets the test necessity degree in the test necessity degree file 191 in association with the target module identifier.
After S140, the process proceeds to S150.

In S150, the test necessity order output unit 150 generates the test necessity order file 199 by arranging the module identifiers in the test necessity order based on the test necessity for each module identifier included in the test necessity file 191 and requires the test. The order file 199 is output. For example, the test necessity order output unit 150 displays the test necessity order file 199 on the screen of the display device. See FIG. 12 for the file 199 in order of necessity.
After S150, the operation of the software test support apparatus 100 ends.

FIG. 14 is a hardware configuration diagram of the software test support apparatus 100 according to the first embodiment.
A hardware configuration of software test support apparatus 100 according to Embodiment 1 will be described with reference to FIG. However, the hardware configuration of the software test support apparatus 100 may not be the same as the configuration illustrated in FIG.

The software test support apparatus 100 is a computer including an arithmetic device 901, an auxiliary storage device 902, a main storage device 903, a communication device 904, and an input / output device 905.
The arithmetic device 901, auxiliary storage device 902, main storage device 903, communication device 904, and input / output device 905 are connected to the bus 909.

The arithmetic device 901 is a CPU (Central Processing Unit) that executes a program. For example, the arithmetic device 901 executes a software test support program that causes a computer to function as the software test support device 100.
The auxiliary storage device 902 is, for example, a ROM (Read Only Memory), a flash memory, or a hard disk device.
The main storage device 903 is, for example, a RAM (Random Access Memory).
The communication device 904 performs communication via the Internet, a LAN (local area network), a telephone line network, or other networks in a wired or wireless manner.
The input / output device 905 is, for example, a mouse, a keyboard, or a display device.

The program is stored in the auxiliary storage device 902.
For example, an operating system (OS) is stored in the auxiliary storage device 902. In addition, a program that realizes the function described as “˜unit” is stored in the auxiliary storage device 902.
The program is stored in the auxiliary storage device 902, loaded into the main storage device 903, read into the arithmetic device 901, and executed by the arithmetic device 901.

  Information, data, files, signal values, or variable values indicating processing results of processing such as determination, determination, extraction, detection, setting, registration, selection, generation, input, and output are stored in the main storage device 903 or the auxiliary storage device 902. Is done.

FIG. 15 is a configuration diagram of the software test support system 200 according to the first embodiment.
The configuration of the software test support system 200 according to Embodiment 1 will be described with reference to FIG. However, the configuration of the software test support system 200 may not be the same as the configuration shown in FIG.

The software test support system 200 includes a software test support device 100, a project management system 210, a software test system 220, a source code management system 230, a defect management system 240, and a work management system 250.
The software test support apparatus 100 included in the software test support system 200 and each system communicate via a network 209.

The project management system 210 is a computer system for managing a project for developing a software program.
The project management system 210 includes a project management storage unit 219 that stores a person-in-charge list file 181, a module person-in-charge file 182, a module list file 184, and a work period file 185.
The software test support apparatus 100 acquires each file stored in the project management storage unit 219 from the project management system 210.

The software test system 220 is a computer system for testing a software program. For example, the software test system 220 performs a unit test of a module or a function using a technology called JUnit. In addition, the software test system 220 generates function coverage rate data set in the function coverage rate file 188 by executing a conventional coverage acquisition program.
The software test system 220 includes a software test storage unit 229 that stores a function coverage rate file 188.
The software test support apparatus 100 acquires the function coverage rate file 188 stored in the software test storage unit 229 from the software test system 220.

The source code management system 230 is a computer system for managing the source code of the software program. For example, the source code management system 230 is configured by a system such as cvs, Subversion, or git.
The source code management system 230 includes a source code management storage unit 239 that stores a source code file group 180 and a change history file 189.
The software test support apparatus 100 acquires the source code file group 180 and the change history file 189 stored in the source code management storage unit 239 from the source code management system 230.

The defect management system 240 is a computer system for managing defects occurring in the software program. For example, the defect management system 240 manages information set in the defect information file 187 by executing a software program such as Redmine or Trac.
The defect management system 240 includes a defect management storage unit 249 that stores a defect information file 187.
The software test support apparatus 100 acquires the defect information file 187 stored in the defect management storage unit 249 from the defect management system 240.

The work management system 250 is a computer system for managing a change work for changing a software program.
The work management system 250 includes a work management storage unit 259 that stores the changed work file 186.
The software test support apparatus 100 acquires the changed work file 186 stored in the work management storage unit 259 from the work management system 250.

*** Explanation of effects ***
According to the first embodiment, for example, the following effects can be obtained.
The software test support apparatus 100 can calculate the test necessity for each module. Then, the tester performs a sufficient test on the function realized by the module having a high test necessity. Thereby, the regression test of a software program is performed efficiently.

Embodiment 2. FIG.
A description will be given of a mode in which the test necessity is updated using the test necessity history.
Hereinafter, items different from the first embodiment will be mainly described. Matters not described are the same as those in the first embodiment.

*** Explanation of configuration ***
FIG. 16 is a functional configuration diagram of the software test support apparatus 100 according to the second embodiment.
A functional configuration of the software test support apparatus 100 according to the second embodiment will be described with reference to FIG. However, the functional configuration of the software test support apparatus 100 may not be the same as the functional configuration illustrated in FIG.

The file storage unit 190 of the software test support apparatus 100 stores an index value file 192 and a test necessity history file 193 instead of the test necessity file 191 in the first embodiment.
Here, the index value file 192 and the test necessity history file 193 will be described.

FIG. 17 is a diagram illustrating an example of the index value file 192 according to the second embodiment.
As shown in FIG. 17, the index value file 192 is obtained by deleting the test necessity column from the test necessity file 191 according to the first embodiment. Refer to FIG. 11 for the test necessity file 191 in the first embodiment.

FIG. 18 is a diagram illustrating an example of the test necessity history file 193 according to the second embodiment.
The test necessity history file 193 in the second embodiment will be described with reference to FIG.
The test necessity history file 193 associates the previous necessity degree, which is the necessity degree of the test calculated last time, with the module identifier.
The test necessity history file 193 in FIG. 18 includes the Nth test necessity that is the currently calculated test necessity, and the (N-1) th test necessity that is the previously calculated test necessity. Are associated with module identifiers.

Returning to FIG. 16, the description of the software test support apparatus 100 will be continued.
The test necessity calculation unit 140 performs the following processing after calculating the test necessity.
The test necessity degree calculation unit 140 selects the previous necessity degree from the test necessity degree history file 193 for each module identifier included in the module list file 184.
The test necessity degree calculation unit 140 updates the current necessity degree based on the magnitude of the difference between the selected previous necessity degree and the current necessity degree calculated this time.
Other functional configurations of the software test support apparatus 100 are the same as those in the first embodiment.

*** Explanation of operation ***
FIG. 19 is a flowchart showing the operation of the software test support apparatus 100 according to the second embodiment.
The operation of the software test support apparatus 100 in the second embodiment will be described with reference to FIG. However, the operation of the software test support apparatus 100 may not be the same as the operation described based on FIG. For example, the processing order may be changed. For example, a part of the processing may be deleted or a new processing may be added.

The software test support apparatus 100 in the second embodiment executes S141, S142, and S151 instead of S140 and S150 in the first embodiment.
The processing from S101 to S133 is the same as that in the first embodiment.
Refer to FIG. 13 for the operation of the software test support apparatus 100 according to the first embodiment.

Here, S141, S142, and S151 will be described.
In S <b> 141, the test necessity calculation unit 140 performs the following process for each module identifier included in the module list file 184. In S141, one module identifier that is a processing target is referred to as a target module identifier.

The test necessity degree calculation unit 140 selects index values such as a person-in-charge technical value, a change work density, a defect amount, module coverage rate data, a change frequency, and a change rate associated with the target module identifier from the index value file 192. However, the test necessity calculation unit 140 may select at least one of these index values. See FIG. 17 for the index value file 192. The index value selected in S141 is referred to as a target index value.
The test necessity calculation unit 140 calculates the test necessity using the target index value. The method for calculating the test necessity is the same as S140 in the first embodiment.
The test necessity degree calculation unit 140 sets the test necessity degree in the test necessity degree history file 193 in association with the target module identifier. See FIG. 18 for the test necessity history file 193.
After S141, the process proceeds to S142.

  In S <b> 142, the test necessity level calculation unit 140 performs the following process for each module identifier included in the module list file 184. In S142, one module identifier to be processed is referred to as a target module identifier. Further, the test necessity calculated this time is referred to as the current necessity, and the test necessity calculated last time is referred to as the previous necessity.

  The test necessity degree calculation unit 140 selects the current necessity degree and the previous necessity degree associated with the target module identifier from the test necessity history file 193. The current necessity level selected in S142 is referred to as the target current necessity level, and the previous necessity level selected in S142 is referred to as the target previous necessity level.

The test necessity degree calculation unit 140 calculates a new current necessity degree using the target current necessity degree and the target previous necessity degree.
For example, the new current necessity degree is calculated by calculating a test necessity update formula in which the target current necessity degree and the target previous necessity degree are substituted. The test necessity update formula is a calculation formula for calculating a new test necessity. The test necessity update formula includes a current necessity variable to which the target current necessity is substituted and a previous necessity variable to which the target previous necessity is substituted. The new current necessity level is a value obtained by adding a correction value corresponding to the difference between the target current necessity level and the target previous necessity level to the target current necessity level.
The greater the increase in the subject's current need relative to the subject's previous need, the higher the test need. It is considered that a module with a large increase in the necessity of testing is likely to incorporate a new defect and easily generate a defect. Such modules require sufficient testing.

The test necessity calculation unit 140 updates the target current necessity included in the test necessity history file 193 to a new current necessity.
After S142, the process proceeds to S151.

In S151, the test necessity order output unit 150 generates the test necessity order file 199 by rearranging the module identifiers in the present necessity degree based on the present necessity degree for each module included in the test necessity history file 193. The test necessity order file 199 is output.
After S151, the operation of the software test support apparatus 100 ends.

  The configuration of the software test support system 200 in the second embodiment is the same as that in the first embodiment. Refer to FIG. 15 for the configuration of the software test support system 200 in the first embodiment and the second embodiment.

*** Explanation of effects ***
According to the second embodiment, the software test support apparatus 100 can update the test necessity using the history of the test necessity. As a result, a more appropriate test necessity is calculated.

Each embodiment is an example of the form of the software test support apparatus 100 and the software test support system 200.
That is, the software test support apparatus 100 and the software test support system 200 do not have to include some of the components described in the embodiments. Moreover, the software test support apparatus 100 and the software test support system 200 may include components that are not described in the embodiments.

  The processing procedures described using the flowcharts and the like in each embodiment are an example of the processing procedures of the method and the program according to each embodiment. The method and program according to each embodiment may be realized by a processing procedure partially different from the processing procedure described in each embodiment.

  In each embodiment, “to part” can be read as “to process”, “to process”, “to step”, “to program”, “to apparatus”, and the like.

  DESCRIPTION OF SYMBOLS 100 Software test support apparatus, 110 Person in charge technical value calculation part, 120 Change work density calculation part, 130 Defect amount calculation part, 131 Module coverage rate calculation part, 132 Change frequency calculation part, 133 Change rate calculation part, 140 Necessity of test Calculation unit, 150 test necessity order output unit, 180 source code file group, 181 responsible person list file, 182 module responsible file, 183 defect amount file, 184 module list file, 185 work period file, 186 modified work file, 187 defect Information file, 188 function coverage rate file, 189 change history file, 190 file storage unit, 191 test necessity file, 192 index value file, 193 test necessity history file, 199 test necessity order file, 2 0 software test support system, 209 network, 210 project management system, 219 project management storage unit, 220 software test system, 229 software test storage unit, 230 source code management system, 239 source code management storage unit, 240 defect management system, 249 Defect management storage unit, 250 work management system, 259 work management storage unit, 901 arithmetic device, 902 auxiliary storage device, 903 main storage device, 904 communication device, 905 input / output device, 909 bus.

Claims (8)

A person-in-charge list file including a person-in-charge identifier of a person in charge of developing at least one of the modules included in the software program; a module person-in-charge file that associates a person-in-charge identifier with the module identifier of the module included in the software program; A file storage unit that stores a defect amount file that associates a defect amount that is the amount of a defect that has occurred in a module with a module identifier;
For each person identifier included in the person-in-charge list file, a module identifier is selected from the module person-in-charge file, a defect amount associated with the selected module identifier is selected from the defect amount file, and based on the selected defect amount And a software test support apparatus comprising a person-in-charge technical value calculating unit that calculates a person-in-charge technical value representing the technical ability of the person in charge. The file storage unit stores a module list file including a module identifier,
The person-in-charge technical value calculated by the person-in-charge technical value calculation unit is selected for each module identifier included in the module list file, and a test of the function realized by the module is performed using the selected person-in-charge technical value. The software test support apparatus according to claim 1, further comprising a test necessity degree calculation unit that calculates a test necessity degree representing a degree of necessity of execution. The file storage unit includes a work period file indicating a work period for each version of the software program, a change work amount required for a change work in which a module is changed to a module identifier of the changed module, and a work in which the change work is performed. Storing a change work file that associates work period selection information used for selecting a period;
The software test support device includes:
For each module identifier included in the module list file, a changed work amount and work period selection information are selected from the changed work file, a work period is selected from the work period file based on the selected work period selection information, and selected. A change work density calculation unit that calculates a change work density representing a change work amount per unit period based on the changed work period and the selected change work amount;
The software test support apparatus according to claim 2, wherein the test necessity calculation unit calculates the test necessity using the changed work density and the person-in-charge technical value for each module identifier included in the module list file. . The file storage unit stores a test necessity history file for associating a previous need that is a test need calculated last time with a module identifier,
The test necessity degree calculation unit selects the previous necessity degree from the test necessity degree history file for each module identifier included in the module list file, and the present necessity degree that is the selected previous necessity degree and the currently calculated test necessity degree. The software test support apparatus according to claim 2, wherein the current necessity level is updated based on a magnitude of a difference from the software test. A module list file including module identifiers of modules included in the software program, a work period file indicating a work period for each version of the software program, and a change required for the change work for changing the module to the module identifier of the changed module A file storage unit that stores a changed work file that associates the work amount with work period selection information used for selecting a work period in which the changed work has been performed;
For each module identifier included in the module list file, a changed work amount and work period selection information are selected from the changed work file, a work period is selected from the work period file based on the selected work period selection information, and selected. A software test support apparatus comprising: a changed work density calculating unit that calculates a changed work density representing a changed work amount per unit period based on the changed work period and the selected changed work amount. It is necessary to select a changed work density calculated by the changed work density calculation unit for each module identifier included in the module list file, and to perform a test on a function realized by the module using the selected changed work density. The software test support apparatus according to claim 5, further comprising a test necessity degree calculation unit that calculates a test necessity degree representing a certain degree. A software testing support program that uses a person-in-charge list file, a module person-in-charge file, and a defect amount file,
The person-in-charge list file is a file including a person-in-charge identifier of a person in charge of developing at least one of the modules included in the software program,
The module responsible file is a file that associates a responsible person identifier with a module identifier of a module included in the software program,
The defect amount file is a file that associates a defect amount that is the amount of a defect that has occurred in a module with a module identifier;
For each person identifier included in the person-in-charge list file, a module identifier is selected from the module person-in-charge file, a defect amount associated with the selected module identifier is selected from the defect amount file, and based on the selected defect amount A software test support program for causing a computer to function as a person-in-charge technical value calculation unit that calculates a person-in-charge technical value representing the technical ability of the person in charge. A software test support program that uses a module list file, a work period file, and a change work file,
The module list file is a file including a module identifier of a module included in a software program,
The work period file is a file indicating a work period for each version of the software program,
The change work file is a file that associates the change work amount required for the change work that changed the module with the module identifier of the changed module and the work period selection information used for selecting the work period in which the change work was performed,
For each module identifier included in the module list file, a changed work amount and work period selection information are selected from the changed work file, a work period is selected from the work period file based on the selected work period selection information, and selected. A software test support program for causing a computer to function as a changed work density calculation unit that calculates a changed work density representing a changed work amount per unit period based on the changed work period and the selected changed work amount.

Images