KR102588856B1 - Method for verifying software and apparatus therefor - Google Patents

Abstract

A method and apparatus for verifying software are provided. A software verification method according to an embodiment of the present invention includes obtaining information about a function called by a module to be verified included in a software design document; Confirming the calling order of functions using the obtained information and generating a functional verification test case including the calling order of the confirmed functions; And comparing the order of functions called when the source code of the module to be verified is executed by a debugger and the order of function calls included in the functional verification test case to determine whether the module to be verified is implemented according to the software design document. It may include steps.

Description

Software verification method and device therefor {METHOD FOR VERIFYING SOFTWARE AND APPARATUS THEREFOR}

The present invention relates to a method for verifying software. More specifically, it relates to a software verification method and device for determining whether software has been implemented according to the design using a functional verification test case that can integrate and verify software functions.

Before developing software, a software design document is prepared, and the developer writes source code according to the software design document. The source code is written using a programming language and can be written using various programming languages such as C language, JavaScript, Python, etc.

Once the source code is completed, software verification is performed to verify whether the source code has been implemented according to the specifications of the software design document. Various tools have been developed for software verification, and among them, a method for measuring source coverage is also used.

The code coverage is a tool used to verify how much code is used and covers the design document when performing software testing. The structure of the code can be divided into statements, conditions, and decisions, and when the source code is executed, it is determined whether the source code corresponds to one or more of statement coverage, condition coverage, and decision coverage, You can measure the coverage of source code.

However, this software verification method mainly involves verification of a single module. To elaborate, the existing software verification method determines whether a function is called and used normally within one module. In other words, the existing software verification method only verifies whether a function call is executed normally by targeting only the source code within the module block, and does not consider a method of integrating and verifying multiple modules.

Accordingly, a method for verifying software by integrating a plurality of modules is required.

Japanese Patent Publication No. 1993-088861 (published on April 9, 1993)

The technical problem to be solved by the present invention is to provide a software verification method and device for performing verification by integrating a plurality of modules.

Another technical problem to be solved by the present invention is to provide a method and device for easily verifying software through a functional verification test case.

Another technical problem to be solved by the present invention is to provide a software verification method and device for determining whether function calls in each module are proceeding in order.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

In order to solve the above technical problem, a software verification method according to an embodiment of the present invention includes the steps of obtaining information about a function called by a module to be verified included in a software design document; Confirming the calling order of functions using the obtained information and generating a functional verification test case including the calling order of the confirmed functions; And comparing the order of functions called when the source code of the module to be verified is executed by a debugger and the order of function calls included in the functional verification test case to determine whether the module to be verified is implemented according to the software design document. It may include steps.

The software verification method includes checking parameters for an input interface and an output interface in the software design document; Checking function information used in each module in the software design document; Checking the interface between each module and the algorithm of each module; And it may further include the step of checking the function calling order based on function information for each module, the input interface and output interface, and the interface between the modules.

The step of checking the algorithm may include analyzing the source code of each module and checking the algorithm, including function call conditions and parameter settings, for each module.

The step of generating the functional verification test case includes: confirming an expected output value in the functional verification test case based on function information for each module, parameters for each input/output interface of the architecture, and interfaces between the modules; and generating the functional verification test case including the expected output value.

In one embodiment, the software verification method compares the result of the source code executed by the debugger with the expected output value included in the test case to determine whether the module to be verified is implemented according to the software design document. Additional steps may be included.

The step of checking the function information may include checking the function information using a unit design document included in the software design document.

The function information may include a calling function used in the corresponding module, a called function, and input parameters and output parameters of each function.

The software verification method may further include mapping and storing the functional verification test case with the software design document.

In one embodiment, the debugger may integrate and analyze the source code of a plurality of modules based on each module included in the mapped functional verification test case.

In order to solve the above technical problem, a software verification device according to another embodiment of the present invention includes a design analysis module that acquires information about a function called by a module to be verified included in a software design document; a test case generation module that verifies the calling order of functions using the obtained information and generates a functional verification test case including the calling order of the confirmed functions; A debugger that executes the source code of the module to be verified; and a verification module that determines whether the module to be verified is implemented according to the software design document by comparing the order of functions called by the debugger and the order of function calls included in the functional verification test case.

1 is a diagram illustrating a software verification system according to an embodiment of the present invention.
FIG. 2 is a diagram showing the configuration of the software verification device of FIG. 1.
Figure 3 is a diagram illustrating parameters for each input/output interface.
Figure 4 is a diagram illustrating function information of a module.
Figure 5 is a diagram illustrating the code coverage measurement result and function connection relationship.
Figure 6 is a diagram illustrating the algorithm of each module.
Figure 7 is a diagram illustrating the order in which functions are called between modules.
Figure 8 is a diagram illustrating a function call sequence and test scenario.
Figure 9 is a flowchart illustrating a method for verifying software according to another embodiment of the present invention.
Figure 10 is an example hardware configuration diagram that can implement a computing device in various embodiments.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. The advantages and features of the present invention and methods for achieving them will become clear by referring to the embodiments described in detail below along with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be implemented in various different forms. The present embodiments are merely intended to ensure that the disclosure of the present invention is complete and to provide common knowledge in the technical field to which the present invention pertains. It is provided to fully inform those who have the scope of the invention, and the present invention is only defined by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

Unless otherwise defined, all terms (including technical and scientific terms) used in this specification may be used with meanings that can be commonly understood by those skilled in the art to which the present invention pertains. Additionally, terms defined in commonly used dictionaries are not interpreted ideally or excessively unless clearly specifically defined. The terminology used herein is for describing embodiments and is not intended to limit the invention. As used herein, singular forms also include plural forms, unless specifically stated otherwise in the context.

Hereinafter, several embodiments of the present invention will be described with reference to the drawings.

1 is a diagram illustrating a software verification system according to an embodiment of the present invention.

As shown in FIG. 1, the software verification system may include a client terminal 200 and a software verification device 100. The client terminal 200 and the software verification device 100 may communicate with each other through the network 300. The network 300 includes a mobile communication network and a wired communication network, and since it corresponds to a known common technology in the present invention, detailed description will be omitted.

The client terminal 200 is a communication device such as a personal computer, server, or mobile terminal, and can connect to the software verification device 100 to register the software design document and the source code of each module to the software verification device 100. The software design document may include one or more architecture design documents and one or more unit design documents. Parameters for the input interface and output interface may be recorded in the architecture design, and function information for each module may be recorded in the unit design. The function information may include a call function used in the corresponding module, a called function, a call target function, and input/output parameters for each function. The module included in the unit design may be a module used when the corresponding unit function is performed. In addition, the calling function is a representative function to be called used in the corresponding module, the call target function represents a function that calls the calling function, and the called function is a function called within the calling function and may be an internal function or an external function. . The internal function may be a function that can be processed and returned by the corresponding module, and the external function may be a function that is executed in another module and whose result value is returned from the other module.

The software verification device 100 may analyze the software design and source code for each module and generate one or more functional verification test cases that can integrate a plurality of modules and verify functionality. The software verification device 100 may use the functional verification test case to determine whether one or more modules subject to verification have been implemented according to the software design document.

FIG. 2 is a diagram showing the configuration of the software verification device of FIG. 1.

As shown in FIG. 2, the software verification device 100 according to an embodiment of the present invention includes a design analysis module 110, a debugger 120, a test case generation module 130, and a verification module 140. It can be done, and these components can be implemented in hardware or software, or through a combination of hardware and software. In addition, the design analysis module 110, debugger 120, test case generation module 130, and verification module 140 are memory 1400 in the form of a computer program 1500 that can be executed on the computing device 1000, which will be described later. Alternatively, it may be stored in storage 1300.

The design analysis module 110 may receive a software design and source code for each module from the client terminal 200, and analyze the software design. In one embodiment, the design document analysis module 110 may analyze the architecture design document included in the software design document and check parameters for each of the input interface and output interface in the architecture design document. The design document analysis module 110 can check parameters for each of the input interface and output interface by parsing the text written in the architecture design document according to promised rules.

Figure 3 is a diagram illustrating parameters for each input/output interface.

As illustrated in Figure 3, the input interface with the name "DRV_Door" is associated with parameter a, the input interface with the name "RKE_Lock_SW" is associated with parameter b, and the output interface with the name "DRV_Door_Lock_Rly" is associated with parameter a. It may be related to parameter c. The design analysis module 110 can analyze the architecture design and check parameters related to each of the input interface and output interface.

In addition, the design document analysis module 110 may analyze the unit design document included in the software design document to obtain function information used in one or more modules in the unit design document. The function information may include one or more call functions and called functions. It can include functions and input/output parameters of each function. The design analysis module 110 identifies a module by parsing the text written in the unit design according to promised rules, and determines one or more call functions, called functions, and input/output parameters of the function called by the module. You can check it.

Figure 4 is a diagram illustrating function information of a module.

As illustrated in FIG. 4, a specific module may include a plurality of function information. According to (a) of Figure 4, a function named "functionA" has a and b as output parameters, is associated with "functionB" and "functionA1" as a called function, and "Tack_A" as a called function. It can be associated with a function that has a name. According to (a) of Figure 4, "functionA" is called through the "Task_A" function, calling one or more of the called functions "functionB" and "functionA1", and also one or more of parameters a and parameter b. Can be printed.

According to (b) of Figure 4, a function named "functionB" has an input parameter a, an output parameter b, is associated with "functionC" as a called function, and has a function "functionA" as a call target function. It can be related. According to (b) of FIG. 4, “functionB” can be called through the “functionA” function, can call “functionC”, which is the called function, and can output parameter b. The design document analysis module 110 can obtain function information as shown in FIG. 4 by using and analyzing the unit design document.

As another embodiment, the design analysis module 110 may receive parameters for each of the input interface and output interface from the client terminal 200, and may also receive function information of each module.

The debugger 120 may measure the coverage of the source code of the module included in the unit design and check the interface between each module based on the measured code coverage measurement result. The debugger 120 may perform the code coverage measurement using known tools such as DT10, LDRA, VectorCAST, CodeScroll Controller Tester, QualityScroll Cover, etc.

Figure 5 is a diagram illustrating the code coverage measurement result and function connection relationship.

As illustrated in (a) of FIG. 5, the debugger 120 can measure the statement coverage and condition coverage of each function in percentage (%). As illustrated in (b) of FIG. 5, the debugger 120 can check whether the call relationship of each function is a horizontal relationship or a vertical relationship based on the code coverage measurement result. According to (a) of Figure 5, "Function A", "Function B", and "Function C" each have a horizontal relationship, and "Function A", "Function A1", and "Function A2" may have a vertical relationship. there is. A horizontal relationship can occur when an external function is used, and a vertical relationship can occur when an internal function is used. The “Function A1” and “Function A2” may be internal functions for “Function A”.

Additionally, the debugger 120 can identify the algorithm of each module, including function call conditions and parameter settings, by analyzing the source code of the corresponding module.

Figure 6 is a diagram illustrating the algorithm of each module.

Figure 6 (a) illustrates the algorithm identified through the source code of module A. Initially, “functionA1” and “functionB” are called, and “functionA2” is called or “functionA2” is called according to the comparison result of parameters a and b. , it illustrates that parameters a and b are set to “0”. Figure 6 (b) illustrates the algorithm identified through the source code of module B, illustrating that "functionC" is called or parameter c is set to "0" depending on whether parameter a is 1. .

When analyzing the source code of a module included in the unit design, the debugger 120 checks the plurality of modules included in the unit design if the unit design is mapped to a functional verification test case, and checks the plurality of modules. You can analyze the source code by integrating. The debugger 120 can integrate and analyze the source code for the plurality of modules by identifying the function used at the last branch of each module and the module that provides the function. That is, the debugger 120 can integrate and analyze a plurality of related modules using functional verification test cases.

The test case generation module 130 checks the calling order of each function based on one or more of the function information for each module, parameters for each input/output interface of the architecture, interfaces between the modules, and algorithms for each module, and makes predictions. After checking the output results, a functional verification test case can be created that includes the calling order and output results of each function. The functional verification test case includes identification information of modules related to the function called according to the calling order, so that the debugger 120 can identify each related module. The test case generation module 130 may map the generated functional verification test case with the corresponding architecture design and unit design. For example, if the functional verification test case is related to module A and module B, the functional verification test case may be mapped to unit blueprint #1 and unit blueprint #2. The test case generation module 130 may identify modules related to the functional verification test case according to the function call order for each module.

Figure 7 is a diagram illustrating the order in which functions are called between modules.

As illustrated in FIG. 7, when “Task_A” occurs, “functionA” of module A, “functionB” of module B, and “functionC” of module C are called sequentially. In addition, the test case generation module 130 can determine another function call order based on the function information for each module, parameters for each input/output interface of the architecture, and algorithms for each module, in addition to those illustrated in FIG. 7. .

Figure 8 is a diagram illustrating a function call sequence and test scenario.

Referring to FIG. 8, the function verification test case with the name "FunctionalTest_01" is the first function call sequence corresponding to "functionA" -> "functionA1", "functionA" -> "functionB" -> "functionC". It may include a corresponding second function call sequence and a third function call sequence corresponding to "functionA" -> "functionA2". The "FunctionalTest_01" functional verification test case is a test scenario and may include input interfaces "DRV_Door" and "RKE_Lock_SW", and may also include turning on the output interface "DRV_Door_Lock_Rly" as an expected output value.

In FIG. 8, "InterfaceTest_01" and "InterfaceTest_01" are examples that have been verified according to a conventional verification method, and "functionA1" and "functionA2", which are internal interfaces (i.e., internal functions), are missing. In addition, "InterfaceTest_01" and "InterfaceTest_01" are limited to being applied only to specific modules, and not only are multiple modules not integrated and used, but the final output result is not expected at all. In other words, “InterfaceTest_01” and “InterfaceTest_01” according to the conventional verification cannot perform functional verification by integrating multiple modules.

On the other hand, "FunctionalTest_01", a functional verification test case created according to this embodiment, includes the function call sequence used between multiple modules and also predicts the final result value. Accordingly, when using a different functional verification test case in this embodiment, multiple modules can be integrated and verified, and it is also possible to check whether the final result is accurate.

The verification module 140 may select a plurality of modules related to the functional verification test case as modules to be verified, and use the debugger 120 to analyze the source codes of the selected plurality of modules to be verified. When the source code analysis for a plurality of verification target modules is executed by the debugger 120, the verification module 140 checks whether the order of functions called by the debugger matches the order of function calls included in the functional verification test case. Thus, it can be determined whether the source code has been accurately implemented according to the software design. When there are multiple function call sequences included in the functional verification test case, the verification module 140 checks whether the function sequence called by the debugger 120 matches any one of the plurality of function call sequences to implement software. You can determine whether or not. If the function call order of the debugger 120 does not match the call function order included in the functional verification test case, the verification module 140 may determine the software verification as failed.

In addition, the verification module 140 compares the results output by the debugger 120 with the expected output results included in the functional verification test case to determine whether the source code has been accurately implemented according to the software design document. You can. If the verification module 140 does not match any one of the output results of the debugger 120 and the expected output results included in the functional verification test case, the software verification may be determined to have failed.

The verification module 140 ensures that the function call order of the debugger 120 matches the call function order included in the functional verification test case, and the results output by the debugger 120 and the expected output results included in the functional verification test case are consistent with the function call order of the debugger 120. If they match, the software verification can be judged as successful. The verification module 140 can transmit the determined results to the client terminal 200, and can also write and store them in the form of a report.

According to this embodiment, functional verification of the software can be performed by generating a functional verification test case based on the correlation between modules and the function call order, and integrating and verifying the modules using the functional verification test case. Convenience and accuracy can be improved. In addition, according to this embodiment, by comparing the data included in the functional verification test case with the test results performed by the debugger 120 and accurately verifying the software, it is possible to clearly identify implementation errors in the software. You can.

Figure 9 is a flowchart illustrating a method for verifying software according to another embodiment of the present invention.

Referring to FIG. 9, the design analysis module 110 may receive a software design document and source code for each module from the client terminal 200 (S101).

Next, the design document analysis module 110 can analyze the architecture design document included in the software design document and check parameters for each of the input interface and output interface in the architecture design document. Next, the design analysis module 110 can analyze the unit design included in the software design and check function information used in one or more modules in the unit design (S103).

Next, the debugger 120 can measure the coverage of the source code included in the unit design document and check the interface between each module based on the code coverage measurement result (S105). Additionally, the debugger 120 can analyze the source code to determine the algorithm of each module, including function call conditions and parameter settings.

Next, the test case generation module 130 checks the calling order of each function based on one or more of the function information for each module, parameters for each input/output interface of the architecture, interfaces between the modules, and algorithms for each module. In addition, after confirming the expected output results, a functional verification test case including the calling order and output results of each function can be created (S107). The functional verification test case includes identification information of modules related to the function called according to the calling order.

Subsequently, the test case generation module 130 may map the generated functional verification test case with the corresponding architecture design and unit design (S109).

The verification module 140 may select one or more modules related to the functional verification test case as a module to be verified, and use the debugger 120 to analyze the source code corresponding to the module to be verified. In one embodiment, the debugger 120 integrates the source code of the plurality of modules by identifying the function used at the last branch of each verification target module and the module that provides the function, based on the functional verification test case. It can be analyzed. That is, the debugger 120 can integrate and analyze the source code of a plurality of related modules using functional verification test cases. Subsequently, when the source code analysis for the module to be verified is executed by the debugger 120, the verification module 140 changes the order of functions called by the debugger 120 to match the order of function calls included in the functional verification test case. By checking whether the source code has been implemented accurately according to the software design, it can be first determined (S111).

Next, the verification module 140 compares the results output by the debugger 120 with the expected output results included in the functional verification test case to determine whether the source code has been accurately implemented according to the software design document. It can be judged by car. Subsequently, the verification module 140 can transmit the determined results to the client terminal 200, and can also prepare and store them in the form of a report.

According to this embodiment, it is possible to generate a functional verification test case and integrate and verify modules using the functional verification test case. In addition, according to this embodiment, by mapping and storing the functional verification test case with the unit design, when the debugger 120 analyzes the module corresponding to the unit design later, other modules associated with the module are also integrated and verified. By doing so, it can have the effect of shortening the verification time.

Hereinafter, the hardware configuration of an example computing device according to some embodiments will be described with reference to FIG. 9.

Figure 10 is an example hardware configuration diagram that can implement a computing device in various embodiments.

The computing device 1000 according to this embodiment includes one or more processors 1100, a system bus 1600, a communication interface 1200, and a memory that loads a computer program 1500 executed by the processor 1100. It may include (1400) and a storage (1300) for storing a computer program (1500). In Figure 10, only components related to the embodiment are shown. Accordingly, anyone skilled in the art to which the embodiments of the present specification pertain can recognize that other general-purpose components other than those shown in FIG. 10 may be further included.

The processor 1100 controls the overall operation of each component of the computing device 1000. The processor 1100 includes at least one of a Central Processing Unit (CPU), Micro Processor Unit (MPU), Micro Controller Unit (MCU), Graphic Processing Unit (GPU), or any type of processor well known in the art of the present specification. It can be configured to include. Additionally, the processor 1100 may perform operations on at least one application or program to execute methods/operations according to various embodiments. Computing device 1000 may include two or more processors.

The memory 1400 stores various data, commands and/or information. The memory 1400 may load one or more programs 1500 from the storage 1300 to execute methods/operations according to various embodiments of the present specification. An example of the memory 1400 may be RAM, but is not limited thereto.

The system bus 1600 provides communication functions between components of the computing device 1000. The system bus 1600 may be implemented as various types of buses, such as an address bus, a data bus, and a control bus. The communication interface 1200 can be connected to the network 300. Storage 1300 may non-temporarily store one or more computer programs 1500. The storage 1300 may be configured to include non-volatile memory such as flash memory, a hard disk, a removable disk, or any type of computer-readable recording medium well known in the technical field to which the embodiments of the present specification pertain. .

The computer program 1500 may include one or more instructions implementing methods/operations according to various embodiments of the present specification. When the computer program 1500 is loaded into the memory 1400, the processor 1100 can perform methods/operations according to various embodiments of the present specification by executing the one or more instructions. The computer program 1500 may include instructions for the above-described request handling operation. In some embodiments, the computer program 1500 includes one or more instructions for performing the operation of the design analysis module 110 described with reference to FIGS. 2 to 9 and one or more instructions for performing the operation of the debugger 120. , It may include one or more instructions for performing the operation of the test case generation module 130 and one or more instructions for performing the operation of the verification module 140.

In one embodiment, the computer program 1500 includes the following operations: acquiring information about a function called by a module to be verified included in a software design document; Confirming the calling order of functions using the obtained information and generating a functional verification test case including the calling order of the confirmed functions; And comparing the order of functions called when the source code of the module to be verified is executed by a debugger and the order of function calls included in the functional verification test case to determine whether the module to be verified is implemented according to the software design document. It may include instructions for performing operations.

The methods according to embodiments of the present invention described so far can be performed by executing a computer program implemented as computer-readable code. The computer program can be transmitted from a first computing device to a second computing device through a network such as the Internet, installed on the second computing device, and thus used on the second computing device. The first computing device and the second computing device include both a server device, a physical server belonging to a server pool for a cloud service, and a stationary computing device such as a desktop PC.

The computer program may be stored in a recording medium such as a DVD-ROM or flash memory device.

Although embodiments of the present invention have been described above with reference to the attached drawings, those skilled in the art will understand that the present invention can be implemented in other specific forms without changing its technical idea or essential features. can understand. Therefore, the embodiments described above should be understood in all respects as illustrative and not restrictive.

Claims (6)

Obtaining information about functions called by a plurality of modules to be verified included in the software design document from the software design document;
Generating a functional verification test case that integrates source codes within a plurality of verification target modules using information obtained from the software design document; and
Implementation of the module to be verified according to the software design document by comparing information about the function called when the source code of the module to be verified is executed by a debugger and information about the function included in the functional verification test case. Including the step of determining whether or not
The step of obtaining information about the function is,
measuring coverage of source code of the plurality of modules to be verified using the debugger; and
Using the measured coverage results, confirming an interface between the plurality of modules to be verified,
The step of creating the functional verification test case is,
Comprising the step of generating the functional verification test case using an interface between the plurality of modules to be verified,
Software verification methods. According to claim 1,
The step of obtaining information about the function is,
Confirming the calling order of functions based on function information for each of the plurality of modules to be verified and an interface between the plurality of modules to be verified,
The step of generating the functional verification test case using an interface between the plurality of modules to be verified includes:
Including generating the functional verification test case using the calling sequence of the function,
Software verification methods. According to clause 2,
The step of checking the calling order of the function is,
Based on the measured coverage results, determining the call relationship of the functions for each module to be verified as either a horizontal relationship or a vertical relationship,
The functions in the horizontal relationship are functions called by a common external function,
The functions in the vertical relationship are functions that include an external function and an internal function called by the external function.
Software verification methods. According to claim 1,
The step of creating the functional verification test case is,
Identifying a function used at a final branch point of each of the plurality of modules to be verified and a module providing the function by the debugger; and
Comprising the step of generating a functional verification test case by integrating a plurality of related modules using the identified results,
Software verification methods. According to clause 4,
The step of creating the functional verification test case is,
Comprising the step of including, by the debugger, function information for each of the plurality of modules to be verified and an expected output value based on an interface between the plurality of modules to be verified in the functional verification test case.
Software verification methods. According to claim 1,
The step of determining whether the module to be verified is implemented according to the software design document,
Comprising the step of determining whether the calling order and result value of the function called by the debugger match the calling order and expected output value of the function included in the functional verification test case,
Software Verification Methods