JPH04276835A - Method of generating program single body test data - Google Patents

Abstract

PURPOSE:To efficiently and effectively generate at the design stage a test data pattern, that is, a test data value of single body test case that is used to verify a program in the program development process. CONSTITUTION:The present method is provided with the function of data type specifying tables 22 and 23 that data types of input/output interface parameters for a verification object program are classified into two groups. Program design data on a FD5 is read through an input/output section 3. Processor 1, when a data definition statement of input interface for verification program is input, the data definition statement is divided into a method for generating all test data items of parameters as test case and the other for generating only part of test data as test case to generate a test data value for a single body test case.

Description

[Detailed description of the invention]

0001

[Industrial Field of Application] The present invention relates to a method for generating test data patterns, so-called unit test cases, used for functional verification of a program in the program development process, and in particular to a method for efficiently generating test data values of the test cases at the design stage. and how to effectively generate unit test data for programs. Note that unit testing refers to verifying a divided program without combining it with other programs.

0002

[Prior Art] Program unit testing involves white-box testing, which generates unit test cases by combining conditions that can be directly known from the internal structure of the source program of the program being tested, and unit test cases, which generate unit test cases by combining only conditions that can be seen from the specifications. It can be divided into black box testing that is generated and performed.

White box testing is a method of generating and testing test cases according to the internal structure of a source program to be tested. Here, the target of structural analysis is the execution path of the program, which mainly consists of branching conditions, etc., and the execution of a test by one test case is a program obtained from a combination of branching conditions extracted from the source program. This corresponds to tracing one execution path of . Then, the set of execution paths corresponding to one group of test cases is determined by the thoroughness of the test.
This is an evaluation of coverage. What is the thoroughness and comprehensiveness shown here?
This is a measure for evaluating the proportion of execution paths that can be verified by the one group of test cases among all execution paths in a program. The advantage of white box testing is that it allows you to determine the execution path from the internal structure of the source program, allowing you to select test cases that increase the level of thoroughness. On the other hand, a drawback is that since the test cases are determined from the source program itself, it is not possible to determine whether the program satisfies the determined specifications. In other words, a mismatch between the specifications and the source program cannot be detected.

[0004] Black box testing is a method of determining and performing test cases according to the specifications of a program, and is a form of testing that can confirm the correct implementation of the program's functions as defined by the specifications. The advantage is that unit test cases can be generated from the design stage based on the external specifications of the program without depending on the source program, so that deficiencies in the specifications of the source program can be discovered. The drawback is that internal branching conditions that cannot be seen from the specifications cannot be considered when selecting unit test cases, so test cases that increase thoroughness cannot be arbitrarily selected as in white box testing.

[0005] The simplest test case selection method in black box testing is the random generation method, in which test cases are randomly selected and tested, and this is not necessarily an effective selection method. Another method is to use a test case generation tool to grasp the features of the functions of the program under test specified in the specifications, and then create and use test cases according to the given distribution and conditions. Although it is effective and has discovered many bugs, there are currently no concrete guidelines established.

[0006] The best test method for black box testing is to exhaust the combinations of input conditions defined in the specifications as much as possible. The number of cases is enormous, and in reality, rather than combining all data values in the data area, only a small portion of the combinations are used as test cases. At that time, the question is how to select a subset of test cases and how to efficiently and easily narrow down the scope to be tested.
This is considered to be an issue in test case generation using a black box.

[0007] Hitherto, known test case selection methods that attempt to solve the problems of black box testing include equivalence partitioning, limited value analysis, cause-effect graphs, and the like.

The equivalence division method divides the input/output data area of a program into several areas called equivalence classes, and extracts representative values from each equivalence class to use as test data. In other words, the division of the input data area into equivalence classes is a method in which data that is considered to be processed by the same procedure in a program, judging from the specifications, is incorporated into the same equivalence class.

The limit value analysis method is positioned as an extension of the equivalence division method. This is because if it is thought that the internal processing of the program will change depending on a certain value of input data, it will also try other values around that value. In other words,
The boundary value and its surrounding values in equivalence partitioning are adopted as test cases. Furthermore, we focus not only on the input but also on the output data area, select the input data necessary to achieve near the boundaries of the output data stipulated in the specifications, and add it to the test case.

A cause-effect graph logically shows input conditions and the corresponding program operations as a graph.
It facilitates the selection of effective test cases by combining input conditions that produce a certain result. However, application to large-scale software is considered difficult because the graph display becomes complicated.

[0011] Regarding the above-described test case generation method using white box testing and black box testing, in unit tests that test procedures, which are the lowest component of a program, black box testing is performed to check whether there are any omissions in the specifications. At the same time as testing, white box testing is often used based on the internal structure of the program, and the ratio of white boxes tends to be high. Reference literature in this type of field includes, for example, Tamai et al., "Software Testing Techniques" (Kyoritsu Shuppan, 1988).

0012

[Problem to be Solved by the Invention] As mentioned above, conventional program unit testing has generally been performed using a combination of white box testing that focuses on the source program and black box testing that focuses on the functionality according to specifications. . However, unit test cases are generated from source programs that have not been checked to see if they satisfy the functionality stipulated in the specifications, such as in white box testing, which means that it is not guaranteed that the execution path according to the specifications is reflected. This means that the required execution path of the test specified in the specification may be leaked or a test case containing an unnecessary execution path may be generated, resulting in a mismatch between the specification and the source program that cannot be detected. It is considered unreasonable because there is.

As a solution, it is necessary to apply only black box tests to unit tests, or to increase the ratio of black box tests compared to white box tests. However, when performing a unit test using a black box test, the best method is to generate test cases by considering all combinations of parameters, but the number of test cases becomes enormous. Especially for parameters with a wide range specified, if all parameter values are used as test cases, this cannot be said to be a realistic number of test cases. In addition, in the random generation method, which is considered to be one of the methods for efficiently generating test cases for black box testing, the test cases are selected randomly, so the generated test cases may not be able to verify some of the functions to be verified. There is a tendency to be biased toward The equivalence partitioning method and the limit value analysis method are effective in that test cases can be created at the design specification creation stage, but since there is no guideline for partitioning the parameter data area, the equivalence partitioning method is more effective than the specification method. It is not easy to extract division points according to the limit value analysis method, and the test case generation efficiency is not high.

The present invention aims to solve the above-mentioned conventional problems, reduce the number of input condition test data, and efficiently generate test cases in unit tests.

[0015]

[Means for Solving the Problems] In order to achieve the above object, the present invention is based on a method using a black box test format that does not depend on a source program in generating a unit test case. It is equipped with a data type type specification table that classifies types into two groups, and when a data definition statement of the input interface is input, the data value area of the parameter is changed from the data definition statement belonging to one group according to the classification by the table. All combinations of data values are generated as test cases, and from the data definition statements belonging to the other group, the data value area of the parameter is further divided into data value areas divided by the dividing points indicated by the data definition statement of the input interface. This method generates only some data values as test cases.

[0016]

[Operation] The present invention sets the data type definition type of the input/output interface parameters of the program to be tested from the design stage to a "range-oriented data type type" in which the data type definition is a numerical data type definition indicating the range of the data area. It is classified into two types: ``set-oriented data type type'', which is a set-like data type definition that has its own meaning. For input/output interface parameters that are data type definitions specified as "range-oriented data type type," the execution path of the program does not necessarily branch depending on the parameter value; in other words, the same execution may occur even for different parameter values. Since there is a tendency for there to be many paths to pass through, there is no point in using all data values in the data value area as test cases. By clarifying the branch boundary value of the execution route branch as design data and setting it in the data definition statement of the input interface, the dividing point of the parameter value becomes clear, and some values between the boundary values of the data value area or the boundary Generate values around the value as test cases for unit tests. Also,
For input/output interface parameters that are data type definitions specified as "set-oriented data type type," the indicated values themselves tend to be branch boundary values for execution path branches in the program, so all values are tested in unit tests. Generate it as a test case.

In this way, in test case generation at the unit test level, by adopting a test case generation method using a black box test format that generates test cases from the design stage, we can create a white test case that generates test cases from an untested source program. Compared to the box test format, the bug detection rate between specifications and source programs is increased even in unit test cases.
Improves reliability of test cases. Regarding test case generation for black box testing, by specifying the test case generation method for unit tests based on the data type definition type of input/output interface parameters, it is possible to create an efficient method that aims to discover many bugs with a small number of test cases. Test cases can be easily generated.

[0018]

[Examples] The present invention will be explained below with reference to Examples. In the embodiment, a procedure, which is the lowest component of a program to be tested, will be described as an example. However, the present invention can also be implemented in units of modules, which are collections of procedures.

FIG. 1 is a system configuration diagram of an embodiment of the present invention. In the figure, 1 is a CPU which is a processing device;
2 is a memory as a data section, 3 is an input/output section, 4 is a display section, and 5 is a floppy disk (FD). The processing device 1 transfers the design data of the program corresponding to the corresponding procedure inputted from the input/output unit 3 to the memory 2, and also retrieves the design data from the memory 2 and determines the characteristics of the data, that is, the characteristics of the data. A unit test case extraction method is determined based on the definition type, a test case is generated, and the test case is transferred to the memory 2 and outputted to the input/output section 3, and displayed on the display section 4. Note that each operation status is always displayed on the display section 4.

[0020] The program design data is created by an external device other than this device and stored on the FD5. Of the data on the FD 5 designed by the external device, only the procedure interface definition data table setting required data list and the branch data table data setting required data list are read out and transferred to the memory unit 2 of this device. As shown in Figure 18, the list of required data for setting the procedure interface definition data table includes the required data for each procedure name, each interface name for the procedure, each parameter name for the interface name, parameter IN/OUT type, and data type definition. shall be. In addition, as shown in Figure 19, the list of data required to set the branch data table includes each procedure name, each interface name corresponding to the procedure, each parameter name corresponding to the interface, and the upper and lower limit values (upper limit values) corresponding to the parameters. indicates that either the data group defined by the definition or the data group defined by the member definition is required. Which one is selected is determined by which one is indicated by the data corresponding to the parameter based on the contents of the program design data. The meanings of the range definitions and member definitions in the list of necessary data for setting the branch data table in FIG. 19 are as follows. Range definition: Number of divisions In the case of a data table group, the parameter data area is divided and the number of divisions is set. Further, an upper limit value, a lower limit value, and an increase condition from the lower limit value to the upper limit value for each data division area are set. Member definition: In the case of a group of member tables, the parameter data area is divided and the number of divisions is set. Also, all members of each data division area are set. However, among the members of the data division area, the smallest member is set first, and the largest member is set last.

FIG. 2 shows a functional block diagram in this embodiment. That is, the processing device 1 functionally includes an execution management section 11, a data editing section 12, a data reading section 13,
It consists of a test case generation and editing section 14 and a data management section 15. The tables in the memory 2 include a procedure interface definition data table 21, a range data table 22 and a set data table 23, both of which are nested tables of the constituent elements of the data type type regulation table, and a nested table of the constituent elements of the branch data table. It consists of a divided data table 24, a member table group 25, and a test case data table 26.

The execution management section 11 manages the environment for creating test cases. Specifically, it interprets and executes input commands input from the input/output unit 3 to start the device, controls the transfer of data input/output to the memory 2, controls the display unit 4, etc. be. The data editing section 12 stores the program design data on the FD 5 transferred from the execution management section 11, the interface definition data table 21 on the memory 2, and the data type type regulation tables 22, 2.
3. Since the branch data tables 24, 25 and the test case data table 26 have different formats, the program design data is analyzed, edited, and set in the corresponding table on the memory 2 through the data management section 15. The data reading unit 13 reads data such as the list of data required to set the procedure interface definition data table shown in FIG. 18 and the list of data required to set the branch data table shown in FIG. 19 of the table set in the memory 2.
The data in the data type type regulation tables 22 and 23 is read out through the data management section 15 and transferred to the execution management section 11. In the test case generation editing section 14, the execution management section 1
1 creates a test case that receives the various data set in the memory 2, and sets it in the test case data table 26 in the memory 2 through the data management section 15, as well as reading it out. The data management section 15 manages reading and writing of the memory 2, which is a data section.

FIGS. 3 to 8 are basic processing flowcharts in this embodiment. Figure 2 according to the flowchart.
The operation will be explained in detail.

Unit test case generation begins with reading the program design data on the FD5. Here, the design data shown in the program is design data created by another external device, and is shown in the procedure interface definition data table setting data list in FIG. 18 and the branch data table setting data list in FIG. 19 related to design. The program design data is stored on the FD5, including various design data such as data. Figure 9
2 shows a procedure interface diagram of the design data on FD5 that is targeted when generating unit test cases. That is, the procedure interfaces include input interface B1, output interface B2, other procedure call input interface B3, other procedure call output interface B4, module data input interface B5, module data output interface B6, and procedure (within unit) data input interface. There are interfaces B7 and B8, a procedure (intra-unit) data output interface. Here, in the procedure interface that is the target of these unit tests, each data (referred to as procedure interface definition data) shown in the procedure interface definition data table setting list in Figure 18 is
Procedure interface definition data table 21
The process to set is shown below.

[0025] In response to a command input from the input/output unit 3, the execution management unit 11 reads out the FD5 through the input/output unit 3, so that the program design data on the FD5 is transferred to the interface S1, the input/output unit 3, the interface S2, and the execution The information is transferred to the management section 11. The procedure interface data taken into this execution management section 11 is
Since it is created in the format of program design data and needs to be edited into the format of a procedure interface definition data table on the memory 2, the data editing section 12 analyzes and edits it through the interface S4. And the formatted procedure interface definition data is
The data is set in the procedure interface definition data table 21 on the memory 2 via the interface S6, the data management unit 15, and the interface S10. In Figure 3,
Data editing from Y1 program design data to procedure interface definition data table (memory),
The settings correspond to this process.

FIG. 10 shows an example of the structure of the procedure interface definition data table 21. Here, the procedure interface definition data table 21 has a 4-word interface head table 212 that indicates each child table for each procedure of the procedure table 211. The interface head table 212 shows the headers of an input/output interface table 223, a call procedure interface table 224, a call module data interface table 225, and a call procedure interface table 226. The configuration of the input/output interface table 223 is as follows:
Interface name, each parameter name and its corresponding
It indicates the input/output type, IN information or OUT information, and the data type definition type, and if the number of parameters does not fill the final area, a stopper value is set at the end. The structure of the call procedure interface table 224 shows each call procedure interface name, each parameter name corresponding to it, the input/output type of IN information or OUT information corresponding to the parameter name, and the data type definition type,
When the number of parameters is less than the final area, the last stopper value is set. The structure of the call module data interface table 225 consists of IN information or OU information corresponding to each call module data name or member.
It indicates the input/output type and data type definition type of T information, and if the number of parameters does not fill the final area, a stopper value is set at the end. The same applies to the call procedure data interface table 226. In addition,
The left column of the interface head table 212 is a valid/invalid indicator for each interface and parameter, where 0 is invalid and 1 is valid. In addition, each child table 223 to 22
6 is an identifier in the leftmost column, 0 is empty, 1 is an interface, 2 is a parameter, and 3 is a stopper. Data is set in these tables at Y1.

After editing and setting each procedure interface parameter, data is edited from the program design data to the branch data tables 24 and 25 at Y2.
Make settings. That is, each data in the branch data table setting required data list in the program design data on the FD5 is the interface S1, input/output section 3, interface S2, execution management section 11, interface S4, data editing section 12, interface S6, data management. Part 15,
It passes through the interface S11 and is set in the division point data table group 24 or member table group 25, which is a nested table of constituent elements of the branch data table.

FIG. 11 shows an example of the structure of the branch data table. As mentioned earlier in the list of data required to set the branch data table in FIG.
It has a branch data interface head table 202 consisting of 4 words indicating each child table. The branch data interface head table 202 has a header configuration of an input/output interface table, a call procedure interface table, a call module data interface table, and a call procedure data interface table. The branch data parameter table 203 indicated by the branch data interface head table 202 is distributed based on each interface name as to whether the data is in the division point data table group 24 or the member table group 25. The distribution display is determined by the next child table type in the branch data parameter table 203. However, the setting of the next child table type is determined by the data information of the program design data. The next child table type is division point data table group 2.
4 is a case where the design data of the program is set in a format with a lower limit value and an upper limit value, and the number of divisions, which is the number of divided data areas of the parameter, is set in the division point data parameter table 241. , values are set in the division point data upper and lower limit value table 242. Furthermore, so that it is possible to add data that mathematically shows the increase conditions from the lower limit value to the upper limit value, the division condition data increase condition table 2 is created.
43, set an increase condition. In addition, if the increase condition indicated by the corresponding parameter or the corresponding data area of the parameter is not set in the program design data, the dividing point data upper and lower limit value table 242 and the increase condition table 243 of the corresponding parameter or the corresponding data area of the parameter are set. is not linked. For this reason, a valid/invalid indicator is provided in the increase condition header of the dividing point data upper/lower limit table 242, with 0 indicating invalid and 1 indicating valid. On the other hand, if the next child table type in the branch data parameter table 203 indicates the member table group 25, this means that the corresponding parameter data in the program setting data is indicated by a member, and the parameter data is in the member data parameter table 251. The number of divisions, which is the number of divided data areas, is set, and the number of members in the unit of divided data and all member values are set in the member data value display table 252.

When the setting of the branch data tables 24 and 25 is completed, the data type type regulation tables 22 and 2 are set in Y3.
The process moves on to step 3 read processing. Here, the data type type specification tables 22 and 23 on the memory 2 are positioned as semi-fixed data tables. In other words, once set, it is a standard table that cannot be changed permanently. However, during initial settings or when adding a new parameter data type, settings can be made by canceling the guard regulations. The data type definition type is set by the input/output section 3 according to the operator's specifications and settings.
11, the specified data type definition type is individually set in the range data table 22 and set data table 23, which are nested tables of the constituent elements of the data type type definition table on the memory 2.

FIG. 12 shows classification standards and examples of data type definition types, ``range-oriented data type types'' and ``set-oriented data type types,'' which are the characteristics of the present invention, based on the communication software description language recommended by CCITT. The CHILL language will be used as an example to show the characteristics of black box testing. As shown in FIG. 12, the classification criteria is that a numerical data type definition that indicates a range is classified as a range-oriented data type type, and a set-like data type definition in which the value itself has a meaning is classified as a set-oriented data type type. In the data type type definition tables 22 and 23 on the memory 2, classifications of data type definitions are set in advance in accordance with the above classifications.

FIG. 13 shows the structure of a data type type specification table corresponding to the classification example shown in FIG. 12. In FIG. 12,
Data types that are range-oriented data types are BIN and BIT.
These are set in the range data table 22. Also, the data type that is a set-oriented data type is CH
AR, PTR, and REF, and these are set in the set data table 23. 0 in tables 22 and 23,
The flag indicated by 1 is a valid/invalid indicator for the member,
0 is invalid, 1 is valid. A data type type head table 200 holds header values of tables 22 and 23. As previously mentioned, both tables are semi-fixed, permanent tables.

At this point, the procedure interface definition data table 21 in the memory 2, the division point data table group 24, which is a nested table group of the branch data table components, the member table group 25, and the data type type specification table. This means that the range data table 22 and set data table 23, which are nested tables of constituent elements, have been set. These data tables are 1
It can be set for each procedure, multiple procedures, or all system procedures, and the amount of data to be set depends on the capacity of the memory 2.

Next, at Y4, all parameters of all interfaces of the corresponding procedure are read from the memory 2. Here, the procedure interface definition data table 21 is read out, and the interface S13, data management section 15, interface S7, data reading section 13,
It is saved in the buffer within the execution management unit 11 through the interface S5. Next, at Y5, the range data table 22 and set data table 23, which are nested tables of the constituent elements of the data type type specification table, are read out and similarly saved in the buffer in the execution management section 11. Then, in Y5, the data type type of one parameter of one interface is specified in the data type type specification tables 22 and 23.
Judgment branching is performed according to the classification indicated by . That is, the data type type of the corresponding parameter of the corresponding procedure interface is determined and branched according to the classification shown in the data type type specification tables 22 and 23. This process is carried out by the execution management unit 11.
, the corresponding procedure interface parameter is set to a parameter that is a range-oriented data type, using the data type of the interface parameter in the procedure interface definition data table 21 and the data in the data type type specification tables 22 and 23. It is classified into "parameters that are oriented data type types. The results of both classifications correspond to Y6 and Y7.

For the parameters that have become the range-oriented data type type (range data) at Y6, the data shown in the branch data table setting required data list in FIG. 19 is read out from the branch data table in memory 2 at Y8. Get it. That is, from the division point data table group 24 or the member table group 25, which is a nest table group of constituent elements of the branch data table,
5. The data is obtained by transferring it to the buffer of the execution management unit 11 through the interface S7, the data reading unit 13, and the interface S5. Then, in Y9, it is determined whether the branch data of the corresponding parameter belongs to the division point data table group 24 or member table group 25 of the branch data table. This determination is made based on the value of the next child table type for the corresponding parameter in the branch data parameter table 203 having the branch data table configuration shown in FIG. That is, if the value of the next child table is 1, it is a division point data table group, and if it is 2, it is a member table group.

If the branch data of the relevant parameter is a division point data table, then Y10 is reached, and the process moves to obtain the division number data of Y12. This is to read the number of divisions in the division point data parameter table 241 of the division point data table group 24 in the branch data table configuration in FIG. It shows. Next, the process moves to obtaining the lower limit value and upper limit value of Y13. This is the lower limit value and upper limit value of the data area, and indicates the lower limit value and upper limit value of the division point data upper and lower limit value table 242 of the division point data table group 24 in FIG. Next, a branch process is performed based on the determination of the presence or absence of the increase condition data in Y14. This is done using the value of the increase condition data presence/absence indicator set in the increase condition header of the division point data upper and lower limit value table 242 in FIG. 11. That is, when the value of the indicator is 0, it is absent, and when it is 1, it is present. The increasing condition here refers to a formula using an arithmetic progression, a geometric progression, a difference progression, etc., from the lower limit value to the upper limit value of one data area divided by the parameter shown above. The constant increase in is expressed mathematically. For irregular items, there are no conditions for increase. Also, things that cannot be expressed numerically are registered in the program design data as member values. Note that processing for member values will be described later.

If the increase condition data is present, the increase condition expression of Y16 is obtained. This is the division point data increase condition display table 24 of the branch data table group 24 in FIG.
3 is to extract the increase condition data for each parameter data area unit. Next, in Y17, all values within the range of the lower limit value and upper limit value of ■ are calculated using the increase conditional formula, and the value obtained by the lower limit value of ■ (minimum increase condition value) and the upper limit value + Calculate the value obtained by (minimum increase condition value). Next, the test data extraction process of Y18 is performed based on the calculated value. The extraction method is to select one value from the already obtained lower limit value, upper limit value, and the value calculated in
A total of five values are set as test data: a value obtained by subtracting the increase condition (increase condition), and a value obtained by adding the minimum increase condition (1 increase condition) from the upper limit value. However, if the lower limit value and upper limit value data area range is narrow and the values calculated and selected by the lower limit value, upper limit value, or increasing conditional expression overlap, one of them is deleted. Next Y
In step 19, it is determined whether all the parameter divisions have been completed. In other words, it is determined whether test data has been extracted from all of the data areas into which the parameters have been divided. If not completed, the process returns to Y13 and repeats the process of obtaining the lower limit value and upper limit value for the data area into which the remaining parameters are divided.

When the number of divisions of the parameters in Y19 has been completed, the test data of the data area units obtained by dividing the parameters in Y24 are combined to form test data for the parameters. Next, in Y25, it is determined whether all parameters of the corresponding procedure interface have been completed, and the process branches. Here, in the case of unfinished (Y26), the process of branching the data type type of one parameter of one interface according to the classification of the data type type specification tables 22 and 23 of Y5 is repeated. Y5 at this point corresponds to processing of the corresponding one parameter. Note that all interfaces and all parameter data of the corresponding procedure have already been set in the buffer of the execution management unit 11 in Y4.

If the process ends in Y25 (Y27), in Y28, the generated parameter test data for each parameter of the corresponding procedure interface is combined to form the interface test data. Then, in Y29, it is determined whether all applicable procedure interfaces of the procedure have been completed, and the process branches. In other words, Y
In step 29, it is determined whether test data has been generated in all interfaces of the procedure. If not completed (Y30), the process is repeated from Y5. Y5 at this point corresponds to processing of the corresponding one procedure interface. If it ends in Y29 (Y31),
The test data of the interfaces of the applicable procedure are combined to form the test data of the procedure. The test data at this point becomes the test case and test data value in the unit test, and becomes the output data as the final purpose (Y34).

On the other hand, if there is no increase condition data as determined in Y14 (Y22),
In Y23, the lower limit value and upper limit value obtained in Y13 are set as the test data value of the data area corresponding to the parameter. And Y1
The process moves on to a process of determining whether the number of divisions of all nine parameters has been completed.

Next, in Y9, if the branch data of the corresponding parameter belongs to the member table group (Y11), in Y35, the member data parameter of the member table group 25 having the branch data table configuration shown in FIG. The division number data of the table 251 is obtained. The number of divisions also indicates the number of data areas into which the parameter has been divided. Next, the process of Y36 is performed. In this process, Figure 11
The number of all members in the corresponding data area of the parameter is obtained from the member data display value table 252 of . Next Y3
In step 7, all members equal to the number of members obtained in Y36 are obtained. In Y38, one of the first member value obtained, the last member value obtained, and a member value other than both member values is selected, and a total of three member values are used as test data. do. Note that if the number of member values is small and the member values overlap, one value is used as test data. In addition, when managing member values in the divided data area of parameters in procedure design data, if the value can be compared numerically or in size, the member value to be set first is the lower limit value or the minimum value, and the member value to be set last is the lower limit value or minimum value. The upper limit or maximum value is set in the correct order. Next, in Y39, it is determined whether all the divisions of the parameter have been completed, and the process branches. That is, the process branches after determining whether test data has been extracted from all the data areas into which the parameters have been divided. If the process is not completed (Y40), the process returns to Y36, and if the process is completed (Y41), the process is executed from Y24.

Next, in Y5, the data type type of one parameter of one interface is classified into a data type type specification table, and the parameter (Y7; set data) whose value itself has a meaning is processed in Y42. However, the processing from Y42 to Y57 is performed from Y8 to Y2, which is the processing for parameters (range data) for which the range specification is meaningful in Y5.
This process is almost the same as the process up to 1, but there is only one difference. The different processes are the test data selection method of the process of Y18 in the case of a parameter whose range specification is meaningful, and the process of Y52 in the case of a parameter of set-oriented data type. In other words, when the range-oriented data type is classified in Y5, the processing in Y18 is calculated using the increasing conditional expression using the lower limit value, the upper limit value, and the value within the range of the lower limit value and the upper limit value, which is ■ in Y17. The minimum increase condition (1 increase condition) from the lower limit value selected from the values ``■''
minus the value, and the minimum increase condition (1
The five values plus the increase condition) were used as test data, but in the process of Y52, the lower limit value, upper limit value, Y1
Test all the values calculated by the increase conditional formula with the values within the range of the lower limit and upper limit of ■ in 7, and the value obtained by adding the minimum increase condition (1 increase condition) from the lower limit, which is ■ in Y17. Data. In other words, the difference between a parameter that is a range-oriented data type and a parameter that is a set-oriented data type is that either the value selected from the parameter's divided data area is used as test data, or all values obtained from the parameter's divided data area are used as test data. The difference is whether to use it as test data.

[0042] Furthermore, the relevant parameter is a parameter indicating a data type that is a set-oriented data type type, and Y4
If the branch data of the corresponding parameter in 3 belongs to the member table group of the branch data table, processing is performed from Y58, but if the corresponding parameter is a range specification parameter and belongs to the member table of the branch data table of the branch data. The process that is different in the comparison is the process of Y61. In other words, in the processing of Y38, which was a range specification parameter, among the member values of the divided data area of the parameter, the first read member value, the last read member value, and the member values other than both member values are Nakayori 1
I selected one and used a total of three values as test data, but
Y6 for parameters of set-oriented data type type
1, all member values of the parameter divided data area are used as test data. In other words, in the present invention, when extracting test data from a parameter's divided data area, some values selected from the parameter's divided data area are used as test data. By using all the values obtained as test data.

As described above, a test case is generated together with procedure test data by combining the test data of each parameter and each interface. These processes are performed by the execution management section 11 and the test case generation/editing section 14 via the interface S8. The generated test cases and test data are set in the test case data table 26 on the memory 2 through the test case generation/editing section 14, interface S9, data management section 15, and interface S16. The test cases and test data set in the test case data table 26 can be displayed on the screen on the display section 4 and can also be output to the FD 5 via the input/output section 3.

Next, a specific example of generating a program test case and test data will be shown. Here, test data values are shown when a program as shown in the procedure specifications of FIG. 14 is created.

The procedure specifications in FIG. 14 are as follows: where the input parameter is a, a is an integer value from 0 to 15, and the variable range of a is that from 0 to 7, A processing is performed, from 8 to 15, B processing is performed; Other than that indicates that C processing is to be performed. In the procedure specification, when the a parameter is a division point data table group of a nest table that is a component of a branch data table, the data area is from 0 to 15,
The data division areas are from 0 to 7 and from 8 to 15. The divided data of the lower limit value and upper limit value of each data division area is 0.
The data division area from 8 to 7 has a lower limit of 0 and the upper limit of 7, while the data division area from 8 to 15 has a lower limit of 8 and an upper limit of 15. Furthermore, if an increasing conditional expression is set, b=lower limit value, and an arithmetic progression of arithmetic difference=1 with the lower limit value as the initial value. The increase conditional expression calculated here is:
When an is an arithmetic progression, b is an initial value, c is an arithmetic difference, and n is an arithmetic progression number, the formula an=b+(n-1)c is established, and the value of each an is determined by the increasing condition. This becomes all the test data. The test data is a1 to a7, a
From 8 to a15. In addition, the minimum increase condition value (1 increase condition) mentioned earlier is, in this case, arithmetic difference = c
=1.

FIGS. 15 and 16 show the results (test data values, number of test data, display images) of test data generated based on the above conditions. Here, (1) to (4) in FIG. 15 show the case where the parameters are set in the division point data table group, and (1) and (2) in FIG. 16 show the case where the parameters are set in the member table group. Indicates when there is. Note that (3) in Figure 16 indicates that general data values that may actually become set members are set in the member table group, rather than numerical parameter values as shown in (1) and (2). This figure shows how test data was generated using days of the week as an example.

Further, FIG. 17 shows an example in which the data values of the procedure specifications shown in FIG. 14 are set as actual data in the branch data table shown in FIG. 11. In FIG. 17, for the next child table type of "*1", 0 indicates not set, 1 indicates data table group (data parameter table header) setting, and 2 indicates member table group (member data parameter table header) setting. "*2" is an indicator of presence/absence of the dividing point data increase condition; 0 means not present and 1 means present. Also, to supplement the increase condition data of "*3", a
n is an arithmetic progression value and serves as a test data value. However, lower limit value≦an≦upper limit value, b=initial value=lower limit value, c=arithmetic difference (here, 1), and n=number of arithmetic progression.

The embodiment of the present invention has been described above, and the nest table of the constituent elements of the procedure interface definition data table 21 in which the data definition type of the parameter is set and the data type type regulation table in which the data definition type classification is set. A test case generation method that selects test data for a parameter of a corresponding procedure by processing data according to a certain range data table 22 and a set table 23 and classifying the test case generation method, or all members of the parameter (test data ) It can be seen that unit test cases can be generated efficiently by dividing into test case generation methods that apply a combination of the following.

[0049]

[Effects of the Invention] As described above, according to the present invention, many bugs can be discovered with a small number of test cases by specifying the test case generation algorithm based on the data type characteristics of the interface parameter of the procedure to be tested. This makes debugging easy and quick.

[Brief explanation of the drawing]

FIG. 1 is a system configuration diagram of an embodiment of the present invention.

FIG. 2 is a functional block diagram of an embodiment of the present invention.

FIG. 3 is part of a basic flowchart of an embodiment of the present invention.

FIG. 4 is also a part of the basic flowchart.

FIG. 5 is also a part of the basic flowchart.

FIG. 6 is also a part of the basic flowchart.

FIG. 7 is also a part of the basic flowchart.

FIG. 8 is also a part of the basic flowchart.

FIG. 9 is an interface diagram of a unit test target procedure.

FIG. 10 is a configuration example of a procedure interface definition data table.

FIG. 11 is a configuration example of a branch data table.

FIG. 12 shows classification criteria and classification examples of data type definition types.

FIG. 13 is a configuration example of a data type type regulation table.

FIG. 14 is an example of a procedure specification.

FIG. 15 shows test data generation results for the procedure specifications in FIG. 14;

FIG. 16 also shows test data generation results for the procedure specifications shown in FIG. 14;

FIG. 17 is an example in which data values of the procedure specifications of FIG. 14 are set in a branch data table.

FIG. 18 is a list of necessary data set in a procedure interface definition data table.

FIG. 19 is a list of necessary data to be set in the branch data table.

[Explanation of symbols]

1 Processing device 2 Memory 3 Input/output section 4 Display section 5 Program design data floppy disk 21
Procedure interface definition data table 22,
23 Data type type regulation table 24, 25 Branch data table 26 Test case data table

Claims (1)

[Claims] Claim 1: Various data values are input from an input interface of a verification target program, and output data values output from the verification target program corresponding to the input data values are determined in advance from the functional specifications of the verification target program. A method for automatically generating a data value of the input data input from the input interface in a program unit test that performs functional verification of the program to be verified by comparing with a predicted output data value, the method comprising: 2 types of various data definition statements used
When a data definition statement of the input interface of the program to be verified is input, the data type classification regulation table is referred to and the data definition statement is classified into two groups. Determine which group it belongs to, and from the data definition statement that belongs to one group,
The program unit test is performed by extracting all of the one or more data values set in the data definition statement, or all of the data values included in the data value area specified by both or one of the lower limit value and upper limit value. , and from a data definition statement belonging to the other group, one or more data values set in the data definition statement, or a data value range specified by both the lower limit value and/or upper limit value. A method for generating program unit test data, characterized in that only a part of data is extracted from the program unit test and used as an input data value for the program unit test.