An Engineering Verification Method and System for the Functional Correctness of Complex Software Systems

Abstract

The present invention discloses an engineering verification method and system for the functional correctness of a complex software system. 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 obtained module functions, input conditions, and execution effects; performing operating environment analysis to determine the software and hardware environments relied on during the operation of the complex software system, performing context environment abstraction, and constructing verification scenarios according to the abstracted context environment, and inserting the description of verification requirements formalized by a verification language into the verification case code to complete the construction of verification cases; using a verification tool to execute the constructed verification cases to obtain verification results and perform verification defect analysis. 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, providing support for the quality assurance of complex software systems.

Description

Technical Field

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

[0002] Complex software systems usually consist of multiple interdependent modules, each responsible for different functions and communicating with other modules through interfaces. Taking the operating system kernel as an example, it is the core component that manages computer hardware resources, provides application programming interfaces (APIs), and executes critical tasks. The operating system kernel not only needs to handle multiple functions such as multitasking scheduling, memory management, and file system operations, but also needs to respond to external interrupts and kernel-mode exceptions in an extremely 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. Such complex concurrent behaviors make the system prone to problems such as 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, facing diverse user inputs and external devices, and any subtle environmental change may trigger potential system function errors. Therefore, it is particularly important to conduct a systematic and comprehensive verification of the functional correctness of complex software systems.

[0003] Existing verification techniques include dynamic testing, static analysis, and formal methods. These techniques have addressed the requirements of system function verification to varying degrees. 1. Dynamic testing is the most commonly used verification method. By dynamically executing the system, it checks whether the output of the system under specific input conditions meets the expectations. The advantage of the testing method is that it is easy to understand and implement, and can discover functional errors and abnormal behaviors in the system to a certain extent. However, testing depends on predefined test cases, usually only covering part of the input space and execution paths of the system. For complex software systems, the input space of the system may be infinite, and it is impossible to exhaust all input combinations and boundary conditions through testing. Therefore, testing techniques cannot provide a complete guarantee of the correctness of system functions. 2. Static analysis technology is a technique that analyzes based on the source code or intermediate code of a 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 depend 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, it is difficult for static analysis to accurately capture the interactions between threads and resource contention issues. 3. Formal verification is a verification technique based on mathematical models. By constructing formal specifications, it proves whether a program meets specific functional requirements. The advantage of formal verification is that it can provide strict mathematical proofs to ensure the correctness of the program. For example, in the method of theorem proving, programmers or verification engineers construct logical propositions about the behavior of a program or system and use automatic or semi-automatic theorem provers (such as Coq, 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, and the cost is extremely high. In addition, the formal method of program verification performs an exhaustive search on the finite state model of the system to check whether the system meets specific specifications and can directly edit verification cases in the source code to automatically execute the verification.

[0004] Formal verification methods based on program verification, with their rigorous logical foundation and highly automated features, significantly reduce the burden on developers during the modeling process of complex software systems. This enables verification work to efficiently execute verification on system modules with the help of automated verification tools, thereby effectively improving software quality. However, many problems still exist during the verification process. First, for a given system to be verified, there is often a lack of clear verification requirements, that is, a clear definition of functional correctness is lacking. Second, in the face of a large and complex system, limited by the verification capabilities of existing verification technologies and tools, it is unrealistic to directly verify the entire system. Therefore, it is necessary to abstract the verification module according to the verification requirements. How to effectively manage its complexity while maintaining the accuracy of the verification module and preventing state space explosion has become an urgent problem to be solved. In addition, during the verification process, it is necessary to ensure both the sufficiency and verifiability of 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 during the abstraction process.

[0005] In summary, when the existing verification methods and frameworks are applied to the verification of complex software systems, their deficiencies are mainly reflected in: 1) The lack of verification requirements, making 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 reducing the verification scale while ensuring verification accuracy. Summary of the Invention

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

[0007] To solve the above technical problems, the technical solution adopted by the present invention is as follows:

[0008] An engineering verification method for the functional correctness of complex software systems, comprising the following steps:

[0009] S101, perform module function analysis to determine the function of the module to be verified in the complex software system; perform module input analysis to determine the input conditions required for the module to be verified in the complex software system to complete the module function; perform execution effect analysis to determine the execution effect of the module to be verified in the complex software system under the given input conditions; construct a description of the verification requirements based on the analyzed module function, input conditions, and execution effect;

[0010] S102. Conduct a runtime environment analysis to determine the software and hardware environment on which the complex software system depends during runtime. Abstract the context environment of the module to be verified and the dependent software and hardware environment in the complex software system to reduce the complexity of verification. Construct a verification scenario based on the abstracted context environment, and insert the formal specification of the verification requirements in the verification language into the verification case code to complete the construction of the verification case.

[0011] S103. Use a verification tool to execute the constructed verification case to obtain a verification result and conduct a verification defect analysis.

[0012] Optionally, step S101 includes:

[0013] S201. Collect relevant documents for the complex software system. The relevant documents include some or all of the requirements specification, design document, and user manual of the complex software system. Identify the module responsibilities based on the collected relevant documents to determine the functions of the module to be verified. Split the functions of the module to be verified according to sub-functions to facilitate designing verification requirements based on each sub-function or individual function and extracting the main execution paths of each sub-function during actual operation.

[0014] S202. Conduct a module input analysis to determine the input conditions required for the module to be verified in the complex software system to complete the verification, including the data types, parameter ranges, and validity conditions of the required inputs of the sub-functions.

[0015] S203. Conduct an execution effect analysis to determine the execution effects of the module to be verified in the complex software system under given input conditions, including: return values of functions or modules, system state changes, event triggers, and changes in global variable values.

[0016] S204. Construct a description of the verification requirements based on the functions, input conditions, and execution effects of the module to be verified obtained from the analysis. Organize and classify the description of the verification requirements, remove duplicate and redundant requirements, and then verify whether all descriptions of the verification requirements are complete and accurate. If the verification passes, jump to step S102; otherwise, jump to step S204 to continue constructing the description of the verification requirements.

[0017] Optionally, the description of the verification requirements constructed in step S204 includes two types: verification requirement T and verification requirement p→q. Among them, verification requirement T means that the execution effect of the module to be verified is universal, and a definite execution effect is obtained for any input condition; verification requirement p→q means that a certain execution effect q of the module to be verified is only satisfied under a specific input p. Record the specific input p as the precondition and the expected execution effect q as the postcondition as the verification requirement p→q.

[0018] Optionally, the context environment abstraction of the module to be verified and the dependent software and hardware environment in the complex software system in step S102 includes:

[0019] S301. Perform functional dependency analysis on the module to be verified in the complex software system to determine the external interfaces on which the module to be verified depends in the software and hardware environment;

[0020] S302. By analyzing the interaction behavior between the module to be verified and the external interface, abstract the external interface as a virtual behavior model by simulating the standard input and output of the external interface to reduce the impact of external dependencies on verification;

[0021] S303. For the complex context environment that cannot be abstracted, use a simulator to simulate key elements including hardware interfaces and system interrupts to ensure that the simulation environment is consistent with the real environment;

[0022] S304. Delete the code unrelated to the module function for the module to be verified in the complex software system to achieve state space reduction.

[0023] Optionally, the verification scenario construction according to the abstracted context environment in step S102 includes:

[0024] S401. Parse the description of the verification requirements, extract and sort out the verification requirements that occur in the same verification scenario. The verification requirements included in multiple verification scenarios can be repeated to ensure that all verification scenarios can cover all verification requirements;

[0025] S402. Design verification scenarios, including: designing verification scenarios that can simulate the 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;

[0026] S403. Determine whether the designed verification scenarios cover all the verification requirements described in the verification requirements. If not all the verification requirements described in the verification requirements are covered, jump to step S402 to continue designing verification scenarios; otherwise, it is determined that the verification scenario construction according to the abstracted context environment is completed.

[0027] Optionally, inserting the description of the verification requirements into the verification case code in the form of a verification language formal specification to complete the construction of the verification case in step S102 includes:

[0028] S501. Represent the input conditions of the description of the verification requirements using the same programming language as the complex software system to be verified;

[0029] S502. Represent the execution environment of the description of the verification requirements using the same programming language as the complex software system to be verified;

[0030] S503. Insert the call of the module to be verified into the description of the verification requirements using the same programming language as the complex software system to be verified, and perform verification requirement specification on the obtained test cases.

[0031] S504. Determine whether the constructed test cases can completely describe the verification scenario. If not, jump to step S501 to continue constructing test cases; otherwise, jump to step S103.

[0032] Optionally, step S103 includes:

[0033] S601. Obtain the project to be verified, where the project to be verified includes the complete project of the complex software system or the abstracted project code, the modeled verification scenario, and the constructed test cases.

[0034] S602. Use the verification tool to execute the constructed test cases in the project to be verified.

[0035] S603. Determine whether the verification process is proceeding normally. If not, analyze the cause of the anomaly and optimize the verification model of the project to be verified, then jump to step S601; otherwise, jump to step S604.

[0036] S604. Collect error messages.

[0037] S605. Locate the defect based on the error messages and analyze the cause of the error.

[0038] S606. Determine whether the defect is introduced due to improper construction of the verification model of the project to be verified. If the defect is introduced due to improper construction of the verification model of the project to be verified, then optimize the verification model of the project to be verified and jump to step S601; otherwise, record the system defect and end and exit.

[0039] In addition, the present invention 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, and the microprocessor is programmed or configured to execute the engineering verification method for the functional correctness of the complex software system.

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

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

[0042] 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 from the analysis; performing operating environment analysis to determine the software and hardware environments relied on when the complex software system runs, performing context environment abstraction, and constructing verification scenarios according to the abstracted context environment, and inserting the description of verification requirements formalized in the verification language into the verification case code to complete the construction of verification cases; using a verification tool to execute the constructed verification cases to obtain verification results and perform verification defect analysis. The present invention forms a complete engineering verification mechanism for the functional correctness of complex software systems through three stages: verification requirement construction, verification case construction, and verification case execution, providing support for the quality assurance of complex software systems and improving the verification effectiveness of complex software systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 It is a schematic diagram of the basic process of the method of the embodiment of the present invention.

[0044] Figure 2 It is a schematic diagram of the process of the verification requirement construction stage in the embodiment of the present invention.

[0045] Figure 3 It is a schematic diagram of the process of context environment abstraction in the embodiment of the present invention.

[0046] Figure 4 It is a schematic diagram of the process of verification scenario construction in the embodiment of the present invention.

[0047] Figure 5 It is a schematic diagram of the process of constructing verification cases in the embodiment of the present invention.

[0048] Figure 6 It is a schematic diagram of the process of the verification execution stage in the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

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

[0050] As Figure 1 shown, the engineering verification method for the functional correctness of the complex software system in this embodiment includes the following steps:

[0051] S101. Conduct module function analysis to determine the functions of the module to be verified in a complex software system; conduct module input analysis to determine the input conditions required for the module to be verified in the complex software system to complete its functions; conduct execution effect analysis to determine the execution effects of the module to be verified in the complex software system under given input conditions; construct a description of the verification requirements based on the analyzed module functions, input conditions, and execution effects.

[0052] S102. Conduct operating environment analysis to determine the software and hardware environments on which the complex software system depends during operation. Abstract the context environment of the module to be verified in the complex software system and the dependent software and hardware environments to reduce the complexity of verification. Execute verification scenario construction based on the abstracted context environment, and insert the formal specification of the verification requirements described in the verification language into the verification case code to complete the construction of the verification cases.

[0053] S103. Use the verification tool to execute the constructed verification cases to obtain the verification results and conduct verification defect analysis.

[0054] As Figure 1 shown, the engineering verification method for the functional correctness of the 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, according to the relevant documents and source files of the complex software system, analyze the correctness requirements of the key modules therein, construct the verification requirements for the functional correctness of the complex software system, and obtain a detailed description of the verification requirements. In the verification case construction stage, by simulating and abstracting the actual execution code of the complex software system, use the constructed correctness verification requirements to construct verification cases for the functional correctness of the system. In the verification case execution stage, use the verification tool to execute the verification cases to obtain the verification results.

[0055] Figure 2 mainly shows the detailed method for obtaining the specific correctness verification requirements of the module. As Figure 2 shown, step S101 of this embodiment includes:

[0056] S201. Collect relevant documents for the complex software system, where the relevant documents include some or all of the requirement specification, design document, and user manual of the complex software system; identify the module responsibilities according to the collected relevant documents to determine the functions of the module to be verified; split the functions of the module to be verified according to sub-functions to facilitate designing verification requirements based on each sub-function or single function and extracting the main execution paths of each sub-function during actual operation.

[0057] S202. Conduct module input analysis to determine the input conditions required for the module to be verified in the complex software system to complete the verification, including the data types, parameter ranges, and validity conditions of the input required for the sub-functions.

[0058] S203, perform execution effect analysis to determine the execution effect of the module under verification in a complex software system under given input conditions, including: return values of functions or modules, system state changes, event triggers, and changes in global variable values;

[0059] S204, construct a description of the verification requirements based on the functions, input conditions, and execution effects of the module under verification obtained from the analysis (which can be achieved through various methods such as test case extraction in software development and prompting generation by large language models LLMs); organize and classify the description of the verification requirements, remove duplicate and redundant requirements, and then verify whether all descriptions of the verification requirements are complete and accurate. If the verification passes, jump to step S102; otherwise, jump to step S204 to continue constructing the description of the verification requirements.

[0060] When performing verification on 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 to clarify the design goals and expected behaviors of the modules to be verified. When analyzing the module functions in step S201, formulating specific correctness verification requirements for the module first requires a detailed analysis of the functions of the module to be verified, mainly including collecting all relevant documents of the complex software system to be verified, identifying module responsibilities, 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 requirement specifications, design documents, user manuals, etc. of the software system to be verified. Module responsibility identification: Clarify the main responsibilities and core functions of the functional module to be verified, and analyze its role in the system, such as resource management, thread scheduling, memory allocation, etc. Sub-function decomposition: Split larger functional modules according to sub-function points to facilitate designing verification requirements based on each sub-function or individual function. Extract key paths: Extract the main execution paths 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: Define the inputs received by the module, sub-module, or specific function and their types, including data types, parameter ranges, validity conditions, etc. Execution effect analysis: Determine the execution effects generated by the module after receiving the specified input, including the return values of functions or modules, changes in system states, events that can be triggered, changes in global variable values, etc. Verification requirement description: It can be divided into two parts: the formulation of verification requirements and the review of verification requirements. Among them, the formulation of verification requirements on the left can be completed by combining various methods to put forward requirements, including based on the functions and input / outputs of the analyzed module or sub-module, extracting from relevant documents or test cases written during software system development, generating using LLMs prompts, etc.; on the right is the review of verification requirements. First, organize and classify all the proposed verification requirements, remove duplicate and redundant requirements, and then verify whether all requirements are complete and accurate by verification personnel, which can be confirmed by the development team or domain experts, and modify and improve the requirements according to the summary and feedback.

[0061] When constructing specific verification requirements in step S204, the verification requirements for a certain verification object are constructed based on the analyzed module functions, inputs, and corresponding execution effects. Additionally, the execution effects of some modules may occur only when certain preconditions are met, that is, the module will obtain the execution effect only under specific input conditions. While for other execution effects, there are no 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 priorities remain 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 ready-state thread should be selected after scheduling, which is a verification requirement with preconditions. Based on the above situations, for the convenience of subsequent verification requirement specification, the descriptions of the verification requirements constructed in step S204 of this embodiment include two types: verification requirement T and verification requirement p→q. Among them, verification requirement T means that the execution effect of the module to be verified is universal, and a definite execution effect is obtained for any input situation; verification requirement p→q means that a certain execution effect q of the module to be verified is satisfied only under a specific input p. The specific input p is regarded as the precondition, and the execution effect q to be obtained is recorded as the postcondition as the verification requirement p→q.

[0062] On the premise of ensuring that the verification environment is consistent with the actual execution environment, during the verification process, it may occur that the verification tool does not support some functions of the software module to be verified, or the verification fails due to problems such as excessive overhead in simulating the actual execution environment or an overly large state space. Therefore, it is necessary to appropriately abstract the context environment of the target module, focus on extracting the interaction relationships between the module and other system components and interfaces, and reduce the complexity of verification through a simplified model. Specifically, as Figure 3 shown, the context environment abstraction of the module to be verified and the dependent software and hardware environment in the complex software system in step S102 of this embodiment includes:

[0063] S301, perform functional dependency analysis on the module to be verified in the complex software system to determine the external interfaces on which the module to be verified depends in the software and hardware environment;

[0064] S302, by analyzing the interaction behavior between the module to be verified and the external interface, abstract the external interface into a virtual behavior model by simulating the standard input and output of the external interface to reduce the impact of external dependencies on verification;

[0065] S303, for the complex context environment that cannot be abstracted, use a simulator to simulate key elements including hardware interfaces and system interrupts to ensure that the simulation environment is consistent with the real environment;

[0066] S304, delete the code irrelevant to the module function for the module to be verified in the complex software system to achieve state space reduction.

[0067] When designing verification scenarios, according to the module functions, inputs and outputs, and the proposed verification requirements, scenarios that may occur during the actual execution of the software system are formulated. Specifically, the verification requirements are parsed: the verification requirements that occur in the same scenario are extracted and organized. The verification requirements included in multiple verification scenarios can be repeated to ensure that all verification scenarios can cover all requirements. Design verification scenarios: According to the preconditions of the requirements or the input conditions of the sub-function under test in the execution path of the software system, such as the values of global variables, the status of the task queue, etc., design scenarios that can simulate the actual operation. Scenarios cover all requirements: When verifying a functional module, all designed verification scenarios ensure that they can cover all verification requirements. The same verification requirement may appear in multiple different scenarios. In this embodiment, when designing verification scenarios, it specifically includes that when designing verification scenarios, by parsing all verification requirements, according to the input and output situations of the module and the critical execution path, design scenarios that can occur during actual operation to ensure that all verification scenarios can cover all verification requirements. Specifically, as Figure 4 shown, in step S102 of this embodiment, constructing the verification scenario according to the abstracted context environment includes:

[0068] S401, Parse the description of the verification requirements, extract and organize the verification requirements that occur in the same verification scenario. The verification requirements included in multiple verification scenarios can be repeated to ensure that all verification scenarios can cover all verification requirements;

[0069] S402, Design verification scenarios, including: Design verification scenarios that can simulate actual operation 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;

[0070] S403, Determine whether the designed verification scenarios cover all the verification requirements described in the verification requirements. If not all the verification requirements described in the verification requirements are covered, jump to step S402 to continue designing verification scenarios; otherwise, it is determined that the construction of the verification scenario according to the abstracted context environment is completed.

[0071] When converting the verification scenario into verification case code, use the same programming language as the complex software system to be verified to represent the input conditions, operating environment, etc. described in the verification scenario, and insert the call of the module to be verified at the appropriate position. Finally, formalize all the verification case specifications involved in this verification case. One verification case code may not be able to completely describe a verification scenario and can be split into multiple verification cases for implementation. As Figure 5 shown, in step S102 of this embodiment, formalizing the description of the verification requirements using the verification language and inserting it into the verification case code to complete the construction of the verification case includes:

[0072] S501, using the same programming language as the complex software system to be verified to express input conditions for describing the verification requirements;

[0073] 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;

[0074] 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;

[0075] 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.

[0076] 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.

[0077] When verifying complex software systems, 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 kind of abstraction not only helps to build an accurate verification model, but also can effectively reduce the complexity of the verification. For the above purposes, when designing verification cases, the analysis and abstraction of the context environment become particularly important. Functional dependency analysis: Sufficiently analyze the dependency relationships 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: According to the dependency relationships sorted out in the functional dependency analysis step, perform operations such as trimming, retaining, and modifying according to their relevance. For external dependencies that are irrelevant to the verification of the module, if it is ensured that the module function is not affected, their code can be directly removed. For example, when verifying the functional correctness of a certain operating system task scheduling, the code related to the kernel startup initialization has nothing to do with it, and it can be directly removed. The initialization operations that are really needed can be designed as verification scenarios for this verification, and only a small part of the parameters that need to be used are initialized. Some external interfaces are related to the verification of the module, but are too complex and have too large a state space, resulting in the inability to carry out the verification work, and 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, and can be modified to be stored in other ways, and alternative functions with the same function are 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 behaviors, simulating the occurrence of a certain event. For example, the logic involving system calls contains assembly code that makes it impossible to verify, and the occurrence of system calls can be abstractly simulated to avoid the impact of the execution of actual assembly code on the verification. State space reduction: The complexity of the verification model can be further reduced by using automated methods such as slicing to delete irrelevant code lines in the abstracted context or the verification cases constructed later, delete the path branches that cannot be reached during verification execution, and reduce the complexity of the verification model.

[0078] In this embodiment, the overall process of using a verification tool to execute the constructed verification cases and summarize and analyze the execution results is as follows. Obtain the verification project: 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 cases. Execute the verification tool: Use model checking tools, such as CBMC for C language verification and Kani for Rust language verification, to verify whether the program meets specific specifications and properties and ensure the correctness of the code. Whether the verification process proceeds normally: Determine whether the verification tool can normally complete the verification when executing the verification cases, without encountering errors such as unimplemented, compilation errors, and state space explosion that are not part of the verification project; if the verification fails to execute normally, analyze the cause of the error based on the error message and correct the error or optimize the verification model; if the verification is completed normally, analyze the verification information given by the verification tool. Collect error messages: According to the verification information given after the verification tool finishes execution, if there is no error, the verification is completed; if an error is found, record the error message. Locate the defect and analyze the cause of the error: Use the recorded error message to trace the line number of the code where the defect appears. For specifications where it is difficult to find the specific defect location, more specific verification cases need to be designed for further verification. Whether the defect is introduced due to improper model construction: Determine whether the defect is caused by an error in the software system itself or a new defect introduced due to improper construction of the verification model during the construction process. Optimize the verification model: Consider the correctness of the design of the verification model from multiple aspects such as requirements, context abstraction, input condition setting, use case construction, and assert statements, and correct the verification model. Record system defects: Record the defect problems that occur in the verified software system for subsequent software optimization. Specifically, as Figure 6 shown, step S103 of this embodiment includes:

[0079] S601. Obtain the project to be verified, where the project to be verified includes the complete project of the complex software system or the abstracted project code, the modeled verification scenario, and the constructed verification cases;

[0080] S602. Use a verification tool to execute the constructed verification cases in the project to be verified;

[0081] S603. Determine whether the verification process proceeds normally. If it does not proceed normally, analyze the cause of the abnormality and optimize the verification model of the project to be verified, and jump to step S601; otherwise, jump to step S604;

[0082] S604. Collect error messages;

[0083] S605. Locate the defect according to the error message and analyze the cause of the error;

[0084] S606. Determine whether the defect is introduced due to improper construction of the verification model of the item to be verified. If the defect is introduced due to improper construction of the verification model of the item to be verified, optimize the verification model of the item to be verified and jump to step S601; otherwise, record the system defect, end and exit. In this embodiment, the error message of the verification tool is used for defect location, and the cause of the defect is further analyzed to ensure that the defect is not introduced due to incorrect construction of the verification model. The discovered defects are classified according to the defect type and severity.

[0085] In summary, the engineering verification method for the functional correctness of complex software systems in this embodiment improves the efficiency and quality of verifying the functional correctness of complex software systems through systematic steps and tools, thereby providing support for the quality assurance of software code. This method covers three core aspects: verification requirement construction, verification case construction, and verification case execution, forming a well-organized and complete verification process. Verification requirement construction is the primary step in the verification process, and the key lies in deeply understanding the module functions of complex software systems and their operating environments. First, by analyzing the source files of the software system, project documents, source code comments, and communication with the development team, clarify the design goals and expected behaviors of the module to be verified. Subsequently, further conduct module input analysis, focusing on various input situations that the module may encounter, including data types, input parameter ranges, and input validity conditions, etc. Through input analysis, clarify the input parameters and scenarios that the module may face in the actual operating environment. Then, analyze the execution effects of the module under given input situations, including how the module processes input data, the operations performed, and the outputs or results generated. Based on these analyses, construct specific verification requirements to ensure that the verification work can comprehensively cover the functional behaviors of the module. Verification case construction is the core aspect of the verification process, and its goal is to transform 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 construct multiple different scenarios, including normal scenarios, boundary scenarios, and abnormal scenarios, etc., to cover all verification requirements. First, analyze the target operating environment to ensure that the verification conditions during the verification process are consistent with the actual deployment environment. Subsequently, appropriately abstract the context environment, focusing on extracting the interaction relationships between the module and other system components and interfaces, and reducing the complexity of verification through a simplified model. On the basis of context environment abstraction, design verification scenarios that conform to the actual application situation and use a verification language to transform the verification scenarios into verification case code. When transforming verification scenarios into verification case code, use the same programming language as the complex software system to be verified, including the simulated operating environment, module inputs, etc. Set the input conditions of the verification module through the any statement, assigning an arbitrary value to the parameter to cover more system states and boundary situations. At the same time, use the assume statement to clearly specify the prerequisite conditions or assumptions known to be true during the verification process to limit the verification scope and exclude test paths that do not meet the assumed conditions. Verification case execution is the last step in the verification process, and its goal is to use verification tools to execute verification cases and obtain verification results. When executing verification cases, first obtain the project to be verified and the constructed verification cases, and then use verification tools to execute verification cases and collect 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 cases, and re-execute the verification.If a verification error occurs, collect the error information and use the verification tool error information to locate the defect, and further analyze the cause of the defect. During the defect analysis process, it is necessary to ensure that the defect is not introduced due to incorrect verification model construction, and classify the discovered defects according to the defect type and severity. The engineering verification method for the functional correctness of the complex software system in this embodiment has the following advantages compared with the traditional direct verification: 1. A clearer and more complete verification process, forming a complete set of ideas and specific implementation methods for verifying the functional modules of the complex software system from the proposal of module requirements to the construction of verification cases to the execution of verification cases finally, effectively improving the execution efficiency and reliability of the complex software during verification; 2. A more explicit requirement construction method, modularizing the verification of the software system correctness, considering the requirements from 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 requirement proposal and verification integrity; 3. A method of abstracting and modeling the verifiable real operating environment, abstracting the environment of the software system during actual execution through methods such as context analysis, external interface abstraction, and state space reduction, and making it verifiable; 4. A complete verification case construction method, considering the input situation of the software system on the module to be verified and all real scenarios that call the module to be verified, constructing a complete verification scenario and covering all verification requirements, and combining with the specification method of verification requirements, can complete the construction of verification cases more comprehensively; 5. An 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 verification cases and complete verification requirement specification in the abstract code, and automatically execute verification in units of code behavior, greatly reducing the workload and improving the verification efficiency.

[0086] 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, and the microprocessor is programmed or configured to execute the engineering verification method for the functional correctness of the complex software system.

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

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

[0089] Those skilled in the art should understand that the technical solutions provided by the embodiments of the present invention can be in the form of methods, systems, or computer program products. Therefore, the present invention can be implemented in the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can be in the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program code. The present invention is described with reference to the flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, and the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing devices to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing devices generate means for implementing the functions specified in the process Figure 1 one process or multiple processes and / or blocks Figure 1 or means for implementing the functions specified in multiple blocks. These computer program instructions can also be stored in a computer-readable memory capable of guiding a computer or other programmable data processing devices to work in a specific manner, such that the instructions stored in the computer-readable memory generate a manufactured article including instruction means, and the instruction means implement the functions specified in the process Figure 1 one process or multiple processes and / or blocks Figure 1 or means for implementing the functions specified in multiple blocks. These computer program instructions can also be loaded onto a computer or other programmable data processing devices, such that a series of operation steps are executed on the computer or other programmable devices to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable devices provide steps for implementing the functions specified in the process Figure 1 one process or multiple processes and / or blocks Figure 1 or means for implementing the functions specified in multiple blocks.

[0090] The above is only the preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions falling within the idea of the present invention belong to the protection scope of the present invention. It should be noted that for those of ordinary skill in the art in this technical field, several improvements and refinements made without departing from the principle of the present invention should also be regarded as within 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; 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 irrelevant codes of the module function to achieve state space reduction; 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.

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 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.

5. The engineering verification method for the functional correctness of a complex software system according to claim 1, 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.

6. 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 5.

7. 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 5 through a processor.

8. 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 5 through a processor.

Images