Interface change detection method and device based on behavior contract, equipment and medium

Abstract

The invention provides an interface change detection method and device based on a behavior contract, equipment and a medium, and the method integrates dominant change detection and implicit service logic verification to complete the construction of a comprehensive interface change analysis framework. The dominant change analysis result is generated through structured comparison, meanwhile, the test state data and the behavior contract object are associated, and then the logic test is executed based on the business rule, so that the problem that the internal business logic implicit change cannot be detected under the condition that the interface definition is kept unchanged is solved; and interface change detection inaccuracy caused by business logic modification is avoided, so that the accuracy of an interface detection result is improved. The method can be applied to an interface change detection function in the financial field or the medical field, so that the prediction accuracy of the car insurance claim settlement amount in the financial field is improved, or the accuracy of a medical data analysis result in the medical field is improved.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a method, apparatus, computer device, and computer-readable storage medium for detecting interface changes based on behavioral contracts. Background Technology

[0002] Interfaces (such as APIs and Web service interfaces) are the core carriers of interaction between software systems, and their stability and correctness directly affect the operation of business logic. Currently, interface testing only checks the interface code. However, with the rapid iteration of business requirements and frequent system version updates, the business logic inside the interface may have been modified. Examples include auto insurance claims interfaces in the financial sector and medical data analysis interfaces in the medical field.

[0003] The auto insurance claims interface provides a calculation interface for the claims amount calculation service. The input to this interface includes the policy number and accident liability certificate, and the output is the claims amount. Its internal business logic calculates based on dynamic data sources such as the latest guidance price from the State Financial Regulatory Commission, the vehicle parts-to-whole ratio database, and repair labor cost standards. The service provider modified the internal price calculation logic for a specific vehicle model's parts without changing the API interface code. For downstream claims approval and financial payment services, the API call format remains completely unchanged, but the benchmark for the calculation result has changed.

[0004] The medical data analysis interface provides a platform for disease risk prediction services. It takes a patient's genomic sequence fragment and clinical indicators as input to obtain the patient's risk level. The internal business logic of the medical data analysis interface relies on a continuously optimized prediction model. Without changing the API code, if the model fine-tunes the weights of a specific gene locus, the API's input and output structure (gene sequence, risk level) remains completely unchanged. This could lead to doctors making treatment recommendations based on outdated model conclusions, posing a medical risk.

[0005] Therefore, improving the accuracy of interface change detection results has become an urgent technical problem to be solved. Summary of the Invention

[0006] The main objective of this application is to provide a method, apparatus, computer device, and computer-readable storage medium for detecting interface changes based on behavioral contracts, with the aim of improving the accuracy of interface change detection results.

[0007] To achieve the above objectives, this application provides an interface change detection method based on behavioral contracts, the interface change detection method comprising the following steps: Obtain the interface identifier of the interface to be verified, and obtain the modified interface definition corresponding to the interface to be tested in the modified code; Based on the comparison results between the standard interface definition corresponding to the interface to be tested and the modified interface definition, the explicit change analysis results of the interface to be tested are generated. Based on the interface identifier, obtain the test status data of the interface to be tested and at least one target behavior contract object related to the interface to be tested, wherein the target behavior contract object includes target test cases and target business rules; Based on the test status data, the target test cases, and the target business rules, business logic testing is performed on the interface to be tested to obtain the implicit change analysis results of the interface to be tested.

[0008] Furthermore, to achieve the above objectives, this application also provides an interface change detection device based on behavioral contracts, the interface change detection device comprising: The interface definition acquisition module is used to obtain the interface identifier of the interface to be verified and to obtain the modified interface definition corresponding to the interface to be tested in the modified code. The interface explicit detection module is used to generate explicit change analysis results for the interface to be detected based on the comparison results between the standard interface definition corresponding to the interface to be detected and the changed interface definition. The behavior contract acquisition module is used to acquire the test status data of the interface to be tested and at least one target behavior contract object related to the interface to be tested based on the interface identifier, wherein the target behavior contract object includes target test cases and target business rules; The interface implicit detection module is used to perform business logic testing on the interface to be tested based on the test status data, the target test cases, and the target business rules, and obtain the implicit change analysis results of the interface to be tested.

[0009] In addition, to achieve the above objectives, this application also provides a computer device, the computer device including a processor, a memory, and a behavior contract-based interface change detection program stored in the memory and executable by the processor, wherein when the behavior contract-based interface change detection program is executed by the processor, it implements the steps of the behavior contract-based interface change detection method as described above.

[0010] In addition, to achieve the above objectives, this application also provides a computer-readable storage medium storing an interface change detection program based on behavioral contracts, wherein when the interface change detection program based on behavioral contracts is executed by a processor, it implements the steps of the interface change detection method based on behavioral contracts as described above.

[0011] This application provides an interface change detection method based on behavioral contracts. The method obtains the interface identifier of the interface to be verified, and retrieves the modified interface definition corresponding to the interface to be detected from the modified code. Based on the comparison result between the standard interface definition corresponding to the interface to be detected and the modified interface definition, an explicit change analysis result of the interface to be detected is generated. Based on the interface identifier, the test status data of the interface to be detected and at least one target behavioral contract object related to the interface to be detected are obtained, wherein the target behavioral contract object includes target test cases and target business rules. Based on the test status data, the target test cases, and the target business rules, business logic testing is performed on the interface to be detected to obtain an implicit change analysis result of the interface to be detected. Through the above method, this application integrates explicit change detection and implicit business logic verification, completing the construction of a comprehensive interface change analysis framework. By generating explicit change analysis results through structured comparison and simultaneously associating test status data with behavioral contract objects, and then executing logic tests based on business rules, the problem of being unable to detect implicit changes in internal business logic when the interface definition remains unchanged is solved, avoiding inaccurate interface change detection due to business logic modifications, thereby improving the accuracy of interface detection results. Attached Figure Description

[0012] Figure 1 A flowchart illustrating an interface change detection method based on behavioral contracts provided in this application; Figure 2 A flowchart illustrating another interface change detection method based on behavioral contracts provided in this application; Figure 3 A flowchart illustrating another interface change detection method based on behavioral contracts provided in this application; Figure 4 A schematic diagram of the functional modules of an interface change detection device based on behavioral contracts provided in this application; Figure 5 A schematic block diagram of the structure of a computer device provided in this application.

[0013] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0016] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0017] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0018] The interface change detection method based on behavior contract involved in the embodiments of this application is mainly applied to computer equipment, which can be a PC, a portable computer, a mobile terminal or other device with display and processing functions.

[0019] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0020] Reference Figure 1 , Figure 1 This is a flowchart illustrating an interface change detection method based on behavioral contracts provided in this application.

[0021] like Figure 1 As shown, this application provides an interface change detection method based on behavioral contracts, which includes steps S101 to S104.

[0022] In this embodiment, the interface change detection method based on behavior contracts includes the following steps: Step S101: Obtain the interface identifier of the interface to be verified, and obtain the modified interface definition corresponding to the interface to be detected in the modified code; As the core carrier of interaction between software systems, the stability and correctness of interfaces have a decisive impact on the smooth operation of business logic. Current interface detection methods mainly rely on static analysis at the code level, focusing only on explicit changes in interface parameter structure, data types, or calling protocols, while failing to effectively identify implicit modifications to the internal business logic of the interface. In the context of rapid iteration of business requirements and frequent system version updates, service providers may adjust the internal implementation logic without changing the interface code definition, such as modifying calculation rules, data processing flows, or business decision conditions. This implicit change results in the interface's input and output formats remaining unchanged, but the actual business behavior deviates, rendering traditional code-based detection methods completely ineffective. Taking the auto insurance claims interface in the financial sector as an example, this interface receives input parameters such as policy number and accident liability certificate, and outputs the claim amount. Its internal logic relies on dynamic data sources such as the State Financial Regulatory Commission's guidance price and vehicle parts-to-whole ratio database for calculation. If the service provider updates the price calculation rules for specific vehicle model parts without adjusting the API interface code, downstream claims approval and financial payment services will not be aware of this change, leading to errors in claim amount calculation and the risk of financial loss. Similarly, in disease risk prediction interfaces in the medical field, patients' genomic sequences and clinical indicator data are input, and risk levels are output. The internal logic is based on a continuously optimized prediction model. When the model fine-tunes the weights of key gene loci, the input-output structure of the interface remains unchanged, but the risk level output may become biased. This could lead doctors to formulate treatment plans based on outdated model conclusions, posing potential medical safety risks. Furthermore, existing technologies lack a comprehensive verification mechanism for test state data, behavioral contract objects, and business rules. They cannot capture the impact of implicit changes on actual business results through business logic testing, resulting in severely insufficient accuracy and reliability of interface change detection.

[0023] In order to effectively identify implicit interface changes and improve the accuracy of business logic verification, thereby increasing the accuracy of interface change detection results.

[0024] In this embodiment, obtaining the interface identifier of the interface to be verified means determining an identifier used to uniquely identify the target interface. This can be achieved by using the interface name, the Uniform Resource Locator (URL) path, or a globally unique identifier. For example, a predefined interface name can be extracted from the system configuration file, or the globally unique identifier of the interface can be obtained by querying the service registry. The main purpose is to achieve accurate positioning of a specific interface and avoid involving irrelevant interface code in the detection process.

[0025] Obtaining the modified interface definition corresponding to the interface to be tested in the modified code refers to extracting the modified interface description information from the code version control system. This can be achieved by parsing the difference files in the code repository or by directly reading the compiled interface metadata. For example, by analyzing the changes in the interface definition file in the Git commit record or by calling the interface description document generated by the compiler. Its main purpose is to provide benchmark data for comparison with the standard interface definition.

[0026] Step S102: Based on the comparison results between the standard interface definition corresponding to the interface to be detected and the changed interface definition, generate the explicit change analysis results of the interface to be detected; In this embodiment, generating explicit change analysis results based on the comparison results between standard interface definitions and modified interface definitions refers to identifying structural differences at the interface form level. This can be achieved by comparing parameter lists or verifying return types. For example, by comparing interface parameter names and data types field by field, or by verifying the compatibility of the interface return structure. Its main purpose is to achieve rapid capture of changes at the interface definition level.

[0027] Obtaining test status data and target behavior contract objects based on interface identifiers refers to the test context information associated with the interface. The target behavior contract object includes target test cases and target business rules, which can be achieved by retrieving predefined test sets from the contract management platform or calling the business rule engine interface. For example, querying the historical test case set in the test database through the interface identifier, or loading the business logic rule document bound to the interface from the rule repository. Its main purpose is to provide verification basis that fits actual business scenarios. Therefore, obtaining implicit change analysis results by conducting business logic testing on the interface under test based on test status data, target test cases, and target business rules refers to verifying the consistency of the interface's internal logic execution. This can be achieved by simulating calls and verifying output behavior or executing sandbox environment tests. For example, inputting preset test data into the interface and checking whether the output meets business expectations, or running the interface logic in an isolated environment and comparing it with historical behavior baselines. Its main purpose is to identify implicit changes in the interface's internal business logic.

[0028] Specifically, this application constructs a comprehensive interface change analysis framework by integrating explicit change detection and implicit business logic verification. In practical applications, after obtaining the interface identifier, the framework locates the changed interface definition, generates explicit change analysis results through structured comparison, and associates test state data with behavioral contract objects. Then, it executes logic tests based on business rules, thereby solving the technical problem of not being able to detect implicit changes in internal business logic when the interface definition remains unchanged. This avoids downstream service errors caused by business logic modifications, such as deviations in calculating car insurance claims or inaccurate predictions of medical risks.

[0029] As a preferred implementation, this method directly extracts historical verification records from the test environment database when acquiring test status data, rather than relying on the identification process of input parameter constraints. This ensures the matching of test data with real business scenarios. At the same time, by introducing behavioral contract objects, the detection process is deepened to the logic execution level, effectively overcoming the shortcomings of existing technologies that only detect interface code and cannot capture internal logic modifications.

[0030] First, by obtaining the interface identifier, the modified interface definition of the interface to be tested is located and obtained in the modified code. This ensures the accuracy of the analysis process for a specific interface and avoids invalid scanning of irrelevant code. Based on the comparison results between the standard interface definition and the modified interface definition corresponding to the interface to be tested, explicit change analysis results are generated. These results quickly capture structural or parameter changes at the interface definition level, but are limited to differences at the interface form level.

[0031] Step S103: Based on the interface identifier, obtain the test status data of the interface to be tested and at least one target behavior contract object related to the interface to be tested, wherein the target behavior contract object includes target test cases and target business rules; In this embodiment, the target behavior contract object includes the target test cases and the target business rules. This ensures that the test data and rules closely match the actual business scenario of the interface, enabling the detection to penetrate to the logic execution level.

[0032] The target test cases include context-aware conditions, which are used to detect the combined conditions of the interface input data and the context of the input data. For example, if the user ID is a positive integer (input data) and the current time is a promotion (context), a special discount logic will be triggered.

[0033] Context-aware conditions are generated by combining the context environment in which the interface runs (including but not limited to dynamic factors such as system status, user identity, business scenario, and time window). These conditions are used to detect both the interface parameters themselves and the context in which they occur. For example, the current time might be a weekday from 9:00 AM to 6:00 PM, the user might be a VIP member, and the system might be running a promotional event. Context-aware conditions adjust as the context changes.

[0034] The target business rule is a combination of predefined rules strongly bound to business logic and expected output. It does not depend on the dynamic context, or only on static business rules. It determines whether the input parameters of the interface satisfy the rules, and whether the interface output meets expectations when the input parameters satisfy the rules. For example, a static business rule might be: when the order amount is ≥100, the discounted amount = amount × 0.9; when the user ID is valid, return status code 200. The determinism of the output data is that the expected output of the above business rule is fixed (or only varies with the input parameters and is independent of the dynamic context).

[0035] For example, when the interface to be tested is an e-commerce order placement interface: The target user test case is as follows: the input condition is that the order amount is ≥100; the context condition is that the current time is a Double 11 promotion day; the business rule is to trigger a Double 11 exclusive discount (amount × 0.8). Expected output: Discounted amount = Amount × 0.8, Status code 200.

[0036] The target user test cases test the combination of input parameters (order amount) and context (promotion day), and whether the output meets the expectations of the "Double 11 scenario".

[0037] The target business rule is: the input condition is that the order amount is ≥100; the business rule is to trigger a discount calculation (amount × 0.9). Expected output: Discounted amount = Amount × 0.9, Status code 200. Detection criteria: Whether the input parameter (order amount) meets the rules, and whether the output meets expectations.

[0038] The target business rule is to check whether the input parameter (order amount) meets the rule and whether the output meets expectations.

[0039] Step S104: Based on the test status data, the target test cases, and the target business rules, perform business logic testing on the interface to be tested to obtain the implicit change analysis results of the interface to be tested.

[0040] In this embodiment, to avoid the lack of a structured mechanism for the substitution and judgment of test status data, thereby avoiding the inability to reliably verify the passability of the test when the data format does not match the requirements of the test cases, as mentioned above; at the same time, it can also avoid the situation where the business rule verification is not associated with the pass conditions of the test status data, which may result in the execution of business logic analysis on invalid test states, causing inaccurate hidden change detection results or omission of key business logic changes.

[0041] Based on test status data, target test cases, and target business rules, business logic testing is performed on the interface to be tested. By substituting test status data into the test cases and evaluating the output in conjunction with business rules, even if the interface definition remains unchanged, deviations in calculation results or behaviors caused by adjustments to business logic can be identified, thereby generating implicit change analysis results.

[0042] For example, in a car insurance claims system, the interface identifier "claim_calculator" is used to obtain the changed interface definition in the modified code; the comparison between the standard interface definition and the changed interface definition generates explicit change analysis results; test status data such as simulated policy numbers and accident liability certificate data are obtained, while the target behavior contract objects include test cases that verify the input format and business rules based on the guidance price of the State Financial Regulatory Commission; by substituting the test status data into the test cases and executing the business rules, implicit change analysis results are generated, effectively detecting modifications to the internal calculation logic. For example, when the vehicle parts-to-whole ratio database is updated, causing adjustments to the parts price calculation logic, even if the API input-output structure remains unchanged, this method can still identify implicit deviations in the calculation of the claim amount.

[0043] Therefore, this method, by integrating explicit change detection with implicit business logic verification, constructs a comprehensive interface change analysis framework, overcoming the limitation of relying solely on interface definition detection to fail to capture internal logic modifications. Specifically, the introduction of a business logic testing phase enables the detection process to delve into the internal execution flow of the interface, effectively identifying output deviations caused by minor adjustments to business rules. This avoids downstream service errors, such as inaccurate calculations of auto insurance claim amounts or inaccurate medical risk predictions, ensuring the comprehensiveness and reliability of interface changes.

[0044] This embodiment provides an interface change detection method based on behavioral contracts. The method obtains the interface identifier of the interface to be verified, and retrieves the modified interface definition corresponding to the interface to be tested from the modified code. Based on the comparison result between the standard interface definition corresponding to the interface to be tested and the modified interface definition, an explicit change analysis result of the interface to be tested is generated. Based on the interface identifier, the test status data of the interface to be tested and at least one target behavioral contract object related to the interface to be tested are obtained, wherein the target behavioral contract object includes target test cases and target business rules. Based on the test status data, the target test cases, and the target business rules, business logic testing is performed on the interface to be tested to obtain an implicit change analysis result of the interface to be tested. This application integrates explicit change analysis with an implicit change testing mechanism based on business logic rules to comprehensively verify the actual impact of interface changes on business behavior, and has the advantages of effectively identifying implicit interface changes and improving the accuracy of business logic verification. Therefore, this application integrates explicit change detection and implicit business logic verification to complete the construction of a comprehensive interface change analysis framework. By generating explicit change analysis results through structured comparison and linking test status data with behavioral contract objects, logic tests are then executed based on business rules. This solves the problem of being unable to detect implicit changes in internal business logic when the interface definition remains unchanged, avoids inaccurate interface change detection caused by business logic modifications, and thus improves the accuracy of interface detection results.

[0045] Reference Figure 2 , Figure 2 A flowchart illustrating another interface change detection method based on behavioral contracts provided in this application.

[0046] like Figure 2 As shown, this application embodiment provides an interface change detection method based on behavioral contracts, wherein step S104 specifically includes: Step S1041: Substitute the test status data into the target test case, determine whether the test status data passes the target test case based on the substitution result, and use the determination result as the first detection result of the target test case; Step S1042: If the test status data passes the target test case, then substitute the input data of the interface to be tested into the target business rule to obtain the current business data, and determine the second detection result of the target business rule based on the comparison result between the preset expected business output and the current business data. Step S1043: Based on the first detection result and the second detection result, generate the latent change analysis result.

[0047] During software system interactions, implicit changes to internal business logic are difficult to identify when the interface definition remains unchanged, leading to deviations in the execution of downstream services. This problem stems from existing detection mechanisms focusing only on formal validation at the interface code level, neglecting dynamic adjustments to business logic, thus continuously impacting system stability and data accuracy.

[0048] For example, in auto insurance claims scenarios, the claims calculation interface receives the policy number and accident liability certificate as input parameters and outputs the claims amount. The internal logic of this interface relies on dynamic data sources such as the State Financial Regulatory Commission's guidance price, vehicle parts-to-whole ratio database, and repair labor cost standards for calculation. When the service provider modifies the price calculation logic for specific vehicle model parts without changing the API definition, the calculation basis of the interface output shifts. Downstream claims approval services, unaware of this implicit change, generate incorrect amounts based on the approval decision.

[0049] To avoid the aforementioned problems, and to prevent implicit changes from causing downstream services to continuously output inaccurate results, which could lead to uncontrollable financial risks in the financial sector and cause treatment recommendations to deviate from actual clinical needs in the medical field, thereby resulting in continuous deterioration of system reliability and irreversible decline in user trust.

[0050] In this embodiment, context-aware conditions represent the state or attributes of the environment in which the interface runs; test state data represents data acquired or set during interface testing to simulate or represent the actual runtime context of the interface. Test state data is dynamic data that changes with the execution environment of each test and represents the specific values ​​assigned to the context-aware conditions during test execution. The test state data is incorporated into the judgment rules of the context-aware conditions to determine whether and how to execute the corresponding core business assertions (i.e., target business rules), thereby ensuring that implicit change detection can cover various complex real-world scenarios.

[0051] Test status data includes environment status data (used to describe the real-time status of the API service deployment environment), business context data (used to represent the business processes or status related to the current request of the interface under test), external dependency status data (used to represent the health status and response characteristics of other services or components that the interface under test depends on), and time and location data.

[0052] Substituting test status data into target test cases refers to inputting the runtime status information of the interface test into a predefined test scenario for verification. This can be achieved using a data adaptation layer or format conversion module to implement field mapping and dimension calibration, aiming to ensure that the test status data meets the input specification requirements of the test cases. If the test status data passes the target test case, it can be understood that the test status data has been verified to meet the execution conditions of the test case. The substitution result can be dynamically evaluated through a logical judgment unit, aiming to establish a reliable judgment mechanism for data validity. Substituting the input data of the interface to be tested into the target business rules refers to applying the interface call parameters to the business logic contract for simulated execution. This can be achieved by dynamically parsing the business logic based on a rule engine or script parsing framework, aiming to accurately reproduce the execution process of the business rules and compare it with the expected output.

[0053] Specifically, the proposed solution implements implicit change detection through a step-by-step triggering test process: Test state data is first substituted into the target test case for format compatibility verification. This step dynamically generates a first detection result based on the substitution result, ensuring that subsequent steps are only allowed when the data dimensions match the test requirements. Under the condition that the test state data passes verification, the input data of the interface to be tested is triggered to execute the target business rules, generating current business data and comparing it with the preset expected business output in multiple dimensions to form a second detection result. Finally, the first and second detection results are comprehensively evaluated through a logical association mechanism to generate implicit change analysis results. This mechanism, through the conditional coupling of data verification and business rule execution, fully covers the entire chain from test state verification to business output verification, avoiding interference from invalid data to business rule analysis.

[0054] As a specific implementation method, the solution of this application is applied to the change detection of the auto insurance claims interface: the interface to be tested is the auto insurance claims calculation interface, and the test status data includes simulated policy numbers and accident liability information; the target test cases predefine the policy number format requirements, and the system substitutes the test status data to determine whether it conforms to the 12-digit number specification. If it passes, the first test result is generated; then the interface input data is substituted into the target business rules (such as the claims calculation logic based on the price of vehicle parts), the business logic is executed to obtain the current claims amount, and the value is compared with the historical benchmark data; based on the comprehensive analysis of the deviation between the test case status and the business data, the system generates implicit change analysis results, effectively identifying the changes in business output caused by the modification of the internal price calculation logic.

[0055] Through the above solution, this application ensures the consistency of the test status data with the test case requirements in terms of format, avoiding test misjudgments caused by data dimension mismatch; at the same time, by limiting the business rule verification to be executed only in a valid test state through a condition triggering mechanism, redundant analysis of invalid scenarios is eliminated, significantly improving the accuracy of implicit change detection, and reliably capturing business logic changes such as minor modifications to the vehicle parts price calculation logic in the auto insurance claims interface.

[0056] In one embodiment, step S1041 specifically includes: Obtain the test conditions in the target test case, and perform field mapping, data cleaning and / or data transformation on the test status data based on the test requirements, so that the format and dimensions of the test status data conform to the test requirements; The processed test state data is substituted into the test conditions, and the first detection result is obtained based on the validity judgment result of the substituted test conditions. The test conditions include at least one of logical expressions, decision trees, or rule sets.

[0057] To further prevent test status data from being directly substituted due to inconsistencies between the original format or dimensions and the test conditions, such as missing fields, data type conflicts, or dimension mismatches, which could lead to test condition judgment failures or misjudgments and thus affect the accuracy of implicit change analysis.

[0058] In this embodiment, the test condition (i.e., context-aware condition) refers to the logical constraint framework in the target test case used to verify the validity of the test state data. It can be implemented by one or more combinations of Boolean logic expressions, multi-level decision tree structures, or predefined rule sets. The purpose is to provide a variety of condition judgment mechanisms to adapt to complex business scenarios. Context-aware rules consist of a condition part (the pattern / threshold to be matched) and a conclusion part (the determination of whether the condition is met). Their structure needs to clearly define the matching logic of the data (such as comparison operations, logical operations, set belonging, etc.).

[0059] By aligning the test status data results with the rule requirements, we ensure that the data format and dimensions of the test status data can be recognized by the rules. Alignment includes field mapping and preprocessing.

[0060] Field mapping refers to the technical operation of establishing a correspondence between source data fields and target fields. It can be implemented by configuring mapping tables or dynamic field matching algorithms, with the aim of solving parsing obstacles caused by differences in field naming or inconsistent structures; for example, associating key fields of test status data (such as temperature, time, and location) with condition fields in rules (such as ambient temperature and current time); Preprocessing includes data cleaning (such as removing outliers) and data transformation (such as time format standardization and numerical unit conversion) to make the data conform to the input requirements of the rules (for example, converting 30℃ to the numerical value 30 and 2 PM to 2 PM).

[0061] Data cleaning refers to the process of quality processing of raw test state data. It can be achieved using techniques such as outlier filtering, missing value imputation, or duplicate data removal, with the aim of improving data integrity and reliability. Data transformation refers to the technical operation of adjusting the data presentation format. It can be achieved using methods such as unit standardization, data type conversion, or dimension normalization, with the aim of ensuring that the data format matches the standard requirements of the test. Test requirements refer to the predefined data specifications on which the test conditions depend. They can be understood as a collection of field types, value ranges, and dimensional structures, with the aim of providing a clear adaptation benchmark for data preprocessing. The first detection result refers to the output of the judgment on whether the test conditions are met or not. It can be expressed as a Boolean value, confidence score, or classification label, with the aim of objectively reflecting the verification status of the test state data through the target test cases.

[0062] Substitute the preprocessed dynamic state data into the condition part of the rule and execute the matching logic: 1. Logical operation matching: If the rule contains logical operators (such as AND / OR / NOT), then each sub-condition is checked in turn to determine whether it is satisfied, and then the overall condition is determined by logical operation (for example, if sub-condition 1 "temperature>30" is true and sub-condition 2 "time∈[12:00,14:00]" is true, then the overall condition is true after AND operation). 2. Pattern matching: If the rule is pattern matching (such as regular expression or behavior sequence), then determine whether the dynamic data conforms to the pattern (for example, whether the user operation sequence "open APP → click button A → swipe screen" conforms to the behavior pattern defined by the rule). 3. Numerical comparison: If the rule is numerical comparison (such as "battery < 20%), then determine whether the value of the dynamic data satisfies the comparison relationship (for example, if the current battery is "15%", then it satisfies "< 20%)).

[0063] Based on the result of rule matching (true / false, satisfied / not satisfied), output the judgment conclusion of the context-aware condition: If the match is successful (all condition items are satisfied, or the triggering logic of the rule is satisfied), then it is determined that "the context-aware condition is satisfied"; If a match fails (either a condition item is not met, or the triggering logic of the rule is not met), then it is determined that "the context-aware condition is not met".

[0064] Specifically, the proposed solution first clarifies the specific requirements of the verification logic by obtaining the test conditions from the target test cases, thereby determining the format and dimensional specifications that the test state data must meet. Based on this, a cascaded process of field mapping, data cleaning, and data transformation is performed on the original test state data according to these test requirements. Field mapping ensures semantic alignment between the source data fields and the test condition fields; data cleaning eliminates data noise to ensure quality; and data transformation adjusts the data presentation to meet the specifications. After the above preprocessing, the format and dimensions of the test state data strictly conform to the test requirements, ensuring that the operation of substituting test conditions accurately reflects the logical relationship between the data and the conditions. Finally, a first detection result is generated based on the validity judgment of the substituted test conditions. This result accurately reflects whether the test state data has passed verification, avoiding the risk of misjudgment caused by data mismatch. This technical solution effectively solves the impact of data format differences on test accuracy by establishing a closed-loop process of data preprocessing and condition verification, ensuring the reliability of implicit change analysis results.

[0065] As a specific implementation method, the solution of this application is implemented as follows: When the test conditions of the target test case require the date field to be in the format of "YYYY-MM-DD" for logical expression judgment, if the original format of the date field in the test status data is "DD / MM / YYYY", the system automatically performs a data conversion operation to standardize the date format to a unified standard. Simultaneously, for the missing "user level" field in the test status data, the corresponding field is extracted from the associated data source and filled in through field mapping. After data cleaning to remove outliers, the processed test status data is substituted into the logical expression test condition containing "user level > 3 and login count ≥ 10". Finally, the first detection result is generated based on whether the expression is true or false. In this embodiment, the test conditions are in the form of logical expressions, the data conversion process involves date format standardization, and the field mapping operation realizes cross-data source field association, ensuring the accuracy of the substitution operation.

[0066] Through the above technical solution, this application effectively solves the problem of test condition judgment failure caused by mismatch in format or dimension of test status data, so that the first detection result can truly reflect the actual situation of the test status data passing the target test case, thereby improving the accuracy of implicit change analysis results and avoiding the risk of misjudgment caused by data adaptation errors.

[0067] Reference Figure 3 , Figure 3 A flowchart illustrating another interface change detection method based on behavioral contracts provided in this application.

[0068] like Figure 3As shown, this application embodiment provides an interface change detection method based on behavioral contracts, wherein step S1042 specifically includes: Step S10421: If the test status data passes the target test case, then execute the business logic rule corresponding to the target business rule on the input data to obtain the current business data; Step S10422: Compare the expected business output predefined in the target business rule with the current business data item by item. The data type of the data comparison includes at least one of numerical calculation results, business status codes, and data formats. Step S10423: Based on the comparison results of each data, generate the second detection result.

[0069] To further prevent insufficient granularity in data comparison from failing to cover multiple data types (such as numerical calculation results, business status codes, and data formats), resulting in low accuracy in detecting implicit changes, it is impossible to effectively identify subtle modifications to the internal business logic of the interface. For example, adjustments to the vehicle parts price calculation logic in the auto insurance claims interface or minor adjustments to gene locus weights in the medical data analysis interface. Although these changes do not alter the interface structure, they may trigger business risks.

[0070] In this embodiment, the business logic rule corresponding to the target business rule refers to the specific implementation mechanism of the business logic, which can be implemented using a rule engine, decision table, or scripted business process, with the aim of accurately simulating the data processing process in real business scenarios; item-by-item data comparison refers to the operation of independently verifying each independent data item of the business output, which can be implemented using field-level comparison algorithms or structured parsers, with the aim of avoiding local deviations caused by overall comparison; data types include at least one of numerical calculation results, business status codes, and data formats, where numerical calculation results can be understood as quantitative indicators generated through arithmetic operations, business status codes can be understood as encoded values ​​that identify the business execution status, and data formats can be understood as the data organization structure specifications, with the aim of covering the multi-dimensional output features that may be affected by changes in business logic; generating a second detection result refers to the judgment process of comprehensively evaluating the verification results of the business rule, which can be implemented using a weighted scoring model or a combination of logic gate circuits, with the aim of providing a reliable basis for judging implicit changes.

[0071] Specifically, the proposed solution first triggers the execution of business logic rules under the condition that the test status data passes the target test cases, ensuring the effectiveness of the test environment and avoiding invalid verification. Then, it generates current business data by executing the business logic rules, directly reflecting the actual impact of interface changes on business output. Next, it employs a multi-dimensional, item-by-item comparison mechanism to independently verify the predefined expected business output against the current business data in terms of numerical calculation results, business status codes, and data formats, covering various manifestations of business logic changes. Finally, it generates a comprehensive second detection result based on the comparison results of each dimension, forming a complete business logic verification closed loop. This sequence of steps, through the organic connection of conditional triggering, precise simulation, multi-dimensional verification, and comprehensive judgment, achieves refined detection of implicit changes.

[0072] As a specific implementation method, the solution of this application is implemented as follows: In the verification scenario of the auto insurance claims interface, after the test status data passes the target test case, the system substitutes the input data such as the policy number and accident liability determination letter into the target business rule, executes the vehicle parts price calculation logic to obtain the current claim amount; then, the predefined expected claim amount is compared with the current claim amount, and the system verifies whether the claim status code conforms to the "0000" success identifier, and checks whether the output data format meets the JSON Schema specification; based on the comparison results of the numerical deviation threshold, status code matching degree, and format compliance, the system generates a second detection result to determine whether there is any hidden change. In this embodiment, the business logic rules are specifically implemented using the Drools rule engine, and the item-by-item data comparison is completed through the field-level validation module. The data types cover the amount value, status code, and structured data format.

[0073] Through the above solution, this application effectively improves the granularity and coverage of implicit change detection, and can accurately identify subtle modifications to the internal business logic of the interface. For example, it can detect adjustments to the calculation logic of vehicle parts prices in the car insurance claims scenario, or capture the fine-tuning of gene locus weights in the medical data analysis scenario, thereby ensuring the accuracy and stability of business output and avoiding business risks caused by implicit changes to the interface.

[0074] In one embodiment, before step S103, the method further includes: Each input parameter of the interface to be tested is identified, and the constraints of each input parameter are determined. The type of the input parameter includes at least one of certificate, floating-point number, string, date and time. The constraints include type constraints, value range constraints, and format constraints. Based on the constraints corresponding to each input parameter and the mapping relationship between each constraint, the corresponding business logic rules and their expected business outputs are matched in the preset business rule base and used as the target business rules.

[0075] In this embodiment, the input parameter constraints (type, value range, format, etc.) of the interface to be tested are first defined to provide legal input conditions for subsequent business logic execution. That is, all input parameters of the interface to be tested are identified (such as user ID, order amount, timestamp, etc.). The constraints for each parameter are then extracted: 1. Type constraints: such as "User ID is an integer" and "Order amount is a floating-point number"; 2. Value range constraints: such as "User ID > 0 (positive integer)" and "Order amount ≥ 0 (non-negative number)"; 3. Format constraints: such as "timestamp conforms to ISO 8601 format" and "mobile phone number is 11 digits".

[0076] 4. Combine constraints to form a set of input conditions (e.g., user ID is a positive integer and order amount is a non-negative number).

[0077] Then, determine the core business logic rules and expected outputs. That is, extract the business logic rules and expected outputs that match the input conditions from the predefined core business assertions (i.e. target business rules) and clarify the expected mapping relationship between input and output.

[0078] Specifically, this is achieved by calling a predefined core business assertion library (which contains mappings of business rules and expected outputs).

[0079] Based on the input conditions, match the corresponding business logic rules in the assertion library (such as "when the user ID is valid (positive integer) and the order amount is ≥100, trigger the discount calculation logic").

[0080] Then, extract the expected business output from the matched assertions: 1. Data output: e.g., "Discounted amount = Order amount × 0.9"; 2. Status output: such as "Return status code is 200"; 3. Formatted output: such as "The returned data includes the discountAmount and statusCode fields".

[0081] Finally, the business logic is executed and the output is compared. That is, the business logic is executed with the input data, and the actual output is compared with the expected output to verify the consistency of the business logic.

[0082] Specifically, executing business logic involves taking input data as parameters, substituting it into business logic rules, and generating actual business output (including data, status, format, etc.).

[0083] The process involves comparing the outputs, specifically comparing the actual output with the expected output item by item (such as numerical calculations, status codes, field formats, etc.). A verification result is then generated, outputting a Boolean verification result based on the comparison results (true if they match, false if they don't).

[0084] In one embodiment, in order to further prevent the target business rules from failing to accurately match the specific type and constraints of the input parameters, resulting in unreliable business logic test results and the inability to effectively identify implicit changes in the business logic within the interface.

[0085] Identifying the input parameters of the interface to be tested refers to parsing the interface definition file to extract parameter information. This can be achieved using static code analysis tools or interface description specification parsers, with the aim of accurately capturing the business semantics of the parameters. The input parameter types include at least one of certificates, floating-point numbers, strings, and date / time, referring to the parameter data type classification system. This can be defined based on programming language type systems or interface specification standards, with the aim of distinguishing parameter processing logic under different business scenarios. Specifically, constraints include type constraints, value range constraints, and format constraints, which are sets of rules restricting parameter values. These can be implemented using regular expressions to define format constraints, numerical ranges to define value range constraints, or enumerated values ​​to define type constraints, with the aim of precisely limiting the valid value range of the parameters. Further, matching the corresponding business logic rules in a pre-set business rule base based on the constraints corresponding to each input parameter and the mapping relationship between the constraints refers to the process of retrieving associated rules based on constraint characteristics. This can be achieved using the condition matching mechanism of a rule engine or database index query technology, with the aim of ensuring the relevance and accuracy of rule selection.

[0086] Specifically, the proposed solution first performs structured parsing of the input parameters of the interface to be tested, determining the type attributes and constraint boundaries of each parameter, thereby establishing a mapping relationship between the parameters and the business scenario. Subsequently, the constraints are input into a preset business rule base as retrieval conditions. Through the synergistic effect of the constraints and the mapping relationship, business logic rules that highly match the current input parameters are dynamically selected. This process avoids the blindness of general rule matching. For example, when the input parameter meets a specific value range, the corresponding calculation logic branch is automatically associated, rather than using default rules. Finally, the matched business logic rules are directly applied as target business rules to implicit change analysis, ensuring that the testing process strictly follows the parameter constraints and forming a closed-loop verification mechanism from parameter identification to rule matching.

[0087] As a specific implementation method, the solution of this application is implemented as follows: In the verification scenario of the auto insurance claims interface, the system identifies input parameters including the policy number (string type, format constraint is "POL-" prefix plus 8 digits) and the accident date (date and time type, value range constraint is within the last 365 days); based on the parameter type and constraints, the system matches the claims calculation rules for specific vehicle models in the preset business rule library. For example, when the vehicle model parameter is SUV, it automatically associates the business rules containing off-road vehicle parts price calculation logic, rather than the general sedan calculation rules; this matching process is implemented through the condition tree of the rule engine, where the format constraints are mapped to the regular expression validator, the value range constraints trigger the numerical interval comparison module, and finally outputs the business logic rules that completely match the input parameter constraints for subsequent testing.

[0088] Through the above scheme, this application ensures the precise matching of target business rules and input parameters, enabling business logic testing to accurately reflect subtle changes in the internal rules of the interface, effectively identifying implicit changes caused by business logic modifications, avoiding detection blind spots caused by mismatch between rules and parameter constraints, and thus improving the reliability of interface change detection.

[0089] In one embodiment, step S10423 specifically includes: Based on the service output metrics of the interface to be tested, the target historical behavior baseline corresponding to the interface to be tested is determined from the pre-constructed historical behavior baselines. The current business data is compared with the target historical behavior baseline to calculate the behavior deviation of the current business data; The second detection result is generated based on the comparison results of various data and the deviation of the behavior.

[0090] To further prevent the ineffective identification of subtle changes in business logic by relying solely on data comparison, especially when implicit changes in the internal business logic of an interface cause the overall behavior pattern of business data to deviate from its historical normal trajectory, simple data comparison may miss such changes. For example, in a car insurance claims interface, if a minor adjustment to the internal calculation logic causes a change in the trend of claims amount distribution, but individual data points still meet the expected range, or in a medical data analysis interface, adjustments to model weights cause a shift in the risk level output pattern, but the structure remains unchanged, this can lead to inaccurate detection of implicit changes.

[0091] In this embodiment, business output metrics refer to the core business dimension data of the interface to be tested. These metrics can be implemented using specific business indicators such as claim amount, risk level, or transaction status. The purpose is to closely link the business function essence of the interface and avoid the generalization problem of general benchmarks. Historical behavior baselines refer to the reference benchmarks of historical normal behavior patterns. These can be implemented based on statistical distributions constructed from historical test data, production environment data, or simulated data. The purpose is to provide a business-specific comparison basis. Behavioral deviation refers to quantifying the overall degree of deviation of current business data from historical normal patterns. This can be achieved by calculating statistical methods such as standard deviation, Mahalanobis distance, or distribution similarity. The purpose is to capture gradual changes in business logic rather than focusing only on single-point data matching. Generating a second detection result refers to comprehensively evaluating the data comparison results and behavioral deviation to determine the state of implicit changes. This can be achieved through weighted scoring, threshold judgment, or machine learning models. The purpose is to distinguish between real business logic changes and accidental fluctuations.

[0092] Specifically, the proposed solution first determines the target historical behavior baseline based on the business output metrics of the interface to be detected, ensuring consistency between the reference benchmark and the core business dimensions. Then, it compares the current business data with the target historical behavior baseline to calculate the behavioral deviation, quantifying the systematic deviation of the overall behavioral pattern. Finally, it integrates the comparison results of each data point with the behavioral deviation to generate a second detection result. This approach retains the ability of data comparison to quickly verify explicit errors while using behavioral deviation to weightedly evaluate implicit pattern changes, thus forming a complete technical logic chain. By introducing behavioral deviation, this solution effectively compensates for the limitations of simple data comparison in detecting subtle changes in business logic, enabling the identification of implicit changes to be sensitive to overall behavioral trends.

[0093] As a preferred embodiment, the solution of this application is implemented as follows: In the detection scenario of the auto insurance claims interface, the business output indicator is the claims amount; the target historical behavior baseline is constructed based on the distribution characteristics of historical claims amounts; the current claims amount data is compared with the target historical behavior baseline to calculate the behavior deviation; when the data comparison result is normal but the behavior deviation exceeds a preset threshold, a second detection result is generated to indicate the existence of a hidden change. In practical applications, this behavior deviation is specifically achieved by calculating the Kullback-Leibler divergence between the current claims amount distribution and the historical baseline distribution, the purpose of which is to quantify the overall degree of shift in the distribution pattern.

[0094] Through the above solution, this application can effectively identify subtle changes in the internal business logic of the interface. For example, it can capture the systematic shift in the distribution trend of claim amount in the auto insurance claim interface, or detect the abnormal shift in the risk level output mode in the medical data analysis interface, thereby avoiding the omission of business risks caused by implicit changes and significantly improving the accuracy and robustness of interface change detection.

[0095] In one embodiment, before determining the target historical behavior baseline corresponding to the interface to be detected from among the pre-built historical behavior baselines based on the service output metrics of the interface to be detected, the method further includes: Collect historical behavior data of the interface to be tested in the test environment or production environment, which has passed each verification, as a historical behavior dataset; Based on the historical behavior dataset and the preset statistical model, at least one historical behavior baseline is established for at least one business output indicator of the interface to be detected.

[0096] In this embodiment, in order to prevent the lack of a clear method for constructing historical behavior baselines, which may cause the baselines to not reflect the real business behavior patterns, for example, relying only on preset but undefined baseline data sources, it is impossible to ensure that the baseline covers the normal fluctuation range of the interface in actual operation, thereby causing distortion in the behavior deviation calculation and ultimately affecting the reliability of the implicit change analysis results.

[0097] Historical behavior datasets refer to historical behavior data collected from testing or production environments that have passed previous verifications. These datasets can be implemented using distributed databases or object storage systems. Their purpose is to ensure that data sources cover pre-release verification and real-world business scenarios, eliminating interference from abnormal calls. Pre-defined statistical models can be understood as mathematical tools used to quantify the fluctuation patterns of business outputs. Specifically, they can be implemented using time series analysis models or probability distribution fitting models. Their purpose is to extract statistical characteristics of normal business behavior from historical data. Business output indicators refer to the output parameters of the interface to be tested, such as claim amounts or risk levels. These can include numerical or categorical indicators, and their purpose is to provide clear quantitative objects for baseline construction.

[0098] Specifically, the solution in this application first collects historical behavior data from the testing and production environments to form a historical behavior dataset. This dataset only contains valid behavior records of the interface under stable business logic conditions, thus ensuring the comprehensiveness and reliability of the data. Based on this, a preset statistical model is used to analyze the historical behavior dataset, extract the normal fluctuation range for each business output indicator, and establish a historical behavior baseline. This baseline can dynamically adapt to the historical evolution of business logic rather than relying on static preset values. Finally, the established historical behavior baseline is used for subsequent behavior deviation calculation. By comparing the current business data with the baseline, data anomalies caused by implicit changes in business logic are accurately identified, thereby supporting the reliability of the implicit change analysis results.

[0099] As a specific implementation method, the solution of this application is implemented as follows: In the scenario of the auto insurance claims interface, the claims amount data that have been verified and passed by the interface in the test environment and production environment are collected as historical behavior datasets; based on the dataset, a time series model is used to establish a historical behavior baseline for the claims amount. This baseline reflects the fluctuation range of the claims amount under normal business logic. For example, the mean and standard deviation range of the claims amount are determined by analyzing historical data; in the subsequent implicit change analysis, the current claims calculation result is compared with the baseline. If the deviation exceeds the threshold, an implicit change alarm is triggered.

[0100] Through the above scheme, this application ensures that the historical behavior baseline can accurately reflect the real business behavior pattern and cover the normal fluctuation range of the interface in actual operation, thereby avoiding the distortion of behavior deviation calculation and effectively improving the reliability of implicit change analysis results.

[0101] Please see Figure 4 , Figure 4 This is a schematic diagram of the functional modules of an interface change detection device based on behavioral contracts provided in this application.

[0102] like Figure 4 As shown, the interface change detection device 400 based on behavior contracts includes: The interface definition acquisition module 410 is used to acquire the interface identifier of the interface to be verified and to acquire the modified interface definition corresponding to the interface to be tested in the modified code. The interface explicit detection module 420 is used to generate explicit change analysis results for the interface to be detected based on the comparison results between the standard interface definition corresponding to the interface to be detected and the changed interface definition. The behavior contract acquisition module 430 is used to acquire the test status data of the interface to be tested and at least one target behavior contract object related to the interface to be tested based on the interface identifier, wherein the target behavior contract object includes target test cases and target business rules. The interface implicit detection module 440 is used to perform business logic testing on the interface to be detected based on the test status data, the target test cases and the target business rules, and obtain the implicit change analysis results of the interface to be detected.

[0103] Furthermore, the interface implicit detection module 440 includes: The test case substitution unit is used to substitute the test status data into the target test case, determine whether the test status data passes the target test case based on the substitution result, and use the determination result as the first detection result of the target test case. The business logic substitution unit is used to substitute the input data of the interface to be tested into the target business rule if the test status data passes the target test case, to obtain the current business data, and to determine the second detection result of the target business rule based on the comparison result between the preset expected business output and the current business data. An interface implicit detection unit is used to generate the implicit change analysis result based on the first detection result and the second detection result.

[0104] Furthermore, the test case substitution unit is also used for: Obtain the test conditions in the target test case, and perform field mapping, data cleaning and / or data transformation on the test status data based on the test requirements, so that the format and dimensions of the test status data conform to the test requirements; The processed test state data is substituted into the test conditions, and the first detection result is obtained based on the validity judgment result of the substituted test conditions. The test conditions include at least one of logical expressions, decision trees, or rule sets.

[0105] Furthermore, the business logic substitution unit is also used for: If the test status data passes the target test case, then the business logic rule corresponding to the target business rule is executed on the input data to obtain the current business data; The expected business output predefined in the target business rule is compared item by item with the current business data. The data type of the data comparison includes at least one of numerical calculation results, business status codes, and data formats. The second detection result is generated based on the comparison results of various data.

[0106] Furthermore, the interface change detection device based on behavioral contracts also includes: The input parameter recognition module is used to recognize each input parameter of the interface to be detected and determine the constraints of each input parameter. The type of the input parameter includes at least one of certificate, floating point number, string, date and time, and the constraints include type constraints, value range constraints and format constraints. The target rule generation module is used to match the corresponding business logic rules and their expected business outputs in a preset business rule library based on the constraints corresponding to each input parameter and the mapping relationship between each constraint, and to use them as the target business rules.

[0107] Furthermore, the business logic substitution unit is also used for: Based on the service output metrics of the interface to be tested, the target historical behavior baseline corresponding to the interface to be tested is determined from the pre-constructed historical behavior baselines. The current business data is compared with the target historical behavior baseline to calculate the behavior deviation of the current business data; The second detection result is generated based on the comparison results of various data and the deviation of the behavior.

[0108] Furthermore, the interface change detection device based on behavior contracts also includes a behavior baseline construction module, used for: Collect historical behavior data of the interface to be tested in the test environment or production environment, which has passed each verification, as a historical behavior dataset; Based on the historical behavior dataset and the preset statistical model, at least one historical behavior baseline is established for at least one business output indicator of the interface to be detected.

[0109] It should be noted that those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the above-described apparatus and modules can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0110] The aforementioned device can be implemented as a computer program, which can be used in, for example... Figure 5 It runs on the computer device shown.

[0111] Please see Figure 5 , Figure 5 This application provides a schematic block diagram of the structure of a computer device. The computer device may be a server.

[0112] See Figure 5The computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0113] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any behavior-contract-based interface change detection method.

[0114] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0115] Internal memory provides an environment for the execution of computer programs in non-volatile storage media. When the computer program is executed by the processor, it enables the processor to execute any interface change detection method based on behavioral contracts.

[0116] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0117] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0118] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Obtain the interface identifier of the interface to be verified, and obtain the modified interface definition corresponding to the interface to be tested in the modified code; Based on the comparison results between the standard interface definition corresponding to the interface to be tested and the modified interface definition, the explicit change analysis results of the interface to be tested are generated. Based on the interface identifier, obtain the test status data of the interface to be tested and at least one target behavior contract object related to the interface to be tested, wherein the target behavior contract object includes target test cases and target business rules; Based on the test status data, the target test cases, and the target business rules, business logic testing is performed on the interface to be tested to obtain the implicit change analysis results of the interface to be tested.

[0119] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Substitute the test status data into the target test case, determine whether the test status data passes the target test case based on the substitution result, and use the determination result as the first detection result of the target test case. If the test status data passes the target test case, the input data of the interface to be tested is substituted into the target business rule to obtain the current business data, and the second detection result of the target business rule is determined based on the comparison result between the preset expected business output and the current business data. Based on the first detection result and the second detection result, the hidden change analysis result is generated.

[0120] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Obtain the test conditions in the target test case, and perform field mapping, data cleaning and / or data transformation on the test status data based on the test requirements, so that the format and dimensions of the test status data conform to the test requirements; The processed test state data is substituted into the test conditions, and the first detection result is obtained based on the validity judgment result of the substituted test conditions. The test conditions include at least one of logical expressions, decision trees, or rule sets.

[0121] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: If the test status data passes the target test case, then the business logic rule corresponding to the target business rule is executed on the input data to obtain the current business data; The expected business output predefined in the target business rule is compared item by item with the current business data. The data type of the data comparison includes at least one of numerical calculation results, business status codes, and data formats. The second detection result is generated based on the comparison results of various data.

[0122] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Each input parameter of the interface to be tested is identified, and the constraints of each input parameter are determined. The type of the input parameter includes at least one of certificate, floating-point number, string, date and time. The constraints include type constraints, value range constraints, and format constraints. Based on the constraints corresponding to each input parameter and the mapping relationship between each constraint, the corresponding business logic rules and their expected business outputs are matched in the preset business rule base and used as the target business rules.

[0123] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Based on the service output metrics of the interface to be tested, the target historical behavior baseline corresponding to the interface to be tested is determined from the pre-constructed historical behavior baselines. The current business data is compared with the target historical behavior baseline to calculate the behavior deviation of the current business data; The second detection result is generated based on the comparison results of various data and the deviation of the behavior.

[0124] In one embodiment, the processor is configured to run a computer program stored in memory to perform the following steps: Collect historical behavior data of the interface to be tested in the test environment or production environment, which has passed each verification, as a historical behavior dataset; Based on the historical behavior dataset and the preset statistical model, at least one historical behavior baseline is established for at least one business output indicator of the interface to be detected.

[0125] The embodiments of this application also provide a computer-readable storage medium storing a computer program, the computer program including program instructions, and the processor executing the program instructions to implement any of the interface change detection methods based on behavioral contracts provided in the embodiments of this application.

[0126] The computer-readable storage medium may be an internal storage unit of the computer device described in the foregoing embodiments, such as the hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, SmartMedia Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the computer device.

[0127] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for detecting interface changes based on behavioral contracts, characterized in that, The interface change detection method includes the following steps: Obtain the interface identifier of the interface to be verified, and obtain the modified interface definition corresponding to the interface to be tested in the modified code; Based on the comparison results between the standard interface definition corresponding to the interface to be tested and the modified interface definition, the explicit change analysis results of the interface to be tested are generated. Based on the interface identifier, obtain the test status data of the interface to be tested and at least one target behavior contract object related to the interface to be tested, wherein the target behavior contract object includes target test cases and target business rules; Based on the test status data, the target test cases, and the target business rules, business logic testing is performed on the interface to be tested to obtain the implicit change analysis results of the interface to be tested.

2. The interface change detection method as described in claim 1, characterized in that, Based on the test status data, the target test cases, and the target business rules, business logic testing is performed on the interface to be tested to obtain the implicit change analysis results of the interface to be tested, including: Substitute the test status data into the target test case, determine whether the test status data passes the target test case based on the substitution result, and use the determination result as the first detection result of the target test case. If the test status data passes the target test case, the input data of the interface to be tested is substituted into the target business rule to obtain the current business data, and the second detection result of the target business rule is determined based on the comparison result between the preset expected business output and the current business data. Based on the first detection result and the second detection result, the hidden change analysis result is generated.

3. The interface change detection method as described in claim 2, characterized in that, The step of substituting the test status data into the target test case, determining whether the test status data passes the target test case based on the substitution result, and using the determination result as the first detection result of the target test case includes: Obtain the test conditions in the target test case, and perform field mapping, data cleaning and / or data transformation on the test status data based on the test requirements, so that the format and dimensions of the test status data conform to the test requirements; The processed test state data is substituted into the test conditions, and the first detection result is obtained based on the validity judgment result of the substituted test conditions. The test conditions include at least one of logical expressions, decision trees, or rule sets.

4. The interface change detection method as described in claim 2, characterized in that, If the test status data passes the target test case, the input data of the interface to be tested is substituted into the target business rule to obtain the current business data. Based on the comparison result between the preset expected business output and the current business data, the second detection result of the target business rule is determined, including: If the test status data passes the target test case, then the business logic rule corresponding to the target business rule is executed on the input data to obtain the current business data; The expected business output predefined in the target business rule is compared item by item with the current business data. The data type of the data comparison includes at least one of numerical calculation results, business status codes, and data formats. The second detection result is generated based on the comparison results of various data.

5. The interface change detection method as described in claim 4, characterized in that, Based on the interface identifier, the step of obtaining the test status data of the interface to be tested and at least one target behavior contract object related to the interface to be tested, wherein the target behavior contract object includes target test cases and target business rules, further includes: Each input parameter of the interface to be tested is identified, and the constraints of each input parameter are determined. The type of the input parameter includes at least one of certificate, floating-point number, string, date and time. The constraints include type constraints, value range constraints, and format constraints. Based on the constraints corresponding to each input parameter and the mapping relationship between each constraint, the corresponding business logic rules and their expected business outputs are matched in the preset business rule base and used as the target business rules.

6. The interface change detection method as described in any one of claims 2-4, characterized in that, The generation of the second detection result based on the comparison results of various data includes: Based on the service output metrics of the interface to be tested, the target historical behavior baseline corresponding to the interface to be tested is determined from the pre-constructed historical behavior baselines. The current business data is compared with the target historical behavior baseline to calculate the behavior deviation of the current business data; The second detection result is generated based on the comparison results of various data and the deviation of the behavior.

7. The interface change detection method as described in claim 6, characterized in that, Before determining the target historical behavior baseline corresponding to the interface to be detected from the pre-built historical behavior baselines based on the service output metrics of the interface to be detected, the method further includes: Collect historical behavior data of the interface to be tested in the test environment or production environment, which has passed each verification, as a historical behavior dataset; Based on the historical behavior dataset and the preset statistical model, at least one historical behavior baseline is established for at least one business output indicator of the interface to be detected.

8. An interface change detection device based on behavioral contracts, characterized in that, The interface change detection device includes: The interface definition acquisition module is used to obtain the interface identifier of the interface to be verified and to obtain the modified interface definition corresponding to the interface to be tested in the modified code. The interface explicit detection module is used to generate explicit change analysis results for the interface to be detected based on the comparison results between the standard interface definition corresponding to the interface to be detected and the changed interface definition. The behavior contract acquisition module is used to acquire the test status data of the interface to be tested and at least one target behavior contract object related to the interface to be tested based on the interface identifier, wherein the target behavior contract object includes target test cases and target business rules; The interface implicit detection module is used to perform business logic testing on the interface to be tested based on the test status data, the target test cases, and the target business rules, and obtain the implicit change analysis results of the interface to be tested.

9. A computer device, characterized in that, The computer device includes a processor, a memory, and a behavior contract-based interface change detection program stored in the memory and executable by the processor, wherein when the behavior contract-based interface change detection program is executed by the processor, it implements the steps of the behavior contract-based interface change detection method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores an interface change detection program based on behavior contracts, wherein when the interface change detection program based on behavior contracts is executed by a processor, it implements the steps of the interface change detection method based on behavior contracts as described in any one of claims 1 to 7.

Images