JPH08272649A - How to create the test item form used for the unit test of the program module - Google Patents

Abstract

(57) [Summary] [Purpose] To provide a method for automatically creating a test item form used for a unit test of a program module. [Structure] When creating a test item form used for a unit test performed for each module of a hierarchical program, a module to be tested is selected (SA1). Next, the source program is read, the syntax is analyzed, the processing structure (tree structure) of the module is acquired, all the test items that pass each path of this tree structure at least once are extracted, and the test item file is generated. Yes (SA2). Finally, the test item data file is read and the test item form is output (SA3).

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method of creating a test item form, and more particularly to a method of creating a test item form used for a unit test of a program module.

[0002]

2. Description of the Related Art A unit test is a test for confirming the normality of modules that compose a program.

In the conventional unit test, items to be tested, so-called test items, are selected from a detailed design document in which the function of the module to be tested is designed in detail, a source program coded in a predetermined language based on the detailed design document, and the like. Was extracted by the tester and confirmed whether the module behaved as it was.

First, focusing on what combination of possible test cases has the highest probability of finding an error, the module to be tested operates normally and the module operates when an abnormality is detected. A test item form is created in which test items are extracted and test results are entered later. In addition, in order to confirm the test results, a debug statement for displaying the input value, output value, running position, etc. of the module on the standard output etc. in the source code, or setting them as files is set.

Further, it is a module called a driver for creating data necessary for testing, driving a test target module to send a test value and confirming a return value, and a pseudo module called from the test target module. Create a module called a stub.

After that, the test is executed in accordance with the test procedure prepared in order to efficiently carry out the test, and the test result obtained by the test is collated with the predicted test result described in the test item form. If the result is normal, enter normal end in the test item form and move to the next test item. If an abnormality is found, the bug will be managed according to the prescribed procedure.

The test results thus obtained are statistically tabulated and reflected in the software quality control and the test progress control in the unit testing process.

As described above, in the conventional unit test, the person in charge of the test prepared the test item form. Therefore, there is a problem that it takes time to extract the test items, and the test items vary depending on the person in charge of the test.

[0009]

SUMMARY OF THE INVENTION Therefore, an object of the present invention is to automatically generate a test item vote by parsing a source program of a module to be tested without manual work of a tester. It is to provide a method for creating a test item vote.

[0010]

In order to achieve the above object, the present invention is a method of creating a test item form used for a unit test performed for each module of a program hierarchically composed of a plurality of modules. A source program of the module, which prepares an item to be tested (test item) for each execution statement or an item to be confirmed (confirmation item) corresponding to the test item as a comment statement, While reading the source program for each execution statement, the test item and the confirmation item are subdivided into execution unit data, and when the execution statement corresponding to the test item of the execution unit data is a branch statement, a branch information table The execution unit data is stored in the execution unit data. If the execution statement corresponding to the test item of the execution unit data is other than the branch statement, the non-branch information information is stored. The execution unit data extraction step of storing the execution unit data in a block and the connection of the execution unit data, the number of the execution unit data located at the head of the branch processing is stored in the head branch number information table, and the execution A branch structure extraction step of storing the number of the execution unit data processed next to the unit data as the next branch number in the execution unit data to obtain the branch structure of the source program of the module, and storing it in the head branch number information table. The process of connecting the execution unit data corresponding to the next branch number of the execution unit data starting from the execution unit data corresponding to the number of the executed execution unit data is repeated until the next branch number disappears, and at least the test item and And a test item voucher creating step for creating a test item voucher including the confirmation items. To.

[0011]

FIG. 1 is a block diagram showing the hardware configuration of the program test system of the present invention. In FIG. 1, 1 is a CPU having a built-in memory, 2 is an external storage device such as a floppy disk, 3 is an input unit such as a keyboard for inputting the execution of a test, 4 is a display device such as a CRT, and 5 is a printer device or the like. It is an output part. The source program stored in the external storage device is loaded into the memory of the CPU 1, a signal instructing the execution of the test is input from the keyboard which is the input unit 3, the source program is parsed for the module in question, Select test items based on the results. The creation process and the result are monitored by the display device 4. The created test item form is output from the printer device 5.

FIG. 2 is a flow chart for explaining the processing procedure of the test system of the present invention.

FIG. 3 is a diagram showing an example of the structure of a program. The program is composed of several modules for each function. It should be noted that here, description will be made assuming that a unit test of a module named test0 is performed.

A procedure for creating a test item form created by the test system of the present invention will be described with reference to FIG.

First, a module to be tested is selected.
In this case, the module "test0" is designated (S
A1). Next, the source program of the module to be tested (test0) is read, the syntax is analyzed to obtain the processing structure of the module (hereinafter referred to as "tree structure"), and each path of this tree structure is acquired at least once. All test items that pass are extracted and a test item data file is generated (SA2).

Finally, the test item data file is read and the test item form is output (SA3).

As described above, according to the present invention, the source program of the test target module is parsed and the test item form is automatically generated. As a result, it is possible to automate the work of “creating a test item form,” which was conventionally created by a tester by manually extracting from a detailed design document or the like.

[0018]

EXAMPLE An example of a procedure for creating test item data (SA2 in the flow chart shown in FIG. 2 above), which is an important component of the method for creating a test item form used for a unit test of a program module of the present invention, will be described below. Will be described in more detail by. However, it goes without saying that the present invention is not limited thereto.

(1) Procedure for Creating Test Item Data File FIG. 4 is a diagram showing the source program of the module to be tested. This program is written in C,
The present invention can be applied to any hierarchical program.

The source program needs to be coded in accordance with a predetermined description rule (coding rule). As an example, "a header section in which a function name and processing contents are described is placed at the beginning as a comment line. ",
“In the program section to be placed after that, for example, a comment (that is, a comment indicating the test item content) corresponding to the conditional statement is placed before the conditional statement (if to else statement, switch statement), or an execution statement for each condition is placed. (Cnt = a;)
, A comment corresponding to the conditional sentence (that is, a comment indicating the contents of the confirmation item) is placed in front of. In this way, the coding rules are provided for clarifying the [test item] and [confirmation item] of the created test item slip.

The feature of the present invention is that "the syntax is analyzed to extract the connection for each branch block, and thus the test items passing through all the branch routes can be extracted".

FIG. 5A is a flow chart showing the source program of FIG. 4, and the tree structure of the source program will be briefly described with reference to this flow chart.

In the first conditional statement (if), "a == NUL
In the case of "L", "NG" is set to (path in the figure) and the process is terminated.

On the other hand, in the case of "a ≠ NULL" (path in the figure), a is substituted for cnt and the process proceeds to the next condition. In the second conditional statement (switch), "a is 1" (see the figure). Process 3 is executed for the middle path), and process 4 is executed for "a is other than 1" (path in the figure), and the processing proceeds to the next conditional statement.

As described above, the tree structure of the source program of FIG. 4 can be represented as shown in FIG. In the following description, a block of processing (such as processing 1) following the conditional statement is called a conditional statement block.

In the test item data file of the present invention, in addition to the above-mentioned test items and confirmation items in the conditional statement block, data indicating a connection of each conditional statement block, that is, a "tree structure" (next branch described later). The number is stored, and a test item slip that passes all the paths (path to path) of the source program (test0) once can be created by these data.

Next, the method of creating the test item data file of the present invention will be described in detail.

FIG. 6 is a work data required for creating the test item data file, and FIG. 7 is a flow chart showing an outline of the test item data creating method.

The procedure for creating the test item data file will be described with reference to FIG.

First, the process name and the function name are extracted from the header part of the source program of FIG. 4 and registered in the header information table of FIG. 6A (SB1).

Next, the program part of the source program is read line by line from the first line, the structure of the program is analyzed, and when a predetermined conditional statement is detected, the conditional statement block is extracted and the block shown in FIG. Predetermined information such as a branch number and conditional statement type is written in the branch information table shown in c) (S).
B2). The source program is described with indentation according to the nest of processing, and branch numbers are given in order from the processing with the shallowest nesting. Also, in the stub function field of the branch information table,
When a function other than the standard function is included in the conditional statement block (corresponding to "sub1" and "sub2" in this embodiment)
Is written in the outside branch information table (FIG. 6D).

Next, the branch number that may be the head of the branch in the tree structure is registered in the head branch number table (see FIG. 6B), and the connection of each conditional statement block will be described later. 16 to 17, and writes in the field of the next branch number of the branch information table (S
B3). That is, in the case of the conditional statement block 2 of this embodiment, the branch number 3 and the branch number 4 are written in the next branch number field.

Finally, based on these head branch number table, branch information table and non-branch information table, FIG.
The test item form shown in 0 is output to the test item data file (SB4).

(2) Procedure for creating branch information table and non-branch information table FIGS. 8 to 13 are flowcharts for explaining a method for creating the branch information table and non-branch information table of the test item data.

A detailed description will be given focusing on processing points.

First, as shown in FIG. 8, initial setting (S
(C1-3), one line (up to the "CR" code indicating a line feed) from the beginning of the program part of the source program (Fig. 4) is read (SC4).

The one-line character string read next is "NIL".
Otherwise, it is determined whether it is a comment line (S
C6).

In the case of a comment line, the comment flag is turned on (SC6-1), the memory is temporarily stored in a predetermined buffer (SC100), and the process returns to the reading step SC4.

If the read one-line character string is not "NIL", that is, "NIL", the process proceeds to the step shown in FIG. Is the reference table No. Is determined (SC51), and the reference table No.
In that case, the standard nest is incremented by 1 before proceeding (SC5
2). Table No. Is the reference table No. If not, the next branch number setting process () is performed (SC53), and the process ends.

Next, as shown in FIG. 9, when the read one-line character string is not a comment line but includes curly braces "{" indicating the start and end of nesting (SC7, SC7-1 and SC8), the nest of the current processing block is updated (SC9). To update the nest, 1 is added to the predetermined variable NEST when the opening curly brace “{” is detected, and 1 is subtracted from NEST when the ending curly brace “{” is detected. When the curly braces "{" indicating the start and end of nesting are not included, the process proceeds to the next SC10.

Next, as shown in FIGS. 9 to 10, it is determined whether or not the read one-line character string includes a "condition sentence" (SC10). What is a conditional statement (if, else, else
if, switch, case, default).

When the conditional statement is included, it is "if, e
lse, else if, switch, case, d
If "default", the nesting level of the branch (hereinafter,
Add 1 to "branch nest level" (SC
11). Here, the conditional statement is "case, default
In the case of "t", the branch nest is not added because the other conditional statements "if, else, else if" and "sw" are added.
This is because the description structure of "itch" is different. That is, in the “switch” statement, the actual conditional statement is “c
As described in “asse, default”, such control is performed so that the branch nest level does not become illegal and the conditional statement block is surely extracted.

When a conditional statement is detected, the branch number is subsequently incremented by 1 to secure a new branch information data area (SC16), and the branch number, the extracted "conditional statement" and memory are stored in the comment buffer. Write the comment, branch nest level, and stub function related to the "test content" that are specified in the corresponding fields of the branch information data (SC
17-27). When there is no stub function (SC25), "none" is set in the "stub information" column of the branch information table (SC25-1).

Finally, the table set flag is turned ON (SC28), and the process proceeds to step SC4 for reading one row again.

The table set flag will be briefly described here. As shown in FIG. 14, whether the extracted character string is inside the conditional statement block (character string A) or outside the conditional statement block (character string B). It is used for the purpose of determining
As shown in, when the conditional statement block is exited (SC3
2), this table set flag is turned off (S
C33-1). It should be noted that the determination as to whether or not the conditional statement block has been skipped (SC32) stores the variable NEST indicating the nesting level described above in the variable Z1 for each conditional statement, and detects the curly braces "}" indicating the end of the processing block. Then, the variable NEST calculated at the time is compared with the above-mentioned variable Z1, and (NEST = Z
If 1-1), it is determined that the conditional statement block is exited.

On the other hand, if the read one-line character string does not include a "conditional sentence" (proceed to SC10), if a comment is stored in a predetermined buffer, the comment is a comment regarding a confirmation item. Write the content of the comment in the corresponding field of the branch information data (SC3
9) If it is a stub function, write it in the corresponding field of the branch information data (SC42).

If the function is a forced termination function of "exit" or "return", the conditional block is terminated there, so "none" information indicating that there is no next branch in the next branch number field of the branch information data. Write (SC4
4).

As shown in FIG. 12, when "nesting level is 1" and "branch nesting level is 0", the character string is the information to be registered in the outside branch table, and therefore the comment is written in the comment buffer. If there is, the content of the comment is written in the "confirmation item field" of the outside-branch information table (SC47), and if there is a stub function (corresponding to "sub3 ()" in this embodiment), "stub of outside-branch information table". Function field "(SC4
9).

Finally, the comment flag is turned off (S
C50), and returns to step SC4 of reading one line again.

FIG. 15 shows the contents of the branch information table after the creation processing of the branch information table and the non-branch information table of the test item data is executed.

(3) Process for assigning next branch number This process is a process for determining the processing structure of the module, that is, the "tree structure". In short, the above-mentioned FIG.
By determining the next branch number based on the branch information table of No. 5, the tree structure of the module is known.

16 and 17 are flowcharts for explaining the process of assigning the next branch number.

FIG. 18 shows the contents of the branch information table after executing the process of assigning the next branch number.

Here, the process of writing the next branch number (SB
3) will be described in detail based on the flowcharts of FIGS. 16 and 17.

First, as the initial value of the branch number of the branch information table to be processed, the branch No. The counter is set to "1" (S1).

Next, the branch No. From the branch information table corresponding to the above, obtain the nest level (when registering the table, register the number corresponding to the nest depth as the nest level. The process with the shallowest nest is the nest level "1".) ( S2).

If the nesting level is "1", it means that the nesting is the shallowest process, and therefore the process directly proceeds to the process for acquiring the next branch number (S5).

On the other hand, when the nesting level is other than "1", it means that the nesting is included in the branching process with a shallower nest than that of itself (this is the parent branching), so the nesting is "1". Branch No. to the branch information table (next number information field) of the shallow parent branch. Is added (S29).

Next, among the next branch numbers of the parent branch, the next branch number of the same nest level as the parent branch is also the next branch number of itself, so it is copied to the "next number information" field of the branch information table ( S30) Return to the process of acquiring the next branch number (S5).

When the next branch number is registered and "none" is not set, the if flag and sw flag are set to "0" (S7). When "none" is set in the next branch number (when registering the branch information table,
When "return" or "exit" is detected, "none" is set in the "next number information" field. This means that the processing of the test target module ends in the current branch processing block. ) Means that there is no branch processing to proceed to, so branch No. Is incremented by "1" (S27), and the branch number to be processed is updated.

After the if flag and the sw flag are set to "0", the conditional sentence type is acquired (S8). If the conditional statement type is “if” or “else if”, then if
The flag is set to "1" (S10). If the conditional statement type is "case", the sw flag is set to "1" (S12), and otherwise the flag is not set.

Next branch No. The counter displays “Branch N
o. +1 "is set (S13). Next branch No. From the branch information table of (S1
4), branch No. Compare with the nesting level of (S1
5). If the nesting levels match, the next branch N
o. The process proceeds to the process of acquiring the branch statement type from the branch information table (S16). If the nesting levels do not match or the next branch No. If the branch information table of No. does not exist, it means that the setting of the next number for the branch number to be processed has been completed, so that the branch No. Is incremented by "1" (s27), and the branch number to be processed is updated.

When the if flag is "1", the acquired next branch number. If the branch statement type of "else if" or "else" is not the next branch number to be set (the else if statement or else statement following the if statement is not the processing target), the next branch No. The process shifts to "1" for counting up (S25). If the if flag is “1”, the acquired next branch N
o. Branch statement type is "elseif" or "els"
If the flag is other than "e", the if flag is set to "0" (S19), and the branch number. The next branch number is set in the branch information table (next branch number field) (S23).

On the other hand, when the sw flag is "1", the acquired next branch No. If the branch statement type is "case" or "default", it is not the next branch number to be set (case statement or default following the case statement).
The ult statement is not the processing target. ), The next branch No. Shifts to the process of counting up "1" (S2
5). When the sw flag is “1”, the acquired next branch number. Branch statement type is "case" or "def"
The sw flag is set to "0" for the grandmothers other than "ult" (S22). Next branch number is set in the branch information table (next branch number field) (S2
3). When both the if flag and the sw flag are “0”, the branch No. The next branch number is set in the branch information table (next number field) of (S23). After setting the next branch number, the next branch number. If the branch statement type is other than "else" or "default" (S
24) is the next branch No. Is incremented by "1" (S25). In addition, the next branch No. The branch statement type is "e
In the case of “lse” or “default”, the branch does not proceed directly to the next branch, so the branch No. Is incremented by "1" (S27), and the branch number to be processed is updated. Next branch No. Is counted up, and the next branch No.
If the branch information table of No. exists (S26), the next branch No. The process returns to the process (S14) of acquiring the nest level of. Next branch No. If the branch information table of No. exists, the branch No. Is incremented by "1" (S2
7) Update the branch number to be processed.

Branch No. If the branch information table of No. exists, the branch No. To get the nesting level of (S
Return to 3). Branch No. If the branch information table of No. does not exist, it means that the setting of the next branch number information to all the branch information tables has been completed, and the processing is ended (S31). In this way, the next number information is registered based on the branch information table manufactured in advance.

(4) Leading Branch Number Table Creating Process FIG. 19 is a flow chart for explaining the leading branch number table creating process. The process will be described in detail with reference to this flowchart.

First, since the branch processing block at the head of the tree structure is the branch processing block with branch number 1,
The branch number is set to 1 (se1), and the maximum value of the branch numbers registered in the branch information table of FIG. 6C (the number of branch information tables is 6 in this example) is compared with the branch number.

If (branch No.) <(Branch information table), the process proceeds to YES in se2 to acquire the branch nest level (se3).

It is judged whether the branch nest level is "1" (if the branch nest level is 2 abnormal, it does not become the head of the tree). If it is 1, the process proceeds to YES in se4 to acquire the condition statement type ( se5).

Next, the branch No. is registered in the head branch number table of FIG. 6B (se6), and it is determined whether the condition statement type acquired earlier is other than "else" or "default" (se7). . Condition sentence type is "els"
In the case of "e" and "default", the branch processing block that follows is always processing after passing through the previous branch processing block. That is, since there is only a branch processing block that is unlikely to be the head of the branch, the process of creating the head head branch number table ends.

Here, since the conditional statement type is "if", there is a possibility that there is a branch processing block at the beginning of the tree, so the processing proceeds to YES in se7, 1 is added to the branch No, and to se2. Return.

In se3, the branch nest level (= 1) of the branch number 2 is acquired, the process proceeds to YES in se4, and the conditional statement type (“else”) is acquired (se5).

In se6, as described above, since the conditional statement type is "else", it is determined that there is no branch processing block that may already be at the beginning of the tree, and N7 in se7.
The process proceeds to O to end this processing.

By this processing, the branch numbers 1 and 2 are registered in the head branch number table of FIG. 6 (b). The next branch number in the branch information table is "none" from the first branch number in the first branch number table assigned by the processing explained above.
The tree structure shown in FIG. Therefore, if at least the items “test content”, “confirmation item”, and “stub function” in the branch information table are extracted and a test item vote is created, a test item vote that follows all branches of the tree can be created.

[0075]

As described above, according to the present invention, a test item form for a unit test can be automatically created from a source program in which a module to be tested is described.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of a program test system of the present invention.

FIG. 2 is a flowchart showing a processing procedure of the test system of the present invention.

FIG. 3 is a program configuration diagram.

FIG. 4 is a diagram showing a source program of a module to be tested.

5 is a diagram showing the source program of FIG. 4,
(A) is a flowchart and (b) is a tree structure diagram.

FIG. 6 is a data format diagram showing work data required when creating a test item data file, where (a) is a header information table, (b) is a head branch number table, (c) is a branch information table, and (d). ) Is a diagram showing a non-branch information table.

FIG. 7 is a flowchart showing an outline of a method for creating test item data.

FIG. 8 is a flowchart illustrating a method of creating a branch information table and a non-branch information table of test item data.

FIG. 9 is a flowchart illustrating a method of creating a branch information table and a non-branch information table of test item data.

FIG. 10 is a flowchart illustrating a method of creating a branch information table and a non-branch information table of test item data.

FIG. 11 is a flowchart illustrating a method of creating a branch information table and a non-branch information table of test item data.

FIG. 12 is a flowchart illustrating a method for creating a branch information table and a non-branch information table of test item data.

FIG. 13 is a flowchart illustrating a method of creating a branch information table and a non-branch information table of test item data.

FIG. 14 is a diagram showing a character string.

FIG. 15 is a diagram showing the contents of a branch information table.

FIG. 16 is a flowchart illustrating a process of assigning a next branch number.

FIG. 17 is a flowchart illustrating a process of assigning a next branch number.

FIG. 18 is a diagram showing the contents of a branch information table.

FIG. 19 is a flowchart illustrating a process of creating a leading branch number table.

FIG. 20 is a diagram showing a test item form.

[Explanation of symbols]

 1 CPU 2 External storage device (floppy disk) 3 Input unit (keyboard) 4 Display device (CRT) 5 Output unit (printer)

Claims (1)

[Claims] 1. A method of creating a test item form used for a unit test of each program of a program hierarchically composed of a plurality of modules, wherein each source statement of the module should be tested for each execution statement. A step of preparing an item (test item) or an item (confirmation item) to be confirmed corresponding to the test item as a comment statement, and the test item and the check item while reading the source program for each execution statement Is subdivided into a pair of execution unit data, and when the execution statement corresponding to the test item of the execution unit data is a branch statement, the execution unit data is stored in a branch information table, and the test item of the execution unit data is If the execution statement corresponding to is other than a branch statement, the execution unit data is stored in the non-branch information table. Data extraction step and the connection of the execution unit data, the number of the execution unit data located at the beginning of the branch processing is stored in the head branch number information table, and the execution unit data to be processed next to the execution unit data is stored. A branch structure extracting step for obtaining a branch structure of the source program of the module by storing a number as a next branch number in the execution unit data; and an execution unit corresponding to the number of the execution unit data stored in the leading branch number information table. The process of connecting the execution unit data corresponding to the next branch number of the execution unit data starting from the data is repeated until the next branch number disappears,
A method of creating a test item vote used for a unit test of a program module, comprising a test item vote creating step of creating a test item vote including at least the test item and the confirmation item.