WO2022009499A1 - Test assistance device and test assistance method - Google Patents

Abstract

Provided is a device for outputting a reference test case by inputting a new test requirement, the device comprising: a test requirement acquisition unit for inputting a new test requirement; a test requirement analysis unit for generating test requirement quantifying data for the new test requirement by natural language analysis; a test case analysis unit for analyzing an existing test case on the basis of the test requirement quantifying data and using a reusable candidate to generate an output test case candidate; and a test case output unit for outputting the output test case candidate as a reference test case. The test case analysis unit uses an existing test case on the basis of test requirement quantifying data to generate an output test case candidate, and calculates the degree of reuse for each output test case candidate. The test case output unit determines a reference test case from among the output test case candidates on the basis of the degree of reuse.

Description

Test support device and test support method Capture by reference

This application claims the priority of Japanese Patent Application No. 2020-116748, which is a Japanese application filed on July 7, 2020, and incorporates it into this application by referring to its contents.

The present invention relates to a test support device and a test support method.

Patent Document 1 as a technique for searching from existing software components for lower-layer software components used in upper-layer software components when newly constructing software by reusing existing software components. The techniques described in are known.

The problem of Patent Document 1 is to provide a technique capable of efficiently searching for necessary software components in consideration of the hierarchical structure and variations between software components, and as a solution, the upper layer software components are supported. A software component information search system that searches for information on lower-layer software components, and has a function to narrow down the search results to the required variations from among the variation components that are multiple lower-layer software components that have the same name. It is stated that it has.

Further, in Patent Document 2, a solution for automatically forming a test case by a computer in order to verify at least one function of one software for a specification including a requirement regarding an input value and an output value of the software. The means are disclosed.

As a solution, a step to distinguish between a combination request and an order request, a step to model the combination request with a truth table and a step to model the order request with a finite state machine, in order to obtain a modeled specification. The software is tested by associating the input values with the probability that the input values are inherited and the transition time between the input values to establish a math matrix and by performing a Monte Carlo draw on the math matrix. Determined to be a step of selecting the inheritance of the input value and a step of determining a test case containing a test line relating each selected inheritance to the expected output value in view of the modeled specification. If the test case allows a predetermined threshold to be reached for at least one of the following criteria, functional code validated percentage, requirement validated percentage, validation time, and validation cost: A step to stop the determination step is described.

Japanese Unexamined Patent Publication No. 2008-287352 Japanese Patent Publication No. 2011-521368

In Patent Document 1, it is possible to narrow down the required software components to those with the required variations by considering the hierarchical structure and variations between the software components, but when there are multiple narrowing results, which software component should be referred to. Since manual confirmation is required to select a key, there is a problem that software components cannot be reused efficiently.

In Patent Document 2, it is possible to search for test cases corresponding to the requirements by modeling the requirements, but in order to select which test case should be referred to when there are a plurality of corresponding test cases. Has a problem that test cases cannot be generated efficiently because it requires manual confirmation.

Therefore, in the present invention, for a test requirement given from the outside, a test case that needs to be developed in order to determine whether or not the software to be verified meets the test requirement from the test cases generated in the past. It is an object of the present invention to provide a test support device that efficiently generates the above.

The present invention is a test support device having a processor and a memory, accepting a new test requirement, and outputting a reusable reference test case, and the test requirement accepting the new test requirement written in a natural language. The acquisition unit, the test requirement analysis unit that performs natural language analysis on the received new test requirements and generates test requirement quantified data, and the existing test cases generated in the past are based on the test requirement quantified data. A test case analysis unit that analyzes and generates reusable existing test case candidates as output test case candidates, and a test case output unit that outputs part or all of the output test case candidates as reference test cases. The test case analysis unit has a test case candidate extraction unit that generates one or more existing test cases as output test case candidates based on the test requirement quantified data, and each of the output test case candidates. It has a reusability evaluation unit that calculates the reusability of the test case, and the test case output unit refers to the output test case candidates based on the reusability calculated by the reusability evaluation unit. Determine the test case.

According to the present invention, it is possible to efficiently generate a test case by using the test case having the highest degree of reuse from the test cases generated in the past for the test requirement given from the outside. ..

Details of at least one implementation of the subject matter disclosed herein are set forth in the accompanying drawings and in the description below. Other features, aspects, and effects of the disclosed subject matter are manifested in the following disclosures, drawings, and claims.

It is a block diagram which shows Example 1 of this invention and shows an example of the function of the test support apparatus. FIG. 1 is a block diagram showing Example 1 of the present invention and showing an example of a configuration including hardware of a test support device. FIG. 1 shows Example 1 of the present invention and is a diagram showing an example of a test requirement described in natural language. FIG. 1 shows Example 1 of the present invention and is a diagram showing an example of a test case described in a formal language that can be interpreted by a computer. It is a flowchart which shows Example 1 of this invention and shows the outline of the process performed in the test requirement analysis part. FIG. 1 is a flowchart of a natural language analysis process executed by the test requirement analysis unit, showing Example 1 of the present invention. FIG. 1 is a diagram showing Example 1 of the present invention and showing an example of test requirement quantified data obtained by converting the test requirements shown in FIG. 2 into numerical data. It is a figure which shows Example 1 of this invention and shows an example of the function of the test case candidate extraction part. It is a figure which shows Example 1 of this invention and shows an example of the code clone data. It is a figure which shows Example 1 of this invention and shows an example of cluster data. It is a figure which shows Example 1 of this invention and shows an example of a test case candidate. FIG. 1 is a diagram showing Example 1 of the present invention and showing an example of the function of the code clone analysis unit. It is a figure which shows Example 1 of this invention and shows an example of a token division test case. It is a figure which shows Example 1 of this invention and shows an example of the token number data. It is a flowchart which shows Example 1 of this invention and shows an example of the process executed in the token counting part. FIG. 1 is a flowchart showing the first embodiment of the present invention and showing the entire process executed in the code clone extraction unit. FIG. 5 is a flowchart showing Example 1 of the present invention and showing in detail the contents of the code clone analysis process in FIG. It is a figure which shows Example 1 of this invention and shows an example of the function of the test case candidate determination part. It is a flowchart which shows Example 1 of this invention and shows an example of the process executed in the classifier generation part. FIG. 1 is a diagram showing Example 1 of the present invention and showing an example of the function of the reusability evaluation unit. It is a figure which shows Example 1 of this invention and shows an example of a reuse graph. It is a figure which shows Example 1 of this invention and shows an example of the reuse degree data. It is a flowchart which shows Example 1 of this invention and shows an example of the process executed in the reuse graph generation part. It is a flowchart which shows Example 1 of this invention and shows an example of the process executed in the reuse degree calculation unit. It is a flowchart which shows Example 1 of this invention and shows an example of the process executed in the test case output part in Example 1. FIG. FIG. 2 is a flowchart showing Example 2 of the present invention and showing an example of processing executed in the test case output unit.

This embodiment relates to a test support device, and particularly to a test technique used for developing control software for an embedded system.

Hereinafter, examples (examples) of embodiments suitable for the present invention will be described.

<Structure>
FIG. 1A is a block diagram showing an outline of the functions of the test support device in the present invention.

<Test support device>
The test support device according to the present invention will be described with reference to FIG. 1A. The test support device 0 includes a test requirement acquisition unit 1 that acquires a new test requirement 11 written in natural language, and a test requirement analysis unit that generates test requirement quantified data from the test requirements using a method such as natural language processing. 2. The test case analysis unit 3 that analyzes the existing test cases manually developed in the past embedded software development project based on the test requirement quantified data and outputs them as candidates for the reference test case 12, and the reference test case. It is composed of a test case output unit 4 that outputs the reference test case 12 having the highest degree of reuse among the 12 candidates.

Further, the test case analysis unit 3 determines the degree of reuse for each of the test case candidate extraction unit 301 that generates one or more existing test cases as test case candidates based on the test requirement quantified data and the test case candidates. It is composed of a reusability evaluation unit 302 for calculation.

The test support device 0 uses an existing test case with high reusability (reusability) as the reference test case 12, so that the user or the like can modify only a part of the reference test case 12 to be verified. You can generate test cases to determine if your software meets the test requirements. This makes it possible to generate a test case with a small number of man-hours.

FIG. 1B is a block diagram showing an example of a configuration including the hardware of the test support device 0. The test support device 0 is a computer including a processor 21, a memory 22, a storage device 23, an input device 24, an output device 25, and a network device 26.

The input device 24 is composed of a keyboard, a mouse, a touch panel, or the like. The output device 25 is composed of a display or the like. The network device 26 is connected to a network (not shown) and communicates with other devices.

The test requirement acquisition unit 1, the test requirement analysis unit 2, the test case analysis unit 3, and the test case output unit 4 are loaded into the memory 22 as programs and executed by the processor 21. The test case analysis unit 3 is composed of a test case candidate extraction unit 301 and a reusability evaluation unit 302.

The processor 21 operates as a functional unit that provides a predetermined function by executing a process according to the program of each functional unit. For example, the processor 21 functions as the test case analysis unit 3 by executing the process according to the test case analysis program. The same applies to other programs. Further, the processor 21 also operates as a functional unit that provides each function of a plurality of processes executed by each program. A computer and a computer system are devices and systems including these functional parts.

<Test requirements and test cases>
FIG. 2 is a diagram showing an example of test requirement 111 written in natural language. The test requirement 111 is data that describes the behavior that the control software to be verified should satisfy, that is, the content to be verified in the test in natural language. 112 and test requirement 113 are included in one entry.

The test requirement 111 is used for a unit test, a combination test, a system test, etc. of a predetermined system, and is used to determine whether or not the system meets the user's requirements.

For example, No. In the test requirement "If mode is START1 and input is low, output is 0 and mode remains START1", the control software needs to hold the mode START1 when the input is low in the mode START1.

In this case, the control software meets the test requirements by inputting low to the control software in mode START1, then measuring the mode of the control software, and finally determining that the mode is START1. You can confirm that it is.

In this way, the test case defines the specific input given to the control software and the specific output measured by the control software to confirm that the control software meets the test requirements. In order to execute the test case automatically, write the test case in a formal language that can be interpreted by a computer.

FIG. 3 is a diagram showing an example of a test case written in a formal language that can be interpreted by a computer. The test case 121 is data in which the contents to be verified as shown in the figure are formally described so that the contents to be verified can be executed by a test device such as a PC capable of automatically executing a test.

<Test requirement analysis department>
FIG. 4 is a flowchart showing an example of the processing performed by the test requirement analysis unit 2.

In step S21, the test requirement analysis unit 2 receives the new test requirement 11 from the test requirement acquisition unit 1. In step S22, the test requirement analysis unit 2 performs a natural language analysis of the received new test requirement 11.

In step S23, the test requirement analysis unit 2 outputs the result of the natural language analysis to the test case analysis unit 3 as the test requirement quantified data 200. In this way, the test requirement analysis unit 2 converts the test requirement into the test requirement quantified data and ends the process.

<Natural language analysis>
FIG. 5 is a detailed flowchart of the natural language analysis process (S22) executed by the test requirement analysis unit 2.

In step S222, the test requirement analysis unit 2 divides the new test requirement 11 into words that are constituent units of the test requirement, and registers each of the words in the queue. In step S223, the test requirement analysis unit 2 determines whether or not a word exists in the queue, and if it exists, proceeds to step S224, and if it does not exist, proceeds to step S229 for processing. finish.

In step S224, the test requirement analysis unit 2 pops a word from the queue. In step S225, the test requirement analysis unit 2 determines whether or not the popped word exists in the already-existing word list, and if the popped word exists in the already-existing word list, the step S226 is performed. If the popped word does not exist in the existing word list, the process proceeds to step S227.

In step S226, the test requirement analysis unit 2 increments the number of appearances of the corresponding existing word described in the existing word list, then returns to step S223 and repeats the above process. In step S227, the test requirement analysis unit 2 adds the popped word to the existing word list. In step S228, the test requirement analysis unit 2 initializes the number of appearances of the word with 1, and then returns to step S223 to repeat the above process.

By the above natural language analysis process, the test support device 0 converts the new test requirement 11 described in the natural language into a numerical vector in which the number of occurrences of the words included in the test requirement is arranged, and the test requirement quantified data 200 is obtained. Can be generated.

<Test requirement quantified data>
FIG. 6 shows the result of generating the test requirement quantified data 200 for each test requirement 111 shown in FIG. It is data that stores the number of times each word appears in a tabular format for each test requirement. For example, No. = 1 As for the test requirement "If mode is STATE1 and output is low, output is 0 and mode remains STATE1", the word if appears once and the mode appears twice, so 1 in each of the corresponding places in the table. 2 is described, and 0 is described in the corresponding place because the word the does not appear.

As described above, the test requirement analysis unit 2 arranges the number of occurrences of the word of the test requirement 113 and converts it into a numerical vector to generate the test requirement quantified data 200.

<Test case candidate extraction unit>
FIG. 7 is a diagram showing the configuration of the test case candidate extraction unit 301 constituting the test case analysis unit 3.

The test case candidate extraction unit 301 is composed of an existing test case storage unit 3011, a code clone analysis unit 3012, a clustering implementation unit 3014, and a test case candidate determination unit 3016.

The test case candidate extraction unit 301 compares the input quantified data of the new test requirement 11 with the quantified data of the existing test requirement 30112 developed in the past, and the numerical value of the new test requirement 11 input as described later. Determine which cluster the conversion data belongs to, and output the existing test cases included in that cluster as test case candidates.

<Existing test case storage unit>
The existing test case storage unit 3011 is one of the components of the test case candidate extraction unit 301, and stores the existing test cases manually developed in the past embedded software development project as the existing test cases 30111.

The existing test cases 30111 are generated based on the test requirements that describe the behavior to be verified in natural language, and each test case is saved in a state associated with the existing test requirement 30112 that describes the behavior to be verified. ing. The association is performed by a method of tagging each existing test case 30111 and each existing test requirement 30112, or a method of describing the correspondence between each existing test case 30111 and each existing test requirement 30112 in a table format.

The existing test case 30111 stored in the existing test case storage unit 3011 is read and executed by, for example, a test device such as HiLS (Hardware in the Loop Simulator) that tests a control controller such as an ECU (Electronic Control Unit) in a vehicle. It is described in a possible format, and FIG. 3 is an example. Further, the test requirement associated with the existing test case 30111 is referred to as an existing test requirement 30112.

<Code Clone Analysis Department>
The code clone analysis unit 3012 is one of the components of the test case candidate extraction unit 301, and evaluates the similarity between the existing test cases 30111 stored in the existing test case storage unit 3011.

The evaluation of the similarity is based on the ratio of code clones common to the existing test case 30111. That is, the code clone analysis unit 3012 analyzes the code clone between the formal languages described in the two existing test cases 30111, and calculates the ratio of the number of elements of the code clone to the number of elements of the formal language as the degree of similarity. do.

FIG. 11 is a diagram showing the configuration of the code clone analysis unit 3012. The code clone analysis unit 3012 is stored in the lexical analysis unit 30121 that divides the existing test case 30111 into tokens, the token count unit 30123 that counts the number of tokens existing in the existing test case 30111, and the existing test case storage unit 3011. It is composed of a code clone extraction unit 30125 that extracts a code clone common to existing test cases 30111.

<Lexical analysis department>
The lexical analysis unit 30121 divides the existing test case 30111 for each token and converts it into the token division test case 30122. The token is the smallest unit that constitutes a test case such as an operator and parentheses. FIG. 12 is an example in which the existing test case 30111 shown in FIG. 3 is converted into the token division test case 30122. In this example, the lexical analysis unit 30121 divides the existing test case 30111 into variable names such as input and mode, operators such as == and <, and parentheses.

<Token count section>
The token counting unit 30123 counts the total number of tokens existing in the token division test case 30122.

FIG. 14 is a flowchart showing an example of the process executed by the token counting unit 30123. In step S301231, the token counting unit 30123 receives the token division test case 30122 from the lexical analysis unit 30121.

In step S301232, the token counting unit 30123 initializes the index i for identifying the existing test case 30111 and the token division test case 30122 converted from the existing test case with 0.

In step S301233, the token counting unit 30123 determines whether or not the index i is smaller than the number of test cases, proceeds to step S301234 if it is smaller than the number of test cases, and proceeds to step S30123A if it is greater than or equal to the number of test cases. move on.

In step S301234, the token counting unit 30123 initializes the variable Count for counting the number of tokens with 1.

In step S301235, the token counting unit 30123 extracts the first token of the token division test case [i].

In step S301236, the token counting unit 30123 determines whether or not a token exists in the token division test case [i], proceeds to step S301237 if it exists, and proceeds to step S301238 if it does not exist. move on.

In step S301237, the token counting unit 30123 increments the variable Count, then returns to step S301235 and repeats the above process.

In step S301238, the token counting unit 30123 increments the index i. In step S301239, the token counting unit 30123 substitutes the Count for the token number data [i], then returns to step S301233 and repeats the above process.

In step S30123A, the token counting unit 30123 outputs the token number data 30124 and ends the process.

As a result, the token counting unit 30123 can output the total number of tokens included in the test cases, which is necessary when calculating the similarity between the existing test cases 30111.

<Token number data>
FIG. 13 is a diagram showing an example of token number data 30124. The token number data 30124 includes the test case identifier and the number of tokens in one entry. The token number data 30124 is data in which the number of tokens included in each test case is stored in a table format.

<Code clone extraction unit>
The code clone extraction unit 30125 extracts a code clone common to the existing test cases 30111 stored in the existing test case storage unit 3011.

FIG. 15 is a flowchart showing the entire process executed by the code clone extraction unit 30125.

In step S301251, the code clone extraction unit 30125 receives the token division test case 30122 as an input, and stores each token included in the received token division test case 30122 in the array TC.

The code clone extraction unit 30125 stores all the existing test cases 30111 stored in the existing test case storage unit 3011 in the array TC. Therefore, the array TC is a two-dimensional array. That is, the row index is used to identify the token split test case 30122, and the column index is used to identify each token contained in the token split test case 30122.

In step S301252, the code clone extraction unit 30125 receives the token number data 30124 as an input.

In step S301253, the code clone extraction unit 30125 initializes the index i for identifying the token division test case 30122 with 0.

In step S301254, the code clone extraction unit 30125 determines whether or not the index i is smaller than the number of test cases, proceeds to step S301255 if it is smaller than the number of test cases, and step S30125A if it is greater than or equal to the number of test cases. Proceed to.

In step S301255, the code clone extraction unit 30125 initializes the index j for identifying the token division test case 30122 with 0.

In step S301256, the code clone extraction unit 30125 determines whether or not the index j is smaller than the number of test cases, proceeds to step S301258 if it is smaller than the number of test cases, and steps S301257 if it is greater than or equal to the number of test cases. Proceed to.

In step S301257, the code clone extraction unit 30125 increments the index i, then returns to step S301254 and repeats the above process.

In step S301258, the code clone extraction unit 30125 performs code clone analysis. The details of the code clone analysis process will be described with reference to FIG.

In step S301259, the code clone extraction unit 30125 increments the index j, then returns to step S301256 and repeats the above process.

In step S30125A, the code clone extraction unit 30125 outputs the code clone data 3013 and ends the process.

As a result, the code clone extraction unit 30125 can output the similarity between the existing test cases 30111 as the code clone data 3013 by performing the code clone analysis on the two existing test cases 30111.

The code clone data 3013 analyzes the code clone between the two existing test cases 30111, and stores the ratio of the number of tokens determined to be the code clone to the total number (number) of tokens in the existing test case 30111 in a tabular format. It is the data that was done.

The higher this ratio, the more similar the two test cases can be evaluated. An example of the code clone data 3013 is shown in FIG. In the illustrated example, it can be determined that the test case 1 and the test case 2 are approximately 50% similar, and the test case 3 and the test case 5 are approximately 80% similar.

<Code clone analysis>
FIG. 16 is a flowchart relating to the code clone analysis process (S301258) in FIG.

In step S3012581, the code clone extraction unit 30125 initializes the index m for identifying the token to be processed in the token division test case 30122 identified by the index i with 0.

In step S3012582, the code clone extraction unit 30125 determines whether or not the index m is smaller than the number of tokens [i], and if it is smaller than the number of tokens [i], proceeds to step S3012583 and the number of tokens [i] or more. In the case of, the process proceeds to step S301258D to end the process.

In step S3012583, the code clone extraction unit 30125 initializes the index n for identifying the token to be processed in the token division test case 30122 identified by the index j to 0.

In step S301284, the code clone extraction unit 30125 determines whether or not the index n is smaller than the number of tokens [j], and if it is smaller than the number of tokens [j], proceeds to step S301258 and proceeds to step S301258, and the number of tokens [j] or more. In the case of, the process proceeds to step S301256D.

In step S301285, the code clone extraction unit 30125 initializes the variable clone_num that counts the number of common tokens continuously detected in the token division test cases i and j to 0.

In step S301258, the code clone extraction unit 30125 increments the index m, then returns to step S3012582 and repeats the above process.

In step S301257, the code clone extraction unit 30125 determines whether or not the m + clone_numth token of the token division test case [i] and the n + clone_numth token of the token division test case [j] are equal, and if they are equal, the code clone extraction unit 30125 determines whether or not they are equal. The process proceeds to step S301258, and if different, the process proceeds to step S301259.

In step S301288, the code clone extraction unit 30125 increments the variable clone_num, then returns to step S301257 and repeats the above process.

In step S301259, the code clone extraction unit 30125 determines whether or not the variable clone_num is larger than the minimum number of tokens, proceeds to step S301258B if it is larger than the minimum number of tokens, and step S301258A if it is less than or equal to the minimum number of tokens. Proceed to.

This makes it possible to prevent the continuously detected common tokens from being detected as a code clone when the number of continuously detected common tokens is less than or equal to the minimum number of tokens.

If the minimum number of tokens is set small, a part that should not be detected as a code clone (for example, a simple variable declaration) will be erroneously detected as a code clone. On the other hand, if the minimum number of tokens is set large, the part that should be detected as a code clone cannot be detected as a code clone. Therefore, the minimum number of tokens needs to be set appropriately according to the data to be analyzed.

In step S301258A, the code clone extraction unit 30125 substitutes n + clone_num + 1 for the index n, then returns to step S301258 and repeats the above process.

In step S301258B, the code clone extraction unit 30125 substitutes the code clone data [i] [j] with the value (similarity) obtained by dividing the variable clone_num by the number of clones [i].

In step S301258C, the code clone extraction unit 30125 substitutes m + clone_num + 1 for the index m, then returns to step S3012582 and repeats the above process.

As a result, the code clone extraction unit 30125 can detect a portion having the same token configuration for the two existing test cases 30111 as a code clone.

<Clustering implementation unit>
The clustering implementation unit 3014 is one of the components of the test case candidate extraction unit 301, and classifies similar existing test cases 30111 into clusters based on the code clone data 3013.

The code clone data 3013 records the similarity between the two existing test cases 30111. By regarding the reciprocal of the reciprocal of the similarity of two existing test cases 30111 as a pseudo distance between the two existing test cases 30111, a known or well-known clustering algorithm is applied to cluster similar existing test cases 30111 with each other. Can be classified into.

For example, in the case of the code clone data 3013 shown in FIG. 8, since test case 1 and test case 2 are approximately 50% similar, the distance between test cases 1 and 2 is 1 / 0.5 = 2, and test case 3 and so on. Since the test case 5 is approximately 80% similar, the distance can be regarded as 1 / 0.8 = 1.25.

From this, it can be determined that the distance between similar existing test cases 30111 is close. VBGMM (Variational Bayesian Gaussian Mixture) is used as the clustering algorithm. VBGMM is an algorithm for classifying point clouds based on distance, and by giving the distance between point clouds, the number of clusters is determined and the cluster classification of each point cloud is automatically performed.

In this embodiment, since a pseudo distance between the existing test cases 30111 is given, it is possible to classify similar existing test cases 30111 into clusters by VBGMM.

<Cluster data>
FIG. 9 is a diagram showing an example of cluster data 3015. The cluster data 3015 includes the test case identifier and the cluster identifier in one entry. The cluster data 3015 is data in which each test case corresponds to which cluster in a tabular format.

<Test case candidate determination unit>
The test case candidate determination unit 3016 is one of the components of the test case candidate extraction unit 301, and determines test case candidates to be referred to.

FIG. 17 is a diagram showing the configuration of the test case candidate determination unit 3016.

The test case candidate determination unit 3016 includes a classifier generation unit 30161 and a classification implementation unit 30162.

The classifier generation unit 30161 generates a classifier based on the existing test case 30111 stored in the existing test case storage unit 3011, the existing test requirement 30112 associated with the existing test case, and the cluster data 3015.

The classification implementation unit 30162 determines to which cluster the data obtained by quantifying the new test requirement 11 using the classifier is classified, and re-uses all the test cases included in the determined cluster as test case candidates. Output to the usability evaluation unit 302.

Thereby, the test case candidate determination unit 3016 can determine the test case candidates to be referred to for the test requirements received by the test requirement analysis unit 2.

<Classifier generator>
FIG. 18 is a flowchart of the process executed by the classifier generation unit 30161.

In step S301611, the classifier generation unit 30161 receives the existing test requirement 30112 associated with each existing test case 30111 stored in the existing test case storage unit 3011 as an input.

In step S301612, the classifier generator 30161 receives the cluster data 3015 as an input.

In step S301613, the classifier generation unit 30161 performs natural language analysis on the existing test requirement 30112 received in step S301611 and generates test requirement quantified data S301614. The natural language analysis is performed by the same method as in step S22 in the test requirement analysis unit 2.

In step S301615, the classifier generator 30161 uses the digitized data (S301614) of the existing test requirement 30112 as an input vector, and refers to the cluster data 3015 to provide an existing test case 30111 associated with the existing test requirement 30112. The number of the cluster to which it belongs is specified, supervised learning is performed using the number of the cluster as a label, and a classifier is generated.

As a supervised learning algorithm, for example, a well-known or known algorithm such as a deep neural network or a support vector machine is used. This method is an application of the method of generating a dog or cat image classifier by performing deep neural network analysis using image data as an input vector and dogs or cats as labels.

<Classification Implementation Department>
The process executed by the classification execution unit 30162 will be described. The classification implementation unit 30162 determines the cluster classification for the data obtained by quantifying the new test requirement 11 by using the classifier generated by the classifier generation unit 30161, and determines all the existing test cases 30111 included in the determined cluster. It is output to the reusability evaluation unit 302 as a test case candidate.

First, the test requirement quantified data 200 generated by the test requirement analysis unit 2 is input to the classifier. At this time, the classifier determines the cluster in which the test requirement quantified data S301614 is classified.

Next, the classification implementation unit 30162 refers to the cluster data 3015 and identifies all the existing test cases 30111 belonging to the cluster determined by the classifier. Finally, the classification implementation unit 30162 outputs all the existing test cases 30111 identified above as test case candidates 3010.

Since the classifier generation unit 30161 analyzes the relationship between the existing test case 30111 developed in the past and the existing test requirement 30112 associated with the existing test case 30111, the output of the test case candidate 3010 by the classification implementation unit 30162 is , Corresponds to predicting or estimating test cases expected to be developed for the new test requirement 11 based on past performance.

<Test case candidate>
FIG. 10 is a diagram showing an example of test case candidate 3010. The test case candidate 3010 is data in which the identifier of the existing test case 30111 is stored in a tabular format.

<Reusability Evaluation Department>
The reusability evaluation unit 302 evaluates the reusability of each existing test case 30111 included in the test case candidate 3010 and generates reusability data 3020.

FIG. 19 is a diagram showing the configuration of the reusability evaluation unit 302. The reusability evaluation unit 302 includes a candidate-to-candidate code clone analysis unit 3021, a reuse graph generation unit 3023, and a reuse degree calculation unit 3025.

The degree of reuse of each existing test case 30111 included in the test case candidate 3010 is calculated using the reuse graph.

<Candidate code clone analysis unit>
The inter-candidate code clone analysis unit 3021 performs code clone analysis on the existing test cases 30111 included in the test case candidates 3010. The code clone analysis is performed by the same method as the code clone analysis unit 3012 described above.

The candidate-to-candidate code clone analysis unit 3021 generates the candidate-to-candidate code clone data 3022 as a result of the analysis. The inter-candidate code clone data 3022 is the same as the code clone data 3013 generated by the code clone analysis unit 3012 regarding the existing test cases 30111 included in the test case candidate 3010.

<Reuse graph generator>
FIG. 22 is a flowchart showing an example of the processing executed by the reuse graph generation unit 3023. In step S30231, the reuse graph generation unit 3023 receives the inter-candidate code clone data 3022 as an input.

In step S30232, the reuse graph generation unit 3023 initializes the index i that identifies the test case candidate 3010 to be processed to 0. In step S30233, the reuse graph generation unit 3023 determines whether or not the index i is smaller than the number of test case candidates, proceeds to step S30234 if the index i is smaller than the number of test case candidates, and if the number is equal to or greater than the number of test case candidates. To step S30236.

In step S30234, the reuse graph generation unit 3023 adds the test case candidate [i] to the reuse degree graph 3024 as a node. In step S30235, the reuse graph generation unit 3023 increments the index i, then returns to step S30233 and repeats the above process.

In step S30236, the reuse graph generation unit 3023 initializes the index i to 0. In step S30237, the reuse graph generation unit 3023 determines whether or not the index i is smaller than the number of test case candidates, proceeds to step S30238 if the index i is smaller than the number of test case candidates, and if the number is equal to or greater than the number of test case candidates. The process proceeds to step S3023F to end the process.

In step S30238, the reuse graph generation unit 3023 initializes the index j that identifies the test case candidate to be compared with respect to the test case candidate of the index i to 0.

In step S30239, the reuse graph generation unit 3023 determines whether or not the index j is smaller than the number of test case candidates, proceeds to step S3023A if the index j is smaller than the number of test case candidates, and if the number is equal to or greater than the number of test case candidates. To step S3023B.

In step S3023A, the reuse graph generation unit 3023 increments the index i, then returns to step S30237 and repeats the above process.

In step S3023B, the reuse graph generation unit 3023 has a code clone [i] [j] indicating how many clones of the test case candidate [j] exist in the test case candidate [i] from a preset threshold value. It is determined whether or not it is large, and if it is larger than the threshold value, the process proceeds to step S3023C, and if it is equal to or less than the threshold value, the process proceeds to step S3023E. The threshold value is for determining whether the test case candidate [i] and the test case candidate [j] are judged to be similar or dissimilar.

In step S3023C, the reuse graph generation unit 3023 indicates how many clones of the test case candidate [i] exist in the test case candidate [j] code clones [j] [i] (inter-candidate code clone data 3022). It is determined whether or not the value (value stored in) is larger than the threshold value, and if it is larger than the threshold value, the process proceeds to step S3023D, and if it is equal to or less than the threshold value, the process proceeds to step S3023E.

In step S3023D, the reuse graph generation unit 3023 describes a node (node i) in which the test case candidates identified by the index i are described on the graph and a node in which the test case candidates identified by the index j are described on the graph. Create a link between (nodes j).

In step S3023E, the reuse graph generation unit 3023 increments the index j, then returns to step S30239 and repeats the above process.

By the above processing, all the existing test cases 30111 included in the test case candidate 3010 are used as nodes, and the similarity between the existing test cases 30111 calculated from the code clone analysis results of the existing test cases 30111 is equal to or higher than the threshold value. In some cases, the reuse degree graph 3024 can be generated by generating the link between the nodes.

The reuse degree graph 3024 shows that the existing test case 30111 corresponding to the node to which many links are connected is similar to many of the other existing test cases 30111 included in the test case candidate 3010. That is, it is considered that the existing test case 30111 corresponding to the node to which many of the links are connected is suitable for reference.

<Reuse graph>
FIG. 20 is a diagram showing an example of the reuse degree graph 3024. The reuse degree graph 3024 is a graph in which test cases are used as nodes and links are generated according to the ratio of code clones between test cases.

In the case of the example shown in FIG. 20, it is shown that the test case 2 has a common code clone with respect to the test case 1 and the test case 4 at a ratio equal to or higher than the threshold value. Similarly, test case 1 shows that test case 2, test case 4, and test case 10 have a common code clone at a ratio equal to or higher than the threshold value.

<Reuse degree calculation unit>
FIG. 23 is a flowchart of the process executed by the reuse degree calculation unit 3025.

In step S30251, the reuse degree calculation unit 3025 receives the reuse degree graph 3024 as an input.

In step S30252, the reuse degree calculation unit 3025 initializes the index i for identifying the test case candidate 3010 to be processed to 0.

In step S30253, the reuse degree calculation unit 3025 determines whether or not the index i is smaller than the number of nodes included in the reuse graph, proceeds to step S30254 if it is smaller than the number of nodes, and if it is equal to or greater than the number of nodes. Goes to step S3025B.

In step S30254, the reuse degree calculation unit 3025 initializes the variable Count to 0, which stores the number of links connected to the node (node i) corresponding to the test case candidate 3010 identified by the index i.

In step S30255, the reuse degree calculation unit 3025 initially sets the index j for identifying the test case candidate 3010 to be compared with the index i and the node (node j) corresponding to the test case candidate to 0. To become.

In step S30256, the reuse degree calculation unit 3025 determines whether or not the index j is smaller than the number of nodes included in the reuse degree graph 3024, and if it is smaller than the number of nodes, proceeds to step S30257 and proceeds to step S30257 or more. In that case, the process proceeds to step S30259.

In step S30257, the reuse degree calculation unit 3025 determines whether or not a link exists between the node i and the node j, proceeds to step S30258 if it exists, and returns to step S30256 if it does not exist. And repeat the above process.

In step S30258, the reuse degree calculation unit 3025 increments the variable Count, then returns to step S30256 and repeats the above process.

In step S30259, the reuse degree calculation unit 3025 substitutes the value of the variable Count into the reuse degree data [i] (which stores the reuse degree of the node i). In step S3025A, the reuse degree calculation unit 3025 increments the index i, then returns to step S30253 and repeats the above process.

In step S3025B, the reuse degree calculation unit 3025 outputs the reuse degree data 3020 and ends the process.

Thereby, the reuse degree calculation unit 3025 can output the number of links possessed by each existing test case 30111 included in the test case candidate 3010 as the reuse degree data 3020 based on the reuse degree graph 3024.

<Reuse degree data>
FIG. 21 is a diagram showing an example of reuse degree data 3020. The reuse degree data 3020 is data in which a test case storing an identifier of an existing test case 30111 and a reuse degree are included in one entry, and the reuse degree of each test case is stored in a tabular format.

<Test case output section>
FIG. 24 is a flowchart of the process executed by the test case output unit 4 in the first embodiment.

The process of the test case output unit 4 is started from step S40. In step S41, the test case output unit 4 receives the reusability data 3020 from the reusability evaluation unit 302 as an input.

In step S42, the test case output unit 4 initializes the index i for identifying the test case candidate 3010 to be processed to 0. In step S43, the test case output unit 4 initializes the variable Max_id that stores the index that identifies the test case candidate 3010 having the maximum reuse degree to 0.

In step S44, the test case output unit 4 determines whether or not the index i is smaller than the number of reuse degree data, and if it is smaller than the number of reuse degree data, proceeds to step S45 and proceeds to step S45 to exceed the number of reuse degree data. In the case of, the process proceeds to step S48.

In step S45, the test case output unit 4 determines whether or not the reuse degree data [i] is larger than the reuse degree data [Max_id], and if it is larger than the reuse degree data [Max_id], step S46. If it is less than or equal to the reuse degree data [Max_id], the process proceeds to step S47.

In step S46, the test case output unit 4 assigns i to the variable Max_id. In step S47, the test case output unit 4 increments the index i, then returns to step S44 to repeat the above process.

In step S48, the test case output unit 4 outputs the test case [Max_id] as the reference test case 12. Then, in step S49, the test case output unit 4 ends the process.

As a result, among the test case candidates 3010, the existing test case 30111 having the maximum reuse degree data 3020 can be output as the reference test case 12.

According to this embodiment, it is possible to present the existing test case 30111, which has the highest degree of reuse, among the existing test cases 30111 manually generated in the past, for the new test requirement 11 given from the outside. , It is possible to efficiently generate test cases.

The test support device and method according to the second embodiment of the present invention will be described. The difference from the first embodiment is that the test case output unit 4 outputs a plurality of reference test cases 12. The same components as those in the first embodiment are designated by the same reference numerals and the description thereof will be omitted.

<Test case output section>
FIG. 25 is a diagram showing a flowchart of processing executed by the test case output unit 4 in the second embodiment. The difference is that step S4A and step S4B are added in the second embodiment with respect to FIG. 24 of the first embodiment.

After determining the reference test case 12 in step S48, in step S4A, the test case output unit 4 tells the test case creator whether or not the determined reference test case 12 is appropriate via the output device 25. Contact us.

If the input from the test case creator is appropriate, the test case output unit 4 proceeds to step S49, outputs the current reference test case 12, and ends the process. On the other hand, if the input from the test case creator is inappropriate, the test case output unit 4 proceeds to step S4B.

In step S4B, the test case output unit 4 extracts the reuse degree data [Max_id], deletes the data of the [Max_id] from the reuse degree data 3020, and then returns to step S42 to repeat the above process.

The test case output unit 4 outputs the test case candidate 3010 having the highest reuse degree from the reuse degree data 3020, and if it is determined that the test case creator accepts the test case candidate 3010, the test case candidate 3010 is referred to. Output as 12.

If the test case creator refuses, the test case output unit 4 outputs the test case candidate 3010 having the second highest degree of reuse, and if it is determined that the test case creator accepts it, the test case candidate 3010 is referred to. Output as test case 12.

If the test case creator rejects the second test case, the test case output unit 4 outputs the existing test case 30111 with the third highest reuse rate, and if the test case creator determines that the test case creator accepts the test case candidate, the test case candidate is output. The process of outputting 3010 as the reference test case 12 is repeated until the test case creator accepts it.

According to this embodiment, even if the reference test case 12 first output from the test support device 0 is not acceptable to the test case creator, as long as the test case exists in the test case candidate 3010, the test case is set. It is possible to continue to present and select the test case candidate 3010, which the test case creator has determined to be more reusable, as the reference test case 12.

<Conclusion>
As described above, the test support device 0 of the above embodiment can be configured as follows.

(1) A test support device having a processor (21) and a memory (22), accepting a new test requirement (12), and outputting a reusable reference test case (12), in natural language. A test that receives the described new test requirement (12), a test requirement acquisition unit (1), and a test that performs natural language analysis on the accepted new test requirement (12) to generate test requirement quantified data (200). The requirement analysis unit (2) and the existing test case (30111) generated in the past are analyzed based on the test requirement quantified data (200), and candidates for the reusable existing test case (30111) are selected. A test case analysis unit (3) generated as an output test case candidate (3010), and a test case output unit (4) that outputs a part or all of the output test case candidate (3010) as a reference test case (12). , And the test case analysis unit (3) generates one or more existing test cases (30111) as output test case candidates (3010) based on the test requirement quantified data (200). It has a candidate extraction unit (301) and a reusability evaluation unit (302) that calculates the degree of reuse for each of the output test case candidates (3010), and the test case output unit (4) is said. A test support device comprising determining a reference test case (12) from the output test case candidates (3010) based on the reusability calculated by the reusability evaluation unit (302).

With the above configuration, the test support device 0 applies the new test requirement 11 to the new test requirement 11 by using the existing test case 30111 having the highest reusability among the existing test cases 30111 generated in the past. It is possible to efficiently generate test cases.

(2) In the test support device according to (1) above, the test case candidate extraction unit (301) is included in the existing test case (30111) and the output test case candidate (3010), and , The similarity between the existing test case (30111) and the existing test case (30111) different from the existing test case (30111) is analyzed, and based on the number of test cases having a value equal to or higher than a predetermined threshold among the similarities, the above-mentioned A test support device characterized by calculating the degree of reuse for each of the output test case candidates (3010).

With the above configuration, the test support device 0 can calculate the reuse degree of the output test case candidate by comparing the similarity between the existing test cases 30111 with a predetermined threshold value.

(3) In the test support device according to (1) above, the test case candidate extraction unit (301) includes an existing test case storage unit (3011), an existing test case storage unit (3012), and clustering. It has a unit (3014) and a test case candidate determination unit (3016), and the existing test case storage unit (3011) sets the test requirements developed in the past as the existing test requirements (30112) and the existing test. The test case developed for verifying that the requirement (30112) is satisfied is set as an existing test case (30111), and the existing test requirement (30112) and the existing test case (30111) are linked and saved, and the above-mentioned The existing test case storage unit (3012) extracts two existing test cases (30111) from the existing test cases (30111) stored in the existing test case storage unit (3011), and the two existing test cases. The code clones between the formal languages described in (30111) are analyzed to calculate the ratio of the number of elements of the code clone to the number of elements of the formal language, and the two existing test cases (30111) are extracted and Code clone data (3013) is generated by performing the calculation by the extraction for all combinations of the existing test cases (30111) stored in the existing test case storage unit (3011), and the clustering execution unit (3011). 3014) clusters by regarding the ratio of the number of elements of the code clone to the number of elements of the formal language stored in the code clone data (3013) as a pseudo distance between the existing test cases (30111). The existing test cases (30111) stored in the existing test case storage unit (3011) are classified into clusters, and information on which cluster each existing test case (30111) is classified into is provided in the cluster data (3015). The test case candidate determination unit (3016) determines one cluster from the clusters based on the test requirement quantified data (200), and the test case candidate determination unit (3016) determines at least one existing cluster included in the determined cluster. A test support device characterized in that a test case (30111) is determined as an output test case candidate (3010).

With the above configuration, the code clone analysis unit 3012 evaluates the similarity between the existing test cases 30111 stored in the existing test case storage unit 3011, and the token configuration is the same for the two existing test cases 30111. Can be detected as a code clone. Further, the clustering implementation unit 3014 classifies similar existing test cases 30111 into clusters based on the code clone data 3013, and the test case candidate determination unit 3016 determines the test requirements received by the test requirement analysis unit 2. Candidates for existing test cases 30111 to be referenced can be determined.

(4) The test support device according to (2) above, which is included in the existing test case (30111) and the output test case candidate (3010), and is different from the existing test case (30111). The similarity between (30111) is included in the format language describing the existing test case (30111) and the output test case candidate (3010), and is different from the existing test case (30111). A test support device for analyzing a code clone between the formal languages in which (30111) is described and characterized in that the number of elements of the code clone occupies the number of elements of the formal language.

With the above configuration, the similarity is analyzed by analyzing the code clone between the formal languages that are included in the existing test cases and the output test case candidates and that describe the existing test cases that are different from the existing test cases. It is possible to calculate from the ratio of the number of elements of the code clone to the number of elements of.

(5) The test support device according to (3) above, wherein the test case candidate determination unit (3016) has a classifier generation unit (30161) and a classification implementation unit (30162). The classifier generation unit (30161) digitizes the existing test requirement (30112) linked to the existing test case (30111) by using the natural language analysis, and obtains the existing test requirement (30112) quantified data (200). The cluster to which the existing test case (30111) linked to the existing test requirement (30112) is classified as training data is specified based on the cluster data (3015), and the identifier that identifies the classified cluster is the correct answer. By learning the classification using a predetermined classifier generation method as a label, a classifier for determining which cluster the test requirement quantified data (200) is classified into is generated, and the classification implementation unit (30162) generates a classifier. , A test support device for determining to which cluster the test requirement quantified data (200) is classified by inputting the test requirement quantified data (200) into the classifier.

With the above configuration, the classification implementation unit 30162 uses the classifier generated by the classifier generation unit 30161 to identify the cluster corresponding to the test requirement quantified data 200 as a result of the natural language analysis of the new test requirement 11. The existing test case 30111 included in the cluster can be specified as a test case candidate.

(6) The test support device according to (1) above, wherein the reference test case (12) is described in a formal language that can be interpreted by a computer.

With the above configuration, if the determined reference test case 12 is read into the computer, the test case can be automatically executed, and the labor required for the test case work can be reduced.

The present invention is not limited to the above-described embodiment, but includes various modifications. For example, the above-described embodiment is described in detail for the purpose of explaining the present invention in an easy-to-understand manner, and is not necessarily limited to the one including all the configurations described. Further, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Further, for a part of the configuration of each embodiment, any of addition, deletion, or replacement of other configurations can be applied alone or in combination.

Further, each of the above configurations, functions, processing units, processing means and the like may be realized by hardware by designing a part or all of them by, for example, an integrated circuit. Further, each of the above configurations and functions may be realized by software by the processor interpreting and executing a program that realizes each function. Information such as programs, tables, and files that realize each function can be placed in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, or a DVD.

In addition, the control lines and information lines indicate what is considered necessary for explanation, and not all control lines and information lines are shown in the product. In practice, it can be considered that almost all configurations are interconnected.

Claims (12)

1. A test support device that has a processor and memory, accepts new test requirements, and outputs reusable reference test cases.
   The test requirement acquisition department that accepts the new test requirements written in natural language,
   The test requirement analysis unit that performs natural language analysis on the accepted new test requirements and generates test requirement quantified data,
   A test case analysis unit that analyzes existing test cases generated in the past based on the test requirement quantified data and generates reusable existing test case candidates as output test case candidates.
   It has a test case output unit that outputs a part or all of the output test case candidates as a reference test case.
   The test case analysis unit
   A test case candidate extraction unit that generates one or more existing test cases as output test case candidates based on the test requirement quantified data, and a test case candidate extraction unit.
   It has a reusability evaluation unit that calculates the degree of reuse for each of the output test case candidates.
   The test case output unit
   A test support device characterized in that a reference test case is determined from the output test case candidates based on the reusability calculated by the reusability evaluation unit.
2. The test support device according to claim 1.
   The test case candidate extraction unit
   The similarity between the existing test case and the existing test case included in the output test case candidate and different from the existing test case is analyzed, and the value of the similarity becomes a value equal to or higher than a predetermined threshold. A test support device characterized in that the degree of reuse for each of the output test case candidates is calculated based on the number of existing test cases.
3. The test support device according to claim 1.
   The test case candidate extraction unit
   It has an existing test case storage unit, a code clone analysis unit, a clustering implementation unit, and a test case candidate determination unit.
   The existing test case storage unit
   The test requirements developed in the past are set as existing test requirements, and the test cases developed to verify that the existing test requirements are satisfied are set as existing test cases, and the existing test requirements and the existing test cases are linked. Save and
   The code clone analysis unit
   Two existing test cases are extracted from the existing test cases stored in the existing test case storage unit, and a code clone between the formal languages described in the two existing test cases is analyzed to analyze the formal language. The ratio of the number of elements of the code clone to the number of elements is calculated, and the extraction of the two existing test cases and the calculation by the extraction are performed for all combinations of the existing test cases stored in the existing test case storage unit. Generate code clone data by doing
   The clustering implementation unit
   Clustering is performed by regarding the ratio of the number of elements of the code clone to the number of elements of the formal language stored in the code clone data as a pseudo distance between the existing test cases, and the existing test case storage unit is used. The existing test cases stored in are classified into clusters, and information on which cluster each existing test case is classified into is generated as cluster data.
   The test case candidate determination unit
   A test support device characterized in that one cluster is determined from the clusters based on the test requirement quantified data, and at least one existing test case included in the determined cluster is determined as an output test case candidate. ..
4. The test support device according to claim 2.
   The degree of similarity between the existing test case and the existing test case included in the output test case candidate and different from the existing test case is
   An element of the formal language is analyzed by analyzing a code clone between the formal language that describes the existing test case and the formal language that is included in the output test case candidate and describes an existing test case different from the existing test case. A test support device characterized in that the number of elements of the code clone occupies the number.
5. The test support device according to claim 3.
   The test case candidate determination unit
   It has a classifier generation unit and a classification implementation unit.
   The classifier generator
   Existing test requirements in which the existing test requirements linked to the existing test cases are quantified using the natural language analysis Which cluster the existing test cases linked to the existing test requirements are classified into as training data using the quantified data. Is specified based on the cluster data, and the test requirement quantified data is classified into which cluster by learning the classification using a predetermined classifier generation method with the identifier that identifies the classified cluster as the correct answer label. Generate a classifier to determine
   The classification implementation unit
   A test support device for determining to which cluster the test requirement quantified data is classified by inputting the test requirement quantified data into the classifier.
6. The test support device according to claim 1.
   The reference test case is a test support device characterized in that it is described in a formal language that can be interpreted by a computer.
7. A test support method in which a computer with a processor and memory accepts new test requirements and outputs reusable reference test cases.
   A test requirement acquisition step in which the computer accepts the new test requirement written in natural language.
   A test requirement analysis step in which the computer performs natural language analysis on the accepted new test requirement and generates test requirement quantified data.
   A test case analysis step in which the computer analyzes existing test cases generated in the past based on the test requirement quantified data and generates reusable existing test case candidates as output test case candidates.
   Includes a test case output step in which the computer outputs some or all of the output test case candidates as reference test cases.
   The test case analysis step is
   A test case candidate extraction step that generates one or more existing test cases as output test case candidates based on the test requirement quantified data, and
   Includes a reusability evaluation step to calculate the reusability for each of the output test case candidates.
   The test case output step is
   A test support method comprising determining a reference test case from the output test case candidates based on the reusability calculated in the reusability evaluation step.
8. The test support method according to claim 7.
   The test case candidate extraction step is
   The similarity between the existing test case and the existing test case included in the output test case candidate and different from the existing test case is analyzed, and the value of the similarity becomes a value equal to or higher than a predetermined threshold. A test support method characterized in that the degree of reuse for each of the output test case candidates is calculated based on the number of existing test cases.
9. The test support method according to claim 7.
   The test case candidate extraction step is
   Includes an existing test case storage step, a code clone analysis step, a clustering implementation step, and a test case candidate determination step.
   The existing test case saving step is
   The test requirements developed in the past are set as existing test requirements, and the test cases developed to verify that the existing test requirements are satisfied are set as existing test cases, and the existing test requirements and the existing test cases are linked. Save and
   The code clone analysis step is
   Two existing test cases are extracted from the saved existing test cases, a code clone between the formal languages described in the two existing test cases is analyzed, and the code clone for the number of elements of the formal language is obtained. Code clone data is generated by calculating the proportion of the number of elements in the above and performing the extraction of the two existing test cases and the calculation by the extraction for all combinations of the saved existing test cases.
   The clustering implementation step is
   Clustering is performed by regarding the ratio of the number of elements of the code clone to the number of elements of the formal language stored in the code clone data as a pseudo distance between the existing test cases, and the stored existing test is performed. The cases are classified into clusters, and information on which cluster each existing test case is classified into is generated as cluster data.
   The test case candidate determination step is
   A test support method characterized in that one cluster is determined from the clusters based on the test requirement quantified data, and at least one existing test case included in the determined cluster is determined as an output test case candidate. ..
10. The test support method according to claim 8.
    The degree of similarity between the existing test case and the existing test case included in the output test case candidate and different from the existing test case is
    An element of the formal language is analyzed by analyzing a code clone between the formal language that describes the existing test case and the formal language that is included in the output test case candidate and describes an existing test case different from the existing test case. A test support method characterized in that the number of elements of the code clone occupies the number.
11. The test support method according to claim 9.
    The test case candidate determination step is
    It has a classifier generation step and a classification implementation step.
    The classifier generation step is
    Existing test requirements in which the existing test requirements linked to the existing test cases are quantified using the natural language analysis Which cluster the existing test cases linked to the existing test requirements are classified into as training data using the quantified data. Is specified based on the cluster data, and the test requirement quantified data is classified into which cluster by learning the classification using a predetermined classifier generation method with the identifier that identifies the classified cluster as the correct answer label. Generate a classifier to determine
    The classification implementation step is
    A test support method comprising inputting the test requirement quantified data into the classifier to determine to which cluster the test requirement quantified data is classified.
12. The test support method according to claim 7.
    The reference test case is a test support method characterized in that it is described in a formal language that can be interpreted by a computer.

Images