Engineering verification method and system for function correctness of complex software system

Abstract

The invention discloses an engineering verification method and system for function correctness of a complex software system, and the method comprises the steps: carrying out module function analysis, module input analysis and execution effect analysis, and constructing a description of a verification demand according to a module function, an input condition and an execution effect obtained through analysis; running environment analysis is carried out to determine a software and hardware environment on which the complex software system depends during running, context environment abstraction is carried out, verification scene construction is executed according to the abstracted context environment, and description of verification requirements is inserted into verification case codes through verification language formalized protocols to complete verification case construction; and executing the constructed verification case by using a verification tool to obtain a verification result, and performing verification defect analysis. According to the method, a complete engineering verification mechanism for the function correctness of the complex software system is formed through the three stages of verification requirement construction, verification case construction and verification case execution, and support is provided for quality assurance of the complex software system.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software verification, and in particular to an engineering verification method and system for the functional correctness of a complex software system. Background Art

[0002] Complex software systems are usually composed of multiple interdependent modules, each of which is responsible for different functions and communicates with other modules through interfaces. Take the operating system kernel as an example. It is a core component that manages computer hardware resources, provides application program interfaces (APIs), and performs key tasks. The operating system kernel not only needs to handle multiple functions such as multi-task scheduling, memory management, and file system operations, but also needs to respond to external interrupts and kernel state exceptions in a very short time to ensure the overall operating efficiency and security of the system. Another notable feature of complex software systems is concurrency and multithreading. For example, the operating system kernel often needs to handle multiple concurrent processes while ensuring the correct allocation and use of resources. This complex concurrent behavior makes the system prone to race conditions, deadlocks, and resource contention, further increasing the difficulty of verification. In addition, the operating environment of complex software systems is usually dynamic and uncertain. The system may need to run on different hardware platforms. Faced with diverse user inputs and external devices, any slight environmental changes may cause potential system functional errors. Therefore, it is particularly important to conduct systematic and comprehensive verification of the functional correctness of complex software systems.

[0003] Existing verification technologies include dynamic testing, static analysis, and formal methods. These technologies address the needs of system functional verification to varying degrees. 1. Dynamic testing is the most commonly used verification method. By dynamically executing the system, it is checked whether the output of the system under specific input conditions meets expectations. The advantages of the test method are that it is easy to understand and implement, and can discover functional errors and abnormal behaviors in the system to a certain extent. However, the test relies on pre-defined test cases and usually only covers part of the input space and execution path of the system. For complex software systems, the input space of the system may be infinite, and the test cannot exhaust all input combinations and boundary conditions. Therefore, the test technology cannot provide a complete guarantee of the correctness of the system function. 2. Static analysis technology is a technology that analyzes the source code or intermediate code of the program without executing the program. Static analysis can capture potential errors in the program, such as uninitialized variables, array out-of-bounds, null pointer references, etc. Compared with testing, static analysis has better code coverage because it does not rely on specific input conditions and can analyze all possible code paths. However, static analysis may produce a large number of false positives and false negatives when dealing with large and complex systems. In addition, static analysis has limited understanding of the dynamic behavior in the program, especially in multi-threaded and concurrent programs, where it is difficult for static analysis to accurately capture the interaction and resource contention issues between threads. 3. Formal verification is a verification technology based on mathematical models that proves whether the program meets specific functional requirements by constructing formal specifications. The advantage of formal verification is that it can provide rigorous mathematical proofs to ensure the correctness of the program. For example, in the theorem proving method, programmers or verification engineers construct logical propositions about the behavior of the program or system and use automatic or semi-automatic theorem provers (such as Coq and Isabelle) to prove that the system meets these propositions. This method requires manual derivation and construction of complex proof steps, and is suitable for verifying highly complex systems or algorithms. However, the degree of automation is limited. When performing verification on complex software systems, a large number of proofs need to be written, which is extremely costly. In addition, the formal method of program verification checks whether the system meets specific specifications by exhaustively searching the finite state model of the system, and can directly edit verification cases in the source code to perform verification automatically.

[0004] The formal verification method based on program verification, with its rigorous logical foundation and highly automated characteristics, significantly reduces the burden of developers in the process of modeling complex software systems, and enables verification work to be efficiently performed on system modules with the help of automated verification tools, thereby effectively improving software quality. However, there are still many problems in the verification process. First, for a given system to be verified, there is often a lack of clear verification requirements, that is, there is a lack of a clear definition of functional correctness. Secondly, facing a large and complex system, it is unrealistic to directly verify the entire system due to the limitations of the verification capabilities of existing verification technologies and tools. Therefore, it is necessary to abstract the verification module according to the verification requirements. How to effectively manage the complexity of the verification module while maintaining its accuracy and preventing the explosion of the state space has become an urgent problem to be solved. In addition, in the verification process, it is necessary to ensure the sufficiency and verifiability of the test cases to cover all critical paths and boundary conditions, and to strictly maintain semantic consistency to prevent the introduction of new defects due to negligence or misunderstanding in the abstract process.

[0005] In summary, the shortcomings of existing verification methods and frameworks when applied to the verification of complex software systems are mainly reflected in: 1) the lack of verification requirements, which makes it difficult to systematically and comprehensively capture the functional correctness requirements of the system; 2) the complexity of constructing and abstracting the context environment of complex software systems, and the need to reduce the scale of verification while ensuring verification accuracy. Summary of the invention

[0006] Technical problem to be solved by the present invention: In view of the above-mentioned problems in the prior art, a method and system for engineering verification of the functional correctness of a complex software system are provided. The present invention aims to form a complete engineering verification mechanism for the functional correctness of a complex software system through three stages: verification requirement construction, verification case construction and verification case execution, so as to provide support for the quality assurance of the complex software system.

[0007] In order to solve the above technical problems, the technical solution adopted by the present invention is: An engineering verification method for the functional correctness of a complex software system comprises the following steps: S101, perform module function analysis to determine the function of the verified module in the complex software system; perform module input analysis to determine the input required for the verified module in the complex software system to complete the module function; perform execution effect analysis to determine the execution effect of the verified module in the complex software system under given input conditions; construct a description of the verification requirements based on the module function, input conditions and execution effect obtained by the analysis; S102, performing an operating environment analysis to determine the software and hardware environment that the complex software system depends on when it runs, abstracting the context environment of the verified module and the software and hardware environment it depends on in the complex software system to reduce the complexity of verification, executing verification scenario construction according to the abstracted context environment, and inserting the description of the verification requirements into the verification case code using the verification language formalization specification to complete the construction of the verification case; S103, using the verification tool to execute the constructed verification case to obtain the verification result and perform verification defect analysis.

[0008] Optionally, step S101 includes: S201, collecting relevant documents for a complex software system, wherein the relevant documents include part or all of the requirements specification, design documents, and user manual of the complex software system; identifying module responsibilities based on the collected relevant documents, and determining the functions of the verified modules; splitting the functions of the verified modules according to sub-functions so as to design verification requirements according to each sub-function or single function and extracting the main execution paths of each sub-function during actual operation; S202, performing module input analysis to determine the input conditions required for the verified module in the complex software system to complete the verification, including the data type, parameter range and validity condition of the required input of the sub-function; S203, performing execution effect analysis to determine the execution effect of the verified module in the complex software system under a given input condition, including: return value of a function or module, system state change, event triggering, and global variable value change; S204, construct a description of the verification requirements based on the functions, input conditions and execution effects of the verified module obtained by analysis; organize and classify the descriptions of the verification requirements, remove duplicate and redundant requirements, and then verify whether the descriptions of all verification requirements are complete and accurate. If the verification is passed, jump to step S102; otherwise, jump to step S204 to continue constructing the description of the verification requirements.

[0009] Optionally, the description of the verification requirements constructed in step S204 includes two categories: verification requirement T and verification requirement p→q, where verification requirement T means that the execution effect of the verified module is universal, and a certain execution effect is obtained for any input situation; verification requirement p→q means that a certain execution effect q of the verified module is only satisfied under a specific input p, and the specific input p is regarded as a precondition, and the execution effect q to be obtained is recorded as a postcondition as the verification requirement p→q.

[0010] Optionally, in step S102, abstracting the context environment of the verified module and the software and hardware environment it depends on in the complex software system includes: S301, performing functional dependency analysis on a verified module in a complex software system to determine an external interface that the verified module depends on in a software and hardware environment; S302, by analyzing the interaction between the verified module and the external interface, the external interface is abstracted into a virtual behavior model by simulating the standard input and output of the external interface to reduce the impact of external dependency on verification; S303, for complex context environments that cannot be abstracted, use simulators to simulate key elements including hardware interfaces and system interrupts to ensure that the simulation environment is consistent with the real environment; S304, for the verified module in the complex software system, delete the code irrelevant to the module function to achieve state space reduction.

[0011] Optionally, executing verification scenario construction according to the abstracted context environment in step S102 includes: S401, parsing the description of the verification requirements, extracting and sorting out the verification requirements occurring in the same verification scenario, and making the verification requirements contained in multiple verification scenarios repeatable, so as to ensure that all verification scenarios can cover all verification requirements; S402, designing a verification scenario, including: designing a verification scenario that can simulate actual runtime according to the preconditions of the verification requirements or the input conditions of the main execution path of the sub-function under test in the complex software system; S403, determine whether the designed verification scenario covers the verification requirements described in all verification requirements. If not, jump to step S402 to continue designing the verification scenario; otherwise, determine that it is completed and execute the verification scenario construction according to the abstracted context environment.

[0012] Optionally, in step S102, inserting the description of the verification requirement into the verification case code using the verification language formal specification to complete the construction of the verification case includes: S501, using the same programming language as the complex software system to be verified to express input conditions for describing the verification requirements; S502, expressing the execution environment of the description of the verification requirement using the same programming language as the complex software system to be verified; S503, inserting the call of the module to be verified into the description of the verification requirement using the same programming language as the complex software system to be verified, and performing verification requirement specification on the obtained verification case; S504, determine whether the constructed verification case can fully describe the verification scenario. If not, jump to step S501 to continue constructing the verification case; otherwise, jump to step S103.

[0013] Optionally, step S103 includes: S601, obtaining a project to be verified, wherein the project to be verified includes a complete project of a complex software system or an abstracted project code, a modeled verification scenario, and a constructed verification case; S602, using a verification tool to execute the verification use case constructed in the project to be verified; S603, judging whether the verification process is carried out normally, if not, analyzing the abnormal reason and optimizing the verification model of the item to be verified, and jumping to step S601; otherwise, jumping to step S604; S604, collecting error information; S605, locating the defect and analyzing the cause of the error according to the error information; S606, determine whether the defect is introduced due to improper construction of the verification model of the project to be verified. If it is a defect introduced due to improper construction of the verification model of the project to be verified, optimize the verification model of the project to be verified and jump to step S601; otherwise, record the system defect, end and exit.

[0014] In addition, the present invention also provides an engineering verification system for the functional correctness of a complex software system, comprising a microprocessor and a memory connected to each other, wherein the microprocessor is programmed or configured to execute the engineering verification method for the functional correctness of the complex software system.

[0015] In addition, the present invention also provides a computer-readable storage medium, in which a computer program or instruction is stored. The computer program or instruction is programmed or configured to execute an engineering verification method for the functional correctness of the complex software system through a processor.

[0016] In addition, the present invention also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the engineering verification method for the functional correctness of the complex software system through a processor.

[0017] Compared with the prior art, the present invention mainly has the following advantages: the method of the present invention includes performing module function analysis, module input analysis and execution effect analysis, and constructing a description of verification requirements based on the module functions, input conditions and execution effects obtained by the analysis; performing an operating environment analysis to determine the software and hardware environment on which the complex software system depends during operation, performing context environment abstraction, and executing verification scenario construction based on the abstracted context environment, and inserting the description of verification requirements into the verification case code using a verification language formal specification to complete the construction of the verification case; using a verification tool to execute the constructed verification case to obtain verification results and perform verification defect analysis. The present invention forms a complete engineering verification mechanism for the functional correctness of a complex software system through three stages: verification requirement construction, verification case construction and verification case execution, which provides support for quality assurance of complex software systems and improves the verification effectiveness of complex software systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 Schematic diagram of the basic flow of the method of the embodiment of the present invention.

[0019] Figure 2 The figure is a flow chart of the verification requirement building phase in an embodiment of the present invention.

[0020] Figure 3 The figure is a flowchart of context environment abstraction in an embodiment of the present invention.

[0021] Figure 4 A schematic diagram of a process for constructing a verification scenario in an embodiment of the present invention.

[0022] Figure 5 The figure is a schematic diagram of the construction process of the verification use case in the embodiment of the present invention.

[0023] Figure 6 Schematic diagram of the process of the verification execution phase in an embodiment of the present invention. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the technical solution of the present invention, the technical solution of the present invention will be further described in detail below in conjunction with the accompanying drawings in the embodiments of the present invention.

[0025] like Figure 1 As shown, the engineering verification method for the functional correctness of a complex software system in this embodiment includes the following steps: S101, perform module function analysis to determine the function of the verified module in the complex software system; perform module input analysis to determine the input required for the verified module in the complex software system to complete the module function; perform execution effect analysis to determine the execution effect of the verified module in the complex software system under given input conditions; construct a description of the verification requirements based on the module function, input conditions and execution effect obtained by the analysis; S102, performing an operating environment analysis to determine the software and hardware environment that the complex software system depends on when it runs, abstracting the context environment of the verified module and the software and hardware environment it depends on in the complex software system to reduce the complexity of verification, executing verification scenario construction according to the abstracted context environment, and inserting the description of the verification requirements into the verification case code using the verification language formalization specification to complete the construction of the verification case; S103, using the verification tool to execute the constructed verification case to obtain the verification result and perform verification defect analysis.

[0026] like Figure 1As shown, the engineering verification method for the functional correctness of a complex software system in this embodiment is carried out in three key stages: verification requirement construction, verification case construction, and verification case execution. In the verification requirement construction stage, the correctness requirements of key modules can be analyzed based on the relevant documents and source files of the complex software system, and the verification requirements for the functional correctness of the complex software system can be constructed, and a detailed description of the verification requirements can be obtained; in the verification case construction stage, by simulating and abstracting the actual execution code of the complex software system, the constructed correctness verification requirements are used to construct a verification case for the functional correctness of the system; in the verification case execution stage, the verification tool is used to execute the verification case to obtain the verification result.

[0027] Figure 2 The main method in this paper is to obtain the detailed correctness verification requirements of the module. Figure 2 As shown, step S101 of this embodiment includes: S201, collecting relevant documents for a complex software system, wherein the relevant documents include part or all of the requirements specification, design documents, and user manual of the complex software system; identifying module responsibilities based on the collected relevant documents, and determining the functions of the verified modules; splitting the functions of the verified modules according to sub-functions so as to design verification requirements according to each sub-function or single function and extracting the main execution paths of each sub-function during actual operation; S202, performing module input analysis to determine the input conditions required for the verified module in the complex software system to complete the verification, including the data type, parameter range and validity condition of the required input of the sub-function; S203, performing execution effect analysis to determine the execution effect of the verified module in the complex software system under a given input condition, including: return value of a function or module, system state change, event triggering, and global variable value change; S204, construct a description of the verification requirements based on the functions, input conditions and execution effects of the verified module obtained by analysis (this can be done through various methods such as test case extraction for software development and generation of large language models (LLMs) prompts); sort and classify the descriptions of the verification requirements, remove duplicate and redundant requirements, and then verify whether the descriptions of all verification requirements are complete and accurate. If the verification is passed, jump to step S102; otherwise, jump to step S204 to continue constructing the description of the verification requirements.

[0028] When verifying a complex software system project, in this embodiment, the functional correctness requirements of each module to be verified in the project are first analyzed one by one, and the design goals and expected behaviors of the modules to be verified are clarified. When analyzing the module functions in step S201, the specific correctness verification requirements of the modules need to be formulated first to conduct a detailed analysis of the functions of the modules to be verified, mainly including collecting all relevant documents of the complex software system to be verified, identifying the module responsibilities, and then decomposing the verification module into multiple sub-modules that can be split and extracting the key execution paths. Collect relevant documents: obtain all relevant requirements specifications, design documents, user manuals, etc. of all software systems to be verified. Module responsibility identification: clarify the main responsibilities and core functions of the functional modules to be verified, and analyze their role in the system, such as resource management, thread scheduling, memory allocation, etc. Sub-function decomposition: split the larger functional modules according to sub-function points, so as to facilitate the design of verification requirements based on each sub-function or single function. Extract key paths: extract the main execution path of the module to be verified during actual operation, for example, the thread priority scheduling loop is a key execution path of the task scheduling module. Module input analysis: defines the inputs and their types received by the module, submodule or specific function, including data type, parameter range, validity conditions, etc. Execution effect analysis: determines the execution effect of the module after receiving the specified input, including the return value of the function or module, changes in the system status, events that can be triggered, changes in the value of global variables, etc. Verification requirements description: can be divided into two parts: formulation of verification requirements and review of verification requirements. Among them, the formulation of verification requirements on the left can be completed in a variety of ways, including the functions and inputs and outputs of the modules or submodules obtained based on the analysis, extraction from relevant documents or test cases written during the development of the software system, and generation using LLMs prompts; the right side is the review of verification requirements. First, all the proposed verification requirements are sorted and classified, and duplicate redundant requirements are removed. Then the verifier verifies whether all requirements are complete and accurate. They can be confirmed by the development team or domain experts, and the requirements are modified and improved based on the summary and feedback.

[0029] When constructing specific verification requirements, step S204 constructs verification requirements for a certain verification object based on the analyzed module functions, inputs, and corresponding execution effects. In addition, the execution effects of some modules may only occur when certain preconditions are met, that is, the module will only obtain the execution effect under specific input conditions. Other execution effects are not subject to precondition restrictions, and the system should produce the same execution effect regardless of the input conditions. For example, in the verification of the system kernel priority scheduling module, the thread priority remains unchanged before and after scheduling, which is an invariant requirement without preconditions; if there are threads waiting to be scheduled in the thread ready queue, then a thread in the ready state should be selected after scheduling, which is a verification requirement with preconditions. Based on the above situation, in order to facilitate the subsequent verification requirement specification, the description of the verification requirements constructed in step S204 of this embodiment includes two categories: verification requirement T and verification requirement p→q. The verification requirement T means that the execution effect of the verified module is universal, and a certain execution effect is obtained for any input situation; the verification requirement p→q means that a certain execution effect q of the verified module is only satisfied under a specific input p, and the specific input p is regarded as a precondition, and the execution effect q to be obtained is recorded as a postcondition as the verification requirement p→q.

[0030] Under the premise of ensuring that the verification environment is consistent with the actual execution environment, the verification tool may not be able to support certain functions of the software module to be verified, or the verification may fail due to the high overhead of simulating the actual execution environment or the state space being too large. Therefore, it is necessary to appropriately abstract the context of the target module, focus on extracting the interaction between the module and other system components and interfaces, and reduce the complexity of verification by simplifying the model. Figure 3 As shown, in step S102 of this embodiment, the context environment abstraction of the verified module and the dependent software and hardware environment in the complex software system includes: S301, performing functional dependency analysis on a verified module in a complex software system to determine an external interface that the verified module depends on in a software and hardware environment; S302, by analyzing the interaction between the verified module and the external interface, the external interface is abstracted into a virtual behavior model by simulating the standard input and output of the external interface to reduce the impact of external dependency on verification; S303, for complex context environments that cannot be abstracted, use simulators to simulate key elements including hardware interfaces and system interrupts to ensure that the simulation environment is consistent with the real environment; S304, for the verified module in the complex software system, delete the code irrelevant to the module function to achieve state space reduction.

[0031] When designing verification scenarios, formulate scenarios that may occur during the actual execution of the software system based on the module functions, inputs and outputs, and the proposed verification requirements. Specifically, parse the verification requirements: extract and organize the verification requirements that occur in the same scenario. The verification requirements contained in multiple verification scenarios can be repeated to ensure that all verification scenarios can cover all requirements. Design verification scenarios: design scenarios that can simulate actual runtime based on the prerequisites of the requirements or the input conditions of the sub-functions under test in the execution path of the software system, such as the values ​​of global variables, the status of task queues, etc. The scenarios cover all requirements: when performing verification on a functional module, all designed verification scenarios ensure that all verification requirements can be covered. The same verification requirement may appear in multiple different scenarios. In this embodiment, designing verification scenarios specifically includes: when designing verification scenarios, by parsing all verification requirements, designing scenarios that can occur during actual runtime based on the input and output conditions of the modules and the key execution paths, to ensure that all verification scenarios can cover all verification requirements. Specifically, Figure 4 As shown, in step S102 of this embodiment, executing verification scenario construction according to the abstracted context environment includes: S401, parsing the description of the verification requirements, extracting and sorting out the verification requirements occurring in the same verification scenario, and making the verification requirements contained in multiple verification scenarios repeatable, so as to ensure that all verification scenarios can cover all verification requirements; S402, designing a verification scenario, including: designing a verification scenario that can simulate actual runtime according to the preconditions of the verification requirements or the input conditions of the main execution path of the sub-function under test in the complex software system; S403, determine whether the designed verification scenario covers the verification requirements described in all verification requirements. If not, jump to step S402 to continue designing the verification scenario; otherwise, determine that it is completed and execute the verification scenario construction according to the abstracted context environment.

[0032] When converting a verification scenario into a verification case code, use the same programming language as the complex software system to be verified to express the input conditions, operating environment and other information described in the verification scenario, insert the call of the module to be verified at the appropriate location, and finally formalize all the verification cases involved in the verification case. A verification case code may not be able to fully describe a verification scenario and can be split into multiple verification case implementations. Figure 5 As shown, in step S102 of this embodiment, the description of the verification requirement is inserted into the verification case code using the verification language formal specification to complete the construction of the verification case, including: S501, using the same programming language as the complex software system to be verified to express input conditions for describing the verification requirements; S502, expressing the execution environment of the description of the verification requirement using the same programming language as the complex software system to be verified; S503, inserting the call of the module to be verified into the description of the verification requirement using the same programming language as the complex software system to be verified, and performing verification requirement specification on the obtained verification case; S504, determine whether the constructed verification case can fully describe the verification scenario. If not, jump to step S501 to continue constructing the verification case; otherwise, jump to step S103.

[0033] In this embodiment, when converting the verification scenario into the verification case code, the constructed scenario is described using the same programming language as the complex software system to be verified. The description includes the simulated operating environment, the input of the module, etc., and finally forms a new function in which the verified module is called. As an optional implementation, in this embodiment, uncertain values ​​can be expressed by using the any keyword, and the input range can be limited and controlled by the assume statement. The constructed verification requirements are inserted into the verification case code using the verification language specification. For the T type, that is, the generally applicable verification requirements, they are described by the assert statement and directly inserted into the appropriate position in the verification case; for the p→q type, that is, the verification requirements with preconditions, the if statement can be used to control the effectiveness of the assertion, so that when the preconditions are met, the postconditions are described by the assert statement to ensure that the verification case can effectively reflect the functional behavior of the module.

[0034] When verifying a complex software system, in order to ensure that the verification environment can accurately simulate the actual execution environment, while reducing the complexity of the verification model as much as possible and improving the executability of the verification, this abstraction not only helps to build an accurate verification model, but also effectively reduces the complexity of the verification. For the above purpose, when designing verification cases, the analysis and abstraction of the context environment become particularly important. Functional dependency analysis: fully analyze the dependencies between the module to be verified and the outside world in the complex software system, and analyze the relevance of these dependencies to the verification of the correctness of the module. External interface abstraction: based on the dependencies sorted out in the functional dependency analysis step, cut, retain, modify, etc. according to their relevance. For external dependencies that are not related to the verification of the module, if it is ensured that it does not affect the module function, its code can be directly removed. For example, when verifying the functional correctness of a task scheduling of an operating system, it has nothing to do with the kernel startup initialization code, so it can be directly removed. The initialization operation that is really needed can be designed as a verification scenario for this verification, and only a small part of the parameters needed are initialized. Some external interfaces are related to the verification of the module, but they are too complex and the state space is too large, which makes the verification work impossible, and they need to be rewritten or abstracted. For example, some variables using the hash method may cause the state space to be too large to be effectively verified. They can be modified to other storage methods, and alternative functions with the same functionality can be designed to perform these operations. Complex environment simulation: For some contexts that are difficult to simply delete or rewrite, they can be replaced by simulating their behavior to simulate the occurrence of certain events. For example, the logic involving system calls contains assembly code that makes it impossible to verify. The occurrence of system calls can be abstractly simulated to avoid the impact of the execution of actual assembly code on verification. State space reduction: The complexity of the verification model can be further reduced. Automated methods such as slicing can be used to delete irrelevant lines of code in abstract contexts or subsequently constructed verification cases, delete path branches that cannot be executed by verification, and reduce the complexity of the verification model.

[0035] In this embodiment, the verification tool is used to perform verification on the constructed verification case and summarize and analyze the overall process of the execution results. Obtain verification projects: including the complete project of the complex software system to be verified or the abstracted project code, the modeled verification scenario, and the constructed verification case. Execute verification tools: Use model verification tools, such as CBMC for C language verification, Kani for Rust language verification, etc., to verify whether the program meets specific specifications and properties to ensure the correctness of the code. Whether the verification process is normal: Determine whether the verification tool can verify the execution normally when executing the verification case, and whether there are no errors in non-verification projects such as unimplemented, compilation errors, and state space explosion; if the verification fails to execute normally, analyze the cause of the error based on the error information and change it to an error or optimize the verification model; if the verification is completed normally, analyze the verification information given by the verification tool. Collect error information: According to the verification information given after the verification tool is executed, if there is no error, the verification is completed, and if an error is found, the error information is recorded. Defect location and error cause analysis: Use the recorded error information to trace the line of code where the defect occurs. For specifications where it is difficult to find the specific defect location, it is necessary to design more specific verification use cases for further verification. Whether the defect is introduced due to improper model construction: Determine whether the defect itself is caused by an error in the software system itself, or whether it is a new defect introduced during the construction of the verification model due to improper construction of the verification model. Optimize the verification model: Consider the correctness of the design of the verification model from multiple aspects such as requirements, context environment abstraction, input condition setting, use case construction, assert statements, etc., and correct the verification model. Record system defects: Record the defects in the verified software system in preparation for subsequent software optimization. Specifically, Figure 6 As shown, step S103 of this embodiment includes: S601, obtaining a project to be verified, wherein the project to be verified includes a complete project of a complex software system or an abstracted project code, a modeled verification scenario, and a constructed verification case; S602, using a verification tool to execute the verification use case constructed in the project to be verified; S603, judging whether the verification process is carried out normally, if not, analyzing the abnormal reason and optimizing the verification model of the item to be verified, and jumping to step S601; otherwise, jumping to step S604; S604, collecting error information; S605, locating the defect and analyzing the cause of the error according to the error information; S606, determine whether the defect is caused by improper construction of the verification model of the project to be verified. If it is caused by improper construction of the verification model of the project to be verified, optimize the verification model of the project to be verified and jump to step S601; otherwise, record the system defect, end and exit. In this embodiment, the error information of the verification tool is used to locate the defect, and the cause of the defect is further analyzed to ensure that the defect is not introduced due to the error in the construction of the verification model. The defects found are classified according to the defect type and severity.

[0036] In summary, the engineering verification method for the functional correctness of a complex software system in this embodiment improves the efficiency and quality of the functional correctness verification of a complex software system through systematic steps and tools, thereby providing support for the quality assurance of software codes. The method covers three core links: verification requirement construction, verification case construction, and verification case execution, forming a set of organized and complete verification processes. Verification requirement construction is the primary step in the verification process, and the key lies in a deep understanding of the module functions and their operating environment of the complex software system. First, by analyzing the source files, project documents, source code annotations of the software system, and communication with the development team, the design goals and expected behaviors of the module to be verified are clarified. Subsequently, the module input analysis is further performed, focusing on various types of input situations that the module may encounter, including data types, input parameter ranges, and input validity conditions. Through input analysis, the input parameters and scenarios that the module may face in the actual operating environment are clarified. Next, the execution effect of the module under a given input condition is analyzed, including how the module processes the input data, the operations performed, and the output or results generated. Based on these analyses, specific verification requirements are constructed to ensure that the verification work can fully cover the functional behavior of the module. Verification case construction is the core of the verification process, and its goal is to convert verification requirements into executable verification cases. When constructing verification cases, it is necessary to fully analyze the actual operating environment of the target software module and build a variety of different scenarios, including normal scenarios, boundary scenarios, and abnormal scenarios, to cover all verification requirements. First, analyze the target operating environment to ensure that the verification conditions in the verification process are consistent with the actual deployment environment. Then, appropriately abstract the context environment, focus on extracting the interaction relationship between the module and other system components and interfaces, and reduce the complexity of verification by simplifying the model. Based on the abstraction of the context environment, design verification scenarios that meet the actual application situation, and use the verification language to convert the verification scenarios into verification case codes. When converting the verification scenario into verification case code, use the same programming language as the complex software system to be verified to describe it, including the simulated operating environment, module input, etc. The input conditions of the verification module are set through the any statement, and the parameters are given an uncertain arbitrary value to cover more system states and boundary conditions. At the same time, use the assume statement to explicitly specify the preconditions or known true assumptions in the verification process to limit the scope of verification and exclude test paths that do not meet the assumptions. Verification case execution is the last step of the verification process. Its goal is to use the verification tool to execute the verification case and obtain the verification results. When executing the verification case, first obtain the verification project and its constructed verification case, then use the verification tool to execute the verification case and collect the verification results. If the verification process exits abnormally, analyze the reasons why the verification cannot proceed normally in combination with the verification tool running log, further optimize the model and verification case, and re-execute the verification.If the verification reports an error, the error information is collected and the error information of the verification tool is used to locate the defect, and the cause of the defect is further analyzed. During the defect analysis process, it is necessary to ensure that the defect is not introduced due to an error in the construction of the verification model, and the defects found are classified according to the defect type and severity. Compared with the traditional direct verification, the engineering verification method for the functional correctness of the complex software system in this embodiment has the following characteristics: 1. A clearer and more complete verification process, from the proposal of module requirements to the construction of verification cases to the final execution of verification cases, forming a complete set of ideas and specific implementation methods for the execution verification of functional modules of complex software systems, effectively improving the execution efficiency and reliability of complex software during verification; 2. A clearer requirement construction method, modularizing the software system correctness verification, considering the proposal of requirements from the perspective of module functions, input conditions and output effects, to a certain extent solving the problem of unclear requirements for verification personnel, and ensuring the correctness of the proposed requirements and the integrity of verification; 3. A method of abstracting and modeling a verifiable real operating environment, through context analysis, external 1. Abstract the actual execution environment of the software system by abstracting the partial interface and reducing the state space, and make it verifiable; 2. Complete verification case construction method, considering the input of the software system on the module to be verified and all the real scenarios of calling the module to be verified, building a complete verification scenario and covering all verification requirements, combined with the specification method of verification requirements, can complete the construction of verification cases more comprehensively; 3. Automated verification method, using the formal verification method of program verification, on the basis of ensuring logical reliability, can directly complete the verification case coding in the software system code, directly embed the verification case and complete the verification requirement specification in the abstract code, and automatically perform verification in units of code behavior, which greatly reduces the workload and improves the verification efficiency.

[0037] In addition, this embodiment also provides an engineering verification system for the functional correctness of a complex software system, including a microprocessor and a memory connected to each other, wherein the microprocessor is programmed or configured to execute the engineering verification method for the functional correctness of the complex software system.

[0038] In addition, this embodiment also provides a computer-readable storage medium, in which a computer program or instruction is stored. The computer program or instruction is programmed or configured to execute an engineering verification method for the functional correctness of the complex software system through a processor.

[0039] In addition, this embodiment also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the engineering verification method for the functional correctness of the complex software system through a processor.

[0040] Those skilled in the art should understand that the technical solutions provided by the embodiments of the present invention may be in the form of methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes. The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, may be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that instructions executed by the processor of a computer or other programmable data processing device generate instructions for implementing the functions in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0041] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.

Claims

1. An engineering verification method for the functional correctness of a complex software system, characterized in that: The steps include: S101, perform module function analysis to determine the function of the verified module in the complex software system; perform module input analysis to determine the input required for the verified module in the complex software system to complete the module function; perform execution effect analysis to determine the execution effect of the verified module in the complex software system under given input conditions; construct a description of the verification requirements based on the module function, input conditions and execution effect obtained by the analysis; S102, performing an operating environment analysis to determine the software and hardware environment that the complex software system depends on when it runs, abstracting the context environment of the verified module and the software and hardware environment it depends on in the complex software system to reduce the complexity of verification, executing verification scenario construction according to the abstracted context environment, and inserting the description of the verification requirements into the verification case code using the verification language formalization specification to complete the construction of the verification case; S103, using the verification tool to execute the constructed verification case to obtain the verification result and perform verification defect analysis.

2. The engineering verification method for the functional correctness of a complex software system according to claim 1 is characterized in that: Step S101 includes: S201, collecting relevant documents for a complex software system, wherein the relevant documents include part or all of the requirements specification, design documents, and user manual of the complex software system; identifying module responsibilities based on the collected relevant documents, and determining the functions of the verified modules; splitting the functions of the verified modules according to sub-functions so as to design verification requirements according to each sub-function or single function and extracting the main execution paths of each sub-function during actual operation; S202, performing module input analysis to determine the input conditions required for the verified module in the complex software system to complete the verification, including the data type, parameter range and validity condition of the required input of the sub-function; S203, performing execution effect analysis to determine the execution effect of the verified module in the complex software system under a given input condition, including: return value of a function or module, system state change, event triggering, and global variable value change; S204, construct a description of the verification requirements based on the functions, input conditions and execution effects of the verified module obtained by analysis; organize and classify the descriptions of the verification requirements, remove duplicate and redundant requirements, and then verify whether the descriptions of all verification requirements are complete and accurate. If the verification is passed, jump to step S102; otherwise, jump to step S204 to continue constructing the description of the verification requirements.

3. The engineering verification method for the functional correctness of a complex software system according to claim 2 is characterized in that: The description of the verification requirements constructed in step S204 includes two categories: verification requirements T and verification requirements p→q. Verification requirement T means that the execution effect of the verified module is universal, and a certain execution effect is obtained for any input situation; verification requirement p→q means that a certain execution effect q of the verified module is only satisfied under a specific input p, and the specific input p is regarded as a precondition, and the execution effect q to be obtained is recorded as a postcondition as the verification requirement p→q.

4. The engineering verification method for the functional correctness of a complex software system according to claim 1, characterized in that: In step S102, the context environment abstraction of the verified module and the software and hardware environment it depends on in the complex software system includes: S301, performing functional dependency analysis on a verified module in a complex software system to determine an external interface that the verified module depends on in a software and hardware environment; S302, by analyzing the interaction between the verified module and the external interface, the external interface is abstracted into a virtual behavior model by simulating the standard input and output of the external interface to reduce the impact of external dependency on verification; S303, for complex context environments that cannot be abstracted, use simulators to simulate key elements including hardware interfaces and system interrupts to ensure that the simulation environment is consistent with the real environment; S304, for the verified module in the complex software system, delete the code irrelevant to the module function to achieve state space reduction.

5. The engineering verification method for the functional correctness of a complex software system according to claim 1, characterized in that: In step S102, the verification scenario construction is performed according to the abstracted context environment, including: S401, parsing the description of the verification requirements, extracting and sorting out the verification requirements occurring in the same verification scenario, and making the verification requirements contained in multiple verification scenarios repeatable, so as to ensure that all verification scenarios can cover all verification requirements; S402, designing a verification scenario, including: designing a verification scenario that can simulate actual runtime according to the preconditions of the verification requirements or the input conditions of the main execution path of the sub-function under test in the complex software system; S403, determine whether the designed verification scenario covers the verification requirements described in all verification requirements. If not, jump to step S402 to continue designing the verification scenario; otherwise, determine that it is completed and execute the verification scenario construction according to the abstracted context environment.

6. The engineering verification method for the functional correctness of a complex software system according to claim 1, characterized in that: In step S102, the description of the verification requirement is inserted into the verification case code using the verification language formal specification to complete the construction of the verification case, including: S501, using the same programming language as the complex software system to be verified to express input conditions for describing the verification requirements; S502, expressing the execution environment of the description of the verification requirement using the same programming language as the complex software system to be verified; S503, inserting the call of the module to be verified into the description of the verification requirement using the same programming language as the complex software system to be verified, and performing verification requirement specification on the obtained verification case; S504, determine whether the constructed verification case can fully describe the verification scenario. If not, jump to step S501 to continue constructing the verification case; otherwise, jump to step S103.

7. The engineering verification method for the functional correctness of a complex software system according to claim 1 is characterized in that: Step S103 includes: S601, obtaining a project to be verified, wherein the project to be verified includes a complete project of a complex software system or an abstracted project code, a modeled verification scenario, and a constructed verification case; S602, using a verification tool to execute the verification use case constructed in the project to be verified; S603, judging whether the verification process is carried out normally, if not, analyzing the abnormal reason and optimizing the verification model of the item to be verified, and jumping to step S601; otherwise, jumping to step S604; S604, collecting error information; S605, locating the defect and analyzing the cause of the error according to the error information; S606, determine whether the defect is introduced due to improper construction of the verification model of the project to be verified. If it is a defect introduced due to improper construction of the verification model of the project to be verified, optimize the verification model of the project to be verified and jump to step S601; otherwise, record the system defect, end and exit.

8. An engineering verification system for the functional correctness of a complex software system, comprising a microprocessor and a memory connected to each other, characterized in that: The microprocessor is programmed or configured to execute the engineering verification method for the functional correctness of a complex software system as claimed in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program or instruction stored therein, characterized in that: The computer program or instruction is programmed or configured to execute the engineering verification method for the functional correctness of a complex software system as claimed in any one of claims 1 to 7 through a processor.

10. A computer program product comprising a computer program or instructions, characterized in that The computer program or instruction is programmed or configured to execute the engineering verification method for the functional correctness of a complex software system as claimed in any one of claims 1 to 7 through a processor.

Images