JPH07210424A - Software test supporting system - Google Patents

Abstract

PURPOSE:To provide a software test supporting system capable of easily executing an efficient software test. CONSTITUTION:A source code 1 prepared by a structured programming procedure is sorted into plural unit routines by a source code analyzing means 10 and calling relation among respective unit routines is also analyzed. A test case preparing means 20 prepares plural test cases covering all calling patterns based upon the calling relation of respective analyzed unit routines. since the test cases can be automatically prepared based on the source code 1, the test cases can be more simply prepared as compared with a convential system for preparing test cases based on the specifications of software described by natural language such as Japanese, the status transition specifications of the software, etc.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a software test support system used when performing an operation test in software development, and in particular, uses a structured design technique to use a high-level language such as C language. The present invention relates to a software test support system used for operation test of application software developed by.

[0002]

2. Description of the Related Art Conventionally, the operation test of software is
The test is often insufficient due to two factors such as "Insufficient examination of test case creation" and "Test case is not tested reliably".

A normal software operation test is performed by manually creating a test case based on a software specification written in a natural language such as Japanese and based on the test case. However, the work of creating the test case often depends on the description content (level) of the original software specification and the ability of the individual who considers the creation of the test case, which causes the deterioration of the quality of the test case.

On the other hand, in the case of bug correction or software revision accompanying version upgrade, a test is often conducted based on an operation test conducted at the time of creating software before revision. However, it is not clear whether the tests performed by this method are sufficient as test cases for the target software. This is because, when a new function is added to the software before modification, a new test is required for the added function part.

As a method for solving such a problem, a method of automatically creating a test case from a state transition specification has been proposed. The automatic generation method of this test case is described in detail in the following documents.

"Method for generating test data from state transition specifications" Proceedings of the 42nd National Convention of Information Processing Society of Japan, pp5-21
8. Okayasu et al. The outline of the automatic test case generation method described in this document uses the operation pattern (operation sequence) of software based on the state transition specification as a test case. Specifically, paying attention to the event that causes the transition from the state described in the state transition model, create an event sequence in which the events that occur are sequentially arranged, and the state transition of the system caused by this is taken as a test pattern as a test case. It is used for.

However, since this generation method is premised on that the state transition specifications are created when the software is created, its applicable range is extremely narrow and not practical.

Regarding the sufficiency of the test, attempts have been made to evaluate the sufficiency by measuring the test coverage indicating how comprehensively the source code is executed in a series of operation tests. (Reference: Tetsuo Tamai "Software Testing Techniques" p3
4,35 Kyoritsu Publishing). However, most test coverage measures the passage rate of instructions and conditional branches contained in each module, and since it goes into the details of software, it can be used for higher level tests such as system tests and software system tests. It was not suitable for test adequacy evaluation.

Further, in the operation test of software,
If the target source code is modified or changed,
It is necessary to examine the test case again. Especially for software created using structured design techniques, some modules that make up the source code are modified and
This is because the influence of the change often affects the module of another part, and it is not always necessary to simply retest only the corrected / changed module part.

[0010]

As described above, in the past, a method of creating a test case for executing a software test has not been established, and a test sufficiency evaluation method is biased. It was a problem.
Therefore, there has been a demand for a software test support system capable of efficiently generating a test case and easily performing a test sufficiency evaluation when a test is performed according to the test case.

The present invention solves such a conventional problem by automatically creating a test case from the source code of the software under test, comparing the test execution result with this test case, and evaluating the module. It is an object of the present invention to provide a system for determining the sufficiency of a test by measuring coverage and identifying untested modules.

Further, according to the present invention, even when the target software is modified or changed, the modified software can be easily supported by generating a test case by comparing the source code and the test case before the modification. The purpose is to provide a system.

[0013]

In order to solve the above problems, the software test support system of the present invention is
Based on (a) a source code analysis unit that classifies the source code into a plurality of unit routines and analyzes the call relationship of each unit routine, and (b) a call relationship of each unit routine that is analyzed by the source code analysis unit, And a test case creating means for creating a plurality of test cases covering all the calling patterns.

Further, (c) a test case report output means for outputting a list of a plurality of test cases created by the test case creation means in a form may be provided.

Further, (d) a test probe inserting means for inserting a test probe into each unit routine of the source code, and (e) a load module by compiling and linking the source code in which the test probe is inserted by the test probe inserting means. May be provided, and (f) a test execution means for executing the load module created by the load module creation means based on each test case created by the test case creation means. In this case, the test probe is an instruction group including at least an instruction for opening a predetermined history file and an instruction for writing a number identifying a unit routine to be inserted into the history file.

Furthermore, (g) by analyzing the history file written by the execution of the load module by the test execution means, a percentage of all the unit routines in the source code is written in this history file. It is also possible to provide a module coverage rate evaluation means for detecting whether or not the module is present and detecting an unexecuted module.
In this case, (h) module coverage rate output means for outputting the module coverage rate detected by the module coverage rate evaluation means and a list of unexecuted modules in a form may be provided.

Furthermore, (j) the history file written by the execution of the load module by the test execution means is analyzed, and the percentage of the test cases among all the test cases created by the test case creation means is this. A test case coverage evaluation unit may be provided to detect whether the test case has been written in the history file and detect an unexecuted test case. In this case, (k) test case coverage rate output means for outputting a list of test case coverage rates and unexecuted test cases detected by the test case coverage rate evaluation means in a form may be provided.

Furthermore, (l) modified source code analysis means for classifying the source code, which has been modified by bugs or by version upgrade, into a plurality of unit routines,
(M) A first modified unit routine that detects a deleted unit routine and an added unit routine by comparing the unit routine classified by the source code analysis unit with the unit routine classified by the modified source code analysis. (N) second modified unit routine detection means for comparing the source code before and after the modification and detecting the modified unit routine among the unit routines classified by the modified source code analysis; ) Among the test cases created by the test case creating means, the test case for the additional unit routine detected by the first modification unit routine detecting means and the modification unit detected by the second modification unit routine detecting means A re-execution target test case specifying unit that specifies a test case that targets a routine may be provided.

[0019]

According to the software test support system of the present invention, the source code created by using the structured programming method is classified into a plurality of unit routines by the source code analysis means, and the calling relation of each unit routine is further classified. Analysis is done. The unit routine includes a routine divided into task units and a routine divided into module units. Here, a task is a unit that realizes one integrated processing function as software in a structured program, and a module is a basic unit of a software structure in a structured program. The test case creating means creates a plurality of test cases covering all calling patterns based on the analyzed calling relationships of the unit routines. In this way, it is possible to automatically create a test case from the source code of the software to be tested. Therefore, based on the software specifications written in natural language such as Japanese and the software state transition specifications, etc. It is possible to create a test case more easily than the conventional method of creating a test case.

The list of the plurality of test cases created by the test case creating means is output in the form of a report by the test case report output means. The document output in this manner can be used as a reference when conducting a software test.

In order to perform a test based on the test case created by the test case creating means, the following processing is performed. First, the test probe insertion means inserts a test probe into each unit routine of the source code. The source code after inserting the test probe is compiled and linked by the load module creating means to create a load module. This load module is executed by the test execution means, and the numbers of all called modules are recorded in the history file.

The history file is analyzed by the module coverage rate evaluation means, and the module coverage rate and unexecuted modules are detected. By performing such detection, it becomes possible to explicitly grasp the omission of the test,
The sufficiency of the test is dramatically improved compared to the past. In particular,
Since the detection result can be output in the form of a form by the module coverage ratio output means, it is possible to efficiently create an additional test or the like.

The history file is also analyzed by the test case coverage evaluation means to detect the test case coverage and unexecuted test cases. By performing such detection, it becomes possible to explicitly grasp the omission of the test, and the sufficiency of the test is dramatically improved as compared with the conventional method. In particular, since the detection result can be output in the form of a report by the test case coverage output means, it is possible to efficiently create an additional test or the like.

When a bug or the like found at the time of testing is corrected or a version is corrected, the corrected source code analyzing means classifies the corrected source code into a plurality of unit routines. Then, the first correction unit routine detection means compares the unit routines before and after the correction,
Deleted unit routines and added unit routines are detected. Further, the source code before and after the correction is compared by the second correction unit routine detecting means, and the corrected unit routine is detected. The additional unit routine and the modified unit routine detected in this way are given to the re-execution target test case identifying means, and the test cases targeting these unit routines are identified. By this identification, the test case to be executed in the retest is judged and evaluated, and the portion to be tested with particular emphasis can be identified, so that the efficient retest can be performed.

[0025]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the accompanying drawings.

1 to 3 are block diagrams showing the configuration of a software test support system according to this embodiment.
From these figures, the software test support system of the present embodiment classifies the source code 1 into a plurality of modules (or tasks) and analyzes the calling relationship of each module, and the calling relationship of each module. And a test case report output unit 30 that outputs a test case report 31.
Also, a test probe insertion unit 40 that inserts a test probe into the source code 1, a load module creation unit 50 that compiles and links the source code 1 to create a load module 3, and a load module 3 is executed to perform test coverage. A test coverage measuring unit 60 for measuring is provided.

Further, a module coverage rate evaluation unit 70 for detecting a module coverage rate and an unexecuted module,
A test case coverage evaluation unit 80 that detects test case coverage and unexecuted test cases, and a module coverage output unit 90 that outputs a test coverage report 91.
And a test case coverage percentage output unit 100 that outputs an untested module transition path report 101. Furthermore, a modified source code analysis unit 110 that classifies the modified source code 6 modified by debugging or the like into a plurality of modules, and a source code change impact evaluation unit 120 that evaluates the effect on the test case due to the modification of the source code 1.
And a re-execution target test case specifying unit 130 that specifies a test case that targets the added / modified module. Also, the source code change impact evaluation unit 12
0 is a first correction module detection unit 121 that detects a deleted module and an added module,
A second modified module detection unit 122 for detecting a modified module is provided.

The processing of the software test support system of this embodiment includes (1) processing for automatically generating test cases, and (2) processing for measuring / evaluating the sufficiency of tests.
(3) It is divided into processing that supports retesting.

The source code analysis unit 10, the test case creation unit 20, and the test case report output unit 30 are involved in the automatic test case generation processing. The test sufficiency measurement / evaluation processing is performed by the test probe insertion unit 40, the load module creation unit 50, and the test coverage measurement unit 6.
0, module coverage evaluation unit 70, test case coverage evaluation unit 80, module coverage output unit 90, and test case coverage output unit 100. Furthermore, the retest support process involves the modified source code analysis unit 110, the source code change impact evaluation unit 120, and the re-execution target test case identification unit 130. Hereinafter, each process will be described.

(1) Automatic test case generation processing In order to automatically generate a test case, the source code analysis unit 10 is first executed to analyze the source code. The source code analysis unit 10 has a role of analyzing the source code 1 of the software to be tested and clarifying its internal structure. Here, the internal structure of software is
It means the relationship between the tasks and modules that make up the software. It is to clarify what kind of tasks the software is composed of, what kind of modules the tasks are composed of, and what kind of call relationship each of the tasks and modules have. For example, when the source code 1 is created by C language, the control structure (if-then-else, while, de
~ While, switch, goto, label,
break, continue, return, fo
r) is analyzed and the task and module are analyzed based on the syntax rules. Related documents include Japanese Patent Laid-Open No. 1-283631.

FIG. 4 is a diagram showing an example in which the internal structure of the source code 1 is analyzed by the source code analysis unit 10. In this example, the source code 1 is modules A and B
1, B2, C1, C2, C3, D1, D2. For example, it can be seen that the module C2 sequentially calls the modules D1 and D2 as its lower modules. Further, it can be seen that the module C3 independently executes the process when called from the module B1 and does not call the lower module, but further calls the module D2 when called from the module B2 to perform the process. Therefore, the module calling relationship obtained by the source code analysis unit 10 corresponds to the actual calling relationship in consideration of the processing conditions inside the module.

After the internal structure of the software is clarified by the analysis of the source code analysis unit 10, the test case creation unit 20 is executed to create a test case to be executed as a software test based on the internal structure of the software. The test case is created so as to cover all the calling sequences that can occur in the actual software operation in consideration of the calling relationship between the tasks and modules that make up the software.

FIG. 5 shows test cases extracted from the software having the internal structure shown in FIG. 4 based on the above idea. As shown in FIG.
Nine test cases are extracted from 1 to Case-9. Next, as a specific example of the extraction of test cases, let us consider, for example, office processing software centering on screen processing. In this case, each module has a structure corresponding to each display screen.
FIG. 6 is an example of a module-related diagram showing an internal structure of software related to financial processing, which is mainly screen processing. Further, FIG. 7 is a block diagram showing the relation of the software processing operation based on the call between the screens of the software. For example, the “Accounting management system initial screen” shown in FIG. 7 when this software is executed is
From the viewpoint of the internal structure of the software, the processing of the (accounting processing main) module shown in FIG. 6 corresponds. In FIG. 7, sub-functions such as "input processing selection function" and "daily processing selection function" can be selected from the "accounting management system initial screen", and these sub-functions can be selected from the "accounting management system initial screen". Is called and executed. From the viewpoint of the internal structure of the software in FIG. 6, this is in the lower level of the (accounting process main) module (input process),
It can be seen that it is realized by calling each module such as (daily processing).

As can be seen from FIGS. 6 and 7,
Regarding such software, the module relation diagram showing the internal structure is deeply related to the screen calling relation and the processing operation relation of the target software.

Therefore, the test case that covers the transition series of the above-mentioned calling relationship generated based on the module relation diagram of FIG. 6 covers the series of processing operations related to the target software.

FIG. 8A shows an example of the test case generated based on FIG. 6, while FIG. 8B shows the flow of the processing operation of the target software assumed from FIG. Is. In the test case (Case-2) generated in FIG. 8A, from the module calling relationship,
From (General Management Main) module (Account Management Main)
Call Modme, and then (input processing) (daily processing)
A module transition series that sequentially calls each module of (monthly processing) (master maintenance) (account settlement processing) is generated as a test case. On the other hand, considering the processing operation of the target software in FIG. 8B, select (Accounting management system initial screen) from (Integrated management system initial screen), and further down (input processing function selection screen) (day It can be seen that there is a flow of sequentially activating the next process selection screen) (monthly process selection screen) (master maintenance process selection screen) (accounting process selection screen). The flow of this processing operation is shown in FIG.
This corresponds to the module transition in the test case generated in Case-2 of (a).

As described above, the test case created from the transition series of the module calling relationship covers the series of processing operations related to the target software. The module relation diagram is obtained by executing the source code analysis unit 10.

The test case created in this way is held as the test case file 2. The test case file 2 is used as reference information for determining which of the test cases created here after the test is tested or not tested. Also, when a defect occurs in the first test and retesting is performed on software with a bug fixed, valid ones of the test cases held in the test case file 2 are reused. .

Furthermore, the created test case is output as a test case report 31 by the test case report output unit 30 from a normal printer in a form. The test case report 31 serves as a reference when conducting a software test. FIG. 9 is a diagram showing an example of the test case report 31 output in the form of a form.

Next, the procedure for generating a test case from the module relation diagram will be described with reference to the flowchart of FIG. For example, when considering creating a test case from the module relation diagram of FIG. 4, first, the module A, which is the highest module of the module relation diagram, is selected as the starting module for creating the test case (step 201). . Next, the submodule called from this starting module is specified by the module relation diagram (step 202). In the example of FIG. 4, two modules B1 and B2 are specified as the lower modules of the module A.

Next, the calling format of the lower module thus identified is confirmed (step 203). The call format is a method in which a lower module is called from a higher module. There are two ways to call a lower module: one is called unconditionally and the other is called when conditions are met. For example, in the example of FIG. 4, as the internal processing of the module A which is the starting module, the case where the lower modules B1 and B2 are sequentially called, and the case where only the lower module B1 is called by the internal condition processing. Similarly, it is possible that only the lower module B2 is called. The call format of these lower modules is specified by analyzing the internal processing procedure of the starting module.

By the above operation, the test case primary tree starting from the starting point module as shown in FIG. 11A is created (step 204). Test case 1
After the next tree is created, it is determined whether or not the calling module exists below the current starting module (step 205). Next, the starting module is moved to the module one level lower. That is, in the example of FIG. 4, the module B1 is selected as the starting point module (step 206).

After that, with respect to the similarly selected starting case module for creating a test case, the subordinate module is specified and the calling format is specified, and the test race primary tree for this starting module is created (step 204).
Similarly, a test case primary tree having each module as a starting point is created by sequentially moving the starting point module to a lower position (step 204). FIG. 11B is an example of a test case primary tree for each module created based on the module relation diagram shown in FIG.
The test case primary trees of the respective modules thus created are fused to comprehensively create the test cases (step 207).

FIG. 12C is an example of a test case created by fusing the modules of FIG. 11B with the test case primary tree. In the fusion of the test case primary trees, the fusion is advanced focusing on the same node on the tree.
For example, in order to fuse and generate Case-1 shown in FIG. 12C, attention is paid to the following four test case primary trees.

Attention is first focused on the module B1 at the end of the test case primary tree <a>. Next, the test case primary tree starting from the module B1 is searched, and <b1> is obtained as the corresponding primary tree.

Focus on the terminal module C1 of the test case primary tree <b1>.

Next, the test case primary tree starting from the module C1 is searched, and the corresponding primary tree <b
2> is obtained.

Attention is paid to the terminal module D2 of the test case primary tree <b2>.

Next, the test case primary tree starting from the module D2 is searched, and the corresponding primary tree <b
3> is obtained.

At the end of the test case primary tree <b3>, it can be seen that there is no lower module as (E), so the search / fusion of the test case primary tree is completed here.

In this way, the search and fusion are sequentially carried out using the end module of the test case primary tree as a key. From the above results, as shown below, a series of test cases shown in Case-1 are fusion-acquired.

<a> Module A → Module B1 <b1> Module B1 → Module C1 <b2> Module C1 → Module D2 <b3> Module D2 → E Case-1 Module A → Module B1 → Module C1 → Module D2 (2 ) Test sufficiency measurement / evaluation process In order to measure the test sufficiency during test execution, a probe for coverage measurement is inserted in the target software. This procedure will be described with reference to the flowchart of FIG.

Regarding the insertion of the test probe, first, all the constituent modules classified by the source code analysis unit 10 are numbered (step 301). 14
Is an example in which each module is numbered with respect to the modules constituting the software shown in FIG. 5, and a correspondence table of each module name and the number assigned is generated.

A counter (test probe) for checking the passage of each task and module is inserted at the beginning of the task and module that compose the target source code (step 302). As shown in FIG. 15, this counter (test probe) is a combination of an instruction (File Write instruction) for writing the number of the task or module in the module passage management file 4.

This counter (test probe) has a role of writing the value of the task or module number to the module passage management file 4 when the task or module is executed. For example, in the software shown in FIG. 5, the module C3 has the module number "0".
6 "is allocated, and in this case, the test probe as shown in FIG. 15 is automatically inserted at the beginning of the module C3 of the source code.

This counter (test probe) has a role of writing the value of the task and the module number to the module passage management file 4 when the task and the module are executed. For example, in the software shown in FIG. 5, the module C3 has the module number "0".
6 "is allocated, and in this case, the test probe as shown in FIG. 15 is automatically inserted at the beginning of the module C3 of the source code.

By compiling and linking the source code in which this test probe is embedded, it is possible to measure the test coverage and evaluate the sufficiency of the test (step 303).

The test coverage is measured by executing the software in which the above test probe is inserted. The test coverage measuring unit 60 sets the module passage management file 4 of the software to be tested during the test execution. The processing procedure of the test coverage measuring unit 60 will be described with reference to the flowchart of FIG.

In the test coverage measuring unit 60, the number of times the software to be test-activated is activated is constantly monitored (step 401). Then, it is determined whether or not the software has started up (step 40).
2). When the software that has not been started before is started for the first time, the test coverage measuring unit 60 automatically creates the module passage management file 4 in a writable state (step 403). If the software has already been activated in the past, the corresponding module passage management file 4 is opened in a writable state (step 404).

As described above, the module passage management file 4
The target software is actually started in the state where the module is opened, and the module passage information is written from the test probe when the module passes (step 40).
5). The module passage management file 4 is set when the software in which the test probe is inserted is first started, and the passage history of the module is continuously recorded unless the software is changed.

An example of the file contents of the module passage management file 4 is shown in FIG. In this file, the test execution date and time and the task / module path at the time of execution are recorded. As shown in FIG. 17, the module passage management file 4 includes a target load module designation unit 18 and a test passage module recording unit 19. The target load module designation unit 18 records the name of the load module of the software to be tested, the creation date and time, and the like. Further, the test passing module recording unit 19 records the date and time when the designated load module was tested and the passed task / module number counted based on the test probe.

In the example of FIG. 17, the load module to be tested is "ESQ-SYS.EXE" and the creation date is "93".
-6-3 15:19 ", and the test date is" 93-
In the 6-5 10:14 "test, it is recorded that the series of module numbers" 01, 04, 09, 02, 01 "was tested.

When the passage history of the module is recorded in the module passage management file 4 by the execution of the test coverage measuring unit 60, next, the module coverage evaluation unit 7
0 and the test case coverage evaluation unit 80 are executed to evaluate the sufficiency of the test.

First, in the module coverage evaluation unit 70,
The module recorded in the configuration module list shown in FIG. 14 and the test execution module number recorded in the module passage management file 4 shown in FIG. 17 are collated to determine which of the modules configuring the target software. It is evaluated whether the percentage has been passed. At the same time, modules that have not passed at the time of testing are specified and a list (untested module list) is created. In the case of FIGS. 14 and 17, it can be seen that the modules C3, C5 and D4 have not been passed.

Next, in the test case coverage evaluation unit 80, the test cases shown in FIG. 5 and the test execution module numbers recorded in the module passage management file 4 shown in FIG. Of these, what percentage is tested is evaluated. At the same time, test paths that have not been tested are specified, and a list (untested module transition path list) is created. In the case of FIGS. 5 and 17, among the test cases shown in FIG.
It can be seen that the -4, 5, 7, 8, 9 paths have not been tested.

The sufficiency of the test is evaluated from the above two viewpoints, the evaluation result is stored in the test result evaluation file 5, and the test coverage report 91 and the untested module transition path report 101 are stored.
Provided to users of this system.

18 and 19 show examples of the test coverage report 91.

FIG. 18 is an example of a “module coverage evaluation report” which is one of the test coverage reports 91, in which the module coverage in a test is calculated from the number of modules constituting the target software and the number of modules executed during the test. -It is written. In addition, FIG.
Is an example of “Module Transition Path Coverage Evaluation Report”, which shows the actual number of tested transition sequences with respect to the number of possible transition sequences between modules that compose the target software. Test coverage is calculated and written.

Untested Module Transition Path Report 101
As for the above, examples thereof are shown in FIGS. Figure 20
Is an example of the “untested module report”, and the module names that have not passed at the time of test execution are listed. FIG. 21 is an example of the “untested module transition path report”. In this report, among the series of transitions between modules that make up the software, paths that have not been confirmed in actual tests are listed as a series of module names.

The test sufficiency evaluation in the present support system is performed by using the total when the target software is executed a plurality of times.

(3) Retest Support Process In software development, usually, a bug found in the test stage is corrected and the test is performed again. In addition, when the version is upgraded, the source code is modified by adding or changing functions, and it is necessary to test again. In such cases, it becomes a problem to identify which part of the modified source code needs to be tested, and create and test a test case corresponding to this.

This system also supports the creation of test cases for these retests.

The source code change impact evaluation section 120 has a role of comparing the source code which has been subjected to the normal first test and the source code which is modified by reflecting the test result. The source code change impact assessment unit 120
A first correction module detection unit 121 that detects a deleted module and an added module, and a second correction module detection unit 1 that detects a corrected module.
And 22 are provided.

In the first correction module detector 121,
The source code structure analysis is performed on the changed source code to clarify the software internal structure as shown in FIG. 4 and to compare with the previously analyzed software internal structure before the change. This makes it possible to identify which module has been deleted / added and which has changed the calling relationship.

In addition, the second correction module detection section 122
Then, the source code before the change and the source code after the change are compared with each other in terms of the number of steps, the number of conditional statements, the number of loops, etc. of each constituent module, and if they are changed, change or modify It can be specified as a module.

FIG. 22 shows the first correction module detector 1
21 shows an example of processing in 21. In the software before the change, the module B1 is the modules C1, C2, C
3 and module C2 is module D
I was calling 1, D2. On the other hand, in the software after the change, only the modules B1, C1 and C2 are called, and the module C2 calls the modules D1 and E1, and it can be seen that the calling relationship is changed.

FIG. 23 shows the second correction module detector 1
22 shows an example of processing in 22. In the software before and after the change, modules B1, C2, D1 and E
It can be seen that the internal structure of 1 has been changed.

After identifying the changes in the source code that have been modified / changed, it is considered that the test cases generated by the test case change impact evaluation unit 120 before the modification are affected by these source code changes. The test cases that will be used. The additional modules detected by the first correction module detection unit 121 and the correction modules detected by the second correction module detection unit 122 are all subject to retesting.

Considering the source code change impact evaluation shown in FIGS. 22 and 23, it is determined that the following test cases among the test cases generated before the change are affected by the source code change.

Case-1: A-B1-C1-C2-C3 Case-2: A-B1-C2-D1-D2 On the contrary, it is considered that the following Case-3 is not affected by the change of the source code. Therefore, it is determined that retesting is not necessary.

Case-3: A-B2-C3-D2 In the re-execution target test case identifying unit 130, regarding the test case created for the source code before the change,
It has the function of identifying whether or not the effects of source code changes are affected. The information on the test cases identified by the re-execution target test case identifying unit 130 is the test case creating unit 2
Given to 0. Then, the test case creation unit 20 creates the test case of the changed source code 6 again based on this information.

For example, in the examples of FIGS. 22 and 23 shown above, the above-described test cases of Case-1 and Case-2 are targets of retesting, while Case-3 is not affected by the source code change. Therefore, it is excluded from the retest test cases.

When the source code changed in this way is tested again, the sufficiency (coverage rate) of the test for the changed software, unexecuted paths,
The unexecuted module is specified. In this case, for the test sufficiency evaluation, it is determined how much the test is performed, including the modules and the module transition paths that are not affected by the modification. In addition, unexecuted modules and unexecuted module paths are also pointed out, including modules that are not affected by changes and module transition paths.

[0084]

As described above, according to the software test support system of the present invention, an efficient software test can be easily performed. That is, it is possible to automatically extract a test case for the test of software created in a normal development language. The test cases generated at this level are
It can be used as a reference for software / system testing of the target software, which allows efficient creation of complete test specifications.

Further, by inserting a test probe for measuring the sufficiency of the test into the source code of the target software, the "module coverage rate" for evaluating how much the modules constituting the target software are tested during the test execution Also, it is possible to evaluate the "module transition path sequence coverage rate" that evaluates how much the transition sequence of executable modules has been tested in consideration of the relationship between each module. In addition, it is possible to confirm these evaluation results as a report. As a result, it becomes clear which module or which module transition path has not been specifically tested when the target software is tested, and efficient test execution and evaluation become possible. By this module coverage rate, module transition path coverage rate, specification of untested module, and specification of untested module path, more reliable software / system test can be performed.

Further, the test case generation from the source code and the sufficiency evaluation at the time of executing the test facilitate the efficient execution of the software test. Further, this prevents omissions and deviations of tests, enables effective testing of software, and improves quality and productivity.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration of a software support system according to an embodiment.

FIG. 2 is a block diagram showing a configuration of a software support system according to the present embodiment.

FIG. 3 is a block diagram showing a configuration of a software support system according to the present embodiment.

FIG. 4 is a diagram showing a module configuration of software to be subjected to a software test.

FIG. 5 is a diagram showing an example of extracted test cases.

FIG. 6 is a module related diagram showing an internal structure of software related to financial office work processing, which is centered on screen processing.

FIG. 7 is a block diagram showing a relation of processing operations of software related to financial office processing, which is centered on screen processing.

FIG. 8 is a diagram showing an example of a flow of generated test cases and processing operations.

FIG. 9 is a diagram showing an example of a test case report output by this device.

FIG. 10 is a flowchart showing a procedure for generating a test case.

FIG. 11 is a diagram showing a test case tree for generating a test case.

FIG. 12 is a diagram showing a test case tree for generating a test case.

FIG. 13 is a flowchart showing a test probe insertion procedure.

FIG. 14 is a diagram showing an example in which each module is numbered.

FIG. 15 is a diagram showing an example of source code in which a test probe is inserted.

FIG. 16 is a flowchart showing a processing procedure of a test coverage measuring unit.

FIG. 17 is a diagram showing an example of file contents of a module passage management file.

FIG. 18 is a diagram showing an example of a “module coverage” evaluation result report of the test coverage reports.

FIG. 19 is a diagram showing an example of a “module transition path sequence coverage rate” evaluation result report of the test coverage reports.

FIG. 20 is a diagram showing an example of an “untested module report”.

FIG. 21 is a diagram showing an example of an “untested module path report”.

FIG. 22 is a diagram showing an example of software configuration evaluation by a source code change impact evaluation unit at the time of retesting.

FIG. 23 is a diagram showing an example of internal evaluation of a constituent module based on a source code change impact evaluation at the time of retesting.

[Explanation of symbols]

 1 ... Source code 2 ... Test case file 3 ... Load module 4 ... Module passage management file 5 ... Test result evaluation file 6 ... Modified source code 10 ... Source code analysis unit 20 ... Test case creation unit 30 ... Test case report output unit 31 … Test case report 40… Test probe insertion unit 50… Load module creation unit 60… Test coverage measurement unit 70… Module coverage evaluation unit 80… Test case coverage evaluation unit 90… Module coverage output unit 91… Test coverage report 100 ... test case coverage output unit 101 ... untested module transition path report 110 ... modified source code analysis unit 120 ... source code change impact evaluation unit 121 ... first modified module detection unit 122 ... second modified module detection unit 130 ... Again Line target test case identifying section.

Claims (8)

[Claims] 1. In a software test support system that analyzes a source code created by a structured programming method to support software testing, the source code is classified into a plurality of unit routines, and the call relationship of each unit routine is defined. A source code analyzing unit for analyzing and a test case creating unit for creating a plurality of test cases covering all calling patterns based on the calling relationship of each unit routine analyzed by the source code analyzing unit. Characteristic software test support system. 2. The software test support system according to claim 1, further comprising a test case report output unit that outputs a list of a plurality of test cases created by the test case creation unit in a form. 3. A load module is created by compiling and linking a test probe inserting means for inserting a test probe into each unit routine of the source code and the source code in which the test probe is inserted by the test probe inserting means. A load module creating means, and a test executing means for executing the load module created by the load module creating means based on each test case created by the test case creating means, wherein the test probe is at least a predetermined 3. A command group including a command for opening a history file and a command for writing a number identifying a unit routine to be inserted into the history file.
Software test support system described in. 4. The history file written by the execution of the load module in the test executing means is analyzed, and a percentage of all unit routines of the source code is written in the history file. 4. The software test support system according to claim 3, further comprising module coverage evaluation means for detecting whether or not there is an unexecuted module. 5. The software test according to claim 4, further comprising module coverage ratio output means for outputting a list of module coverage ratios and unexecuted modules detected by the module coverage ratio evaluation means in a form. Support system. 6. The history file written by the execution of the load module by the test execution means is analyzed, and the percentage of test cases among all the test cases created by the test case creation means is the history. 4. The software test support system according to claim 3, further comprising a test case coverage evaluation unit that detects whether or not the test case has been written in the file and detects an unexecuted test case. 7. The test case coverage rate output means for outputting, in a form, a list of test case coverage rates and unexecuted test cases detected by the test case coverage rate evaluation means. Described software test support system. 8. A modified source code analyzing unit for classifying a source code, which is modified by a bug correction or a version upgrade, into a plurality of unit routines, a unit routine classified by the source code analyzing unit, and the modified source code analysis. First modified unit routine detecting means for detecting a deleted unit routine and an added unit routine by comparing with the unit routines classified by, and the modified source by comparing the source code before and after the modification. A second modified unit routine detecting means for detecting a modified unit routine among the unit routines classified by the code analysis; and the first modified unit routine of the test cases created by the test case creating means. A test case targeting the additional unit routine detected by the detection means, and the second
8. The re-execution target test case specifying means for specifying a test case targeting the correction unit routine detected by the correction unit routine detecting means of (1), according to any one of claims 1 to 7. Described software test support system.