JP2013142967A - Related test item presentation device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To select a test item to be preferentially executed, and efficiently check a failure correction and find degradation in a short time without being affected by a degree of skill of a person in charge of the test.SOLUTION: A related test item presentation device includes generation means, calculation means, and extraction means. The generation means generates test result change data that have information representing a change/non-change in a test result obtained by executing a test of software of each version for one test item from test result data that include test results as execution results of test items, the test items thereof and information representing a version of an object subject to the execution of the test item. The calculation means calculates similarity among the test items on the basis of the test result change data. The extraction means extracts a related test item on the basis of the similarity.

Description

  The embodiment described in the present specification relates to a related test item presentation device.

  In recent years, software has rapidly increased in scale and complexity as products have higher performance and functionality. As a result, the number of test items to be performed to confirm the quality of software has increased, and the number of man-hours for testing has increased.

  On the other hand, shortening the development period has become an important issue since product release to the market in a short period is required.

  In order to ensure the quality of software in a short period of time, it is required to efficiently find defects that exist in software, and the importance of selecting test items is increasing.

JP 2007-102475 A JP 2001-160955 A

  However, due to the shortening of the development period, it is difficult to repeatedly carry out all of the huge test items at each regression test. In order to conduct regression tests efficiently, it is necessary to select the test items that should be prioritized accurately, and to quickly confirm defect corrections and find degradations. Based on the intuition and experience, test items related to important functions, test items related to functions that have recently occurred frequently, test items that may be related to changes, and so far Test items that should not be executed are selected with priority, and high skills are required to accurately select test items that should be executed with priority.

  The present invention is capable of selecting test items to be preferentially performed regardless of the level of proficiency of the person in charge of the test, and efficiently performing defect correction confirmation and degradation discovery even in a short period of time. The purpose is to provide.

  According to one embodiment, a related test item presentation device is proposed. The related test item presentation device includes a generation unit, a calculation unit, and an extraction unit. The generation means implemented one test item on each version of software from the test result that is the result of executing the test item and the test result data having information indicating the test item and the version of the test item to be executed. Test result change data having information indicating whether or not the test result has changed is generated. The calculation means calculates the similarity between the test items based on the test result change data. The extracting means extracts related test items based on the similarity.

The figure which shows the example of the change pattern which considers that the test result of the plural test items changed with the same timing Another diagram showing an example of a change pattern that captures that the test results of multiple test items have changed at the same timing Diagram showing examples of relations between test items, functions, modules, and source code The figure which shows the example of the relation of the test item, function, module and source code after FIG. Still another diagram showing an example of a change pattern that captures that the test results of multiple test items have changed at the same timing Diagram showing examples of relations between test items, functions, modules, and source code The figure which shows the example of the relationship of the test item after FIG. 6, a function, a module, and a source code (A) is a diagram showing a change pattern not treated as the same timing change pattern, (B) is a diagram showing another change pattern not treated as the same timing change pattern, (C) is not treated as the same timing change pattern, Diagram showing yet another change pattern Figure showing an example of test result change data The block diagram which shows the structural example of a related test item presentation apparatus The figure which shows the data structural example of the record of test item data An example of the data structure of a record of test result data is shown Flow chart showing an example of related test item presentation processing Diagram showing an example of test result data Diagram showing an example of the data structure of test result aggregated data The figure which shows the example for demonstrating the process which produces | generates test result change data from test result integrated data The figure which shows the example of the test result change data produced | generated from the test result integrated data of FIG. The figure which shows the example of similarity data between items The figure which shows the example of a screen displayed by the related test item display part The figure which shows the example of a screen which changes after a test item is selected in the screen of FIG. The figure which shows the example of similarity data between items The figure which displayed the numerical value which met the standard extracted by Method 1 with bold underline in the similar data between items The figure which shows the example of a screen which changes after a test item is selected in the screen of FIG.

Hereinafter, an example of a related test item presentation device according to an embodiment of the present invention will be described with reference to the accompanying drawings.
[0. Definition of terms]
First, definitions of terms used in this embodiment will be described.
[0.1. test]
“Test” refers to an operation for confirming whether or not the implemented source code operates according to the specification in software development.
[0.2. failure]
“Fail” means that, as a result of the test, the operation result does not become the result expected by the test.
[0.3. Passed]
“Pass” means that as a result of the test, the operation result is the expected result.
[0.4. defect]
“Defect” refers to an error in the source code. “Bugs” are also included in “defects”.
[0.5. Defect]
“Bad” is a phenomenon where software does not operate as expected.
[0.6. Degrade]
“Degrade” means that a test item that has already passed the test is rejected when it is tested again after a software change.
[0.7. Test item]
“Test item” means a unit of test execution. When the “test item” is determined, the specific content of the test to be executed is determined. In one test item, check points, execution procedures, expected values, etc. are recorded. In the present specification, “execution (execution) of a test item” refers to executing a test having contents defined in the test item.
[0.8. test results]
“Test result” refers to a record indicating pass or fail when a test item is executed. The test result is either pass or fail, and other information such as date and version is recorded at the same time.
[0.9. version]
The “version” is an attribute that associates the software to be tested with the test result, and is information that makes it possible to identify how many times the software has been revised / updated. . Based on the version, it is possible to understand which configuration is being tested. Software build numbers (numbers), configuration management system revision numbers, tags attached to each milestone (β version or RC version), etc. are used as versions.
[0.10. Regression Test (Regression Test)]
“Regression test” refers to a test that is performed to confirm whether or not an unexpected influence is manifested by the change when the program is changed. By removing the defect in the source code, check whether a new defect is embedded instead.

[1. Overview]
The outline of the present embodiment will be described below.
In the present embodiment, a test item (related test item) that is highly likely to be related to a test item (execution test item) to be executed in the regression test is extracted from a plurality of registered test items, The related test item is output as a test item to be executed with priority over other registered test items.

  The related test item is a test item that is assumed to be a test item that may be affected by the change of the source code and the test result may change simultaneously with the execution test item.

This related test item presentation device is based on the historical data of a series of test results, and related test items that have changed in the past at the same timing (change of test target version) as the test items to be executed. Extract as an item.
If the test result changes from pass to fail or fail to pass, it means that the test result is affected by the change in the source code.

[1.1. Change pattern of test results of multiple test items]
In the following, a change pattern (referred to as “same timing change pattern”) that is considered to have changed the test results of a plurality of test items at the same timing in the present embodiment will be described. The timing change pattern is basic information for calculating whether or not the test items are related test items.

[1.1.1. Change pattern (1)]
In the present embodiment, the first of the same timing change pattern is a case where the test results of the two test items simultaneously change from fail to pass, or change from pass to fail. 1 and 2 show examples of the change pattern (1). In the example of FIG. 1, the test result when test item A is executed for version V0.1 is “× (failed)”, and the test is performed for version V0.2, which is the next version of version V0.1. While the test result is “○ (pass)”, the test result when test item B is executed for version V0.1 is “× (fail)”, which is the next version of version V0.1 The test result when implemented for version V0.2 is “◯ (pass)”. FIG. 2 shows the reverse pattern of FIG.

  The relationship between test items, functions, modules, and source code when the above same timing change pattern occurs will be described. FIG. 3 is a diagram illustrating an example of the relationship between test items, functions, modules, and source codes.

  In this example, there is a function A, a function B, and a function C for a certain version of software, and test items A, test items B, and test items that are test items for verifying the functions A, B, and C. There is C.

  Modules 1 and 2 are used as modules for realizing the function A. Modules 2 and 3 are used as modules for realizing the function B, and they are used for realizing the function C. There are a module 4 and a module 5 as modules to be performed. Module 2 is a module common to function A and function B.

  Each module is composed of one or a plurality of submodules. Module 1 is composed of a submodule corresponding to source code a and a submodule corresponding to source code b. The module 2 includes a submodule corresponding to the source code c, a submodule corresponding to the source code d, and a submodule corresponding to the source code e. The module 3 includes a sub module corresponding to the source code e and a sub module corresponding to the source code f. The module 4 includes a sub module corresponding to the source code g and a sub module corresponding to the source code h. The module 5 includes a submodule corresponding to the source code i and a submodule corresponding to the source code j. In the present specification, description will be made using source code corresponding to a submodule instead of the submodule for convenience of explanation.

As a result of the test item A, test item B, and test item C being executed for this software, the function A has a defect and the test item A has failed, and the function B has a defect and the test item B The test result of the test item C was rejected, the function C was not defective, and the test result of the test item C was passed.
Here, it is assumed that the cause of the malfunction of the function A and the function B is in the module 2 and the source code c is defective.

Next, it is assumed that the next version of the software in which the defect of the source code c is corrected is created. As a result of test item A, test item B, and test item C being executed for the next version of this software, there is no defect for function A and the test result for test item A is passed. The test result passed, and there was no defect for function C, and the test result for test item C also passed. Such a state is shown in FIG.
The example shown in FIGS. 3 and 4 corresponds to the same timing change pattern shown in FIG.

[1.1.2. Pattern (2)]
In the present embodiment, the second of the same timing change pattern is the case where the test result of another test item changes from pass to fail at the timing when the test result of one test item changes from fail to pass. . FIG. 5 shows an example of the change pattern (2). In this example, the test result when test item A is executed for version V0.1 is “× (failed)”, and the test result when test item A is executed for version V0.2, which is the next version of version V0.1. The test result when test item B is executed for version V0.1 is “○ (failed)”, while version “V0” is the next version of version V0.1. The test result when implemented for 2 is “× (pass)”.

  The relationship between test items, functions, modules, and source code when the above same timing change pattern occurs will be described. FIG. 6 is a diagram showing an example of the relationship between test items, functions, modules, and source codes, and the test items, functions, modules, and source codes constituting the software are the examples shown in FIGS. 3 and 4 described above. It is the same.

As a result of test item A, test item B, and test item C being executed for this software, there was a problem with function A and the test result of test item A was rejected. The test result of B passed, and there was no defect for function C, and the test result of test item C passed.
Here, it is assumed that the cause of the malfunction of the function A is the module 2 and that the source code c is defective. However, this defect did not affect the function B.

  Next, it is assumed that the next version of the software in which the defect of the source code c is corrected is created. However, as a result of correcting the defect of the source code c, another new “defect” is inherent in the source code c, and this new defect affects the function B.

When test item A, test item B, and test item C are executed for the next version of this software, there is no defect for function A, the test result for test item A is passed, and there is a defect for function B, the test result for test item B Failed, and there was no defect for function C, and the test result for test item C was passed. Such a state is shown in FIG.
The example shown in FIGS. 6 and 7 corresponds to the same timing change pattern shown in FIG.

[1.1.3. It cannot be considered that it has changed at the same time]
A pattern that cannot be regarded as having changed at the same timing will be described. In the case where the test result of only one test item changes and the test result of the other test item does not change, this embodiment does not handle the same timing change pattern. FIG. 8 shows a change pattern that is not treated as the same timing change pattern. FIGS. 8A and 8B are change patterns in which only the test result of one test item changes and the test result of the other test item does not change. This change pattern is not treated as the same timing change pattern. FIG. 8C shows a pattern in which the test result does not change for any test item. Of course, this is not treated as the same timing change pattern.

[1.2. Data for extracting related test items]
In the present embodiment, data indicating whether or not the same timing change pattern has occurred for two test items is generated, and based on this data, it is determined whether or not it is a related test item. A vector representing a history of changes in test results is used as data indicating whether or not the same timing change pattern has occurred for two test items. The dimension of this vector is the number of times the source code has been modified. For example, if some software was originally version 1 modified to version 2 and version 2 modified to version 3, it was modified twice, so the vector dimension was “2” is there. The vector element (component) is information indicating whether or not the test result has changed. Here, when there is a change in the test result, the value of the element is described as “1”, and when there is no change in the test result, the value of the element is described as “0”. Needless to say, the information indicating the presence / absence of change may be any information as long as it can be distinguished.

  The order of vector elements is a sequence of source code modifications arranged in time series. For example, using the example of the above two-dimensional vector, the first element of the two-dimensional vector is whether or not there is a change between the test result of version 1 and the test result of version 2 for a test item. The presence / absence of a change between the test result of version 2 and the test result of version 3 for a test item is set as the second element of the two-dimensional vector.

  The order of the vector elements is preferably the order in which the source code corrections (version changes) are arranged in time series, but the present embodiment can also be configured as an arrangement in other orders.

  Test result change data, which is data for extracting related test items, is generated by creating the above vector for each test item. An example of test result change data is shown in FIG. In this example, the software to be tested is corrected four times in order of version v0.4, version v0.5, version v0.6, version v0.7, and version v0.8.

  The test items from which the related test items are extracted are test item 1 (test ID: 1), test item 2 (test ID: 2), test item 3 (test ID: 3), test item 4 (test ID: 4). ) And five test items 5 (test ID: 5). The vector corresponding to each test item is the first element corresponding to the presence / absence of changes in the test results between version v0.4 and version v0.5, and the presence / absence of changes in the test results between version v0.5 and version v0.6 The second element corresponding to, the third element corresponding to the presence or absence of the change of the test result between version v0.6 and version v0.7, corresponding to the presence or absence of the change of the test result between version v0.7 and version v0.8 And has a fourth element.

  In the present embodiment, if the values of the same element in any two vectors included in the test result change data, which is the data for extracting related test items, indicate that the test result has changed, the two vectors It is determined that the same timing change pattern exists in the test item corresponding to.

  For example, both the test item 1 and the test item 2 in FIG. 9 have the same timing change pattern in the second element. On the other hand, the test item 1 and the test item 4 do not have the same timing change pattern in any element. Therefore, it can be determined that test item 2 can be a related test item for test item 1, but test item 4 cannot be a related test item for test item 1.

[2. First Embodiment]
[2.1. Device configuration example]
A configuration example of the related test item presentation device according to the first embodiment will be described.
The related test item presentation device is a device realized by an information processing device such as a computer or a workstation. The information processing apparatus includes an arithmetic processing unit (CPU), a main memory (RAM), a read-only memory (ROM), an input / output device (I / O), and, if necessary, an external storage device such as a hard disk device. It is a device.

  FIG. 10 is a block diagram illustrating a configuration example of the related test item presentation device. The related test item presentation device 1 includes a data storage unit 10, a test result change data generation unit 20, a similarity calculation unit 30, a related test item extraction unit 40, a related test item display unit 50, and an input unit 60. have. In addition, these components are the functions of the related test item presentation device 1 that are grouped for each function and regarded as a block. The related test item presentation device 1 includes modules, devices, circuits, components, and the like corresponding to the respective components. It does not mean that it is equipped.

  The data storage unit 10 is connected to the test result change data generation unit 20. The test result change data generation unit 20 is connected to the similarity calculation unit 30. The similarity calculation unit 30 is connected to the related test item extraction unit 40. The related test item extraction unit 40 is connected to the related test item display unit 50. The input unit 60 is connected to the related test item extraction unit 40.

  Here, “connected” means that data, information, commands, etc. can be transmitted and received, and is in a meaning limited to physical connections that are connected by wiring. Absent.

  The data storage unit 10 has a function of storing data necessary for extracting related test items. In the present embodiment, the data storage unit 10 stores test item data and test result data.

[Test item data]
The test item data is data configured by collecting a plurality of records for storing information for identifying each of the plurality of test items (in this embodiment, a test ID) and other information. FIG. 11 shows a data configuration example of the test item data record. Each record includes a test ID field 1100 for storing a test ID, a folder ID storage field 1101 for storing a folder ID, a title storage field 1102 for storing a title, a priority storage field 1103 for storing a priority, A checkpoint storage field 1104 for storing checkpoints, a test method storage field 1105 for storing test methods, a success condition storage field 1106 for storing success conditions, a test environment storage field 1107 for storing test environments, and tags A tag storage field 1108 for storing, a special item storage field 1109 for storing special items, a registration date storage field 1110 for storing registration dates, an update date storage field 1111 for storing update dates, and attached files And a file attachment storage field 1112 for storing a path indicating a storage location.

“Test ID” is information for uniquely specifying a test item, and is, for example, a uniquely determined number.
“Folder ID” is information indicating a storage location of a test item.
“Title” is a character string indicating the test item.
“Priority” is information indicating the level of necessity of executing the test item.
“Checkpoint” is a description of the intention of the test item and the point to be confirmed.
“Test method” is a description of a test execution method.
The “success condition” is a condition necessary for determining that the test result of the test item is successful.
“Test environment” is a specification of equipment, software, etc. that should be satisfied when the test item is executed.
The “tag” is information for searching for the test item.
The “special notes” are information such as special comments and points to be noted regarding the test item.
“Registration date” is the date when this test item record was registered.
“Update date” is the date when this test item record was updated.
The “attached file” is an explanatory material regarding the test item.

(Test result data)
The test result data 1400 is data configured by collecting a plurality of records for storing information (test result ID in the present embodiment) for specifying a test result and other information. FIG. 12 shows a data configuration example of a record of test result data. Each record includes a test result ID storage field 1200 for storing a test result ID, a test ID storage field 1201 for storing a test ID, a pass / fail storage field 1202 for storing information indicating pass / fail, and a result for storing result details. A detail storage field 203, a defect information storage field 1204 for storing defect information, an execution date storage field 1205 for storing an execution date, a version storage field 1206 for storing a version, a charge storage field 1207 for storing a charge, It has a model storage field 1208 for storing a model, a man-hour storage field 1209 for storing a man-hour, a schedule name storage field 1210 for storing a schedule name, and an attachment file storage field 1211 for storing an attachment file.

“Test result ID” is information for uniquely specifying a result when a test item is executed.
“Test ID” is information for uniquely identifying a test item, and is associated with a test ID used for the test item record.
“Pass / fail” is information indicating whether the test result is pass or fail.
“Result details” is information describing the detailed contents of the test results.
The “defect information” is information describing a defect found with the test result.
“Implementation date” is the date when the test item was executed.
“Version” is information indicating a software (including source code) version to be tested.
“Person in charge” is information indicating a person in charge who executed the test item.
“Model” is information that identifies the type of device on which the test item was executed.
“Man-hour” is information indicating the time required to execute the test item.
The “schedule name” is information for specifying the test execution schedule to which the test result information belongs when the test execution schedule for separately managing the execution period and the person in charge is used for each test item.
“Attached file” is an explanatory document related to the test result.

  The test result change data generation unit 20 has a function of generating test result change data which is information describing whether or not there is a change in the test result for each version for each test item. The test result change data generation unit 20 corresponds to a generation unit.

  The similarity calculation unit 30 has a function of calculating the similarity between test items based on the test result change data. The similarity calculation unit 30 corresponds to a calculation unit.

  The related test item extraction unit 40 has a function of extracting related test items of the specified test item based on the similarity between the test items. The related test item extraction unit 40 corresponds to extraction means.

  The related test item display unit 50 has a function of presenting the extracted related test items to the user. The presentation method may be paper printout, image display by a liquid crystal display device, or other forms of presentation.

  The input unit 60 has a function of transmitting information indicating the test item selected by the user to the related test item extraction unit 40, and is, for example, a pointing device, a keyboard, a touch panel, or the like.

[2.2. Example of operation]
Next, an operation example of the related test item presentation device 1 will be described. FIG. 13 is a flowchart showing an example of related test item presentation processing which is the main operation of the related test item presentation device 1.

  First, test result data is stored in advance in the data storage unit 10 of the related test item presentation device 1. The test result data is taken in from another system or apparatus or input by an operator.

  When the related test item presentation process is started, the related test item presentation device 1, more specifically, the test result change data generation unit 20 reads the test result data from the data storage unit 10 (S10). FIG. 14 shows an example of test result data. The test result data 1400 is data having one record 1401 for one test result. Each record 1401 includes a test result ID storage field 1411 for storing a test result ID, which is information for specifying a test result, a test ID storage field 1412 for storing a test ID, which is information for specifying a test item, and a test result. A test result storage field 1413 that is information indicating whether the test is successful or not, a version storage field 1414 that stores information indicating the version of the software to be tested, and a test item that is executed and tested And an implementation date storage field 1415 in which information indicating the date when the result is obtained is stored.

  Next, the related test item presentation device 1, more specifically, the test result change data generation unit 20, from the test result data, the test result aggregate data that is information storing the test result for each version of each test item. Is generated (S20). FIG. 15 shows a data configuration example of the test result aggregated data. The test result consolidated data 1500 is data having one record 1501 for one test item. Each record 1501 includes a test ID storage field 1511 for storing a test ID corresponding to the test item, a first test result storage field 1512 for storing a test result of the test item for each version, and a second test result storage field 1513. , A third test result storage field 1514, a fourth test result storage field 1515, and a fifth test result storage field 1516. The related test item presentation device 1, more specifically, the test result change data generation unit 20, refers to the test result data 1400, and includes a first test result storage field 1512, a second test result storage field 1513, and a third test result storage field 1514. In the fourth test result storage field 1515 and the fifth test result storage field 1516, information indicating the test result is stored.

  For example, the related test item presentation device 1, more specifically, the test result change data generation unit 20 reads the first record of the test result data 1400 (the record immediately below the title line of the table in the figure). The first record describes that when the test item corresponding to the test ID 1 is executed for version v0.4, the test result is acceptable. The related test item presentation device 1, more specifically, the test result change data generation unit 20, records that test ID = 1 is stored in the test ID storage field 1511 of the test result aggregated data 1500 (in FIG. Information indicating “pass” is stored in the first test result storage field 1512 corresponding to the version v0.4 of the record. In the illustrated example, the pass is described as a symbol “◯” and the failure is described as a symbol “x”. Similarly, each record of the test result data 1400 is read, information indicating pass or fail is described in the corresponding test result storage field of the corresponding test result aggregated data 1500, and all the records of the test result data 1400 are recorded. The generation of the test result aggregated data 1500 is completed in the same manner.

[When there are multiple test results for the same test item and version]
If multiple test results exist for the same test item and the same version, an example of how to write test results in the test result aggregated data is as follows. If all the test results pass, the test results for that version Is described as “pass”, and even if one of the test results fails, there is a possible method to set the test result of that version to “fail”. When there are a plurality of test results for the same test item and the same version using the processing method, pass / fail of the test result in the relevant version may be determined.

  Next, the related test item presentation device 1, more specifically, the test result change data generation unit 20, generates test result change data, which is information composed of vectors representing a history of changes in test results, from the test result aggregated data 1500. Generate.

FIG. 16 is a diagram illustrating an example for explaining a process of generating test result change data from the test result aggregated data 1500.
The related test item presentation device 1, more specifically, the test result change data generation unit 20 compares the test results stored in the adjacent test result storage fields 1512 to 1516 of the test result aggregated data 1500. If they are the same (passed or rejected), the information indicating no change (for example, “0”), if different (one pass, the other fail), information indicating the change. For example, “1” is written in the corresponding field of the corresponding record of the test result change data.

  In FIG. 16, a symbol “arrow” is added between adjacent fields where there is a change. The related test item presentation device 1, more specifically, the test result change data generation unit 20, determines that there is a change in the test result between versions corresponding to the adjacent fields with arrows. FIG. 17 is a diagram illustrating an example of test result change data 1700 generated from the test result aggregated data 1500 of FIG.

  For example, the related test item presentation device 1, more specifically, the test result change data generation unit 20 sets the test ID 1 of the test result change data 1700 based on the content of the first record corresponding to the test ID 1 of the test result aggregated data 1500. When writing information indicating the change in the test result in the corresponding record, the test result of version v0.4 and the test result of the next version v0.5 are “○”, so it corresponds to the test ID 1 of the test result change data. Information indicating changes in test results of versions v0.4 and v0.5 in the record is information “0” indicating no change. Next, the related test item presentation device 1, more specifically, the test result change data generation unit 20, the test result of the version v0.5 and the test result of the next version v0.6 are “O” and “X”. Information indicating the test result change of the versions v0.5 and v0.6 in the record corresponding to the test ID 1 of the test result change data 1700 is information “1” indicating that there is a change. Next, the related test item presentation device 1, more specifically, the test result change data generation unit 20, since the test result of version v0.6 and the test result of the next version v0.7 are “x”, the test result change Information indicating the test result change of the versions v0.6 and v0.7 in the record corresponding to the test ID 1 of the data 1700 is set to information “0” indicating “no change”. Next, the related test item presentation device 1, more specifically, the test result change data generation unit 20, the test result of version v0.7 and the test result of the next version v0.8 are “×” and “O”. Information indicating the test result change of the versions v0.7 and v0.8 in the record corresponding to the test ID 1 of the test result change data 1700 is information “1” indicating “changed”.

  Thus, the description of the record in the first line of the test result change data shown in FIG. 17 is completed. Similarly, the generation of the test result change data is completed when the records after the second line of the test result change data are described.

  The test result change data 1700 has the same data structure as the test result change data in FIG.

  Next, the related test item presentation device 1, more specifically, the similarity calculation unit 30 calculates the similarity between the test items based on the test result change data (S40). “Similarity” is information indicating a high or low possibility that a test result is changed simultaneously with a test item to be performed under the influence of a change in source code.

  In the present embodiment, it is determined that the degree of similarity is higher for the two test items as the number of the above-described simultaneous timing change patterns increases.

  FIG. 18 shows an example of item-to-item similarity data, which is data describing the degree of similarity between test items calculated by the related test item presentation device 1, more specifically, the similarity calculation unit 30. The inter-item similarity data 1800 has one record 1801 for each test item, and the record 1801 has a test ID storage field 1811 for storing a test ID, and a similarity storage field for each test item as a counterpart. . In this example, five similarity storage fields 1812 to 1816 corresponding to test item 1 to test item 5 are included.

  In the present embodiment, the number of the same timing change patterns existing between two test items is used as the similarity. The related test item presentation device 1, more specifically, the similarity calculation unit 30 calculates the number of the same timing change patterns existing between the two test items for all combinations of the two test items based on the test result change data 1700. It counts and it describes in the similarity data 1800 between items as a similarity.

  Next, the related test item presentation device 1, more specifically, the related test item extraction unit 40, extracts a related test item for a reference test item based on the inter-item similarity data 1800 (S 50).

  For example, based on the inter-item similarity data 1800 shown in FIG. 18, when the test item 1 (test ID: 1) is used as a reference test item, the test item 3 (test ID) having a similarity of “2” : 3), and the test item 2 (test ID: 2) and the test item 5 (test ID: 5) having a similarity of “1” are represented by the related test item presentation device 1, more specifically, the related test. The item extraction unit 40 extracts. However, it is possible to freely set the magnitude of the similarity value to be extracted as the related test item. For example, in this example, only the test item having the similarity degree of “2” or more is set. The test items may be extracted as related test items. In this case, only the test item 3 whose similarity is calculated as “2” is extracted as the related test item for the test item 1 as a reference.

Next, the related test item presentation device 1, more specifically, the related test item display unit 50 displays or outputs the related test items extracted by the related test item extraction unit 40 (S60). FIG. 19 is an example of a screen displayed by the related test item display unit 50. This screen is a user interface that allows the user to select a standard test item. When the user selects any test item with a pointing device or a keyboard, the check box next to the test item is turned on, and the related test item extraction unit 40 extracts related test items for the selected test item. FIG. 20 is an example of a screen that transitions after a test item is selected on the screen of FIG. 19, and related test items for a reference test item are displayed in an area 2001 for displaying related test items.
Thus, the related test item presentation device 1 ends the related test item presentation process.

  When executing the selected test item, the user can immediately consider performing the related test item displayed in the area 2001 without depending on intuition or experience.

[3. Second Embodiment]
The second implementation will be described. The second embodiment calculates the cosine similarity of vectors indicating changes in test results of two test items, and uses the value as the similarity, the related test item presentation device according to the first embodiment. 1 and different.

[3.1. Device configuration example]
The related test item presentation device 1 according to the second embodiment is the same as the related test item presentation device 1 according to the first embodiment, and as illustrated in FIG. The test result change data generation unit 20, the similarity calculation unit 30, the related test item extraction unit 40, the related test item display unit 50, and the input unit 60 are included. Since the operations of the constituent elements other than the similarity calculation unit 30 are the same as those in the first embodiment, description thereof will be omitted.

  The similarity calculation unit 30_2 in the second embodiment (reference numeral 2 is expressed as 30_2 for distinction) applies cosine similarity based on the test result change data 1700, and the similarity between two test items. A degree is calculated, and inter-item similarity data, which is data storing the calculated similarity, is generated.

The cosine similarity is a technique in which the closeness of the vector direction is used as an index of similarity.
Vectors A and B represented by the following equations

Cosine similarity P is calculated by the following equation.

  The similarity calculation unit 30_2 treats each record of the test result change data 1700 as a corresponding test item vector, calculates the cosine similarity between the two test item vectors, and uses the obtained values as the two test items. Is stored in the similarity data between items.

The calculation example of the similarity in 2nd Embodiment is shown. Based on the test result change data 1700 shown in FIG. 17, the similarity between the test item 1 (test ID: 1) and the test item 2 (test ID: 2) is calculated. If the test result change history of test item 1 is a vector A, its component display is A = (0, 1, 0, 1). If the test result change history of test item 2 is a vector B, its component display is B = (0, 1, 0, 0). The similarity P between vector A and vector B is

It becomes.

Similarly, when the similarity P is calculated for the test item 1 (test ID: 1) and the test item 4 (test ID: 4),

In this way, the similarity is calculated for all combinations of the two test items, and the similarity data between items is generated. FIG. 21 shows an example of item-to-item similarity data generated by the similarity calculation unit 30_2 based on the test result change data 1700. The related test item extraction unit 40 extracts a related test item for a test item that is a reference based on the similarity data between items.

As a method for extracting related test items, for example, there is a method using the following criteria.
Method 1. Recommendation method if similarity is greater than 0.0 Method 2. Recommendation method when the similarity is greater than or equal to the threshold specified by the user. Recommend as many as can be performed within the man-hours specified by the user (in that case, it is necessary to set the planned man-hours in the test item)
The user may set the method by which the related test item extraction unit 40 performs the extraction based on the test environment, the development progress, or the like.

  FIG. 22 is a diagram in which the numerical values satisfying the criteria extracted by the method 1 are displayed with bold underline in the inter-item similarity data shown in FIG. For example, regarding the test item 5 (test ID: 5), if the related test item is extracted by the method 1, the related test item extraction unit 40 includes the test item 1 (test ID: 1) and the test item 3 (test ID). : 3) Only the test item 5 is extracted as the related test item.

  The related test item presentation device 1, more specifically, the related test item display unit 50 displays or outputs the related test item extracted by the related test item extraction unit 40. First, the above-described screen shown in FIG. 19 is displayed. When the user selects any test item with a pointing device or a keyboard, the check box next to the test item is turned on, and the related test item extraction unit 40 selects the test item. The related test items are extracted for the test items that have been set. FIG. 23 is an example of a screen that transitions after a test item is selected on the screen of FIG. 19, and related test items for a reference test item are displayed in an area 2301 for displaying related test items.

[3.2. Example of operation]
The related test item presentation device 1 according to the second embodiment executes a related test item presentation process as its main operation. Since the content of the related test item presentation processing is the same as that of the first embodiment except for the similarity calculation method, detailed description thereof is omitted.

[4. Summary]
As mentioned above, although embodiment of this invention was described, this invention is not limited to these, A various change, addition, a combination, etc. are possible in the range which does not deviate from the meaning of invention.

  In the first and second embodiments, the related test item presentation device 1 presents the related test items for the test item selected by the user or the like. However, each test item is displayed for all the test items without waiting for the user's selection. Related test items may be presented.

[5. Other]
According to the related test item presenting apparatus, a regression test can be efficiently performed within a limited time regardless of the intuition and experience of the person in charge of the test.
Since the related test item presentation device automatically extracts and displays the related test items, it is possible to select the test items to be preferentially performed regardless of the skill level of the person in charge of the test.
Even in a short period of time, it is possible to efficiently check for defects and find a degradation.

  The applicant conducted an evaluation experiment to confirm whether the related test items could be correctly extracted, and confirmed that all the related test items prepared as correct answers could be extracted. This is the result of an evaluation experiment using a method of preparing test items whose relation has been clarified as correct answers and confirming whether they can be extracted.

DESCRIPTION OF SYMBOLS 1 ... Related test item presentation apparatus; 10 ... Data storage part; 20 ... Test result change data generation part; 30 ... Similarity calculation part; 40 ... Related test item extraction part; ..Related test item display section;

Claims (3)

One test item from test result data having information for specifying the test item, information indicating the version of the software to be executed by the test item, and a test result that is a result of executing the test item for the version Generating means for generating test result change data having information indicating the presence / absence of a change in the test result performed on each version of the software;
Based on the test result change data, calculating means for calculating the similarity between test items;
A related test item presentation device comprising: extraction means for extracting a related test item based on the similarity.   The related test item presentation device according to claim 1, wherein the calculation unit calculates the similarity based on the number of same timing change patterns existing between two test items from the test result change data.   The calculation means treats each record of the test result change data as a vector of corresponding test items, calculates the cosine similarity of the vectors of the two test items, and uses the obtained value as the similarity between the two test items. The related test item presentation device according to claim 1, wherein