Regression defect detection method based on structured behavior prediction

Abstract

This invention belongs to the field of automated testing technology, and particularly relates to a regression defect detection method based on structured behavioral predictions. The method includes: S1, acquiring metadata and code differences of the pull request to be detected; extracting the global intent of the pull request and identifying affected code regions based on the metadata and code differences; S2, synthesizing function-level structured behavioral predictions for the affected code regions, whereby the structured behavioral predictions include behaviors that should remain unchanged and behaviors expected to change; S3, generating executable test cases based on the structured behavioral predictions; executing the same test cases in both the pre-code change version and the post-code change version and collecting structured execution data; S4, determining whether the pull request introduces behavioral regression based on the structured execution data, the global intent, and the structured behavioral predictions. This invention solves the problems of difficulty in distinguishing between expected changes and unexpected regressions, difficulty in covering deep behavioral boundaries, and unstable model generation.

Description

Technical Field

[0001] This invention belongs to the field of automated testing technology, and in particular relates to a regression defect detection method based on structured behavior prediction; it is applicable to scenarios such as continuous integration, code review, open source project maintenance, and enterprise-level software quality assurance, and can be used to automatically identify unexpected behavioral differences introduced by code changes before or after code merging. Background Technology

[0002] In modern software development, developers typically make incremental modifications to software systems through pull requests (PRs), commits, or patches. These modifications may be used for defect fixing, feature expansion, performance optimization, or code refactoring, but they can also unintentionally break existing correct behavior, introducing regression defects. Unlike general defect detection, regression testing inherently involves two issues: first, comparing whether there are behavioral differences before and after code changes; and second, further determining whether these behavioral differences belong to the developer's expected functional evolution or unexpected behavioral degradation. Existing technologies for regression testing and regression detection after code changes mainly include the following three types of solutions.

[0003] (1) Regression test selection and prioritization based on existing test suites. (2) Based on differential execution, semantic difference analysis and differential input exploration. (3) PR-level behavioral regression detection based on code changes, natural language artifacts and large language models.

[0004] While the above approach can identify issues caused by code modifications to some extent, it still has the following shortcomings in PR-level behavior regression detection tasks:

[0005] First, regression test selection and prioritization methods based on existing test suites lack the ability to proactively discover new regressions. Methods like Ekstazi and STARTS can reduce test execution costs in continuous integration environments, but their core premise is that existing tests in the project already cover key modified areas and key behaviors. In other words, these methods primarily address the question of "which existing tests need to be re-executed," rather than "how to proactively construct new regression-triggered tests for this PR." If existing tests do not cover modified functions, affected call chains, boundary inputs, or compatibility interfaces, even if the PR has introduced regressions, it may not trigger any test failures. Therefore, while these methods are valuable in terms of engineering efficiency, they have inherent limitations in discovering PR-level behavioral regressions not covered by existing tests.

[0006] Second, while methods based on differential execution and semantic difference analysis can identify behavioral differences, they struggle to determine whether these differences align with the developer's intent. Methods like SymDiff, shadow symbolic execution, and DifFuzz can proactively identify behavioral discrepancies between old and new versions compared to traditional RTS methods, but they primarily answer the questions of "whether a difference exists" or "what input would cause a difference." In real-world PR scenarios, behavioral differences are not inherently equivalent to regression. For example, a bug fix PR might inherently change the handling logic for erroneous inputs, while a feature addition PR might intentionally introduce new outputs, exceptions, or control flow paths. If the system only observes differences without understanding the developer's intent, it's easy to misjudge expected evolution as regression, or fail to explain whether a particular difference disrupts existing correct behavior. Therefore, these methods are strong in "difference discovery" but weak in "difference interpretation" and "intent alignment."

[0007] Third, PR-level methods based on natural language artifacts and large language models still tend to remain at a superficial level of change understanding, lacking structured behavioral predictions. Methods like Testora have attempted to incorporate PR descriptions, code diffs, and natural language intents into regression detection, which is a step further than simple difference execution. However, existing methods typically still treat PR text and code diffs as unstructured context input to the model, with the model directly generating tests or judging differences. This easily leads to two problems: firstly, the model is more likely to generate tests around the newly added logic explicitly described in the PR, ignoring deeper preservation behaviors and compatibility consequences; secondly, existing methods lack function-level, structured, and traceable behavioral predictions, making it difficult to clearly distinguish which behaviors should remain unchanged, which behaviors are allowed to change, and which specific behavioral constraints each test covers. Your review also clearly points out that PR-level tools like Testora tend to rely on unstructured diffs, often focusing on change behavior rather than preserved behavior, thus making them more prone to missing detections in scenarios where "old behaviors are quietly broken but new logic appears to work correctly."

[0008] In summary, existing technologies have evolved from traditional regression testing and re-execution to differential behavior exploration and PR-level regression detection combined with natural language intent. However, overall, existing methods still have three key shortcomings: methods relying on existing tests are not proactive enough; methods relying on differential execution do not adequately understand intent; and methods relying on LLM and unstructured PR context lack explicit, structured, and traceable behavioral predictions. Summary of the Invention

[0009] This invention aims to propose a regression defect detection method based on structured behavioral prediction. By introducing an interpretable "behavioral prediction" intermediate layer between code differences and test generation, it solves the problems of existing technologies, such as difficulty in distinguishing between expected changes and unexpected regressions, difficulty in covering deep behavioral boundaries, and unstable model generation.

[0010] The main objectives of this invention include:

[0011] 1. Extract developer intent from PR titles, descriptions, code differences, and related metadata to determine whether the change is a bug fix, feature addition, refactoring, optimization, or a hybrid change, and identify the expected scope of behavioral changes.

[0012] 2. Use abstract syntax trees and structural difference analysis to locate directly affected functions, methods, constructors, or class properties, and identify potential compatibility risk types.

[0013] 3. For each change unit with behavioral impact, synthesize a structured function-level behavioral prediction, explicitly distinguishing between behaviors that should remain unchanged, behaviors that are expected to change, execution prerequisites, and key control flow conditions.

[0014] 4. Automatically generate and enhance executable tests under behavioral oracle constraints, so that the test focus is on covering persistent behavior, changing behavior, and new control flow branches, rather than just pursuing code coverage.

[0015] 5. Run the same tests in the isolated environment before and after the change, and combine deterministic rules with constrained large language model reasoning to make stable and interpretable regression judgments on behavioral differences.

[0016] The specific technical solution of this invention is as follows:

[0017] First, this invention provides a regression defect detection method based on structured behavior prediction, comprising:

[0018] S1. Obtain the metadata and code differences of the pull request to be detected; extract the global intent of the pull request based on the metadata and code differences and identify the affected code regions;

[0019] The extraction of global intent for pull requests described in S1 includes extracting change type, expected scope of behavior changes, compatibility statements, and high-level goal constraints from the title, description, commit message, comment summary, and code difference summary;

[0020] The identification of affected code regions described in S1 includes parsing modified lines in code differences and mapping the modified lines to abstract syntax tree nodes to determine the functions, methods, constructors, or class properties containing the modified lines.

[0021] S1 also includes performing structural risk analysis on the affected code region to identify at least one risk type, which includes parameter deletion, default value change, anomaly drift, silent parameter swallowing, or generator transformation;

[0022] The risk types obtained from the structural risk analysis are used as prompt constraints input into the structured behavior prediction synthesis process, so that the synthesized structured behavior prediction includes the maintain behavior or change behavior constraints corresponding to the risk types.

[0023] S2. Synthesize function-level structured behavior predictions for the affected code regions, the structured behavior predictions including behaviors that should remain unchanged and behaviors that are expected to change;

[0024] The structured behavioral predictions described in S2 also include function identifiers, code difference summaries, execution prerequisites, behavioral annotations, and control flow hints.

[0025] S3. Generate executable test cases based on the structured behavior prediction; execute the same test cases in both the version before and after the code change and collect structured execution data;

[0026] The generation of executable test cases described in S3 includes requiring each test case to carry an oracle_ref identifier, which is used to indicate the structured behavioral oracle regions and entry indexes covered by the test case.

[0027] The structured execution data described in S3 includes at least one of the following: execution status, runtime, memory usage, exception information, return value, standard output, standard error, and assertion results.

[0028] S3 also includes statistics on the coverage of structured behavior oracle entries based on oracle_ref, and identifies uncovered hold behavior, change behavior, or control flow hints as coverage gaps;

[0029] Perform test enhancements for the coverage gaps, including boundary value perturbation, abnormal path triggering, default parameter explicitation, generator output consumption, or targeted regeneration based on uncovered oracle entries;

[0030] S3 also includes static repair of test cases before execution. The static repair includes code block extraction, indentation normalization, import completion, symbol resolution, misdirection correction, removal of unused imports, and syntax verification. The static repair does not change the test semantics of the test cases.

[0031] S4. Determine whether to introduce behavioral regression in the pull request based on the structured execution data, the global intent, and the structured behavioral oracle.

[0032] Whether the pull request described in S4 introduces behavioral regression includes first performing deterministic rule judgment, and then performing constrained model inference for cases not covered by deterministic rules;

[0033] The deterministic rules include performance degradation rules, infrastructure error rules, rules for new functions without baselines, and rules for no behavioral changes;

[0034] The constrained model inference includes enabling the model to answer questions about behavioral differences, state changes, abnormal changes, changes in output or return values, and performance degradation based on structured execution data, and outputting regression labels based on the combination of answers.

[0035] The present invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, characterized in that the computer program, when executed by the processor, implements the regression defect detection method based on structured behavior prediction.

[0036] The present invention also provides a computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the regression defect detection method based on structured behavior prediction.

[0037] Compared with the prior art, the present invention has at least the following beneficial effects:

[0038] 1. By introducing structured behavior prediction, behavior understanding and test code generation are decoupled, avoiding the model from undertaking the tasks of intent understanding and executable code construction simultaneously in a single generation, thereby improving generation stability and interpretability.

[0039] 2. Explicitly distinguishing between maintenance behaviors and change behaviors helps determine whether behavioral differences are expected evolutions or unexpected regressions, reducing false positives and false negatives.

[0040] 3. By using AST to locate the affected area and analyze structural risks, targeted tests can be generated for fine-grained risks such as parameter deletion, changes in default values, abnormal drift, silent parameter swallowing, and generator conversion.

[0041] 4. By using oracle_ref coverage tracing and coverage gap enhancement, the test generation goal shifts from simple code coverage to behavioral prediction coverage, thereby improving the coverage of deep regression triggering conditions.

[0042] 5. Objective evidence is collected through isolated differential execution, and then combined with deterministic rules and constrained model reasoning to balance the stability, reproducibility and flexibility in complex semantic scenarios.

[0043] 6. This method can be embedded into the continuous integration process to automatically detect real software changes at the PR level, reducing the burden of manual code review and regression testing. Attached Figure Description

[0044] Figure 1 This is a schematic diagram of the regression defect detection process based on structured behavior prediction of the present invention.

[0045] Figure 2 This is a schematic diagram illustrating the data organization and flow relationships of the structured behavior prediction of this invention.

[0046] Figure 3 This is a schematic diagram of the prediction-guided test generation and coverage enhancement process of the present invention.

[0047] Figure 4 This is a schematic diagram of the differential execution and hybrid regression determination process of the present invention. Detailed Implementation

[0048] The specific technical solutions in this aspect are illustrated with reference to the embodiments.

[0049] In this embodiment, given a pull request to be tested, the system first parses the PR metadata and code differences to form a structured context; secondly, it synthesizes function-level behavioral predictions based on the context; thirdly, it generates and enhances test cases based on the predictions; and finally, it executes tests in both versions before and after the change and classifies the behavioral differences. The overall process is as follows: Figure 1 As shown.

[0050] The method comprises the following four interconnected core steps.

[0051] S1, PR Intent and Impact Area Identification: The system extracts the global change intent from the PR title, description, commit message, comment summary and code diff, and maps the diff modification lines to AST nodes to locate the affected functions, methods, constructors or class properties. At the same time, it identifies structural risks such as parameter deletion, default value changes, anomaly drift, silent parameter swallowing and generator conversion.

[0052] S2, Structured Behavior Prediction Synthesis: The system inputs the PR intent, affected code units, code before and after the change, and structural risk signals obtained from S1 into the prediction synthesis module to generate function-level structured behavior predictions, explicitly distinguishing between preserved_behavior, changed_behavior, setup_requirements, and control_flow_hints, thereby expressing "old behaviors that should be maintained" and "new behaviors that are allowed to change" separately.

[0053] S3, Oracle-guided Test Generation and Coverage Enhancement: The system does not directly generate tests based on the original diff, but extracts verification targets from structured behavioral oracles, generates executable tests carrying oracle_ref, and calculates the coverage of oracle entries based on oracle_ref; for uncovered entries, coverage gaps are filled through boundary value perturbation, exception triggering, explicit default parameterization, generator consumption, and targeted regeneration, while performing static repairs that do not change the test semantics.

[0054] S4, Differential Execution and Hybrid Regression Decision: The system runs the same set of tests in two isolated environments before and after the change, collecting structured execution data such as status, exceptions, return values, output, runtime, and memory. Then, deterministic rules are used to handle situations such as no difference, environmental errors, new functions without baselines, and obvious performance degradation. For complex differences, a constrained model is called to answer standardized questions, and finally, the regression or clean label is output.

[0055] The specific methods for each step are as follows:

[0056] S1. Identification of PR Intent and Impact Areas;

[0057] S1.1. PR Global Intent Extraction;

[0058] The system extracts global change intent from PR titles, descriptions, commit messages, comment summaries, and code diff summaries. The extracted results are normalized into a machine-readable structure, as shown in the example in Table 1, to constrain subsequent oracle generation, rather than simply serving as natural language background.

[0059] Table 1 shows that the extracted results have been normalized to a machine-readable structure.

[0060] Fields meaning Example values change_type Change type optimization / bug_fix / refactor / feature / mixed / unknown expected_behavior_change Expected range of behavioral changes none / local / global / unknown backward_compatibility Compatibility Statement Does it break compatibility, remove features, or change migration paths? high_level_expectations High-level goal constraints Fixing an anomaly, maintaining compatibility with existing APIs, and improving performance, etc.

[0061] Using the above structure, the system can determine whether certain output changes belong to the expected behavior changes declared by the developer. For example, if a PR is identified as a bug_fix and does not declare a breach of compatibility, the successful execution of the original valid input should generally be included in a preservation behavior oracle.

[0062] S1.2. Location of the Influence Region Based on AST

[0063] The system parses file paths and line numbers from Git diffs and maps modified lines to abstract syntax tree nodes. Functions, methods, constructors, or class attributes containing modified lines are marked as directly affected regions. For each affected region, the system extracts the code before the change, the code after the change, the function signature, the module it belongs to, the call relationships, and the adjacent context.

[0064] To reduce noise, the system prioritizes retaining code units that are directly related to the changed behavior, excluding modifications that only involve comments, formatting, documentation, non-executable abstract interfaces, or mechanical forwarding wrappers.

[0065] S1.3. Structural Risk Analysis

[0066] The system performs lightweight static analysis on the function structure before and after the change to identify high-risk patterns that may cause silent behavior deviations. These include at least the following five categories:

[0067] Table 2 Five Types of Risks

[0068] Risk type Detection object Potential impact Parameter deletion Parameters removed from function signature Existing callers may fail or semantic changes may occur. Default value changes Old and new values ​​of default values ​​for formal parameters Silent changes occur when parameters are not explicitly passed. Abnormal drift Added or removed exception types and error paths Caller captures logic failure Silent parameter swallowing **Changes in the way variable parameters such as kwargs are received** Illegal parameters no longer report errors or the errors are hidden. Generator Transformation A normal return function becomes a yield generator or vice versa. Changes in return type, consumption method, and timing of side effects

[0069] The aforementioned risk types do not directly provide regression conclusions, but are injected as explicit danger signals into the structured prediction synthesis stage, prompting the system to generate maintenance or change behavior constraints around these risks.

[0070] S2. Structured Behavioral Prediction Synthesis

[0071] like Figure 2 The core of this invention, as illustrated in the process, lies in introducing a "structured behavioral oracle" layer between code difference understanding and test code generation. A behavioral oracle is a function-level behavioral contract used to describe which behaviors must remain unchanged, which behaviors are allowed or should be changed, the environmental prerequisites required for test execution, and key control flow conditions.

[0072] In a preferred embodiment, the system represents function-level behavioral oracles as JSON or an equivalent structured object, with fields as shown in Table 3:

[0073] Table 3 Field Descriptions

[0074] Fields illustrate function_id A unique identifier for the modified function, such as module.class.function code_diff_summary Semantic summary of code differences setup_requirements Dependencies, data, environment, or mock prerequisites required to execute the test preserved_behavior Behaviors that should remain unchanged, when deviated from, typically constitute the regression boundary. changed_behavior The developers intend to change the behavior to reduce false positives. behavior_notes Additional information, reasons for skipping, error status, or confidence level. control_flow_hints Adding paths, modifying paths, and important conditional expressions

[0075] For example, for a PR that fixes the handling logic for invalid external links, if the PR goal is "invalid links should be rolled back", but the original behavior of "valid links should be resolved normally" should not be changed, then the structured predictions may include: preserved_behavior is "valid links should still be resolved normally and successfully", and changed_behavior is "invalid links should trigger a fallback path instead of failing directly".

[0076] The oracle synthesis process is driven by two types of information: one is deterministic facts and risk signals obtained from static analysis, and the other is semantic induction by a large language model based on PR intent, pre- and post-change code, and context. Combining the two can improve the coverage of deep behavioral boundaries without introducing heavy procedural analysis costs.

[0077] S3. Oracle-guided test generation and coverage enhancement

[0078] like Figure 3 As shown, it includes the following sub-steps:

[0079] S3.1. Initial Test Generation

[0080] Instead of generating tests directly from the raw diff, the system extracts validation targets from structured behavioral oracles, including `preserved_behavior`, `changed_behavior`, and `control_flow_hints`. The large language model generates executable tests under constraint hints, requiring each test to explicitly include an `oracle_ref` field to identify the oracle regions and indexes it covers.

[0081] In one embodiment, the system sets a base test budget for each public request (PR) and allocates the number of tests based on function priority. Function priority can be calculated as follows: Priority = 5 × |changed_behavior| + 2 × |preserved_behavior|. This weight is used to prioritize covering functions with more pronounced behavioral changes and higher regression risk, while ensuring that preserveable behaviors are also tested.

[0082] S3.2. Coverage Gap Identification and Enhancement

[0083] After the initial test is generated, the system calculates the coverage of each oracle entry based on oracle_ref. If certain hold behaviors, change behaviors, or new paths are not covered by any test, they are recorded as coverage gaps.

[0084] To address coverage gaps, the system employs two types of enhancement strategies:

[0085] (1) Input mutation enhancement: Based on existing tests, perform boundary value perturbation, anomaly triggering, default parameter explicitation, generator consumption and other operations to trigger high-risk paths.

[0086] (2) Ordinal-directed regeneration: Explicitly inject hints for uncovered ordinal entries, requiring the model to generate new tests that reference the corresponding oracle_ref.

[0087] The enhancement process can set a global cap to prevent the number of tests from ballooning. Functions are sorted by the number of uncovered oracle entries, thus prioritizing the repair of structural coverage gaps.

[0088] S3.3. Static Repair

[0089] Because the tests generated by the model may contain syntax, import, or identifier errors, the system performs static fixes to improve executability. Static fixes include Markdown code block extraction, indentation normalization, import completion, symbol resolution, misdirection degradation, removal of unused imports, and AST syntax verification.

[0090] Static fixes are only used to ensure that tests can run, without changing the logical intent of the tests, and without adapting to the versions before or after the change, so as to avoid masking the actual behavioral differences.

[0091] S4. Differential Execution and Hybrid Regression Decision

[0092] like Figure 4 The system installs both the pre-PR and post-PR versions in isolated containers or virtual environments, and performs the same set of build tests on both versions. Except for the code version under test, dependencies, system configurations, resource limits, and execution parameters remain consistent.

[0093] During execution, the system records structured execution data, including test status, runtime, memory usage, exception type and stack, return value, standard output, standard error, and assertion results.

[0094] The decision-making phase employs a hybrid strategy of "prioritizing deterministic rules and supplementing with model reasoning." In a preferred embodiment, the deterministic rules include:

[0095] (1) If the execution time after the change exceeds the preset threshold (e.g., twice) compared to before the change, and it is not due to environmental reasons, it is marked as a risk of performance degradation.

[0096] (2) If the difference is caused by infrastructure errors such as missing dependencies, installation failure, network timeout or resource limitations, it is marked as an infrastructure error and excluded from regression determination.

[0097] (3) If the function under test is newly added after the change and there is no comparable baseline before the change, then it shall be processed according to the new function path.

[0098] (4) If there are no significant differences in status, output, abnormality and performance, it is judged as clean.

[0099] For cases where hard rules cannot cover the behavior, the system calls the constrained large language model and answers standardized questions based solely on structured execution data, PR intent, and behavioral predictions: Q1: Are there behavioral differences? Q2: Has there been a state change from OK to anomaly, timeout, or failure? Q3: Have any anomalies been added or changed? Q4: Have any return values ​​or outputs changed unexpectedly? Q5: Is there any performance degradation exceeding the threshold? If Q1 is yes and at least one of Q2 to Q5 is yes, then output "regression"; otherwise, output "clean".

[0100] This invention can be implemented as a software system, a continuous integration plugin, a code hosting platform application, a command-line tool, or a cloud service. The system includes at least: a PR acquisition module, an intent extraction module, an AST analysis module, a structural risk analysis module, a behavioral oracle synthesis module, a test generation module, a test enhancement module, a static repair module, an isolated execution module, a differential data acquisition module, and a regression determination module.

[0101] Each module can be deployed on the same electronic device or distributed in a microservice manner; the large language model can be provided through local inference, private model services, or third-party API calls.

Claims

1. A regression defect detection method based on structured behavior prediction, characterized in that, include: S1. Obtain the metadata and code differences of the pull request to be detected; Based on the aforementioned metadata and code differences, extract the global intent of the pull request and identify the affected code regions; S2. Synthesize function-level structured behavior predictions for the affected code regions, the structured behavior predictions including behaviors that should remain unchanged and behaviors that are expected to change; S3. Generate executable test cases based on the structured behavior prediction; execute the same test cases in both the version before and after the code change and collect structured execution data; S4. Determine whether to introduce behavioral regression in the pull request based on the structured execution data, the global intent, and the structured behavioral oracle.

2. The regression defect detection method based on structured behavior prediction according to claim 1, characterized in that, The extraction of global intent for pull requests described in S1 includes extracting change type, expected scope of behavior changes, compatibility statements, and high-level goal constraints from the title, description, commit message, comment summary, and code difference summary; The identification of affected code regions described in S1 includes parsing modified lines in code differences and mapping the modified lines to abstract syntax tree nodes to determine the functions, methods, constructors, or class properties containing the modified lines.

3. The regression defect detection method based on structured behavior prediction according to claim 1, characterized in that, S1 also includes performing structural risk analysis on the affected code region to identify at least one risk type, which includes parameter deletion, default value change, anomaly drift, silent parameter swallowing, or generator transformation; The risk types obtained from the structural risk analysis are used as prompt constraints input into the structured behavior prediction synthesis process, so that the synthesized structured behavior prediction includes the maintain behavior or change behavior constraints corresponding to the risk types.

4. The regression defect detection method based on structured behavior prediction according to claim 1, characterized in that, The structured behavioral predictions described in S2 also include function identifiers, code difference summaries, execution prerequisites, behavioral annotations, and control flow hints.

5. The regression defect detection method based on structured behavior prediction according to claim 1, characterized in that, The generation of executable test cases described in S3 includes requiring each test case to carry an oracle_ref identifier, which is used to indicate the structured behavioral oracle regions and entry indexes covered by the test case. The structured execution data described in S3 includes at least one of the following: execution status, runtime, memory usage, exception information, return value, standard output, standard error, and assertion results.

6. The regression defect detection method based on structured behavior prediction according to claim 4, characterized in that, S3 also includes statistics on the coverage of structured behavior oracle entries based on oracle_ref, and identifies uncovered hold behavior, change behavior, or control flow hints as coverage gaps; Perform test enhancements for the coverage gaps, including boundary value perturbation, abnormal path triggering, default parameter explicitation, generator output consumption, or targeted regeneration based on uncovered oracle entries; S3 also includes static repair of test cases before execution. The static repair includes code block extraction, indentation normalization, import completion, symbol resolution, misdirection correction, removal of unused imports, and syntax verification. The static repair does not change the test semantics of the test cases.

7. The regression defect detection method based on structured behavior prediction according to claim 1, characterized in that, Whether the pull request described in S4 introduces behavioral regression includes first performing deterministic rule judgment, and then performing constrained model inference for cases not covered by deterministic rules; The deterministic rules include performance degradation rules, infrastructure error rules, rules for new functions without baselines, and rules for no behavioral changes; The constrained model inference includes enabling the model to answer questions about behavioral differences, state changes, abnormal changes, changes in output or return values, and performance degradation based on structured execution data, and outputting regression labels based on the combination of answers.

8. An electronic device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it implements the regression defect detection method based on structured behavior prediction as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the regression defect detection method based on structured behavior prediction as described in any one of claims 1 to 7.

Images