JP2012185539A - Software verification support device, software verification support method, and software verification support program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a software verification support device, a software verification support method, and a software verification support program which enable software verification in which verification omission is suppressed.SOLUTION: For supporting software verification based on verification requirements, a function model is generated from software, and the verification requirements are generated on the basis of the generated function model. To generate the verification requirements, function elements which match a pattern of a verification target are extracted from the function model to generate the verification requirements on the basis of the extracted function elements, or the function model is decomposed into snapshots to generate the verification function on the basis of the decomposed snapshots.

Description

  The present invention relates to a software verification support apparatus, a software verification support method, and a software verification support program that support software verification based on verification requirements.

  When software is developed, it is necessary to verify whether the software operates normally. In order to verify the software, the requirements to be verified are determined, and verification is performed based on the verification requirements. Verification requirements are primarily determined by a person and may be automatically generated by the device based on the structure of the software. Patent Document 1 discloses verification support that supports verification processing for a register included in a hardware-designed verification target circuit, and specifies a verification target register to be verified from the configuration of the verification target circuit. A pattern that requires verification as a coverage standard is extracted for the specified verification target register, and there is a possibility that the pattern included in the verification target circuit is generated from the four states of Declare, Initialize, Read, and Write at the time of extraction. A DIRW matrix representing a certain state transition is prepared, and two types of coverage standards, a matrix coverage standard and an implementation coverage standard, are determined using the DIRW matrix.

JP 2010-3281 A

  Software is not necessarily described in a form that is easy for humans to understand because of implementation reasons, such as reducing computational load and unrelated functions in one program. In some cases, software of a certain system is written in a plurality of different languages. For these reasons, it is difficult to read and understand each function from software, and it is a work that requires skill. Therefore, when a person determines verification requirements, the quality of the verification requirements varies from person to person. Further, when the verification requirement is determined based only on the software structure, since the standard to be covered by the verification is based on the software structure, the verification requirement covering the function to be verified cannot be extracted. As a result, verification leakage occurs. Further, the verification support of Patent Document 1 described above is not applicable to extraction of software verification requirements because the verification target is a hardware circuit and the verification requirements are extracted by paying attention to the state change of the register.

  Therefore, an object of the present invention is to provide a software verification support apparatus, a software verification support method, and a software verification support program that enable verification of software with suppressed verification leakage.

  A software verification support apparatus according to the present invention is a software verification support apparatus that supports software verification based on verification requirements, and includes a function model generation unit that generates a function model from software, and a function model generated by the function model generation unit And verification requirement generation means for generating verification requirements based on the above.

  In this software verification support apparatus, a function model is generated from software to be verified by a function model generation means. The function model is a model that covers the functions of the software, and is obtained by extracting a certain aspect (point) of the software to be verified. In addition, the function model can be shown in a form that is visible to the person, and is modeled so that the person can easily read and understand the function of the software. When such a function model is generated, the software verification support apparatus generates a verification requirement based on the function model by the verification requirement generation means. In this way, the software verification support device generates a functional model from software and generates a verification requirement from the functional model, thereby easily and automatically generating a verification requirement covering the functions to be verified from the functional model, The verification leakage can be suppressed by verifying the software based on the verification requirement. Even when software is described in a plurality of different languages, the software can be handled uniformly by the function model, and verification requirements can be easily generated from the function model.

  Note that various languages can be applied as the description language of the verification target software, for example, a procedural language such as C language and a modeling language such as Simulink. As the function model, for example, there is a data flow graph model for control flow, a state transition model for control mode switching, and Timed Autodata for timing problems.

  In the software verification support apparatus according to the present invention, the verification requirement generation unit may extract a functional element that matches the pattern to be verified from the functional model and generate the verification requirement based on the extracted functional element. This software verification support device covers the functions that should be verified from the functional model by generating verification requirements by extracting functional elements that match the pattern to be verified (ie, the pattern of the function to be verified) from the functional model. Verification requirements can be extracted easily and with high accuracy.

  In the software verification support apparatus of the present invention, the verification requirement generation unit may be configured to decompose the functional model into snapshots and generate verification requirements based on the decomposed snapshots. In this software verification support device, verification requirements covering functions to be verified can be easily and accurately extracted from the function model by generating verification requirements by breaking down the functional model into snapshots.

  The software verification support apparatus according to the present invention may include a test generation unit that generates a test to be input to software from the verification requirement generated by the verification requirement generation unit. In this software verification support apparatus, a function to be verified can be efficiently verified by automatically generating a test from verification requirements and inputting the test to verify the software.

  The software verification support apparatus of the present invention may be configured to include display means for displaying what is generated by each generation means. Examples of display by the display means include a function model, verification requirements, verification target patterns, decomposed snapshots, and tests according to the verification requirements. In this software verification support device, by displaying what is generated by each generation means, it is possible to clearly indicate the functional model, verification requirements, etc. to the person performing the verification, such as the functional configuration of the software, the requirements to be verified, etc. Can be easily recognized.

  A software verification support method according to the present invention is a software verification support method for supporting software verification based on verification requirements, a function model generation step for generating a function model from software, and a function model generated in the function model generation step And a verification requirement generation step of generating verification requirements based on the above. According to this software verification support method, the operations and effects of the software verification support apparatus are achieved by performing the processing of each step.

  A software verification support program according to the present invention is a software verification support program for supporting verification of software based on verification requirements, and a functional model generation function for generating a functional model from software in a computer, and a functional model generation function And a verification requirement generation function for generating verification requirements based on the functional model generated in (1). According to the software verification support program, by causing the computer to execute this program, the operation and effect of the software verification support apparatus can be achieved.

  According to the present invention, by generating a functional model from software and generating a verification requirement from the functional model, it is possible to easily and automatically generate a verification requirement that covers the function to be verified from the functional model. The verification leakage can be suppressed by verifying the software based on the verification.

It is a conceptual diagram of the control software verification apparatus which concerns on this Embodiment. It is a block diagram of the control software verification apparatus which concerns on 1st Embodiment. It is an example of a program in which control software is written in C language. It is a data flow graph of the program of FIG. It is an example in case control software is described in a different language, (a) is a data flow graph (the same data flow graph as FIG. 4) of the control software described in a different language, (b) is control software A Simulink model in which a part is described, and (c) is a C language program in which a part of the control software is described. It is an example ((a), (b)) of the verification pattern used with a pattern matching method. 7 is an example of a functional element that matches each verification pattern of FIG. 6 extracted from the data flow graph of FIG. 4 by a pattern matching method. It is an example of the verification requirement corresponding to the functional element of FIG. 7 extracted by the pattern matching method. It is a conceptual diagram of snapshot decomposition. It is an example ((a), (b), (c), (d)) of the snapshot data flow graph decomposed | disassembled from the data flow graph of FIG. 4 with the snapshot decomposition | disassembly method. 11 is an example of verification requirements corresponding to the snapshot data flow graph of FIG. 10D extracted by the snapshot decomposition method. It is an example of a structure of a verification means, (a) is a structure of a real machine verification test, (b) is a structure of a HILS test. This is a procedure for embedding monitoring information in a program to be verified. It is an example of a program in which monitoring information is embedded. It is a block diagram of the control software verification apparatus which concerns on 2nd Embodiment. It is an example of a program in which an instruction for generating a test input is embedded.

  Hereinafter, embodiments of a software verification support apparatus, a software verification support method, and a software verification support program according to the present invention will be described with reference to the drawings. In addition, the same code | symbol is attached | subjected about the element which is the same or it corresponds in each figure, and the overlapping description is abbreviate | omitted.

  In the present embodiment, the present invention is applied to a control software verification apparatus that verifies control software that controls an arbitrary system. When the control software to be verified is input, the control software verification apparatus according to the present embodiment automatically generates control software verification requirements and verifies the control software according to the verification requirements. In this embodiment, there are two forms, the first embodiment is a basic form, and the second embodiment is a function that automatically generates a test to be input to the control software in addition to the basic form. It is a form which also has. The control software verification apparatus according to the present embodiment may be a dedicated apparatus that performs only control software verification, or may be configured by executing a control software verification application on a general-purpose computer.

  The verification target software may be described in a single language or may be described in a plurality of different languages. Various languages can be applied as the description language. For example, there are a procedural language such as C language and a data flow type modeling language such as Simulink.

  First, an overview of the control software verification apparatus according to the present embodiment will be described with reference to FIG. FIG. 1 is a conceptual diagram of a control software verification apparatus according to this embodiment. In FIG. 1, the configuration connected by a solid line is the maximum configuration of the control software verification apparatus, and each configuration (each combination) connected by a broken line is the minimum configuration of the control software verification apparatus.

  First, the control software verification device generates a function model from the control software to be verified. The function model is a model that covers the functions of the control software, and is obtained by extracting a certain aspect (point) to be verified of the control software. The function model can be shown in a form visible to the human eye, and is modeled so that the person can easily understand the functions of the control software. Thus, since it can be clearly shown to the person in the form of a function model, it can be easily understood whether the functions that the person should verify by looking at the function model are covered.

  Since the control function realizing the control software has various aspects, the function model is modeled according to each aspect of the control function. For example, in the case of a control flow, a data flow graph model (DFG Model), a state transition model for switching the control mode, and Timed Automata for timing problems. In the present embodiment, the case of a data flow graph model will be described as an example.

  Next, the control software verification device generates verification requirements from the function model. The verification requirements are requirements for functions to be verified in the control software. There are two methods for generating the verification requirement: pattern matching and snapshot decomposition. In the pattern matching method, functional elements that match the verification pattern are extracted from the functional model, and verification requirements are generated based on the extracted functional elements. The verification pattern is a function pattern to be verified in the functional model, and is determined by a person. In the snapshot decomposition method, a functional model is decomposed into snapshots, and verification requirements are generated based on the decomposed snapshots. The snapshot of the functional model is a pattern established at a specific moment (timing) in the functional model, and may be all possible patterns or a part of the patterns in the functional model. When only a part of the snapshot is used, it is determined by the person because of the importance of the control function.

  Next, the control software verification device verifies the control software according to the generated verification requirement. Here, a coverage monitor or automatic test generation is used to determine the inspection path. In the coverage monitor, verification requirements generated to clearly indicate how much the functions to be verified of the control software are covered as a coverage standard are displayed on the monitor. In the automatic test generation, the test input of the control software is automatically generated using the model checker from the generated verification requirements. Then, the generated test input is input to the control software for verification. The verification is usually performed by a dedicated device or a general-purpose computer, but may be performed by a person based on verification requirements.

  A control software verification apparatus 1 according to the first embodiment will be described with reference to FIG. FIG. 2 is a configuration diagram of the control software verification apparatus according to the first embodiment.

  When the control software S to be verified is input, the control software verification apparatus 1 generates a data flow graph (functional model M) from the control software S, generates verification requirements from the data flow graph, and Then, verification according to the verification requirement is performed and a verification result R is output. For this purpose, the control software verification apparatus 1 includes a function model generation unit 10, a verification requirement generation unit 11, and a verification unit 12.

  The input control software S is described in an arbitrary language, and is configured as a software model SM or a program SP. The control software S may be written in a single language, or may be written in a plurality of different languages. For example, FIG. 3 shows an example of a C code program SP1 written in a single C language for a certain control. In the C code program SP1, all variables except for the variable t are global variables. FIG. 5 shows an example in which the same control as that in FIG. 3 is described in two languages. FIG. 5B shows a Simulink model SM2 whose first half is described in Simulink and FIG. The second half shows a C code program SP2 written in C language.

  When the control software S is input, the function model generation unit 10 generates a data flow graph as the function model M from the control software S. As described above, the control software S may be partially described in different languages, but by defining a functional model called a data flow graph, regardless of the description language, “data flow from input to output and its One aspect of the control function "switching" can be extracted. The data flow graph is modeled as a graph in which program operations and branches are represented by nodes and variables are represented by edges. The generated data flow graph (functional model M) is displayed on a monitor (display means) and can be visually confirmed by a person to be verified.

  A conventional method is applied to the generation of the data flow graph. For example, in the case of a procedural program, the program syntax is analyzed, a program control flow graph is generated based on the program syntax analysis result, and global variables are reached using the control flow graph. The definition is calculated, the arrival definitions are traced in reverse order from the output variables using the arrival definition set of each node, and a data flow graph is generated that outputs the output variables based on the tracking results.

  FIG. 4 shows a data flow graph DFG1 of the C code program SP1 shown in FIG. In the data flow graph, operations are represented by squares, selectors are represented by diamonds, input / output ports are represented by ellipses, reference variables are added to arrows (edges), and reference constant values are added to the ends of arrows. Is done. The data flow graph DFG1 uses “gout” as an output variable. Therefore, in the data flow graph DFG1, only the operation flow related to “gout” is extracted in an easily understandable form.

Further, the control software composed of the Simulink model SM2 and the C code program SP2 shown in FIG. 5 is the same data flow graph DFG1 as in FIG. As shown in FIG. 5A, in the data flow graph DFG1, the upper left part divided by the broken line is a part DFG1 _M corresponding to the Simulink model SM2, and the lower right part is a part DFG1 corresponding to the C code program SP2. _P.

  When a data flow graph is generated as the function model M, the verification requirement generation unit 11 generates a verification requirement C from the data flow graph. As described above, the verification requirement generation method includes a pattern matching method and a snapshot decomposition method. Either one of these methods is used, or a combination of the two methods is used.

  First, pattern matching will be described. First, a portion (functional element) that matches the verification pattern is extracted from the data flow graph. The verification pattern is a pattern that requires verification (branch, calculation, etc.) and corresponds to a functional element having a local pattern. The verification pattern may be determined in advance by the person to be verified and registered in advance in the control software verification apparatus 1, or may be selected by looking at the data flow graph displayed on the monitor by the person to be verified. . In order to easily determine the verification pattern, it is preferable to construct a database in the control software verification apparatus 1 and register a regular verification pattern in the database so that the verification pattern can be selected from the database. FIG. 6 shows a verification pattern IP1 in FIG. 6A and a verification pattern IP2 in FIG. Such a verification pattern may be displayed on a monitor. FIG. 7 shows a portion IP1 ′ matching the verification pattern IP1 shown in FIG. 6A and a portion IP2 ′ matching the verification pattern IP2 shown in FIG. 6B in the data flow graph DFG1 shown in FIG. Yes. In such a data flow graph, a portion matching the verification pattern may be highlighted and displayed on the monitor.

  Next, a portion corresponding to a portion (functional element) matching the verification pattern in the data flow graph is extracted from the control software S, and a verification requirement C is generated from the portion corresponding to the verification pattern in the control software S. By using a portion that matches the verification pattern extracted from the data flow graph (functional model M) that is easily modeled in a human-visible form in this way, the verification requirement C can be easily generated. Verification leakage can be suppressed. FIG. 8 shows lines corresponding to a portion (functional element) IP1 ′ matching the verification pattern IP1 shown in FIG. 7 and a portion (functional element) IP2 ′ matching the verification pattern IP2 in the C code program SP1. The line corresponding to the functional element IP1 ′ is 5-7 lines, and the part corresponding to the functional element IP2 ′ is 17-18 lines. In this example, “execution of verification covering lines 5-7 and 17-18 of C code program SP1” is the verification requirement C, and the condition for establishing the path of line 5-7 is (P == TRUE). and R == TRUE), and the conditions for establishing a path on lines 17-18 are (Q == TRUE). The generated verification requirement C is displayed on a monitor and can be visually confirmed by a person to be verified.

  Next, snapshot decomposition will be described. The outline of snapshot decomposition will be described with reference to the example of FIG. In the data flow DF, the output variable e1 of the process A and the output variable e2 of the process B are switched by the selector SL1, the output variable of the selector SL1 is input to the process C, the output variable e3 of the process C and the output variable e4 of the process D Are switched by the selector SL2 and output. Here, if one edge is selected for each of the selectors SL1 and SL2 with respect to the data flow switched by the selectors SL1 and SL2 (that is, snapshot decomposition), the data flow without switching from input to output (snapshot) Is obtained. The snapshot SS1 is a data flow in which the output variable e1 of the process A is selected by the selector SL1 and the output variable e3 of the process C is selected by the selector SL2. The snapshot SS2 is a data flow in which the output variable e2 of the process B is selected by the selector SL1 and the output variable e3 of the process C is selected by the selector SL2. The snapshot SS3 is a data flow in which the output variable e4 of the process D is selected by the selector SL2. From the viewpoint of the control function, these snapshots can be considered as functions (control modes) that are established at a certain moment, and the entire control function can be considered to be realized by appropriately switching these control modes. Therefore, such a snapshot can be considered as a function in which each function in the data flow is decomposed into constituent elements, and verification without leakage can be performed by performing verification according to the functional elements.

  Therefore, first, one edge is selected for each selector included in the data flow graph, and a snapshot data flow graph without switching from input to output is generated. Here, snapshot data flow graphs for all patterns in the case of configuring all switching combinations for all selectors may be generated, or snapshot data flow graphs for some patterns may be generated. It may be generated. In the case of some patterns, it is preferable that the person who verifies determines the pattern to be generated according to the importance of the control mode. For example, it is preferable that the person to be verified can interactively select an edge to be switched in the data flow graph while looking at the data flow graph displayed on the monitor. The generated snapshot data flow graph is displayed on a monitor and can be visually confirmed by a person to be verified.

  FIG. 10 shows an example in which the data flow graph DFG1 shown in FIG. Data flow graphs SSDFG1, SSDFG2, SSDFG3, SSDFG4 are obtained. The snapshot data flow graph SSDFG1 shown in FIG. 1A is a case where an edge having a constant value 0 is selected by the selector GSL3. The snapshot data flow graph SSDFG2 shown in FIG. 4B is a case where the edge of the variable x = 0 is selected by the selector GSL1. The snapshot data flow graph SSDFG3 shown in FIG. 4C is a case where the edge of the variable x = gin is selected by the selector GSL1. The snapshot data flow graph SSDFG4 shown in FIG. 4D is a case where the edge of the variable x = gin is selected by the selector GSL2.

  Next, a portion corresponding to the snapshot data flow graph is extracted from the control software S, and a verification requirement C is generated from the portion corresponding to the snapshot data flow graph in the control software S. As described above, by using the snapshot data flow graph that is easily understandable in a form visible to human eyes and decomposed into functional elements, verification requirements can be easily extracted, and verification leakage can be suppressed. FIG. 11 shows the lines corresponding to the snapshot data flow graph SSDFG4 shown in FIG. 10D in the C code program SP1, and the lines 2, 4, 11-12, 16, and 20 surrounded by a rectangle. It is. In this example, the condition for establishing this path is (P == FALSE and Q == FALSE), which is the verification requirement C. The generated verification requirement C is displayed on a monitor and can be visually confirmed by a person to be verified.

  When the verification requirement C is generated, the verification unit 12 verifies the control software S according to the verification requirement C and outputs a verification result R. Here, verification is performed by applying the generated verification requirement C as a coverage criterion. As a verification method, various conventional methods can be applied. For example, depending on the verification requirement C (that is, a functional element), an actual machine test, HILS [Hardware In the Loop Simulator], SILS [Software In the Loop Simulator], etc. There are tests that cut out a part of the control software S such as closed-loop simulation and unit test, and model checking. The output verification result R is displayed on the monitor and can be visually confirmed by the person to be verified.

  FIG. 12A shows an internal state monitoring system in an actual machine verification test as an example of the configuration of the verification unit 12. The verification unit 12A includes a test condition input device 12c and an internal state monitoring device 12d for an actual system that controls the control target 12a with the control device 12b. For example, when the verification target control software S is software for controlling an engine of an automobile, the control target 12a is an engine, and the control device 12b is an ECU [Electronic Control Unit] for controlling the engine. An execution file of the control software S to be verified is incorporated in the control device 12b. The test condition input device 12c is a device for inputting a test condition (test input) for satisfying the verification requirement C for each verification requirement C. The internal state monitoring device 12d is a device that monitors the internal state by monitoring the RAM value and the like of the control device 12b when the control target 12a is controlled by the control device 12b after inputting the test conditions. By monitoring the internal state in this way, it is verified whether the verification requirement C is a comprehensive test or whether the control software S is operating normally so as to satisfy the verification requirement C for each verification requirement C. . This internal state is displayed on the monitor and can be visually confirmed by the person to be verified.

  FIG. 12B shows an internal state monitoring system in the HILS test as another example of the configuration of the verification unit 12. The verification unit 12B includes a test condition input device 12c and an internal state monitoring device 12d for a simulation system in which the control target model calculation device 12e is controlled by the control device 12b. The controlled object model calculation device 12e is a simulator that simulates the operation of the controlled object. In this way, the verification unit 12B performs verification using a simulator (controlled object model calculation device 12e) instead of the actual machine as compared with the verification unit 12A.

  There are various methods for monitoring the internal state. As an example, a method for incorporating information to be monitored into the verification target program SP will be described with reference to FIG. First, a monitoring code is embedded in the verification target program SP to create a monitoring code-added program CSP. FIG. 14 shows the path establishment condition (P == FALSE and Q ==) which is the verification requirement C generated from the snapshot data flow graph SSDFG4 shown in FIG. 10 (d) in the C code program SP1 shown in FIG. The monitoring code-added program CSP1 in which the monitoring codes WC1, WC2, WC3, WC4, WC5, WC6, and WC7 necessary for verifying that FALSE is established is shown. Then, the monitoring code-added program CSP is cross-compiled to create an execution file EF, and the execution file EF is transferred to the control device 12b and incorporated into the control device 12b. Accordingly, it is possible to monitor whether or not the verification target program SP incorporated in the control device 12b is operating so as to satisfy the verification requirement C in the test environment as shown in FIG.

  In addition, although the verification using the above-mentioned actual machine and simulator was demonstrated, the verification which applied the verification requirement C as a coverage standard can be similarly performed in the unit test etc. of the control software S.

  According to this control software verification apparatus 1, by generating a functional model M that covers the functional configuration of the control software S and is easy to grasp visually and generates verification requirements C from the functional model M, The verification requirement C covering the functions to be verified can be generated easily and automatically, and the verification leakage can be suppressed by verifying the control software S based on the verification requirement C. Even when the control software S is described in a plurality of different languages, the control software S can be handled uniformly by the function model M, so that the verification requirement C can be easily generated from the function model M. Further, by generating the verification requirement C using the function model M, the verification requirement C can be generated and verified without depending on human skills.

  Further, according to the control software verification apparatus 1, by using pattern matching and snapshot decomposition to generate the verification requirement C from the function model M, the verification requirement C covering the functions to be verified from the function model M can be easily obtained. And it can be extracted with high accuracy. Moreover, according to the control software verification apparatus 1, the function model M, the verification requirement C, etc. can be clearly shown to the person who performs verification by displaying what was generated by each generation means 10, 11, 12 on the monitor. A person can easily understand the functional configuration of the control software S and the requirements to be verified.

  With reference to FIG. 15, the control software verification apparatus 2 which concerns on 2nd Embodiment is demonstrated. FIG. 15 is a configuration diagram of a control software verification apparatus according to the second embodiment.

  The control software verification device 2 is different from the control software verification device 1 according to the first embodiment in that a test input (test vector) T is automatically generated from the verification requirement C and verified. For this purpose, the control software verification apparatus 2 includes a function model generation unit 20, a verification requirement generation unit 21, a verification unit 22, and a test input generation unit 23. The function model generation unit 20, the verification requirement generation unit 21, and the verification unit 22 are the same as the function model generation unit 10, the verification requirement generation unit 11, and the verification unit 12 according to the first embodiment. Omitted.

  When the verification requirement C is generated, the test input generation unit 23 automatically generates a test input T that satisfies the verification requirement C. As this generation method, a conventional method can be applied, for example, a random test generation or a method using a model checker. The generated test input T is displayed on a monitor and can be visually confirmed by a person to be verified.

  As an example, generation of a test input using a model checker will be described with reference to FIG. Here, for the C code program SP1 shown in FIG. 4, the path establishment condition (P == FALSE and Q == FALSE) of the verification requirement C generated from the snapshot data flow graph SSDFG4 shown in FIG. A case where the test input T for establishing is generated will be described. First, as shown in FIG. 16, the C code program SP1 requires a property P1 that should satisfy a logical expression that negates the path establishment condition (P == FALSE and Q == FALSE) and the logical expression. Each code TC1, TC2, TC3, TC4, TC5, TC6 is embedded to create a property-added program PSP1. Then, this property-added program PSP1 is applied to the model checker to generate a test input T that satisfies the path establishment condition (P == FALSE and Q == FALSE) of the verification requirement C as an example of an input that does not satisfy the condition of the logical expression. . In the case of a program written in C language, a model checking tool called CBMC can be applied.

  When verification is performed by the verification means 22 using the test input T generated in this way, the unit test of the control software S is mainly targeted, and the control software S alone is verified.

  The control software verification apparatus 2 has the same effects as the control software verification apparatus 1 according to the first embodiment, and also has the following effects. According to the control software verification apparatus 2, the function to be verified can be efficiently verified by automatically generating the test input T from the verification requirement C and inputting the test input T to verify the control software S. it can.

  As mentioned above, although embodiment which concerns on this invention was described, this invention is implemented in various forms, without being limited to the said embodiment.

  For example, in this embodiment, control software verification requirements are generated and applied to a control software verification apparatus that performs control software verification based on the verification requirements. However, the software verification requirements and tests according to the verification requirements are performed. You may apply to the software verification assistance apparatus for producing | generating. Also, it can be applied to programs stored in a storage medium such as a CD-ROM or a program that can be used via a network such as the Internet, and by executing such a program on a computer, software verification requirements and verification can be performed. It is good also as a structure which produces | generates the test according to requirements.

  In this embodiment, the present invention is applied to control software used for controlling a car or the like. However, the present invention can be applied to various software other than control.

  DESCRIPTION OF SYMBOLS 1,2 ... Control software verification apparatus 10,20 ... Function model production | generation means 11,21 ... Verification requirement production | generation means 12,12A, 12B, 22 ... Verification means, 12a ... Control object, 12b ... Control apparatus, 12c ... Test condition input device, 12d... Internal state monitoring device, 12e... Control target model calculation device, 23.

Claims (7)

A software verification support device that supports software verification based on verification requirements,
Function model generation means for generating a function model from software;
Verification requirement generation means for generating verification requirements based on the functional model generated by the functional model generation means;
A software verification support apparatus comprising:   The software verification support according to claim 1, wherein the verification requirement generation unit extracts a functional element that matches a pattern to be verified from the functional model, and generates a verification requirement based on the extracted functional element. apparatus.   The software verification support apparatus according to claim 1, wherein the verification requirement generation unit decomposes the functional model into snapshots and generates verification requirements based on the decomposed snapshots.   The software verification support apparatus according to claim 1, further comprising a test generation unit that generates a test to be input to software from the verification requirement generated by the verification requirement generation unit.   The software verification support apparatus according to any one of claims 1 to 4, further comprising display means for displaying what is generated by each of the generation means. A software verification support method for supporting software verification based on verification requirements,
A function model generation step for generating a function model from software;
A verification requirement generation step for generating a verification requirement based on the functional model generated in the functional model generation step;
A software verification support method comprising: A software verification support program for supporting software verification based on verification requirements,
On the computer,
A function model generation function for generating a function model from software;
A verification requirement generation function for generating verification requirements based on the functional model generated by the functional model generation function;
Software verification support program characterized by realizing

Images