A function function and requirement consistency verification method and system

Abstract

The application discloses a function function and requirement consistency verification method and system, and the method comprises the steps of obtaining a function function requirement document described in natural language, parsing the function function requirement document based on a requirement document analysis model, generating corresponding requirement semantic vectors, and forming a requirement semantic vector set; obtaining a to-be-tested function source code, performing static analysis on the to-be-tested function source code, constructing an intermediate representation, determining a plurality of code segments based on the intermediate representation, generating a code semantic vector corresponding to each code segment, and forming a code analysis result; determining a candidate matching relationship between requirement constraint units and code segments based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, performing logical implication checking based on the candidate matching relationship, and forming a consistency comparison result; and determining the deviation type and deviation code segment range between the function function requirement document and the to-be-tested function source code based on the consistency comparison result.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method and system for verifying the consistency between function functionality and requirements. Background Technology

[0002] In industries with high security requirements, such as military, automotive electronics, fintech, and industrial control, software typically requires function-level verification. This involves verifying whether the functionality of each function meets its design requirements. Since function requirements are usually described in natural language documentation, while function implementation manifests as conditional statements, variable assignments, return value settings, exception handling branches, and other code logic in the source code, accurately determining whether the source code of the function under test implements the functional constraints and logical rules in the function requirement document is a crucial issue in software quality verification.

[0003] The following are the main verification methods currently used in the industry:

[0004] The purely manual verification method involves testers reading the function requirement document described in natural language and manually reviewing the source code of the function under test or writing test cases to determine whether the function meets the requirements. This method relies on the personal experience of engineers, which has problems such as large subjective differences, low efficiency, and easy omission of implicit semantic biases. At the same time, the involvement of a large number of people in the core code review and verification process also increases the risk of code leakage.

[0005] Tool-assisted verification methods include using unit testing frameworks such as JUnit and TestNG to provide test scaffolding, or using random test data generation tools to assist in generating input data. However, these tools can usually only assist in test execution or test data construction; they cannot directly understand the business semantics in natural language requirements documents, nor can they automatically determine whether the function implementation logic is consistent with the requirements constraints.

[0006] Static analysis tools, such as Coverity and SonarQube, are primarily used to detect issues like code style, potential null pointer exceptions, resource leaks, and security vulnerabilities. However, they typically focus on code syntax, control flow, or defect pattern checks, lacking the ability to automatically compare the semantic consistency between natural language requirements and code implementation. For example, static analysis tools can detect null pointer dereference issues, but they struggle to determine whether a function is implemented according to the boundary conditions, exception handling requirements, or output behavior specified in the requirements document.

[0007] Large model-assisted analysis: Large language models or AI programming plugins can help understand requirements, interpret code, or generate test code. However, existing methods usually still require manual judgment of the accuracy of the model output, and lack a complete processing mechanism for structured comparison, logical implication check, and deviation location of the results of parsing the function requirement document with the source code analysis results of the function under test.

[0008] A common drawback of existing technologies is the difficulty in automatically identifying semantic discrepancies where "the code is syntactically correct and compiles, but the function implementation does not meet the requirements of natural language." This is especially true in function-level verification scenarios, where the function under test may not have syntax errors or crash, but may be missing a boundary condition, exception handling requirement, or output behavior. For example, a function that processes vehicle speed signals may run normally, but it might omit the logic to "limit the vehicle speed to the upper limit and set an over-limit alarm flag when the speed exceeds the upper limit," resulting in a discrepancy between the function's implementation and the requirements document. Traditional manual verification, static analysis, or test-aiding tools struggle to reliably and automatically detect such discrepancies. Summary of the Invention

[0009] This invention addresses the problems and shortcomings of existing technologies by providing a method and system for verifying the consistency between function functionality and requirements. It involves structured parsing of the function requirement document, static analysis and semantic vectorization of the source code of the function under test, and identification of the types and ranges of deviations between the function requirement document and the source code of the function under test based on candidate matching relationships and logical implication checks between the requirement semantic vector and the code semantic vector. This improves the automation and accuracy of the consistency verification, and provides a basis for requirement constraints and code location for automated test case generation, defect review, or code correction.

[0010] The technical solution adopted by this invention to solve the above-mentioned technical problems is to provide a method for verifying the consistency between function functionality and requirements, comprising the following steps:

[0011] Functional requirement document parsing: Obtain the functional requirement document described in natural language; parse the functional requirement document based on the requirement document parsing model to generate a structured requirement parsing result; the structured requirement parsing result includes multiple requirement constraint units; generate corresponding requirement semantic vectors based on the multiple requirement constraint units to form a requirement semantic vector set.

[0012] The source code of the function under test is parsed, the source code of the function under test is obtained, and static analysis is performed on the source code of the function under test. An intermediate representation corresponding to the source code of the function under test is constructed. Multiple code segments are determined based on the intermediate representation, and a code semantic vector corresponding to each code segment is generated. A code analysis result is formed based on the multiple code segments and their corresponding code semantic vectors.

[0013] Consistency comparison is performed by determining candidate matching relationships between requirement constraint units and code segments based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, and by performing logical implication checks on the requirement constraint units and corresponding code segments based on the candidate matching relationships, and forming a consistency comparison result.

[0014] Deviation identification and localization: Based on the consistency comparison results, determine the type of deviation and the range of deviation code segments between the function requirement document and the source code of the function under test.

[0015] Preferably, the function requirement document parsing includes:

[0016] Based on a preset prompt word template, a requirement parsing prompt message is generated, which includes a parsing task description, output field constraints, output format constraints, and example guidance.

[0017] Based on the functional description information in the functional requirements document, retrieve the normative constraint information related to the functional description information from the industry standard knowledge base;

[0018] The function requirement document, requirement analysis prompts, and specification constraint information are input into the requirement document analysis model to obtain a structured requirement analysis result, which includes multiple requirement constraint units.

[0019] The multiple requirement constraint units are respectively input into the semantic encoder to generate a set of requirement semantic vectors;

[0020] Each demand semantic vector in the demand semantic vector set corresponds to a demand constraint unit.

[0021] Preferably, the parsing of the source code of the function to be tested includes:

[0022] The source code of the function under test is anonymized to obtain the anonymized source code of the function under test;

[0023] Static analysis is performed on the source code of the de-identified function to be tested to construct an intermediate representation, which includes an abstract syntax tree, a control flow graph, a data flow graph, and a set of path conditions.

[0024] Multiple code segments are determined based on the intermediate representation, and a corresponding code segment record is generated for each code segment;

[0025] Based on the abstract syntax tree, control flow graph, and data flow graph, a heterogeneous code graph is constructed, and the graph structure range corresponding to each code fragment is determined in the heterogeneous code graph based on the code fragment records.

[0026] Input the graph structure range corresponding to each code fragment into the code understanding model to generate the code semantic vector corresponding to the code fragment, and form a code semantic vector set based on multiple code semantic vectors;

[0027] Code analysis results are generated based on the multiple code fragments and their corresponding code semantic vectors.

[0028] Preferably, the consistency comparison includes:

[0029] Based on the vector space similarity between the set of requirement semantic vectors and the set of code semantic vectors, candidate matching relationships between requirement constraint units and code fragments are determined.

[0030] Based on the candidate matching relationship, a logical implication check is performed on the requirement constraint unit and the corresponding code segment to obtain the logical implication check result.

[0031] Based on the candidate matching relationships and logical implication check results, a consistency comparison result is generated.

[0032] Preferably, the heterogeneous code graph is used to uniformly represent the syntactic inclusion relationships, control flow relationships, and data dependency relationships in the source code of the anonymized function under test within the same graph structure;

[0033] The nodes of the heterogeneous code graph include syntax nodes, control nodes, and data flow nodes;

[0034] The edges of the heterogeneous code graph include syntax inclusion edges, control flow edges, and data flow edges.

[0035] Preferably, the step of performing a logical implication check on the requirement constraint unit and its corresponding code fragment based on the candidate matching relationship includes:

[0036] The requirement constraint unit is converted into a requirement logic expression, which includes preconditions and conclusion conditions. The preconditions are determined based on the input conditions in the requirement constraint unit, and the conclusion conditions are determined based on the output behavior, exception handling, or boundary values ​​in the requirement constraint unit.

[0037] Based on the path condition list, control flow graph node list, control flow graph edge list, data flow node list, and data flow edge list recorded in the code snippet, extract the actual logical path corresponding to the code snippet;

[0038] In the actual logical path, find the execution path that meets the preconditions, and check whether the execution path obtains the execution result corresponding to the conclusion condition;

[0039] The logical implication check result is determined based on the execution result, and the logical implication check result includes pass, partial pass, or fail.

[0040] Preferably, determining the logical implication check result based on the execution result includes:

[0041] When the conclusion condition includes a conclusion condition item:

[0042] If all execution paths that meet the preconditions can obtain the execution result corresponding to the conclusion condition, then the logical implication check result is determined to be passed.

[0043] Otherwise, the logical implication check result is determined to be failed;

[0044] When the conclusion condition includes multiple conclusion condition items:

[0045] If all execution paths that meet the preconditions can obtain the execution results corresponding to all conclusion condition items, then the logical implication check result is determined to be passed.

[0046] If none of the execution paths that satisfy the preconditions can obtain the execution result corresponding to any conclusion condition item, or if there is no execution path that satisfies the preconditions, then the logical implication check result is determined to be unsuccessful.

[0047] If an execution path that meets the preconditions can obtain the execution results corresponding to some of the conclusion condition items, but cannot obtain the execution results corresponding to all of the conclusion condition items, then the logical implication check result is determined to be partially passed.

[0048] Preferably, based on the consistency comparison results, the type of deviation between the function requirement document and the source code of the function under test is determined, including:

[0049] When the requirement constraint unit does not form a candidate matching relationship and the constraint type of the requirement constraint unit does not belong to the exception handling requirement, the deviation type is determined as functional deficiency.

[0050] When the requirement constraint unit forms a candidate matching relationship, but the logical implication check result corresponding to the candidate matching relationship is not passed or partially passed, and the constraint type of the requirement constraint unit does not belong to the exception handling requirement, the deviation type is determined to be a logical error.

[0051] When a code snippet does not form a candidate matching relationship with any requirement constraint unit, and the code snippet does not belong to the preset auxiliary code type, the deviation type is determined as redundant implementation. The preset auxiliary code type includes at least one of logging code, assertion code, debugging code, resource release code, exception handling auxiliary code, or parameter initialization auxiliary code.

[0052] When the constraint type of the requirement constraint unit is an exception handling requirement, and the requirement constraint unit has not formed a candidate matching relationship, or the requirement constraint unit has formed a candidate matching relationship but the logical implication check result is not passed or partially passed, the deviation type is determined to be exception handling missing.

[0053] Preferably, for different types of deviations, a corresponding positioning method is used to determine the range of the deviation code segment, including:

[0054] When the deviation type is a missing function, based on the input conditions in the requirement constraint unit, the code fragment record related to the input conditions is searched in the control flow graph node list, control flow graph edge list and path condition list in the code analysis results. If a corresponding code fragment record is found, the start line number to the end line number in the code fragment record is determined as the deviation code fragment range. If no corresponding code fragment record is found, the start line number to the end line number in the code fragment record corresponding to the code semantic vector with the highest similarity to the requirement semantic vector of the requirement constraint unit is determined as the deviation code fragment range.

[0055] When the deviation type is a logical error, the code segment record corresponding to the requirement constraint unit is determined based on the candidate matching relationship, and the starting line number to the ending line number in the code segment record is determined as the deviation code segment range.

[0056] When the deviation type is redundant implementation, the starting line number to the ending line number in the code segment record corresponding to the code segment that does not form a candidate matching relationship with any requirement constraint unit is determined as the deviation code segment range;

[0057] When the deviation type is missing exception handling, if the requirement constraint unit forms a candidate matching relationship, the corresponding code segment record is determined based on the candidate matching relationship, and the start line number to the end line number in the code segment record is determined as the deviation code segment range. If the requirement constraint unit does not form a candidate matching relationship, based on the input conditions and exception handling in the requirement constraint unit, the code segment record related to the input conditions or exception handling is searched in the control flow graph node list, control flow graph edge list, and path condition list in the code analysis results, and the start line number to the end line number in the found code segment record is determined as the deviation code segment range.

[0058] This invention also provides a system for verifying the consistency between function functionality and requirements, the system comprising:

[0059] The function requirement document parsing module obtains the function requirement document described in natural language, parses the function requirement document based on the requirement document parsing model, and generates a structured requirement parsing result. The structured requirement parsing result includes multiple requirement constraint units. Based on the multiple requirement constraint units, corresponding requirement semantic vectors are generated and a requirement semantic vector set is formed.

[0060] The test function source code parsing module obtains the source code of the test function, performs static analysis on the source code, constructs an intermediate representation corresponding to the source code, determines multiple code segments based on the intermediate representation, generates a code semantic vector corresponding to each code segment, and forms a code analysis result based on the multiple code segments and their corresponding code semantic vectors.

[0061] The consistency comparison module determines the candidate matching relationship between the requirement constraint unit and the code segment based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, and performs logical implication check on the requirement constraint unit and the corresponding code segment based on the candidate matching relationship, and forms a consistency comparison result.

[0062] The deviation identification and localization module, based on the consistency comparison results, determines the type of deviation and the range of deviation code segments between the function functional requirements document and the source code of the function under test.

[0063] Compared with the prior art, the technical solution of the embodiments of the present invention has the following beneficial effects:

[0064] This invention provides a method and system for verifying the consistency between function functionality and requirements. The method includes: parsing a function functionality requirement document, obtaining a function functionality requirement document described in natural language, parsing the function functionality requirement document based on a requirement document parsing model, generating a structured requirement parsing result, the structured requirement parsing result including multiple requirement constraint units, generating corresponding requirement semantic vectors based on the multiple requirement constraint units, and forming a requirement semantic vector set; parsing the source code of the function under test, obtaining the source code of the function under test, performing static analysis on the source code of the function under test, constructing an intermediate representation corresponding to the source code of the function under test, determining multiple code segments based on the intermediate representation, generating a code semantic vector corresponding to each code segment, and forming a code analysis result based on the multiple code segments and their corresponding code semantic vectors; consistency comparison, determining candidate matching relationships between requirement constraint units and code segments based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, and performing logical implication checks on the requirement constraint units and corresponding code segments based on the candidate matching relationships, and forming a consistency comparison result; and deviation identification and localization, determining the deviation type and deviation code segment range between the function functionality requirement document and the source code of the function under test based on the consistency comparison result. This invention performs structured parsing of function requirement documents described in natural language, generating multiple requirement constraint units and corresponding requirement semantic vectors. It then performs static analysis on the source code of the function under test, forming code snippets, code semantic vectors, and code analysis results. Based on this, it determines candidate matching relationships between requirement constraint units and code snippets based on the vector space similarity between the requirement semantic vector set and the code semantic vector set. Finally, it uses logical implication checks to determine whether the candidate matching code snippets meet the input conditions, output behavior, exception handling, or boundary value requirements of the corresponding requirement constraint unit. Therefore, this invention can identify deep-seated semantic biases where "the code is executable but the function implementation does not meet the requirements," overcoming the problem that traditional static analysis tools mainly focus on syntax defects, code style, or common defect patterns, making it difficult to understand the semantics of function requirement requirements.

[0065] Furthermore, this invention assists in parsing requirement documents by using preset prompt word templates and industry standard knowledge bases. This allows the functional requirements described in natural language to be converted into requirement constraint units with fields such as input conditions, output behaviors, exception handling, and boundary values, improving the structure and comparability of the requirement parsing results. By anonymizing the source code of the function under test, constructing abstract syntax trees, control flow graphs, data flow graphs, and path condition sets, and further constructing heterogeneous code graphs and graph structure ranges, code syntax inclusion relationships, control flow relationships, and data dependencies can be uniformly expressed under the same structure, thereby improving the ability of code semantic vectors to represent the function implementation logic. By comparing the vector space of requirement semantic vectors and code semantic vectors, and combining logical implication checks to further determine whether code fragments meet the requirement logical expressions, the risk of misjudgment caused by relying solely on semantic similarity can be reduced. By identifying deviation types as missing functions, logical errors, redundant implementations, or missing exception handling, and further determining the range of deviation code fragments, the verification results can be located to the start and end line numbers of the code fragments, facilitating review and correction by developers and improving the traceability of the verification results of the consistency between function functionality and requirements. Attached Figure Description

[0066] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention, but not all embodiments. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0067] Figure 1 This is a flowchart of a method for verifying the consistency between function functionality and requirements according to a preferred embodiment of the present invention.

[0068] Figure 2 This is a flowchart illustrating the source code parsing of the function under test according to a preferred embodiment of the present invention.

[0069] Figure 3 This is a flowchart illustrating the consistency comparison in a preferred embodiment of the present invention.

[0070] Figure 4 This is a schematic diagram of the architecture of the function functionality and requirement consistency verification system according to a preferred embodiment of the present invention. Detailed Implementation

[0071] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0072] The technical solution of the present invention will be described in detail below with reference to specific embodiments.

[0073] To address the problems existing in the prior art, this invention provides a method and system for verifying the consistency between function functionality and requirements. By performing structured parsing of the function functionality requirement document, static analysis and semantic vectorization of the source code of the function under test, and based on the candidate matching relationship and logical implication check results between the requirement semantic vector and the code semantic vector, the method identifies the type of deviation and the range of deviation code segments between the function functionality requirement document and the source code of the function under test. This improves the automation and accuracy of the consistency verification between function functionality and requirements, and provides a basis for requirement constraints and code location for automated test case generation, defect review, or code correction.

[0074] Now see Figure 1 This invention provides a method for verifying the consistency between function functionality and requirements, comprising the following steps:

[0075] Step S101: Function functional requirement document parsing. Obtain the function functional requirement document described in natural language. Parse the function functional requirement document based on the requirement document parsing model to generate a structured requirement parsing result. The structured requirement parsing result includes multiple requirement constraint units. Generate corresponding requirement semantic vectors based on the multiple requirement constraint units to form a requirement semantic vector set.

[0076] In this step, the requirement document parsing model is a parsing model based on a large language model. This model performs semantic parsing on the function requirement document and generates a structured requirement parsing result according to a predefined output template. The structured requirement parsing result includes multiple requirement constraint units. Each requirement constraint unit represents a functional point or constraint condition in the function requirement document. Specifically:

[0077] First, requirement parsing prompts are generated based on a preset prompt template. These prompts include a description of the parsing task, output field constraints, output format constraints, and example guidance.

[0078] The task description is parsed to instruct the requirements document parsing model to convert the natural language description of the functional requirements document into a structured requirements parsing result.

[0079] Output field constraints are used to limit the fields that need to be output in the requirement constraint unit.

[0080] Output format constraints are used to limit the requirement document parsing model to output multiple requirement constraint units according to a predefined output template.

[0081] Example guidance is provided to offer at least one typical requirement text and its corresponding structured transformation example.

[0082] In one implementation, the predefined output template includes a function name field and a list of requirement constraint units field. The function name field represents the function name corresponding to the function's functional requirements document; the list of requirement constraint units stores multiple requirement constraint units. Each requirement constraint unit includes a requirement identifier, constraint type, requirement text, and constraint content fields. The constraint type characterizes the constraint category corresponding to the requirement constraint unit, and includes at least one of core functional points, input / output rules, business logic constraints, exception handling requirements, and boundary conditions. The requirement text is an original requirement text fragment extracted or truncated from the function's functional requirements document, used to retain the original description of the requirement constraint unit in the function's functional requirements document. The constraint content field includes input conditions, output behavior, exception handling, and a list of boundary values.

[0083] The output template example is as follows:

[0084] {

[0085] "function_name": "Function Name",

[0086] "requirements": [

[0087] {

[0088] "requirement_id": "REQ_001",

[0089] "requirement_text": "Requirement text",

[0090] "constraint_type": "Core functionalities | Input / output rules | Business logic constraints | Exception handling requirements | Boundary conditions",

[0091] "constraints": {

[0092] "input_condition": "Description of input condition",

[0093] "output_action": "Description of output behavior",

[0094] "exception_handling": "Exception handling description",

[0095] "boundary_values": [List of boundary values]

[0096] }

[0097] } ]

[0099] }

[0100] Then, based on the functional description information in the function requirement document, the relevant normative constraint information is retrieved from the industry standard knowledge base.

[0101] The industry standard knowledge base is a pre-established knowledge base that includes structured clauses of industry standards, such as those in GJB141, ISO 26262, and IEC 61508.

[0102] In one implementation, keywords or key semantic fragments are extracted from the function requirement document using Retrieval Enhancement Generation (RAG) technology to form function description information. Based on this function description information, standard clauses with semantic similarity meeting preset conditions are retrieved from an industry standard knowledge base and used as standard constraint information. The preset conditions include retrieving the top K standard clauses with the highest semantic similarity to the function description information from the industry standard knowledge base. Here, K is a positive integer, for example, K = 3~5. This standard constraint information is used to supplement the parsing context of the requirement document parsing model, so that the generated requirement constraint units can reflect the industry standard constraints related to the function requirement document.

[0103] For example, keywords such as "vehicle speed," "safety," and "over-limit" are extracted from the function requirement document as function description information, and safety requirements related to vehicle speed signal processing are retrieved from the ISO 26262 standard clauses contained in the industry standard knowledge base to form standard constraint information related to the function description information.

[0104] Next, the function requirement document, requirement parsing prompts, and specification constraint information are input into the requirement document parsing model to obtain the structured requirement parsing result, which includes multiple requirement constraint units.

[0105] In this embodiment, the requirement document parsing model is a natural language requirement parsing model based on a large language model. It is used to perform semantic understanding on function requirement documents described in natural language and generate structured requirement parsing results according to a predefined output template. In one embodiment, the requirement document parsing model can employ a general large language model, a domain-fine-tuned large language model, or a locally deployed large language model.

[0106] Specifically, the function functional requirements document, requirement parsing prompts, and specification constraint information are input into the requirement document parsing model. The function functional requirements document provides the original requirement content to be parsed; the requirement parsing prompts define the parsing task, output fields, and output format; and the specification constraint information supplements the industry specification context related to the function functional requirements.

[0107] The requirement document parsing model parses requirements based on functional requirement documents, requirement parsing prompts, and specification constraints, and outputs structured requirement parsing results according to a predefined output template. The structured requirement parsing results include multiple requirement constraint units, each of which includes a requirement identifier, requirement text, constraint type, input conditions, output behavior, exception handling, and boundary values.

[0108] Finally, the multiple requirement constraint units are input into the semantic encoder to generate a set of requirement semantic vectors. Each requirement semantic vector in the set corresponds to a requirement constraint unit.

[0109] In one implementation, the semantic encoder employs a pre-trained code-natural language dual-encoding model, such as CodeBERT or UniXCoder, to generate a set of requirement semantic vectors represented as R = {r1, r2, ..., r...} m}, where r m This represents the requirement semantic vector corresponding to the m-th requirement constraint unit, where m represents the number of requirement constraint units. Each vector corresponds to a function point or constraint condition. The dimension of each requirement semantic vector is determined according to the model structure of the semantic encoder, for example, 768 dimensions.

[0110] In one implementation, an example of the structured requirements parsing result from the requirements document parsing model is as follows:

[0111] {

[0112] "function_name": "processVehicleSpeed",

[0113] "requirements": [

[0114] {

[0115] "requirement_id": "REQ_001",

[0116] "requirement_text": "If the input speed is between 0 and 300, the input speed will be stored as the current speed value".

[0117] "constraint_type": "Input / output rules",

[0118] "input_condition": "Input vehicle speed greater than or equal to 0 and less than or equal to 300",

[0119] "output_action": "Store the input vehicle speed as the current vehicle speed value",

[0120] "exception_handling": "",

[0121] "boundary_values": [0, 300]

[0122] },

[0123] {

[0124] "requirement_id": "REQ_002",

[0125] "requirement_text": "If the input vehicle speed is less than 0, the current vehicle speed will be set to 0, and the fault flag will be set."

[0126] "constraint_type": "Exception handling requirements",

[0127] "input_condition": "Input vehicle speed is less than 0",

[0128] "output_action": "Set the current vehicle speed to 0 and set the fault flag",

[0129] "exception_handling": "Executes fault handling for invalid vehicle speed inputs less than 0",

[0130] "boundary_values": [0]

[0131] },

[0132] {

[0133] "requirement_id": "REQ_003",

[0134] "requirement_text": "If the input speed is greater than 300, the current speed will be limited to 300, and the over-limit warning sign will be set."

[0135] "constraint_type": "boundary conditions",

[0136] "input_condition": "Input vehicle speed greater than 300",

[0137] "output_action": "Limit the current vehicle speed to 300 and set the overspeed warning sign",

[0138] "exception_handling": "Executes over-limit handling for speed inputs exceeding the upper limit".

[0139] "boundary_values":

[300]

[0140] } ]

[0142] }

[0143] After obtaining the structured requirement parsing results, the multiple requirement constraint units in the structured requirement parsing results are input into the semantic encoder to generate a set of requirement semantic vectors. For example, for the requirement constraint unit REQ_003, the following is combined into a requirement constraint unit text representation: "Constraint type: boundary condition; Requirement text: If the input vehicle speed is greater than 300, then limit the current vehicle speed to 300 and set the over-limit alarm flag; Input condition: Input vehicle speed is greater than 300; Output behavior: Limit the current vehicle speed to 300 and set the over-limit alarm flag; Boundary value: 300", and input into the semantic encoder to generate the corresponding requirement semantic vector r3.

[0144] Semantic encoding of REQ_001 yields the demand semantic vector r1=[r 11 ,r 12 ,...,r 1d Semantic encoding is performed on REQ_002 to obtain the demand semantic vector r2=[r 21 ,r 22 ,...,r 2d Semantic encoding is performed on REQ_003 to obtain the demand semantic vector r3=[r 31 ,r 32 ,...,r 3d This forms a set of semantic vectors for demand, R = {r1, r2, r3}. Here, d represents the dimension of the vector output by the semantic encoder.

[0145] Step S102: Parse the source code of the function under test, obtain the source code of the function under test, perform static analysis on the source code of the function under test, construct an intermediate representation corresponding to the source code of the function under test, determine multiple code segments based on the intermediate representation, generate a code semantic vector corresponding to each code segment, and form a code analysis result based on the multiple code segments and their corresponding code semantic vectors.

[0146] In this step, after anonymizing the source code of the function under test, an intermediate representation describing the code's logical features is constructed based on static analysis. Multiple code segments are determined based on this intermediate representation, and a corresponding code segment record is generated for each segment. Furthermore, a heterogeneous code graph is constructed based on the intermediate representation, and the graph structure range corresponding to each code segment is determined within the heterogeneous code graph. The graph structure range is input into the code understanding model to generate a code semantic vector corresponding to each code segment. Finally, the code analysis result is formed based on multiple code segments, code segment records, and corresponding code semantic vectors.

[0147] The output code analysis results include function names, a list of code snippets, and a set of code semantic vectors. The function names are either the original names of the functions corresponding to the source code of the function under test, or anonymous function identifiers after anonymization. The list of code snippets includes multiple code snippet records, with each record corresponding to one code snippet.

[0148] Each code snippet record includes a unique identifier for the code snippet, the code snippet type, the anonymized code text, the starting line number, the ending line number, a list of syntax nodes, a list of syntax-containing edges, a list of control flow graph nodes, a list of control flow graph edges, a list of data flow nodes, a list of data flow edges, a list of path conditions, and a code semantic vector associated with the code snippet.

[0149] The code snippet types include basic block types, execution path types, or statement snippet types; the syntax node list and syntax containment edge list are used to represent the local structure of the abstract syntax tree corresponding to the code snippet; the control flow graph node list and control flow graph edge list are used to represent the local structure of the control flow corresponding to the code snippet; the data flow node list and data flow edge list are used to represent the local structure of the data flow corresponding to the code snippet; the path condition list includes conditional expressions, branch directions, and corresponding code line numbers; and the code semantic vector is the multi-dimensional floating-point vector corresponding to the code snippet.

[0150] In this embodiment, the code semantic vector set is represented as C={c1,c2,...,c n}, where c nThis represents the code semantic vector corresponding to the nth code segment, where n represents the number of code segments. Each code semantic vector is stored in association with its corresponding code segment record. For example, code segment CF_001 corresponds to code semantic vector C1, and code segment CF_002 corresponds to code semantic vector c2.

[0151] In this embodiment, a code understanding model is used to construct code semantic vectors from the intermediate representation. The code understanding model is a graph neural network-based code representation model, such as CodeGNN or a graph attention network-based code representation model. When the output dimension of the code understanding model is 768-dimensional, each code semantic vector is a 768-dimensional floating-point vector.

[0152] Step S103: Consistency comparison. Based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, determine the candidate matching relationship between the requirement constraint unit and the code segment. Based on the candidate matching relationship, perform logical implication check on the requirement constraint unit and the corresponding code segment, and form a consistency comparison result.

[0153] In this step, a dual-encoder architecture is used to compare the vector space similarity between the requirement semantic vector set and the code semantic vector set, obtaining the maximum similarity value corresponding to each requirement constraint unit, and determining candidate matching relationships based on the maximum similarity value. The similarity score of the candidate matching relationship is the maximum similarity value.

[0154] A logical implication check is performed on the candidate matching relationships, and a consistency comparison result is formed based on the logical implication check result. The consistency comparison result includes multiple comparison result records, and each comparison result record corresponds to a requirement constraint unit.

[0155] Each comparison result record includes the requirement constraint unit identifier, the matching code fragment identifier, the similarity score, and the logical implication check result.

[0156] Among them, the demand constraint unit identifier is the demand identifier of the demand constraint unit, which is used to uniquely identify the generated demand constraint unit.

[0157] The matching code snippet identifier is a unique identifier for the code snippet record that forms a candidate matching relationship with the requirement constraint unit. If no candidate matching relationship is formed with the requirement constraint unit, the matching code snippet identifier is empty.

[0158] The similarity score, which is the maximum similarity value, is used to represent the degree of similarity in the vector space between the requirement semantic vector and the code semantic vector.

[0159] The logical implication of the check result includes pass, partial pass, or fail.

[0160] Step S104, Deviation Identification and Location: Based on the consistency comparison results, determine the type of deviation and the range of deviation code segments between the function functional requirements document and the source code of the function under test.

[0161] In this step, based on the formed consistency comparison results, deviations are identified for requirement constraint units that fail or partially pass, and the range of deviation code segments is determined based on the corresponding code snippet records, control flow graph node list, control flow graph edge list, data flow node list, data flow edge list, and path condition list.

[0162] In this embodiment, based on the consistency comparison results, the type of deviation between the function requirement document and the source code of the function under test is determined, including:

[0163] When the requirement constraint unit does not form a candidate matching relationship and the constraint type of the requirement constraint unit does not belong to the exception handling requirement, the deviation type is determined as functional deficiency.

[0164] When the requirement constraint unit forms a candidate matching relationship, but the logical implication check result corresponding to the candidate matching relationship is not passed or partially passed, and the constraint type of the requirement constraint unit does not belong to the exception handling requirement, the deviation type is determined to be a logical error.

[0165] When a code snippet does not form a candidate matching relationship with any requirement constraint unit, and the code snippet does not belong to the preset auxiliary code type, the deviation type is determined as redundant implementation. The preset auxiliary code type includes at least one of logging code, assertion code, debugging code, resource release code, exception handling auxiliary code, or parameter initialization auxiliary code.

[0166] When the constraint type of the requirement constraint unit is an exception handling requirement, and the requirement constraint unit has not formed a candidate matching relationship, or the requirement constraint unit has formed a candidate matching relationship but the logical implication check result is not passed or partially passed, the deviation type is determined to be exception handling missing.

[0167] In this embodiment, for different types of deviations, corresponding positioning methods are used to determine the range of deviation code segments, including:

[0168] When the deviation type is "functional missing", based on the input conditions in the requirement constraint unit, the code fragment record related to the input conditions is searched in the control flow graph node list, control flow graph edge list, and path condition list in the code analysis results. If a corresponding code fragment record is found, the start line number to the end line number in the code fragment record is determined as the deviation code fragment range. If no corresponding code fragment record is found, the start line number to the end line number in the code fragment record corresponding to the code semantic vector with the highest similarity to the requirement semantic vector of the requirement constraint unit is determined as the deviation code fragment range.

[0169] When the deviation type is a logical error, the code segment record corresponding to the requirement constraint unit is determined based on the candidate matching relationship, and the starting line number to the ending line number in the code segment record is determined as the deviation code segment range.

[0170] When the deviation type is redundant implementation, the range of the deviation code segment is determined from the start line number to the end line number in the code segment record corresponding to the code segment that does not form a candidate matching relationship with any requirement constraint unit.

[0171] When the deviation type is missing exception handling, if the requirement constraint unit forms a candidate matching relationship, the corresponding code segment record is determined based on the candidate matching relationship, and the start line number to the end line number in the code segment record is determined as the deviation code segment range; if the requirement constraint unit does not form a candidate matching relationship, based on the input conditions and exception handling in the requirement constraint unit, the code segment record related to the input conditions or exception handling is searched in the control flow graph node list, control flow graph edge list, and path condition list in the code analysis results, and the start line number to the end line number in the found code segment record is determined as the deviation code segment range.

[0172] Now see Figure 2 This invention provides a method for parsing the source code of a function under test, comprising the following steps:

[0173] Step S1021: Desensitize the source code of the function to be tested to obtain the desensitized source code of the function to be tested.

[0174] In this step, the anonymization process includes replacing variable names and function names in the source code of the function under test with anonymous identifiers, such as "V1", "V2", or "func_1", while retaining the type information, calling relationships, and syntax structure of the variables or functions. In one implementation, this replacement can be performed by establishing a symbol mapping table. The symbol mapping table records the correspondence between variable names or function names in the source code of the function under test and anonymous identifiers. This anonymization process reduces the risk of source code content leakage while preserving the syntactic and logical relationships required for subsequent static analysis.

[0175] Step S1022: Perform static analysis on the source code of the desensitized function to be tested and construct an intermediate representation, which includes an abstract syntax tree, a control flow graph, a data flow graph, and a set of path conditions.

[0176] In this step, the intermediate representation is used to describe the code logic characteristics of the source code of the function to be tested after anonymization. The intermediate representation includes:

[0177] An Abstract Syntax Tree (AST) is a tree whose nodes are syntax nodes, including expression nodes, statement nodes, variable declaration nodes, function call nodes, and conditional statement nodes. The edges in an AST are syntax inclusion edges, used to represent parent-child inclusion relationships or syntax dependency relationships between syntax nodes. The AST is used to record the node type, node position, and relationship with child nodes of each syntax node in the anonymized source code of the function under test.

[0178] A control flow graph (CFG) consists of control nodes, which represent basic blocks in the anonymized source code of the function under test. Each basic block is a set of statements executed sequentially. Edges in the CFG represent the control flow relationships between basic blocks. Control flow edges include sequential execution edges, conditional branch edges, loop jump edges, and exception jump edges. An execution path is formed by multiple control nodes and the control flow edges connecting them, arranged in execution order. The execution path represents a sequence of executable statements in the anonymized source code of the function under test when the corresponding path conditions are met. The CFG describes the execution jump relationships between basic blocks in the anonymized source code of the function under test. Based on the CFG, branch conditions, loop conditions, exception handling branches, and executable paths in the source code of the function under test can be determined.

[0179] A Data Flow Graph (DFG) consists of nodes that represent the locations of variable definitions, usages, parameter passing, and return values ​​in the anonymized source code of the function under test. Edges represent data dependencies between data flow nodes, including dependencies from variable definition to usage, variable assignment, computation, parameter passing, and return value dependencies. The DFG records the variable definitions, usage chains, and data dependencies in the anonymized source code of the function under test. Data dependencies include at least one of the following: variable assignment, variable access, computation, parameter passing, and return value dependencies. Based on the DFG, the input variables, output variables, state variables, and the transitive relationships between variables in the source code of the function under test can be determined.

[0180] The path condition set represents the triggering conditions corresponding to different execution paths in the source code of the function under test after anonymization. The path condition set includes normal path conditions, abnormal path conditions, and boundary condition path conditions. Normal path conditions represent the conditions corresponding to execution paths that do not enter the exception handling branch; abnormal path conditions represent the conditions corresponding to execution paths that enter the exception handling branch; and boundary condition path conditions represent the conditions corresponding to execution paths involving comparison operations, range judgments, or threshold judgments.

[0181] Step S1023: Determine multiple code segments based on the intermediate representation, and generate a corresponding code segment record for each code segment.

[0182] In this step, the code snippet is the code analysis unit in the source code of the function to be tested after anonymization, used for requirement consistency comparison.

[0183] In one implementation, code snippets of basic block types are determined based on control nodes in the control flow graph, wherein each code snippet of a basic block type corresponds to a basic block represented by a control node.

[0184] In another implementation, the code fragment of the execution path type is determined based on multiple control nodes in the control flow graph and the control flow edges connecting the multiple control nodes. Each code fragment of the execution path type corresponds to an execution path in the control flow graph, and the execution path consists of multiple control nodes and control flow edges connected sequentially according to the control flow direction.

[0185] In another implementation, each code fragment of the statement fragment type corresponds to a statement node, or to a statement structure consisting of multiple syntax nodes and syntax inclusion edges connecting the multiple syntax nodes. The statement structure is used to represent a complete statement or a local expression structure within a statement.

[0186] For each code snippet, a corresponding code snippet record is generated. The code snippet record includes a unique identifier for the code snippet, the code snippet type, the anonymized code text, the starting line number, the ending line number, a list of syntax nodes, a list of syntax-containing edges, a list of control flow graph nodes, a list of control flow graph edges, a list of data flow nodes, a list of data flow edges, and a list of path conditions.

[0187] The code snippet types include basic block types, execution path types, or statement snippet types; the abstract syntax tree representation includes node types and a list of child nodes; the syntax node list and syntax containment edge list are used to represent the local structure of the abstract syntax tree corresponding to the current code snippet; the control flow graph node list and control flow graph edge list are used to represent the local structure of the control flow corresponding to the current code snippet; the data flow node list and data flow edge list are used to represent the local structure of the data flow corresponding to the current code snippet; the path condition list is determined based on the path condition set and is used to record the path conditions related to the current code snippet.

[0188] It should be noted that, in this embodiment, the same code fragment record is used to uniformly associate the syntax structure information, control flow information, data flow information and path condition information corresponding to the code fragment, thereby avoiding the generation of fragmented code fragment records based on the abstract syntax tree, control flow graph and data flow graph respectively.

[0189] Step S1024: Based on the abstract syntax tree, control flow graph, and data flow graph, construct a heterogeneous code graph, and determine the graph structure range corresponding to each code fragment in the heterogeneous code graph based on the code fragment records.

[0190] In this step, a heterogeneous code graph is used to uniformly represent the syntactic inclusion relationships, control flow relationships, and data dependencies in the anonymized source code of the function under test within the same graph structure. The heterogeneous code graph is constructed based on the intermediate representation's abstract syntax tree, control flow graph, and data flow graph.

[0191] The nodes of the heterogeneous code graph include syntax nodes, control nodes, and data flow nodes; the edges of the heterogeneous code graph include syntax inclusion edges, control flow edges, and data flow edges.

[0192] After constructing the heterogeneous code graph, based on the generated code fragment records, the graph structure range corresponding to each code fragment is determined in the heterogeneous code graph. The graph structure range includes the set of nodes and the set of edges associated with the corresponding code fragment.

[0193] Specifically, for a code snippet of a basic block type, based on its corresponding control flow graph node list, the control node corresponding to the basic block, the syntax node and syntax inclusion edge corresponding to the control node, and the data flow node and data flow edge related to the syntax node are determined in the heterogeneous code graph as the graph structure range corresponding to the code snippet of the basic block type.

[0194] For code snippets of execution path type, based on their corresponding control flow graph node list, control flow graph edge list, and path condition list, multiple control nodes on the execution path, control flow edges between multiple control nodes, syntax nodes and syntax inclusion edges corresponding to multiple control nodes, and related data flow nodes and data flow edges within the execution path are determined in the heterogeneous code graph as the graph structure range corresponding to the code snippet of execution path type.

[0195] For code fragments of the statement fragment type, based on their corresponding start line number, end line number, syntax node list or syntax containment edge list, the syntax nodes and syntax containment edges corresponding to the statement fragment, as well as the data flow nodes and data flow edges related to the syntax nodes, are determined in the heterogeneous code graph as the graph structure range corresponding to the code fragment of the statement fragment type.

[0196] Step S1025: Input the graph structure range corresponding to each code fragment into the code understanding model to generate the code semantic vector corresponding to the code fragment, and form a code semantic vector set based on multiple code semantic vectors.

[0197] In this step, for each code snippet, the graph structure range corresponding to the code snippet in the heterogeneous code graph is input into the code understanding model. The code understanding model encodes the node features in the graph structure range and the edge connection relationships between nodes to generate the code semantic vector corresponding to the code snippet.

[0198] The code understanding model is used to encode the syntactic inclusion relationships, control flow relationships, and data dependencies between nodes in the graph structure to obtain vector representations of the corresponding code fragments.

[0199] In one implementation, the code understanding model is a graph neural network-based code representation model, such as CodeGNN or a graph attention network-based code representation model. The code understanding model encodes node features and edge connections within a graph structure to generate a code semantic vector corresponding to the code fragment. When the code understanding model uses a graph attention network, it weights and aggregates node features based on the connections between nodes within the graph structure to generate the code semantic vector corresponding to the code fragment.

[0200] In one implementation, for code fragments of the basic block type, the code understanding model generates a code semantic vector corresponding to the basic block type code fragment based on the control nodes, syntax nodes, data flow nodes, and corresponding edges corresponding to the basic block type code fragment; for code fragments of the execution path type, the code understanding model generates a code semantic vector corresponding to the execution path type code fragment based on multiple control nodes, control flow edges, syntax nodes, syntax inclusion edges, data flow nodes, and data flow edges corresponding to the execution path type code fragment; for code fragments of the statement fragment type, the code understanding model generates a code semantic vector corresponding to the statement fragment type code fragment based on the syntax nodes, syntax inclusion edges, data flow nodes, and data flow edges corresponding to the statement fragment type code fragment.

[0201] After generating code semantic vectors corresponding to multiple code snippets, a set of code semantic vectors C={c1,c2,...,c...} is formed. n}. Where c n This represents the code semantic vector corresponding to the nth code segment, where n represents the number of code segments. Each code semantic vector corresponds to a code segment of the anonymized source code of the function to be tested. The code segment types include basic block type, execution path type, or statement segment type.

[0202] In one implementation, the generated code semantic vectors are associated with and stored in association with the corresponding code fragment records. For example, the code semantic vector c1 corresponding to code fragment CF_001 is associated with the code fragment record of code fragment CF_001, and the code semantic vector c2 corresponding to code fragment CF_002 is associated with the code fragment record of code fragment CF_002.

[0203] Through the above processing, the code semantic vector is used to calculate the similarity with the requirement semantic vector in the subsequent requirement consistency comparison process, so as to determine the candidate matching relationship between the requirement constraint unit and the code fragment.

[0204] Step S1026: Generate code analysis results based on the multiple code fragments and their corresponding code semantic vectors.

[0205] In this step, the output code analysis results include function names, a list of code snippets, and a set of code semantic vectors. The function name is the original name of the function corresponding to the source code of the function under test, or an anonymous function identifier after anonymization. The list of code snippets includes multiple code snippet records, with each record corresponding to one code snippet.

[0206] Each code snippet record includes a unique identifier for the code snippet, the code snippet type, the anonymized code text, the starting line number, the ending line number, a list of syntax nodes, a list of syntax-containing edges, a list of control flow graph nodes, a list of control flow graph edges, a list of data flow nodes, a list of data flow edges, a list of path conditions, and a code semantic vector associated with the code snippet.

[0207] The code snippet types include basic block types, execution path types, or statement snippet types; the syntax node list and syntax containment edge list are used to represent the local structure of the abstract syntax tree corresponding to the code snippet; the control flow graph node list and control flow graph edge list are used to represent the local structure of the control flow corresponding to the code snippet; the data flow node list and data flow edge list are used to represent the local structure of the data flow corresponding to the code snippet; the path condition list includes conditional expressions, branch directions, and corresponding code line numbers; and the code semantic vector is the multi-dimensional floating-point vector corresponding to the code snippet.

[0208] In this embodiment, the code semantic vector set is represented as C={c1,c2,...,c n}, where c n This represents the code semantic vector corresponding to the nth code segment, where n represents the number of code segments. Each code semantic vector is stored in association with its corresponding code segment record. For example, code segment CF_001 corresponds to code semantic vector C1, and code segment CF_002 corresponds to code semantic vector c2.

[0209] Now see Figure 3 This invention provides a consistency comparison method, comprising the following steps:

[0210] Step S1031: Based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, determine the candidate matching relationship between the requirement constraint unit and the code fragment.

[0211] In this step, a dual-encoder architecture is used to map the requirement semantic vectors in the requirement semantic vector set and the code semantic vectors in the code semantic vector set to a unified vector space, and the vector space similarity between the requirement semantic vectors and the code semantic vectors is calculated in the unified vector space. Specifically:

[0212] The architecture consists of a dual encoder, comprising a requirement encoder (Encoder_R) and a code encoder (Encoder_C). Specifically:

[0213] The requirement encoder (Encoder_R) employs a pre-trained language model, such as CodeBERT. Its input is a text representation of requirement constraint units, obtained by serializing the requirement constraint units from the structured requirement parsing results. The output is a requirement mapping vector of a preset dimension, for example, 768 dimensions.

[0214] Code Encoder (Encoder_C): The code encoder uses a hybrid model of graph neural network and Transformer. The input of the code encoder is the graph structure range corresponding to the code fragment, and the output of the code encoder is a code mapping vector of a preset dimension, such as 768 dimensions.

[0215] In this embodiment, the requirement semantic vector is processed by the requirement encoder to obtain the requirement mapping vector, and the code semantic vector is processed by the code encoder to obtain the code mapping vector. The forward propagation processes of the requirement encoder and the code encoder correspond to the requirement-side mapping process and the code-side mapping process, respectively.

[0216] In one implementation, the dual encoder architecture is trained using a contrastive learning approach. Specifically, a training dataset is constructed by collecting validated correct requirement constraint unit-code snippet pairs from historical projects as positive examples, and generating erroneous implementations as negative examples through random replacement or perturbation. The code snippets in the positive examples correctly implement the corresponding requirement constraint units, while the negative examples include samples with missing functionality, logical errors, redundant implementations, or missing exception handling.

[0217] In one implementation, the dual encoder architecture is trained using the contrastive loss function InfoNCE. By minimizing the contrastive loss, the similarity between the requirement mapping vector and the code mapping vector corresponding to positive examples in the unified vector space is increased, while the similarity between the requirement mapping vector and the code mapping vector corresponding to negative examples in the unified vector space is decreased.

[0218] After training the dual encoder architecture, the set of requirement semantic vectors R = {r1, r2, ..., r...} is then used. m Each requirement semantic vector in the code semantic vector set C = {c1, c2, ..., c} is input into the requirement encoder to obtain the corresponding requirement mapping vector; the code semantic vector set C = {c1, c2, ..., c} is then processed. n Each code semantic vector in} is input into the code encoder to obtain the corresponding code mapping vector.

[0219] For any requirement mapping vector and any code mapping vector, calculate the vector space similarity between them. In one implementation, the vector space similarity is a cosine similarity. Specifically, calculate the similarity of each requirement semantic vector r. iThe corresponding requirement mapping vector and each code semantic vector c j The cosine similarity between the corresponding code mapping vectors is used to obtain the similarity matrix.

[0220] For each requirement constraint unit, the requirement semantic vector corresponding to it is determined, and the code semantic vector with the highest similarity is used as the maximum similarity value.

[0221] When the maximum similarity value is greater than the preset similarity threshold, the requirement constraint unit corresponding to the requirement semantic vector and the code segment corresponding to the code semantic vector are determined as candidate matching relationships; when the maximum similarity value is not greater than the preset similarity threshold, it is determined that the requirement constraint unit has not found a code segment that meets the candidate matching conditions.

[0222] In one implementation, the preset similarity threshold is a configurable threshold, for example, the preset similarity threshold is 0.75.

[0223] Step S1032: Based on the candidate matching relationship, perform a logical implication check on the requirement constraint unit and the corresponding code segment to obtain the logical implication check result.

[0224] In this step, the logical implication check of the requirement constraint unit and its corresponding code fragment based on the candidate matching relationship includes:

[0225] The requirement constraint unit is converted into a requirement logic expression, which includes the preconditions and the conclusion conditions.

[0226] The preconditions are determined based on the input conditions in the demand constraint unit, and the conclusion conditions are determined based on the output behavior, exception handling, or boundary values ​​in the demand constraint unit.

[0227] Based on the path condition list, control flow graph node list, control flow graph edge list, data flow node list, and data flow edge list recorded in the code snippet, the actual logical path corresponding to the code snippet is extracted.

[0228] For example, the requirement logic expression P→Q, where P is the premise condition and Q is the conclusion condition.

[0229] In the actual logical path, find the execution path that satisfies the precondition P, and check whether the execution path obtains the execution result corresponding to the conclusion condition Q.

[0230] When the conclusion condition Q includes a conclusion condition term:

[0231] If all execution paths that satisfy the precondition P can obtain the execution result corresponding to the conclusion condition, then the logical implication check result is determined to be passed.

[0232] Otherwise, the logical implication check result is determined to be unsuccessful.

[0233] When conclusion condition Q includes multiple conclusion condition terms:

[0234] If all execution paths that satisfy the precondition P can obtain the execution results corresponding to all conclusion condition items, then the logical implication check result is determined to be passed.

[0235] If none of the execution paths that satisfy the precondition P can obtain the execution result corresponding to any conclusion condition, or if there is no execution path that satisfies the precondition P, then the logical implication check result is determined to be unsuccessful.

[0236] If the execution path that satisfies the precondition P can obtain the execution results corresponding to some of the conclusion condition terms, but cannot obtain the execution results corresponding to all of the conclusion condition terms, then the logical implication check result is determined to be partially passed.

[0237] For example, if the demand constraint unit states "if the input vehicle speed is greater than 300, then the current vehicle speed will be limited to 300 and the over-limit alarm will be set", then the corresponding precondition P is "the input vehicle speed is greater than 300" and the conclusion condition Q includes a first conclusion condition item and a second conclusion condition item; wherein, the first conclusion condition item is "the current vehicle speed is limited to 300" and the second conclusion condition item is "the over-limit alarm will be set".

[0238] In the actual logical path corresponding to the code snippet, if all execution paths that satisfy "input speed greater than 300" can obtain the execution results of "current speed is limited to 300" and "set over-limit alarm flag", then the logical implication check result is passed.

[0239] If the execution path that satisfies "input vehicle speed greater than 300" can only obtain one of the execution results, "current vehicle speed is limited to 300" and "set over-limit alarm flag", and does not obtain the other execution result, then the logical implication check result is partially passed.

[0240] If there is no execution path that satisfies "input vehicle speed greater than 300", or if the execution path that satisfies "input vehicle speed greater than 300" cannot obtain either "current vehicle speed is limited to 300" or "set over-limit alarm flag", then the logical implication check result is failed.

[0241] Step S1033: Based on the candidate matching relationship and logical implication check results, generate consistency comparison results.

[0242] In this step, the consistency comparison results include multiple comparison result records, and each comparison result record corresponds to a requirement constraint unit.

[0243] Each comparison result record includes the requirement constraint unit identifier, the matching code fragment identifier, the similarity score, and the logical implication check result.

[0244] Among them, the demand constraint unit identifier is the demand identifier of the demand constraint unit, which is used to uniquely identify the generated demand constraint unit.

[0245] The matching code snippet identifier is a unique identifier for the code snippet record that forms a candidate matching relationship with the requirement constraint unit. If no candidate matching relationship is formed with the requirement constraint unit, the matching code snippet identifier is empty.

[0246] The similarity score, which is the maximum similarity value, is used to represent the degree of similarity in the vector space between the requirement semantic vector and the code semantic vector.

[0247] The logical implication of the check result includes pass, partial pass, or fail.

[0248] Now see Figure 4 This invention also provides a function functionality and requirement consistency verification system 400, the system comprising:

[0249] The function requirement document parsing module 410 obtains a function requirement document described in natural language, parses the function requirement document based on the requirement document parsing model, and generates a structured requirement parsing result. The structured requirement parsing result includes multiple requirement constraint units. Based on the multiple requirement constraint units, corresponding requirement semantic vectors are generated respectively, and a set of requirement semantic vectors is formed.

[0250] The test function source code parsing module 420 obtains the test function source code, performs static analysis on the test function source code, constructs an intermediate representation corresponding to the test function source code, determines multiple code segments based on the intermediate representation, generates a code semantic vector corresponding to each code segment, and forms a code analysis result based on the multiple code segments and their corresponding code semantic vectors.

[0251] The consistency comparison module 430 determines the candidate matching relationship between the requirement constraint unit and the code segment based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, and performs a logical implication check on the requirement constraint unit and the corresponding code segment based on the candidate matching relationship, and forms a consistency comparison result.

[0252] The deviation identification and localization module 440 determines the type of deviation and the range of deviation code segments between the function functional requirements document and the source code of the function under test based on the consistency comparison results.

[0253] In summary, this invention provides a method and system for verifying the consistency between function functionality and requirements. The method includes: parsing a function functionality requirement document, obtaining a function functionality requirement document described in natural language, parsing the function functionality requirement document based on a requirement document parsing model, generating a structured requirement parsing result, the structured requirement parsing result including multiple requirement constraint units, generating corresponding requirement semantic vectors based on the multiple requirement constraint units, and forming a requirement semantic vector set; parsing the source code of the function under test, obtaining the source code of the function under test, performing static analysis on the source code of the function under test, constructing an intermediate representation corresponding to the source code of the function under test, and based on the intermediate representation... This invention involves: 1) structuring and parsing a function's functional requirements document described in natural language to generate multiple requirement constraint units and corresponding requirement semantic vectors. 2) performing static analysis on the source code of the function under test to generate code fragments, code semantic vectors, and code analysis results. 3) determining candidate matching relationships between requirement constraint units and code fragments based on the vector space similarity between the requirement semantic vector set and the code semantic vector set. 4) using logical implication checks to determine whether candidate matching code fragments meet the input conditions, output behaviors, exception handling, or boundary value requirements of the corresponding requirement constraint units. 5) identifying and locating deviations based on the consistency comparison results to determine the type of deviation and the range of deviation code fragments between the function's functional requirements document and the source code of the function under test. Therefore, this invention can identify the deep-seated semantic bias problem of "code can run but function implementation does not meet requirements", and overcomes the problem that traditional static analysis tools mainly focus on syntax defects, code style or general defect patterns and have difficulty understanding the semantics of function functional requirements.

[0254] Furthermore, this invention assists in parsing requirement documents by using preset prompt word templates and industry standard knowledge bases. This allows the functional requirements described in natural language to be converted into requirement constraint units with fields such as input conditions, output behaviors, exception handling, and boundary values, improving the structure and comparability of the requirement parsing results. By anonymizing the source code of the function under test, constructing abstract syntax trees, control flow graphs, data flow graphs, and path condition sets, and further constructing heterogeneous code graphs and graph structure ranges, code syntax inclusion relationships, control flow relationships, and data dependencies can be uniformly expressed under the same structure, thereby improving the ability of code semantic vectors to represent the function implementation logic. By comparing the vector space of requirement semantic vectors and code semantic vectors, and combining logical implication checks to further determine whether code fragments meet the requirement logical expressions, the risk of misjudgment caused by relying solely on semantic similarity can be reduced. By identifying deviation types as missing functions, logical errors, redundant implementations, or missing exception handling, and further determining the range of deviation code fragments, the verification results can be located to the start and end line numbers of the code fragments, facilitating review and correction by developers and improving the traceability of the verification results of the consistency between function functionality and requirements.

[0255] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for verifying the consistency between function functionality and requirements, characterized in that, include: Functional requirement document parsing: Obtain the functional requirement document described in natural language; parse the functional requirement document based on the requirement document parsing model to generate a structured requirement parsing result; the structured requirement parsing result includes multiple requirement constraint units; generate corresponding requirement semantic vectors based on the multiple requirement constraint units to form a requirement semantic vector set. The source code of the function under test is parsed, the source code of the function under test is obtained, and static analysis is performed on the source code of the function under test. An intermediate representation corresponding to the source code of the function under test is constructed. Multiple code segments are determined based on the intermediate representation, and a code semantic vector corresponding to each code segment is generated. A code analysis result is formed based on the multiple code segments and their corresponding code semantic vectors. Consistency comparison is performed by determining candidate matching relationships between requirement constraint units and code segments based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, and by performing logical implication checks on the requirement constraint units and corresponding code segments based on the candidate matching relationships, and forming a consistency comparison result. Deviation identification and localization: Based on the consistency comparison results, determine the type of deviation and the range of deviation code segments between the function requirement document and the source code of the function under test.

2. The method for verifying the consistency between function functionality and requirements according to claim 1, characterized in that, The parsing of the function requirement document includes: Based on a preset prompt word template, a requirement parsing prompt message is generated, which includes a parsing task description, output field constraints, output format constraints, and example guidance. Based on the functional description information in the functional requirements document, retrieve the normative constraint information related to the functional description information from the industry standard knowledge base; The function requirement document, requirement analysis prompts, and specification constraint information are input into the requirement document analysis model to obtain a structured requirement analysis result, which includes multiple requirement constraint units. The multiple requirement constraint units are respectively input into the semantic encoder to generate a set of requirement semantic vectors; Each demand semantic vector in the demand semantic vector set corresponds to a demand constraint unit.

3. The method for verifying the consistency between function functionality and requirements according to claim 1, characterized in that, The source code analysis of the function under test includes: The source code of the function under test is anonymized to obtain the anonymized source code of the function under test; Static analysis is performed on the source code of the de-identified function to be tested to construct an intermediate representation, which includes an abstract syntax tree, a control flow graph, a data flow graph, and a set of path conditions. Multiple code segments are determined based on the intermediate representation, and a corresponding code segment record is generated for each code segment; Based on the abstract syntax tree, control flow graph, and data flow graph, a heterogeneous code graph is constructed, and the graph structure range corresponding to each code fragment is determined in the heterogeneous code graph based on the code fragment records. Input the graph structure range corresponding to each code fragment into the code understanding model to generate the code semantic vector corresponding to the code fragment, and form a code semantic vector set based on multiple code semantic vectors; Code analysis results are generated based on the multiple code fragments and their corresponding code semantic vectors.

4. The method for verifying the consistency between function functionality and requirements according to claim 1, characterized in that, The consistency comparison includes: Based on the vector space similarity between the set of requirement semantic vectors and the set of code semantic vectors, candidate matching relationships between requirement constraint units and code fragments are determined. Based on the candidate matching relationship, a logical implication check is performed on the requirement constraint unit and the corresponding code segment to obtain the logical implication check result. Based on the candidate matching relationships and logical implication check results, a consistency comparison result is generated.

5. The method for verifying the consistency between function functionality and requirements according to claim 3, characterized in that, The heterogeneous code graph is used to uniformly represent the syntax inclusion relationships, control flow relationships, and data dependency relationships in the source code of the de-identified function under test in the same graph structure; The nodes of the heterogeneous code graph include syntax nodes, control nodes, and data flow nodes; The edges of the heterogeneous code graph include syntax inclusion edges, control flow edges, and data flow edges.

6. The method for verifying the consistency between function functionality and requirements according to claim 4, characterized in that, The step of performing a logical implication check on the requirement constraint unit and its corresponding code fragment based on the candidate matching relationship includes: The requirement constraint unit is converted into a requirement logic expression, which includes preconditions and conclusion conditions. The preconditions are determined based on the input conditions in the requirement constraint unit, and the conclusion conditions are determined based on the output behavior, exception handling, or boundary values ​​in the requirement constraint unit. Based on the path condition list, control flow graph node list, control flow graph edge list, data flow node list, and data flow edge list recorded in the code snippet, extract the actual logical path corresponding to the code snippet; In the actual logical path, find the execution path that meets the preconditions, and check whether the execution path obtains the execution result corresponding to the conclusion condition; The logical implication check result is determined based on the execution result, and the logical implication check result includes pass, partial pass, or fail.

7. The method for verifying the consistency between function functionality and requirements according to claim 6, characterized in that, The logical implication check result is determined based on the execution result, including: When the conclusion condition includes a conclusion condition item: If all execution paths that meet the preconditions can obtain the execution result corresponding to the conclusion condition, then the logical implication check result is determined to be passed. Otherwise, the logical implication check result is determined to be failed; When the conclusion condition includes multiple conclusion condition items: If all execution paths that meet the preconditions can obtain the execution results corresponding to all conclusion condition items, then the logical implication check result is determined to be passed. If none of the execution paths that satisfy the preconditions can obtain the execution result corresponding to any conclusion condition item, or if there is no execution path that satisfies the preconditions, then the logical implication check result is determined to be unsuccessful. If an execution path that meets the preconditions can obtain the execution results corresponding to some of the conclusion condition items, but cannot obtain the execution results corresponding to all of the conclusion condition items, then the logical implication check result is determined to be partially passed.

8. The method for verifying the consistency between function functionality and requirements according to claim 1, characterized in that, Based on the consistency comparison results, the types of deviations between the function requirement document and the source code of the function under test are determined, including: When the requirement constraint unit does not form a candidate matching relationship and the constraint type of the requirement constraint unit does not belong to the exception handling requirement, the deviation type is determined as functional deficiency. When the requirement constraint unit forms a candidate matching relationship, but the logical implication check result corresponding to the candidate matching relationship is not passed or partially passed, and the constraint type of the requirement constraint unit does not belong to the exception handling requirement, the deviation type is determined to be a logical error. When a code snippet does not form a candidate matching relationship with any requirement constraint unit, and the code snippet does not belong to the preset auxiliary code type, the deviation type is determined as redundant implementation. The preset auxiliary code type includes at least one of logging code, assertion code, debugging code, resource release code, exception handling auxiliary code, or parameter initialization auxiliary code. When the constraint type of the requirement constraint unit is an exception handling requirement, and the requirement constraint unit has not formed a candidate matching relationship, or the requirement constraint unit has formed a candidate matching relationship but the logical implication check result is not passed or partially passed, the deviation type is determined to be exception handling missing.

9. The method for verifying the consistency between function functionality and requirements according to claim 1, characterized in that, For different types of deviations, corresponding positioning methods are used to determine the range of deviation code segments, including: When the deviation type is a missing function, based on the input conditions in the requirement constraint unit, the code fragment record related to the input conditions is searched in the control flow graph node list, control flow graph edge list and path condition list in the code analysis results. If a corresponding code fragment record is found, the start line number to the end line number in the code fragment record is determined as the deviation code fragment range. If no corresponding code fragment record is found, the start line number to the end line number in the code fragment record corresponding to the code semantic vector with the highest similarity to the requirement semantic vector of the requirement constraint unit is determined as the deviation code fragment range. When the deviation type is a logical error, the code segment record corresponding to the requirement constraint unit is determined based on the candidate matching relationship, and the starting line number to the ending line number in the code segment record is determined as the deviation code segment range. When the deviation type is redundant implementation, the starting line number to the ending line number in the code segment record corresponding to the code segment that does not form a candidate matching relationship with any requirement constraint unit is determined as the deviation code segment range; When the deviation type is missing exception handling, if the requirement constraint unit forms a candidate matching relationship, the corresponding code segment record is determined based on the candidate matching relationship, and the start line number to the end line number in the code segment record is determined as the deviation code segment range. If the requirement constraint unit does not form a candidate matching relationship, based on the input conditions and exception handling in the requirement constraint unit, the code segment record related to the input conditions or exception handling is searched in the control flow graph node list, control flow graph edge list, and path condition list in the code analysis results, and the start line number to the end line number in the found code segment record is determined as the deviation code segment range.

10. A system for verifying the consistency between function requirements and functionalities, characterized in that, include: The function requirement document parsing module obtains the function requirement document described in natural language, parses the function requirement document based on the requirement document parsing model, and generates a structured requirement parsing result. The structured requirement parsing result includes multiple requirement constraint units. Based on the multiple requirement constraint units, corresponding requirement semantic vectors are generated and a requirement semantic vector set is formed. The test function source code parsing module obtains the source code of the test function, performs static analysis on the source code, constructs an intermediate representation corresponding to the source code, determines multiple code segments based on the intermediate representation, generates a code semantic vector corresponding to each code segment, and forms a code analysis result based on the multiple code segments and their corresponding code semantic vectors. The consistency comparison module determines the candidate matching relationship between the requirement constraint unit and the code segment based on the vector space similarity between the requirement semantic vector set and the code semantic vector set, and performs logical implication check on the requirement constraint unit and the corresponding code segment based on the candidate matching relationship, and forms a consistency comparison result. The deviation identification and localization module, based on the consistency comparison results, determines the type of deviation and the range of deviation code segments between the function functional requirements document and the source code of the function under test.

Images