JP5743663B2 - Test support system, test support method, and program - Google Patents

Description

  The present invention relates to a test support system, a test support method, and a program.

  In software development, testing is important for ensuring quality. The test is a process for verifying whether software (source code, compiled intermediate code, object code) created based on a requirement (specification) satisfies the requirement (specification). In other words, the purpose of the test is to determine whether or not the created software satisfies the requirements, and to find out a defect that causes the software if the requirements are not satisfied. Tests are also called requirements-based tests because they are based on requirements.

  FIG. 15 shows a flow of general software test creation work. As shown in FIG. 15, in creating a normal software test, work of requirement coverage analysis (S33) and structure coverage analysis (S36) is performed. The requirement coverage analysis (S33) and the structure coverage analysis (S36) will be described below.

  The requirement coverage analysis is a process of confirming whether or not the created test covers the requirements (specifications). The degree of coverage of how much a test covers requirements is called requirements coverage. The purpose of requirement coverage analysis is to confirm whether the items defined in the requirement are implemented by software by executing the created test. For example, when 1000 functions are defined in the requirement, it is verified that each function is implemented in the requirement coverage analysis.

  The result of the requirement coverage analysis is analyzed (S34), and when the test is insufficient for the requirement (S34: No), the test designer adds the shortage test (S35) and repeats the requirement coverage analysis (S34). ).

  Tests including items necessary for requirements coverage analysis can verify that the requirements (specifications) are implemented in the software. However, if extra processing is implemented in the software (for example, if there is an implementation error or unnecessary code due to a misunderstanding of requirements), a test that includes only the items necessary for requirements coverage analysis , Can not detect such problems. Therefore, it is necessary to perform the structure coverage analysis described below.

  The structure coverage analysis is a process for confirming how much the created test covers the structure of the software (source code, compiled intermediate code, object code). The software structure is an element constituting a logical structure of software such as a line, a conditional statement, a branch, and an execution path. The degree of coverage indicating how much the created test covers the software structure is called structure coverage.

  The standard of software structure coverage is determined according to the viewpoint from which the structure is defined. For example, when only the source code line is regarded as the software structure, the result of dividing the code line executed by the created test by all the code lines is the structure coverage. Further, the software structure may be captured in consideration of conditions and branches. The standard of software structure coverage is appropriately determined according to the concept of quality at the development site, the field in which the software to be tested is used, and the industry standard.

  If the test meets all the software structure coverage criteria (100%), the test executes all structures that conform to the software structure coverage criteria. Here, the number of test cases that can make the software structure coverage 100% differs depending on the adopted software structure coverage standard, and in some cases, the number of test cases becomes so large that the test cannot be executed practically. Therefore, at the time of actual test execution, the test designer determines the number of test cases based on the balance between coverage (coverage rate) and test execution costs.

  In software structure coverage analysis, if it becomes clear that there is a structure of code that is not executed in the created test (test that satisfies the requirement coverage analysis), the test performer is mixed with an unintended structure, that is, code. Can be judged. This allows testers to find bugs.

  The purpose of performing software structure coverage analysis is to confirm that the tests for verifying that the code has the intended implementation are designed correctly. According to the analysis result of the software structure coverage analysis, the test designer corrects (corrects, etc.) the test as appropriate.

  As described above, simply executing a test that satisfies the requirements of the software requirement coverage analysis cannot detect the code when an unintended code is mixed. Therefore, it is necessary to use tests corrected by software structure coverage analysis after software requirements coverage analysis.

  The general method of software structure coverage analysis is described below. First, run the test after the requirement coverage analysis is completed, and check the execution result with the coverage measurement tool. When it is found that the items included in the test are insufficient, the test designer adds test items. Patent Document 1 discloses an aspect of the technique.

  In Patent Document 2, the SAT method (satisfiability determination method) is applied to analyze golden (implementation that completely satisfies the specification S (requirement condition for realizing a certain system)), thereby satisfying the operation requirement. A technique for automatically extracting test constraints is disclosed. Golden operates as a reference program. The method for calculating the golden needs to be described by a formal method description, and requires a lot of man-hours for the correspondence. Note that Patent Document 2 has no suggestion or teaching about generating test constraints without using a reference program.

JP-A-5-324402 JP 2010-238057 A

NASA / TM-2001-210876: "A Practical Tutorial on Modified Condition / Decision Coverage", [March 31, 2011 search], Internet <URL: http://shemesh.larc.nasa.gov/fm/papers /Hayhurst-2001-tm210876-MCDC.pdf>

  In general, in software structure coverage analysis, it is a troublesome task to check how much the created test covers the software structure. Also, it takes time to correct the test according to the analysis result.

  In particular, when modified condition decision coverage (MC / DC, Modified Condition Decision Coverage) is adopted as the standard in software structure coverage analysis, the judgment result is reversed when only one of the multiple conditions in the judgment is changed. It is difficult to obtain a combination of conditions to do so. That is, when the change condition determination coverage is adopted, it is very difficult to confirm how much the created test covers the software structure.

  Furthermore, it is very difficult to adjust the test case by modifying, adding, or deleting the test case so as to satisfy the change condition judgment coverage (MC / DC). In the above method, the test can determine the coverage rate in the change condition determination coverage. However, in the above method, what kind of test cases are missing when the coverage rate is low, how to change which test cases, and how to minimize the number of test cases? This is because it is not possible to recognize whether the change should be made.

  Non-Patent Document 1 describes a method for determining whether a test satisfies change condition determination coverage. However, there is no teaching or suggestion about how to correct the test when the test does not satisfy the change condition determination coverage.

  That is, there is a problem that man-hours for generating a test satisfying the software structure coverage analysis are very large in an environment without a reference program.

  The present invention has been made in view of the above circumstances, and a main object of the present invention is to provide a test support system, a test support method, and a program that can easily generate a test that satisfies the requirements of software structure coverage analysis. And

One aspect of the test support system according to the present invention is:
An analysis unit including a control flow graph generation unit that generates a control flow graph displaying the flow of processing in a graph format from the source code;
A control path set generation unit that generates a control path set including an execution path in the source code based on the control flow graph and a first coverage standard according to the software structure;
The control path set is composed of the execution paths that satisfy the first coverage criterion.

One aspect of the test support method according to the present invention is as follows.
Generate a control flow graph that displays the flow of processing in the form of a graph from the source code,
Based on the control flow graph, a control path set including an execution path in the source code that satisfies the first coverage criterion concerning the software structure is generated.

One aspect of the program according to the present invention is as follows:
On the computer,
Processing to generate a control flow graph that displays the flow of processing in the form of a graph from the source code;
And generating a control path set including an execution path in the source code that satisfies the first coverage standard for the software structure based on the control flow graph.

  According to the present invention, it is possible to provide a test support system, a test support method, and a program that can easily generate a test that satisfies the requirements of software structure coverage analysis.

1 is a block diagram showing a configuration of a test support system 1 according to a first exemplary embodiment. It is a figure which shows the source code which the test assistance system 1 concerning Embodiment 1 makes into a process target. It is a figure which shows the control flow graph which the control flow graph production | generation part 12 concerning Embodiment 1 produced | generated. It is a figure which shows the control flow graph which the control flow graph production | generation part 12 concerning Embodiment 1 produced | generated. It is a figure which shows the truth table which the truth table production | generation part 13 concerning Embodiment 1 produced | generated. FIG. 6 is a diagram showing a display screen of a control flow graph generated by the test case creation method instruction unit 16 according to the first embodiment. It is a figure which shows the display screen of the truth table which the test case creation method instruction | indication part 16 concerning Embodiment 1 produced | generated. FIG. 3 is a diagram showing a display screen of a source code generated by a test case creation method instruction unit 16 according to the first embodiment. FIG. 6 is a diagram showing a display screen of a control flow graph generated by the test case creation method instruction unit 16 according to the first embodiment. It is a figure which shows the display screen of the truth table which the test case creation method instruction | indication part 16 concerning Embodiment 1 produced | generated. FIG. 3 is a diagram showing a display screen of a source code generated by a test case creation method instruction unit 16 according to the first embodiment. 3 is a flowchart showing an outline of software test creation work using the test support system 1 according to the first exemplary embodiment; 3 is a flowchart showing an operation of the test support system 1 according to the first exemplary embodiment. 1 is a block diagram showing a configuration of a test support system 1 according to a first exemplary embodiment. It is a flowchart which shows the outline | summary of a general software test preparation work.

<Embodiment 1>
Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing the configuration of the test support apparatus according to the present embodiment. The test support system 1 includes a source code information input unit 11, a control flow graph generation unit 12, a truth table generation unit 13, a coverage criterion input unit 14, a control path set generation unit 15, and a test case creation method instruction. Unit 16.

  The test support system 1 generally operates by program control on a general-purpose computer. Each processing unit included in the test support system 1 may be distributed and arranged on a plurality of computers connected by a network or the like.

  The test designer specifies the source code to be tested in the system. The source code information input unit 11 reads the source code designated by the test designer from a file system or the like. FIG. 2 is a diagram illustrating an example of source code read by the source code information input unit 11. Hereinafter, description will be given using the source code shown in FIG. The source code information input unit 11 supplies the read source code to the control flow graph generation unit 12 and the test case creation method instruction unit 16.

  The control flow graph generation unit 12 is a processing unit that generates a control flow graph from the supplied source code. FIG. 3 is a diagram showing a control flow graph generated by the control flow graph generation unit 12 from the source code shown in FIG. As shown in the figure, the source code is composed of two branches and seven processing instructions. In FIG. 3, the branch is described as being configured by a plurality of conditional statements such as “w && x”, but is not necessarily limited thereto, and is described so that the processing branches for each conditional statement as illustrated in FIG. 4. You may do it. The control flow graph generation unit 12 supplies the generated control flow graph to the truth table generation unit 13, the control path set generation unit 15, and the test case creation method instruction unit 16.

  The truth table generation unit 13 is a processing unit that generates a truth table for each branch from the supplied control flow graph. The truth table generation unit 13 extracts a branch sentence included in the control flow graph, extracts a conditional sentence included in the extracted branch sentence, and generates a truth table from the extracted information. FIG. 5 is a diagram showing a truth table related to the source code shown in FIG. 2 generated by the truth table generation unit 13. As shown in the figure, the truth table describes the true (1) or false (0) condition of each condition and the true (1) or false (0) of each branch statement. The truth table generation unit 13 supplies the generated truth value table to the control path set generation unit 15 and the test case creation method instruction unit 16.

  The coverage criterion input unit 14 is a processing unit to which a coverage criterion for software structure coverage specified by the user is input. The coverage reference input unit 14 supplies the input coverage reference to the control path set generation unit 15.

  Here, the coverage standard may be freely determined according to what viewpoint the software structure is defined from. For example, when only the source code line is regarded as the software structure, the ratio of the number of execution lines to all the source code lines may be designated as the coverage standard. Also, the execution ratio of steps excluding branch instructions and the number of execution branches with respect to the total number of branches may be specified as the coverage standard. Examples of coverage criteria include “execution of 100% of all instruction steps (steps excluding branch processing) (instruction coverage)”, “execution of 100% of conditional branches (branch coverage)”, and the like.

  The control path set generation unit 15 is a processing unit that generates a control path set from the supplied control flow graph, truth table, and coverage criterion. A control path set is a set of control paths that can satisfy a coverage criterion. A control path (also referred to as an execution path) indicates an execution path of a program. The control path set generation unit 15 extracts all control paths from the control flow graph.

The control flow graph of FIG. 3 includes the following four control paths.
Path 1: 1 (w && x == 1) 23 (y && z == 1) 467
Path 2: 1 (w && x == 1) 23 (y && z == 0) 567
Pass 3: 1 (w && x == 0) 3 (y && z == 1) 467
Path 4: 1 (w && x == 0) 3 (y && z == 0) 567
Here, in the notation of the above path, the notations “1” to “7” represent process names.

Hereinafter, the operation of the control path set generation unit 15 when “execute 100% of all instruction steps (steps excluding branch processing)” is designated as the coverage criterion will be described. The control path set generation unit 15 extracts all the control paths from the control flow graph as described above. The control path set generation unit 15 counts all instruction steps from the control flow graph (FIG. 3), and determines that all instructions are composed of seven instructions. For example, when the following path 1 is selected, the control path set generation unit 15 determines that six instructions can be executed. The path may be selected by giving priority to a path that executes more instructions that are not subject to instruction coverage, for example.
Path 1: 1 (w && x == 1) 23 (y && z == 1) 467

The control path set generation unit 15 determines that approximately 86% (6/7) of instructions are executed by executing the path 1 described above. The control path set generation unit 15 determines that the above-described path 1 alone does not satisfy the coverage criterion, and selects the following path 2. At this time, for example, the control path set generation unit 15 selects a path including the process 5 that is not included in the path 1. In this way, a path including a larger number of instructions that are not subject to instruction coverage (a path with a relatively higher coverage rate than when other paths are selected) is selected with priority.
Path 2: 1 (w && x == 1) 23 (y && z == 0) 567

  The control path set generation unit 15 determines that 100% (7/7) instructions are executed by executing the path 1 and the path 2 described above. The control path set generation unit 15 determines that the coverage criterion is satisfied by executing the path 1 and the path 2, and configures the control path set from the path 1 and the path 2 described above.

  Note that the control path set generation unit 15 may calculate a plurality of control path set candidates including the minimum number of control paths. For example, the control path set generation unit 15 may set the control path set to either (path 1, path 2) or (path 1, path 4).

  The control path set generation unit 15 supplies the control path set to the test case creation method instruction unit 16.

  A source code, a control flow graph, a truth table, and a control path set are supplied to the test case creation method instruction unit 16. The test case creation method instruction unit 16 generates a display screen in which control path set information is superimposed on at least one of a source code, a control flow graph, and a truth table.

  First, a display screen in which control path set information is superimposed on a control flow graph will be described. The test case creation method instruction unit 16 outputs a display screen in which each control path of the input control path set is superimposed on the control flowgram to the display unit or the like. FIG. 6 is a diagram showing a display screen in which the control path set (path 1, path 2) is superimposed on the control flow graph shown in FIG. As shown in the figure, each control path is superimposed on the control flow graph so that it can be recognized.

  Next, a display screen in which control path set information is superimposed on the truth table will be described. FIG. 7 is a diagram showing a display screen in which information of control path sets (path 1 and path 2) is reflected on the truth table shown in FIG. The test case creation method instruction unit 16 calculates a determination process to be executed at the time of testing from each control path of the input control path set. In the above example, pass 1 and pass 2 are executed. The path 1 includes (w && x == 1) and (y && z == 1). Path 2 includes (w && x == 1) and (y && z == 0). The test case creation method instruction unit 16 extracts all the determination processes (in the above example, (w && x == 1), (y && z == 1), (y && z == 0)). Then, the test case creation method instruction unit 16 marks the truth table so that the item line corresponding to the extracted determination sentence can be identified.

  In FIG. 7, from the determination sentence (w && x == 1), the test case creation method instructing unit 16 puts a mark (◯) that makes line number 1 a determination process that must be executed. Similarly, from the determination sentence of (y && z == 1), the test case creation method instruction unit 16 puts a mark (◯) that makes line number 5 a determination process that should be executed. In FIG. 7, from the determination sentence (w && x == 0), the test case creation method instruction unit 16 marks (Δ1) as a determination process in which one of the line numbers 2 to 4 should be executed.

  Next, a display screen in which control path set information is superimposed on the source code will be described. The test case creation method instruction unit 16 superimposes and displays each control path of the input control path set in association with the source code. FIG. 8 is a diagram showing a display screen in which control paths (path 1 and path 2) are superimposed on the source code. As shown in the figure, path 1 and path 2 are displayed in association with the source code.

  Furthermore, the operation of the test support system 1 will be described using another coverage standard. Hereinafter, a case where “all branches have been executed (branch coverage)” is given as a coverage criterion. The source code to be tested is shown in FIG. The operations of the source code information input unit 11, the control flow graph generation unit 12, the truth table generation unit 13, and the coverage reference input unit 14 are as described above.

The control path set generation unit 15 extracts all determination processes (w && x and y && z) from the control flow graph (FIG. 3). The control path set generation unit 15 selects, for example, the following path 1 that executes the largest number of determination processes.
Path 1: 1 (w && x == 1) 23 (y && z == 1) 467

Subsequently, the control path set generation unit 15 extracts the path 4 that is different from the path 1 in the output of the determination process.
Path 4: 1 (w && x == 0) 3 (y && z == 0) 567

  The control path set generation unit 15 determines whether the true / false (1, 0) of all branch processes is executed. In the above example, the control path set generation unit 15 determines that “all branches have been executed” by executing the path 1 and the path 4. Then, the control path set generation unit 15 configures the control path set from path 1 and path 4. In this way, the control path set generation unit 15 selects control paths in the order in which the branch coverage rate becomes relatively high.

  The test case creation method instruction unit 16 generates a display screen in which the information of the control path set (path 1, path 4) is superimposed on at least one of the source code, the control flow graph, and the truth table. FIG. 9 is a diagram showing a display screen in which the control path set (pass 1, path 4) is superimposed on the control flow graph shown in FIG. FIG. 10 is a diagram showing a display screen in which information of the control path set (path 1, path 4) is reflected on the truth table shown in FIG. FIG. 11 is a diagram showing a display screen in which control paths (path 1 and path 4) are superimposed on the source code.

  Next, an outline of software test creation work using the test support system 1 according to the present embodiment will be described. FIG. 12 is a flowchart showing an outline of the software test creation work.

  First, a programmer or the like creates source code to be tested (S11). Subsequently, the test designer executes processing using the test support system 1 described above (S12). Details of this processing will be described with reference to FIG.

  First, the test designer inputs a source code to the source code information input unit 11 (S21). Further, the test designer inputs a coverage standard to the coverage standard input unit 14 (S22).

  The control flow graph generation unit 12 generates a control flow graph from the input source code (S23). The truth table generation unit 13 generates a truth table from the generated control flow graph (S24). The control path set generation unit 15 generates a control path set from the control flow graph, the truth table, and the coverage criterion (S25). The test case creation method instruction unit 16 generates a display screen in which the control path set information is superimposed on at least one of the source code, the control flow graph, and the truth table (S26).

  Returning to the description of FIG. By referring to the display screen generated by the test case creation method instruction unit 16, the test designer can grasp a control path necessary for creating a test that satisfies the software structure analysis. The test designer creates a test that satisfies the requirements for software structure analysis (S13).

  The test designer performs software requirement coverage analysis (S14). As a result of the software requirement coverage analysis, the test designer determines whether or not the requirements of the software requirement coverage are satisfied (S15). When the requirement is not satisfied (S15: No), the test designer adds an insufficient test item (S16). If the requirement is satisfied (S15: Yes), the test designer finishes creating the test item (S17).

  Next, effects of the test support system according to the present embodiment will be described. First, the problems of a general test creation procedure as a comparison target will be described in detail.

  In the general test creation procedure shown in FIG. 15, it was necessary to perform software structure coverage analysis. Therefore, the determination as to whether the created test set satisfies the coverage standard of the predetermined software structure cannot be grasped until all the test cases of the test set are executed and coverage measurement is executed. Moreover, although the coverage rate of the software structure coverage could be measured by coverage measurement, it was not possible to grasp what tests should be added when the coverage coverage rate was not sufficient. Furthermore, it is difficult to detect a case where the test case of the test set is redundant (when the test case is included more than necessary).

  On the other hand, the above-described test support system generates a control path set from a coverage standard regarding software structure coverage, a control flow graph that is an analysis result of a source code, and the like. The control path set includes a set of control paths (also referred to as execution paths) indicating program execution paths that can satisfy the coverage criteria. Therefore, the test designer can efficiently generate the minimum necessary test set by referring to the control path set.

  Further, the control path set generation unit 15 satisfies the coverage criterion as described above, and configures a control path set from the minimum number of control paths. As a result, the test designer does not create a redundant test set.

  Furthermore, the control path set generation unit 15 may generate a plurality of control path sets when there are a plurality of control path set candidates. As a result, the test designer can select the control path set that is most easily used for test creation from a plurality of control path sets, and create a test.

  The test case creation method instruction unit 16 generates a display screen that reflects the information of the control path set in the control flow graph or the like. The test designer can easily recognize each process executed by the required test case by referring to the display screen.

  The essential part of the present invention will be described again with reference to FIG. The test support system 1 includes an analysis unit 20 and a control path set generation unit 15. The analysis unit 20 is a processing unit that analyzes the information of the source code necessary for generating the control path set, and corresponds to the control flow graph generation unit 12 and the truth table generation unit 13 in FIG. The control path set generation unit 15 extracts a control path set from the coverage standard and the analysis result (for example, a control flow graph) by the analysis unit 20. The control path set is composed of a set of control paths indicating program execution paths that can satisfy the coverage criteria. Therefore, the test designer can efficiently generate the minimum necessary test set by referring to the control path set.

  Note that the present invention is not limited to the above-described embodiment, and can be changed as appropriate without departing from the spirit of the present invention.

  In the above configuration, a plurality of coverage criteria may be input. Hereinafter, a description will be given with reference to FIGS. For example, it may be specified that two coverage criteria of “execute 100% of all instruction steps (steps excluding branch processing)” and “execute 100% of conditional branches” are satisfied.

  The control path set generation unit 15 selects (path 1, path 2) or (path 1, path 4) as a control path set corresponding to “execution of 100% of all instruction steps (steps excluding branch processing)”. select. The control path set generation unit 15 selects (path 1, path 4) as the control path set corresponding to “execute 100% of the conditional branch”.

  The control path set generation unit 15 finally selects (path 1, path 4) as a control path set that satisfies both conditions. The processing of other processing units is the same as described above.

  Each process of the source code information input unit 11, the control flow graph generation unit 12, the truth table generation unit 13, the coverage reference input unit 14, the control path set generation unit 15, and the test case creation method instruction unit 16 is arbitrary. It can be realized as a program operating in the computer. The program may be stored using various types of non-transitory computer readable media and supplied to a computer. Non-transitory computer readable media include various types of tangible storage media. Examples of non-transitory computer-readable media include magnetic recording media (for example, flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (for example, magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs, CD-R / W and semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (random access memory)) are included. The program may also be supplied to the computer by various types of transitory computer readable media. Examples of transitory computer readable media include electrical signals, optical signals, and electromagnetic waves. The temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.

  A part or all of the above embodiment can be described as in the following supplementary notes, but is not limited thereto.

(Appendix 1)
An analysis unit including a control flow graph generation unit that generates a control flow graph displaying the flow of processing in a graph format from the source code;
A control path set generation unit that generates a control path set including an execution path in the source code based on the control flow graph and a first coverage standard according to the software structure;
The test support system, wherein the control path set includes the execution paths that satisfy the first coverage criterion.

(Appendix 2)
The test support system according to appendix 1, wherein the control path set includes a minimum number of execution paths that satisfy the first coverage criterion.

(Appendix 3)
The test support system according to appendix 2, wherein the control path set generation unit generates a plurality of the control path sets when there are a plurality of candidates for the control path set.

(Appendix 4)
The first coverage standard is a standard related to an instruction coverage rate obtained by dividing the number of executed instructions by the total number of instructions included in the source code,
The control path set generation unit extracts all the execution paths included in the source code and counts all the instructions included in the source code until the instruction coverage rate is satisfied. The test support system according to any one of Supplementary Note 1 to Supplementary Note 3, wherein the execution paths included in the control path set are selected in an order in which the coverage rate becomes relatively high.

(Appendix 5)
The first coverage standard is a standard related to a branch coverage rate obtained by dividing the number of execution branches by the number of all branches included in the source code,
The control path set generation unit extracts all the execution paths included in the source code and counts all the branches included in the source code until the branch coverage rate is satisfied. The test support system according to any one of Supplementary Note 1 to Supplementary Note 3, wherein the execution paths included in the control path set are selected in an order in which the coverage rate becomes relatively high.

(Appendix 6)
The control path set generation unit generates the control path set based on the first coverage standard and the second coverage standard for the software structure,
The test support system according to any one of appendix 1 to appendix 5, wherein the control path set includes the execution paths that satisfy both the first coverage criterion and the second coverage criterion.

(Appendix 7)
The analysis unit includes a truth table generation unit that generates a truth table from a branch process included in the source code,
The test support system further includes a test case creation method instructing unit that generates a display screen reflecting information on the control path set in at least one of the source code, the control flow graph, and the truth table. The test support system according to any one of appendix 1 to appendix 6, which is characterized.

(Appendix 8)
The test case creation method instruction unit generates the display screen by superimposing all the execution paths included in the control path set on the control flow graph. Test support system.

(Appendix 9)
Generate a control flow graph that displays the flow of processing in the form of a graph from the source code,
A test support method for generating a control path set including an execution path in the source code that satisfies a first coverage criterion for a software structure based on the control flow graph.

(Appendix 10)
The test support method according to appendix 9, wherein the control path set includes a minimum number of execution paths that satisfy the first coverage criterion.

(Appendix 11)
The test support method according to appendix 10, wherein when there are a plurality of candidates for the control path set, a plurality of the control path sets are generated.

(Appendix 12)
The first coverage standard is a standard related to an instruction coverage rate obtained by dividing the number of executed instructions by the total number of instructions included in the source code,
While extracting all the execution paths included in the source code and counting the number of all instructions included in the source code, the instruction coverage ratio is relatively high until the instruction coverage ratio is satisfied. 12. The test support method according to any one of appendix 9 to appendix 11, wherein the execution paths included in the control path set are selected in order.

(Appendix 13)
The first coverage standard is a standard related to a branch coverage rate obtained by dividing the number of execution branches by the number of all branches included in the source code,
All the execution paths included in the source code are extracted, and the number of all branches included in the source code is counted, and the branch coverage ratio becomes relatively high until the branch coverage ratio is satisfied. 12. The test support method according to any one of appendix 9 to appendix 11, wherein the execution paths included in the control path set are selected in order.

(Appendix 14)
Generating the control path set based on the first coverage criterion and a second coverage criterion for the software structure;
14. The test support method according to any one of appendix 9 to appendix 13, wherein the control path set includes the execution paths that satisfy both the first coverage standard and the second coverage standard.

(Appendix 15)
Generate a truth table from the branch process included in the source code,
15. The test support method according to any one of supplementary notes 9 to 14, wherein a display screen reflecting information related to the control path set in at least one of the source code, the control flow graph, and the truth table is generated.

(Appendix 16)
On the computer,
Processing to generate a control flow graph that displays the flow of processing in the form of a graph from the source code;
A program for executing, based on the control flow graph, a process for generating a control path set including an execution path in the source code that satisfies a first coverage standard for a software structure.

DESCRIPTION OF SYMBOLS 1 Test support system 11 Source code information input part 12 Control flow graph generation part 13 Truth table generation part 14 Coverage reference | standard input part 15 Control path set generation part 16 Test case creation method instruction | indication part

Claims (6)

An analysis unit including a control flow graph generation unit that generates a control flow graph displaying the flow of processing in a graph format from the source code;
A control path set generation unit that generates a control path set including an execution path in the source code based on the control flow graph and a first coverage criterion for the software structure;
A test case creation method instruction unit that generates a display screen in which all the execution paths included in the control path set are superimposed on the control flow graph, and
The test support system, wherein the control path set includes the execution paths that satisfy the first coverage criterion. An analysis unit including a control flow graph generation unit that generates a control flow graph displaying the flow of processing in a graph format from the source code;
A control path set generation unit that generates a control path set including an execution path in the source code based on the control flow graph and a first coverage criterion for the software structure;
A test case creation method instruction unit that generates a display screen in which all the execution paths included in the control path set are superimposed on the source code, and
The test support system, wherein the control path set includes the execution paths that satisfy the first coverage criterion. Generate a control flow graph that displays the flow of processing in the form of a graph from the source code,
Based on the control flow graph, generating a control path set including an execution path in the source code that satisfies a first coverage criterion for a software structure ;
A test support method for generating a display screen in which all the execution paths included in the control path set are described in a superimposed manner in the control flow graph . Generate a control flow graph that displays the flow of processing in the form of a graph from the source code,
Based on the control flow graph, generating a control path set including an execution path in the source code that satisfies a first coverage criterion for a software structure ;
A test support method for generating a display screen in which all the execution paths included in the control path set are superimposed on the source code . On the computer,
Processing to generate a control flow graph that displays the flow of processing in the form of a graph from the source code;
Generating a control path set including an execution path in the source code that satisfies a first coverage criterion for a software structure based on the control flow graph;
A program for executing a process of generating a display screen in which all the execution paths included in the control path set are described in a superimposed manner in the control flow graph . On the computer,
Processing to generate a control flow graph that displays the flow of processing in the form of a graph from the source code;
Generating a control path set including an execution path in the source code that satisfies a first coverage criterion for a software structure based on the control flow graph;
A program for executing a process of generating a display screen in which all the execution paths included in the control path set are described in a superimposed manner in the source code .

Images