Interface assertion method, system, terminal and storage medium

Abstract

The application relates to the technical field of automatic testing, and discloses an interface assertion method, a system, a terminal and a storage medium. The method comprises the following steps: when an automatic testing process corresponding to a target business scenario is executed for the first time, if it is detected that a target interface call return state is consistent with an expectation, valid data returned from the target interface is acquired as expected response data; based on a preset business process association rule, corresponding data records are extracted from a plurality of database tables related to the target business scenario as expected business data; the expected response data and the expected business data are integrated into an expected data set, and after the expected data set is associated with a use case identifier, the expected data set is stored in an expected value database to form a data snapshot; when a testing process of a same business scenario as the target business scenario is executed subsequently, actual response data and actual business data are acquired, and the actual response data and the actual business data are compared with corresponding data snapshots in the expected value database to generate an interface automatic assertion result.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of automated testing, in particular to an interface assertion method and system, a terminal and a storage medium. BACKGROUND

[0002] In the current field of interface automated testing, the mainstream assertion methods mainly include two kinds: one is to pre-write expected JSON data based on the interface return result, and to complete the assertion by comparing the fields with the actual response; the second is to query the specific fields of the specific table in the database after the interface is called, and to simply match them with the interface return data to verify the data consistency.

[0003] However, the above methods have significant defects. First, the expected data maintenance cost is high: when the interface return structure or the database table structure changes, the tester needs to manually update a large number of JSON files or SQL statements, the process is tedious and prone to errors, which leads to the risk of assertion failure. Second, the assertion coverage is limited: usually only the key fields of the interface or a few main table data are checked, it is difficult to cover the complete business link involving multi-table linkage, such as account table, loan table, transaction detail table and repayment plan table in the loan process, and it is easy to miss the cross-table data inconsistency problem. In addition, the development threshold of automated use cases is high, which requires testers to have comprehensive abilities such as programming, interface protocol, JSON parsing and SQL writing, which restricts the popularization and efficiency improvement of automated testing. SUMMARY

[0004] Therefore, the embodiments of the present application provide an interface assertion method, system, terminal and storage medium.

[0005] In a first aspect, the embodiments of the present application provide an interface assertion method, comprising:

[0006] When the automated testing process corresponding to the target business scenario is executed for the first time, if it is detected that the target interface call return state meets the expectation, the valid data from the data returned by the target interface is obtained as the expected response data;

[0007] Based on a preset business process association rule, corresponding data records are extracted from at least two database tables related to the target business scenario as expected business data;

[0008] The expected response data and the expected business data are integrated into an expected data set, and after being associated with a use case identifier, they are stored in an expected value database to form a data snapshot of the target business scenario;

[0009] In subsequent execution of a test procedure of the same business scenario as the target business scenario, actual response data and actual business data are acquired, and the actual response data and the actual business data are compared with corresponding data snapshots in the expectation database to generate interface automation assertion results.

[0010] In an optional implementation, the extraction of corresponding expected business data from at least two database tables related to the target business scenario based on the preset business procedure association rule comprises:

[0011] The business procedure association rule corresponding to the target business scenario is loaded, wherein the business procedure association rule comprises table identifiers of all database tables related to the target business scenario, expected value query statements for acquiring data, and parameter source paths for determining query parameters;

[0012] According to the parameter source path, the query parameters are parsed from the response data of the target interface;

[0013] Based on the table identifiers, the corresponding database tables are determined, and the corresponding query parameters are filled into the expected value query statements of the corresponding database tables to generate executable query commands;

[0014] The executable query commands are executed to acquire data records in the corresponding database tables, and the corresponding expected business data are generated according to the data records of each database table.

[0015] In an optional implementation, each business scenario corresponds to a unique use case identifier;

[0016] Before the integration of the expected response data and the expected business data into an expected data set, the association with the use case identifier, and the storage into an expectation database, the method further comprises:

[0017] Based on the use case identifier, the expectation database is queried, and if the data snapshot associated with the current use case identifier exists, the historically stored data snapshot is deleted.

[0018] In an optional implementation, the acquisition of actual response data and actual business data, the comparison with corresponding data snapshots in the expectation database, and the generation of interface automation assertion results based on the comparison results comprise:

[0019] An actual value query statement configured in pairs with the expected value query statement is called to acquire the actual response data and the actual business data from a business database; wherein the actual value query statement and the expected value query statement have the same query structure and parameter mapping mode;

[0020] performing a field-level consistency comparison between the actual response data and the actual business data and the corresponding expected response data and the expected business data;

[0021] if all non-dynamic fields are matched, outputting an assertion pass result, otherwise generating an assertion failure report containing difference information.

[0022] In an optional embodiment, after the target interface changes or the database table structure changes, the same use case identification corresponding automation test process is re-executed to obtain updated expected response data and expected business data;

[0023] based on the current use case identification, the corresponding expected data set is cleared, and the data snapshot is updated based on the updated expected response data and expected business data.

[0024] In an optional embodiment, the automation test process is implemented based on a modular script framework, and when a new test case is added, the new test case is added by configuring a use case identification, referencing a pre-configured interface calling method, and filling in the expected value query statement template and the actual value query statement template.

[0025] In an optional embodiment, the table structure of the database table in the expected value database only has one column of use case identification field more than the table structure of the database in the business database.

[0026] In a second aspect, the embodiments of the present application provide an interface assertion system, comprising:

[0027] an interface calling module, configured to, when a target business scenario corresponding automation test process is executed for the first time, if it is detected that the target interface calling return state meets the expectation, obtain valid data returned from the target interface as expected response data;

[0028] a data collection module, configured to, based on a preset business process association rule, extract corresponding data records from at least two database tables related to the target business scenario as expected business data;

[0029] an expected value management module, configured to integrate the expected response data and the expected business data into an expected data set, and after associating with a use case identification, store it into an expected value database to form a data snapshot of the target business scenario.

[0030] A comparison execution module is configured to, when a test flow of a same business scenario as the target business scenario is executed subsequently, acquire actual response data and actual business data, and compare the actual response data and the actual business data with corresponding data snapshots in the expected value database to generate an interface automatic assertion result.

[0031] In a third aspect, an embodiment of the present application provides a terminal device, which comprises a processor and a memory, the memory stores a computer program, and the processor is configured to execute the computer program to implement the interface assertion method described above.

[0032] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program, when executed on a processor, implements the interface assertion method described above.

[0033] The embodiments of the present application have the following beneficial effects: the present application automatically collects expected response data of a target interface when it is executed for the first time, extracts expected business data in multiple related database tables based on a business flow association rule, integrates the two into a data snapshot associated with a use case identifier, and stores the data snapshot into an independent expected value database to form complete baseline data. In subsequent testing, actual execution results of the same scenario are compared with the data snapshot to verify the consistency of interface return and underlying data state. This method effectively overcomes the high cost and error-prone problems caused by the traditional assertion relying on manual maintenance of expected data, improves the automation degree and data coverage integrity of the assertion process, and enhances the accuracy, reliability and maintainability of interface automatic testing. BRIEF DESCRIPTION OF DRAWINGS

[0034] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor.

[0035] Figure 1 A first flowchart of the interface assertion method of the embodiments of the present application is shown;

[0036] Figure 2 A second flowchart of the interface assertion method of the embodiments of the present application is shown;

[0037] Figure 3 A third flowchart of the interface assertion method of the embodiments of the present application is shown;

[0038] Figure 4Fig. 1 shows a schematic diagram of an interface assertion system according to an embodiment of the present application. DETAILED DESCRIPTION

[0039] The technical solutions in the embodiments of the present application will be clearly and completely described with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments of the present application.

[0040] The components of the embodiments of the present application generally described and illustrated in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of the present application.

[0041] Hereinafter, the terms "include", "have", and their conjugates used in various embodiments of the present application are only intended to denote a certain characteristic, number, step, operation, element, component, or a combination thereof, and should not be construed as excluding the presence or addition of one or more other characteristics, numbers, steps, operations, elements, components, or combinations thereof. In addition, the terms "desirable", "actual", "third", and the like are only used to distinguish the description, and cannot be understood as indicating or implying relative importance.

[0042] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which various embodiments of the present application belong. The terms (such as those defined in commonly used dictionaries) will be interpreted as having a meaning that is the same as the contextual meaning in the relevant technical field and will not be interpreted in an idealized or overly formal sense, unless clearly defined in various embodiments of the present application.

[0043] Some embodiments of the present application will be described in detail below with reference to the accompanying drawings. The following embodiments and features in the embodiments can be combined with each other without conflict.

[0044] The interface assertion method will be described below in conjunction with some specific embodiments.

[0045] Figure 1 Fig. 1 shows a schematic diagram of an interface assertion system according to an embodiment of the present application.

[0046] Step S110, when the automatic test process corresponding to the target business scenario is first performed, if it is detected that the return state of the target interface call conforms to the expectation, the valid data from the data returned by the target interface is acquired as the expected response data.

[0047] This step is used to construct the initial baseline data of the interface automation assertion, which is the first step of generating the expected data set. When a certain test scenario is first executed, the system collects representative valid business data as the benchmark for subsequent comparison by calling the target interface and verifying its response result.

[0048] Exemplarily, when the automatic test process corresponding to a certain target business scenario is first performed, the system first triggers the calling operation of the target interface. The target interface is pre-configured according to specific business needs, and may involve a single or multiple service interfaces, and its calling mode and request parameters have been predefined in the automatic test framework.

[0049] After the interface call is completed, the system receives the return data from the target interface, and judges the state of the return data to determine whether the preset expected condition is met. Among them, the return state conforms to the expectation, which includes double verification of the communication level and the business logic level of the interface. The communication level verification is based on the HTTP protocol status code, and when the status code is 200, it means that the request has been successfully processed. The business level verification is achieved by analyzing the key state field in the interface return body, such as whether the value of the flag field is S, or whether the code field is "0000" and other success identifiers. Only when the communication state and the business state are both determined to be successful, the system continues to perform the subsequent data collection action.

[0050] When it is confirmed that the return state of the target interface call conforms to the expectation, the system extracts the valid data from the data returned by the interface as the expected response data. In this embodiment, the valid data is all the contents contained in the data field of the interface return JSON structure; the system extracts its value through the preset path parsing rule as the main output result generated by this interface call, which has a clear business meaning and is an important basis for subsequent assertion comparison.

[0051] It should be noted that this step is only performed to collect the expected response data when the automatic test process corresponding to the business scenario is first performed. The valid data obtained will be part of the baseline data, and after being integrated with other associated business data, it is stored in the expected value database to form a data snapshot of the test scenario. In the subsequent repeated execution of the test process of the same business scenario, the system no longer performs the data collection operation of this step, but directly enters the comparison stage and uses the stored expected data for verification.

[0052] By this way of the embodiment, automatic capture of expected response data can be realized, avoiding high cost and error-prone problems caused by manual writing and maintenance of corresponding expected results in traditional ways, and thus improving maintainability and reliability of automatic testing.

[0053] In step S120, corresponding data records are extracted from at least two database tables related to the target business scenario as expected business data based on preset business process association rules.

[0054] After the target interface call is completed and it is confirmed that the return state thereof meets the expectation, the system enters an expected data collection phase at a database level. This step aims to obtain database records corresponding to a plurality of business entities associated with the interface call, so as to build a complete data baseline covering the whole-link business process. Traditional interface assertion methods usually only verify a single master table or a few fields, and it is difficult to find data logic abnormalities between cross-tables; and the embodiment introduces preset business process association rules, realizes automatic and batch data extraction of a plurality of database tables, and thus can improve data coverage and defect detection capability of assertion.

[0055] In some embodiments, as shown in FIG. 2, step S120 includes steps S210-S240. Figure 2

[0056] In step S210, the business process association rules corresponding to the target business scenario are loaded.

[0057] The business process association rules include table identifiers of all database tables related to the target business scenario, expected value query statements for obtaining data, and parameter source paths for determining query parameters.

[0058] Exemplarily, before starting data collection, the system first loads the preconfigured business process association rules bound to the target business scenario being executed. The rule set is a set of structured configuration information defined in the test case initialization phase, and is used to guide the system to extract all data records related to the interface call from the business database.

[0059] ​The business process association rules include but are not limited to table identifier, expected value query statement and parameter source path. The table identifier is used to uniquely identify each database table that needs to participate in comparison, for example, "t_loan_info" represents a loan information table, "t_repayment_plan" represents a repayment plan table, "t_transaction_detail" represents a transaction detail table, etc. The expected value query statement is a SQL query statement template set for each table, which is used to retrieve the data rows in the table related to the current business operation; the parameter source path is used to specify how to extract the parameter values required by the above query from the response data of the target interface, which is implemented by using a standard path expression syntax.

[0060] The rule set can be stored in the configuration file of the test engineering in JSON, YAML or XML format, or can be centrally managed in the configuration table in the database. When the system identifies that the current execution is the "user loan lending" target business scenario, it will automatically load all the rule entries corresponding to this scenario to provide metadata support for subsequent multi-table data extraction.

[0061] In step S220, the query parameters are parsed from the response data of the target interface according to the parameter source path.

[0062] After successfully loading the business process association rules, the system iterates through each rule in the rules one by one, and extracts the corresponding query parameter values from the target interface response data obtained in step S110 according to the parameter source path specified by the rule.

[0063] The system has a built-in general data structure parsing engine that can select the appropriate parsing strategy according to the expression type in the parameter source path. For mainstream JSON format responses, the system calls the JSON Path parser to perform field positioning and extraction operations; for other formats (such as XML), the XPath parsing module is enabled for processing.

[0064] Taking a successful response of a loan interface as an example, the returned content can be:

[0065] json

[0066] {"flag": "S",

[0067] "code": "0000",

[0068] "msg": "Success",

[0069] "data": {"loanId": "LN20251111001", "userId": "U1000234",

[0070] "amount": 10000.00, "disburseTime": "2025-11-03T10:00:00"}

[0071] For example, when processing the rule with table identification "t_loan_info", the system reads its parameter source path and extracts the parameter value "LN20251111001" from it via the JSON Path parser; when processing the rule with table identification "t_account_balance", the system can extract "U1000234" from the parameter source path.

[0072] All extracted parameter values are cached in the local context environment for use in the next step of constructing specific query statements. If a path cannot match a valid value (e.g., the field does not exist, is empty, or the type does not match), the system will record a warning log and skip data collection for that table, but will not affect the normal processing flow of the remaining tables, ensuring that some key data can still be captured.

[0073] Step S230, based on the table identification, determine the corresponding database table, and fill the corresponding query parameters into the expected value query statement of the corresponding database table to generate an executable query command.

[0074] For example, after obtaining valid query parameters, the system locates the actual database table corresponding to the table identification of the current rule item and substitutes the parameter values extracted in the previous step into the expected value query statement configured for the table to generate an SQL command that can be directly executed in the database.

[0075] This process is completed by the system's SQL template filling engine, which supports multiple parameter substitution mechanisms, including position-based placeholders (such as?) and name-based variables (such as loanId or {loanId}). The system will automatically select the appropriate filling method based on the syntax structure of the expected value query statement.

[0076] For example, for the rule with table identification "t_loan_info", its expected value query statement is "SELECT*FROMt_loan_info WHERE loan_id =?", combined with the extracted parameter value "LN20251111001", the system generates an executable query command: "SELECT*FROM t_loan_info WHERE loan_id = LN20251111001".

[0077] Similarly, for the rule with table identifier "t_repayment_plan", the original SQL statement is "SELECT * FROM t_repayment_plan WHERE loan_id =?", after substituting the same parameter, it can be generated as "SELECT * FROM t_repayment_plan WHERE loan_id = LN20251111001".

[0078] All generated executable query commands are added to the execution queue, ready to be submitted to the business database for query operation. Throughout the process, the system will perform syntax checking on the SQL statement, and enable the pre-compilation mechanism as much as possible to prevent SQL injection risks, ensuring the security and stability of data access.

[0079] Step S240, execute the executable query command, get the data records in the corresponding database table, and generate the corresponding expected business data according to the data records of each database table.

[0080] In this step, a communication channel is established with the business database through the database connection pool, and each executable query command generated in the previous step is executed in turn. After each command is executed, the database returns the corresponding result set, which contains zero or more complete data records, each record consists of several fields and their values, and the field definition is consistent with the structure of the corresponding database table. The system receives and parses these result sets, converts them into standardized internal data structures such as JSON arrays or memory object lists, and associates them with the original table identifier to form the expected business data corresponding to the table.

[0081] Continuing with the above loan scenario as an example: after executing the query command for the "t_loan_info" table, the system obtains a loan information record containing loan amount, loan status, creation time, etc. After executing the query command for the "t_repayment_plan" table, the system obtains 12 installment repayment plan records, each containing period number, principal, interest, repayment date, etc. After executing the query command for the "t_account_balance" table, the system obtains the account balance, available limit, frozen amount, etc. of the user's state data.

[0082] After the above data records from different tables are summarized, a complete set of expected business data is formed, which can fully reflect the impact range of this interface call at the database level. This set not only covers the core data of the main business table, but also includes the derivative information in the associated business table, thereby providing a solid data foundation for subsequent multi-table full coverage comparison.

[0083] In this embodiment, the system can realize automatic multi-table data collection based on business process tracking, and can solve the problems of insufficient assertion coverage and missing implicit data errors in the prior art.

[0084] In step S130, the expected response data and the expected business data are integrated into an expected data set, and are associated with a use case identifier, and are stored in an expected value database to form a data snapshot of the target business scenario.

[0085] In this step, data from different sources, including expected response data obtained from the target interface and expected business data extracted from multiple business database tables, are uniformly organized into a structured whole and marked by a unique use case identifier, and finally written into an independently deployed expected value database to form a complete data baseline, i.e., a data snapshot, under the test scenario.

[0086] The data snapshot not only records the direct output results generated by the interface call, but also contains all data changes caused by the interface call in the entire business link, thereby providing a comprehensive and accurate comparison benchmark for subsequent automated assertions.

[0087] In some embodiments, each target business scenario corresponds to a globally unique use case identifier, which is predefined by the tester when designing the test case, or automatically generated by the automation framework and ensured to be unique. For example, the use case identifier of the user loan disbursement success scenario can be set to “DISBURSE_SUCCESS_01”, and the repayment plan generation verification scenario corresponds to “REPAY_PLAN_GEN_02”. The use case identifier, as the main index field of the data snapshot, runs through the entire process of storage, query, and update of the expected data.

[0088] Before performing the data storage operation, the system first initiates a pre-check query to the expected value database based on the use case identifier corresponding to the current business scenario, to determine whether there is a historical version of the data snapshot. Specifically, the system constructs a query statement for retrieving whether there is any record associated with the use case identifier in the expected value database. If the query result shows that there is a matching data entry, it indicates that there is previously generated expected data for this test scenario. To avoid interference of old data on subsequent assertions, the system automatically triggers a cleaning mechanism, i.e., locates all related data records according to the use case identifier and deletes them from the expected value database. This way can ensure that the latest and most accurate baseline data is written each time, preventing data redundancy or version conflicts.

[0089] After the historical data cleaning is completed, the system begins to perform formal data integration and writing operations. First, the system standardizes and encapsulates the expected response data obtained in step S110, usually preserving its original structure or converting it into a universal data object format; at the same time, the expected business data of each table obtained in step S120 is classified and arranged according to the respective table identifiers, forming a set of data collections with clear structure. Subsequently, a new data container is created, and the above two types of data are unified into it, and a strong association relationship between the container and the current use case identifier is established. This association can be achieved by adding a special field to each data record, or by building a metadata table with the use case identifier as the primary key for management.

[0090] Finally, the system writes the integrated data set to the expected value database in batches. This database is a separately deployed storage unit, physically or logically isolated from the business database of the system under test, and is dedicated to storing data snapshots of various test scenarios. Once the writing is completed, the system announces that the data snapshot of the target business scenario has been officially generated. Thereafter, this snapshot will serve as the standard reference benchmark for all repeated test runs under this scenario until the next time it is refreshed due to interface or table structure changes.

[0091] Step S140, when executing the test process of the same business scenario as the target business scenario subsequently, obtaining actual response data and actual business data, and comparing the actual response data and the actual business data with the corresponding data snapshot in the expected value database to generate an interface automation assertion result.

[0092] After completing the first execution and successfully building the data snapshot of the target business scenario, the system enters the regular interface automation test running phase. Whenever this business scenario is triggered to execute again (for example, in the daily build, regression test, or pre-release verification process), the system no longer regenerates expected data, but directly starts the assertion verification mechanism, compares the actual output data of this run with the data snapshot stored in the expected value database for consistency, and determines whether the interface behavior meets expectations. It can be understood that this step includes the full-link impact range of a complete business operation from the interface return layer to the "database persistence layer" in the automation verification category, breaking through the limitations of traditional assertions that only compare interface fields or single-table records, significantly improving defect detection capability, and is particularly suitable for complex systems with strong data consistency requirements such as financial transactions and order processing.

[0093] In some embodiments, as shown in Figure 3 actual response data and actual business data are obtained, and compared with the corresponding data snapshot in the expected value database, and an interface automation assertion result is generated based on the comparison result, including steps S310-S330:

[0094] Step S310, calling the actual value query statement configured in pairs with the expected value query statement to obtain actual response data and actual business data from the business database.

[0095] Exemplarily, during the execution of the current test procedure, the system first calls the target interface, and after confirming that the returned state is normal, the actual response body of the current interface is collected, and the part carrying the core business information is extracted as the actual response data. As above, the data field content in the JSON structure is extracted.

[0096] Subsequently, the system enters the actual data collection stage at the database level. To ensure the fairness and traceability of the comparison process, the system uses a set of pre-defined actual value query statements corresponding to the expected value query statements to obtain real-time data.

[0097] It should be noted that the actual value query statement is not independently written, but is configured in pairs with the expected value query statement during the test case initialization stage. Each expected value query statement is associated with an actual value query statement that has the same structure and consistent logic. That is, they share the same query structure, the same parameter mapping method, and the same parameter source path.

[0098] When the system is executed, the parameter parsing mechanism is reused to extract the actual parameter value from the current interface response, substitute it into the actual value query statement, generate a SQL command that can be executed on the business database, and submit it for execution through the database connection pool. Finally, the real data records in each related table under this run are obtained to form the actual business data.

[0099] It should be noted that although the expected value query statement is used to collect baseline data for the first execution, and the actual value query statement is used to collect real-time data for subsequent execution, the two are completely consistent in terms of syntax structure, field selection, filtering conditions, etc., ensuring the same source and same structure for comparison, and thus avoiding false positives due to query differences. In addition, the actual response data is also obtained following the same path rules as the expected response data, thereby ensuring consistency in data extraction methods.

[0100] Step S320, comparing the actual response data and the actual business data with the corresponding expected response data and expected business data at the field level.

[0101] In this step, when performing field-by-field consistency checking, two dimensions are mainly compared: one is the interface response layer, i.e., comparing whether the values of each field in the current actual response data and the original expected response data are consistent; the other is the database business layer, i.e., comparing whether the values of all non-dynamic fields in each associated table of the actual business data and the expected business data match.

[0102] Structured comparison strategy can be used in this embodiment. For example, for JSON format response data, the system recursively traverses all nested fields, and compares the field name and field value one by one; for database table data, the system performs matrix comparison by row and column, and performs equality judgment for each field of each record.

[0103] However, not all fields participate in strict equality checking. Some fields change every time they are executed due to their natural dynamic nature, and if they are included in the comparison, the assertion will fail frequently. Therefore, the system introduces the concept of non-dynamic fields, and only performs consistency checking on fields with stable business meaning.

[0104] Non-dynamic fields are fields that reflect the state of business entities, amounts, identifiers, control flows, and other key information and should not be changed arbitrarily, such as loan amounts, loan status, account balances, and repayment periods. Fields such as creation time, update time, request serial number, session ID, and random salt value, which change every time they are executed but have no substantial business impact, are considered dynamic fields and are automatically ignored during comparison.

[0105] The system identifies non-dynamic fields through a pre-set field whitelist mechanism or a blacklist mechanism. For example, common dynamic field names such as create_time, update_time, and request_id can be excluded by configuration; or a list of fields to be checked can be explicitly specified, and the remaining fields are skipped by default.

[0106] For fields that still need to retain some fault tolerance capability (such as floating point amounts that may have precision rounding differences), the system supports setting a comparison tolerance threshold, such as allowing an amount field error of no more than 0.01 yuan to be considered a match.

[0107] Step S330, if all non-dynamic fields match, output the assertion pass result, otherwise generate an assertion failure report containing difference information.

[0108] After completing all field-level comparisons, the system aggregates the comparison results and makes a final assertion decision. If the values of all non-dynamic fields in the interface response layer and all database tables are completely consistent with the expected data (or meet the preset tolerance conditions), the system determines that this test is passed, generates an assertion pass result, and records an execution log for subsequent auditing. On the contrary, as long as there is any non-dynamic field value that does not match, the system determines that the assertion fails and immediately generates a detailed assertion failure report. The report not only indicates the assertion failure result, but also includes specific difference information, such as: where the difference occurs; which field is inconsistent; what is the expected value, what is the actual value; the case identifier and execution timestamp, etc. The report can be output in a structured format (such as JSON, XML) or a visual HTML page, which facilitates testers to quickly locate the problem source and assist the development team in troubleshooting data logic errors.

[0109] It should be noted that when the system detects that the table structure itself has changed (such as adding a field that is not synchronized to the expected data set), a structure inconsistency warning can also be marked in the report to prompt the user to re-execute the baseline collection process.

[0110] This way of the embodiment can realize an automated assertion mechanism with high coverage, high precision, and easy diagnosis. Compared with the traditional method that can only find obvious abnormalities, the present solution can effectively identify deep-level logic defects such as cross-table data misplacement, field missing update, and state transition error, greatly enhancing the reliability and protection capability of interface testing.

[0111] In some embodiments, after the target interface is changed or the database table structure is changed, the same automated test process corresponding to the use case identifier is re-executed to obtain updated expected response data and expected business data; the corresponding expected data set is cleared based on the current use case identifier, and the data snapshot is updated based on the updated expected response data and expected business data.

[0112] Exemplarily, to cope with the changes in the interface return structure or the database table structure in the software system iteration process, the embodiment provides an automated expected data refreshing method. When the relevant changes are detected, only the automated process with the same use case identifier as the original test scenario needs to be re-executed to update the expected data, without the need for manual modification of the JSON expected file or the SQL query statement.

[0113] Specifically, the system collects updated expected response data and expected business data in the same steps as the first execution. In the data storage stage, the expected value database is first queried according to the use case, and the existing historical data record is deleted to ensure that the old version snapshot is cleared. Subsequently, the newly collected data is associated with the use case identifier and written into the expected value database to complete the coverage update of the data snapshot. This process realizes that as long as the interface call is successful and valid data is returned, the system can automatically capture the structural changes and generate a new baseline, thereby reducing maintenance costs and error risks.

[0114] In some embodiments, the automated test process is implemented based on a modular script framework. When a new test case is added, the new test case is added by configuring the case identifier, referencing the pre-configured interface call method, and filling in the expected value query statement template and the actual value query statement template.

[0115] To reduce the technical threshold of interface automated assertion and improve the development efficiency of the test team, the entire test process is encapsulated in a modular script framework. The framework uses component-based design to abstract common functions such as interface call, data collection, expected value management, comparison execution, and result output into reusable independent modules, and provides standardized calling interfaces and configuration entrances to support integration into specific business scenarios in a declarative or configuration manner.

[0116] When adding a new test case, the tester only needs to configure a globally unique case identifier to distinguish between different business scenarios and serve as the storage and retrieval index of the data snapshot. Subsequently, by referencing the pre-configured interface call method, the tester can trigger the request operation of the target interface without writing underlying request construction code. These pre-configured methods have encapsulated complete URL, HTTP method, request header, parameter serialization, and response parsing logic to ensure consistent calls.

[0117] For database-level assertion requirements, the tester needs to fill in the expected value query statement template for each related business table. This template is a SQL statement containing parameter placeholders, and the query conditions are extracted from the interface response in combination with the parameter source path to obtain baseline data during the first execution. At the same time, the tester also needs to configure the actual value query statement template that is paired with it. The query structure and parameter mapping method of the actual value query statement template remain consistent with the expected value query statement to ensure that actual data can be obtained in the same logic during subsequent runs, ensuring fair comparison.

[0118] After the above configuration is completed, the system automatically integrates the information into executable test units and incorporates them into an automated scheduling plan. Test personnel do not need to master programming details or understand the interaction mechanism between modules. They only need to have basic business knowledge, such as familiarity with interface return structures and the meaning of related database tables, to complete the construction of use cases. This low-code mode of "configuration as coding" significantly reduces the participation threshold for automated testing, enabling non-development background testers to efficiently develop and maintain use cases and effectively promote the large-scale landing of the automated testing system.

[0119] In some embodiments, the table structure of the database table in the expected value database only has one column of use case identification field more than the corresponding table structure in the business database. This design adopts a lightweight mirroring mechanism, so that the expected table is completely consistent with the original business table in terms of field definition, data type, and constraint rule, and only the use case identification field is newly added to identify the data belonging to different test scenarios. When data is written, the system stores the collected expected data in association with the current use case identification; when the assertion comparison is performed, the corresponding data snapshot is accurately read through the identification. This structure not only guarantees data consistency, but also realizes multi-scene data isolation, and is easy to update synchronously with changes in the business table structure, thereby improving the maintainability and scalability of the system.

[0120] The embodiment improves the accuracy and maintenance efficiency of interface automated assertion by constructing an independent expected value database and realizing automatic pre-embedding and dynamic refreshing of expected data. Compared with the traditional manual writing of expected results, the present scheme can realize multi-table and multi-field coverage comparison of full-link business data, greatly improving the defect detection capability, and is especially suitable for strong data consistency scenarios such as finance and e-commerce. At the same time, through the modular script framework and low-code configuration mode, the technical threshold of testers is reduced, so that non-development background test engineers can also quickly add and maintain use cases. In addition, the data isolation and automatic update mechanism based on use case identification can effectively cope with the maintenance challenges brought by interface or table structure changes, thereby reducing the long-term operation and maintenance cost of test assets and improving the scalability and sustainability of automated testing.

[0121] Figure 4 A structure schematic diagram of an interface assertion system of an embodiment of the present application is shown. Exemplarily, the interface assertion system comprises:

[0122] The interface calling module 100 is configured to, when the target interface calling return state is detected to be consistent with the expectation when the automated test process corresponding to the target business scenario is executed for the first time, obtain valid data returned from the target interface as expected response data.

[0123] The data acquisition module 200 is configured to extract corresponding data records from at least two database tables related to the target business scenario as expected business data based on a preset business process association rule.

[0124] The expectation management module 300 is configured to integrate the expected response data and the expected service data into an expected data set, and store the expected data set into the expectation database after associating the application case identifier, so as to form a data snapshot of the target service scenario.

[0125] The comparison execution module 400 is configured to acquire actual response data and actual service data when a test process of the same service scenario as the target service scenario is executed subsequently, and compare the actual response data and the actual service data with the corresponding data snapshot in the expectation database, so as to generate an interface automation assertion result.

[0126] It can be understood that the apparatus of the embodiment corresponds to the interface assertion method of the above-mentioned embodiment, and the optional items in the above-mentioned embodiment are also applicable to the embodiment, and thus will not be described herein again.

[0127] The application further provides a terminal device. Illustratively, the terminal device includes a processor and a memory. The memory stores a computer program. The processor runs the computer program, so that the terminal device performs the functions of the interface assertion method or each module in the interface assertion system.

[0128] The processor can be an integrated circuit chip with a signal processing capability. The processor can be a general-purpose processor, including a central processing unit (CPU), a graphics processing unit (GPU), and a network processor (NP), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations thereof. The general-purpose processor can be a microprocessor, or the processor can also be any conventional processor, etc., and can implement or execute the disclosed methods, steps, and logic block diagrams in the embodiments of the application.

[0129] The memory can be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), and the like. Among them, the memory is used to store a computer program, and the processor can execute the computer program correspondingly after receiving an execution instruction.

[0130] The application further provides a computer readable storage medium for storing the computer program used in the terminal device. For example, the computer readable storage medium can include, but is not limited to, a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0131] In several embodiments provided in the application, it should be understood that the disclosed apparatus and method can also be implemented by other ways. The apparatus embodiments described above are only schematic, for example, the flow charts and block diagrams in the drawings show the possible implementation architectures, functions and operations of the apparatus, method and computer program product according to the embodiments of the application. In this regard, each block in the flow chart or block diagram can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logic function. It should also be noted that, in alternative implementation ways, the functions noted in the block can also occur in different order from that noted in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the structural diagram and / or flow chart, and the combination of blocks in the structural diagram and / or flow chart, can be implemented by a dedicated hardware-based system for executing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0132] In addition, each functional module or unit in the embodiments of the application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0133] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the parts that contribute to the prior art or parts of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application.

[0134] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application.

Claims

1. An interface assertion method, characterized in that, include: When executing the automated test process corresponding to the target business scenario for the first time, if the return status of the target interface call is found to be in line with expectations, valid data is obtained from the data returned by the target interface as the expected response data; Based on preset business process association rules, extract corresponding data records from at least two database tables related to the target business scenario as expected business data; The expected response data and the expected business data are integrated into an expected dataset, associated with the corresponding use case identifier, and then stored in the expected value database to form a data snapshot of the target business scenario; When performing a test process for a business scenario identical to the target business scenario, the actual response data and actual business data are obtained, and the actual response data and actual business data are compared with the corresponding data snapshot in the expected value database to generate an automated assertion result for the interface.

2. The interface assertion method according to claim 1, characterized in that, The step of extracting corresponding expected business data from at least two database tables related to the target business scenario based on preset business process association rules includes: Load the business process association rules corresponding to the target business scenario; wherein, the business process association rules include table identifiers of all database tables related to the target business scenario, expected value query statements for obtaining data, and parameter source paths for determining query parameters; Based on the parameter source path, the query parameters are parsed from the response data of the target interface; The corresponding database table is determined based on the table identifier, and the corresponding query parameters are filled into the expected value query statement of the corresponding database table to generate an executable query command. The executable query command is executed to obtain the data records in the corresponding database tables, and the corresponding expected business data is generated based on the data records in each of the database tables.

3. The interface assertion method according to claim 1, characterized in that, Each of the aforementioned business scenarios corresponds to a unique use case identifier; Before integrating the expected response data and the expected business data into an expected dataset, associating it with the corresponding use case identifier, and storing it in the expected value database, the method further includes: If the expected value database is queried based on the use case identifier, and a data snapshot associated with the current use case identifier exists, the historically stored data snapshot is deleted.

4. The interface assertion method according to claim 2, characterized in that, The process of acquiring actual response data and actual business data, comparing them with the corresponding data snapshots in the expected value database, and generating automated assertion results based on the comparison results includes: Invoke the actual value query statement configured in pair with the expected value query statement to obtain the actual response data and the actual business data from the business database; wherein the actual value query statement and the expected value query statement have the same query structure and parameter mapping method; Perform a field-level consistency comparison between the actual response data and the actual business data and the corresponding expected response data and expected business data; If all non-dynamic fields match, the assertion passes; otherwise, an assertion fails report containing discrepancy information is generated.

5. The interface assertion method according to claim 1, characterized in that, After the target interface or database table structure changes, the automated test process corresponding to the same use case identifier is re-executed to obtain the updated expected response data and expected business data. The expected dataset corresponding to the current use case identifier is cleared, and the data snapshot is updated based on the updated expected response data and expected business data.

6. The interface assertion method according to claim 4, characterized in that, The automated testing process is implemented based on a modular script framework. When adding new test cases, the process is completed by configuring test case identifiers, referencing pre-defined interface call methods, and filling in expected value query statement templates and actual value query statement templates.

7. The interface assertion method according to claim 1, characterized in that, The table structure of the database table in the expected value database is only one column longer than the table structure of the database table in the business database, with the addition of a use case identifier field.

8. An interface assertion system, characterized in that, include: The interface call module is used to obtain valid data as expected response data from the data returned by the target interface when the automated test process corresponding to the target business scenario is executed for the first time. The data acquisition module is used to extract corresponding data records from at least two database tables related to the target business scenario based on preset business process association rules, as expected business data. The expectation value management module is used to integrate the expected response data and the expected business data into an expectation dataset, associate it with the corresponding use case identifier, and store it in the expectation value database to form a data snapshot of the target business scenario; The comparison execution module is used to obtain actual response data and actual business data when performing test processes for the same business scenario as the target business scenario, and compare the actual response data and actual business data with the corresponding data snapshot in the expected value database to generate interface automated assertion results.

9. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the interface assertion method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed on a processor, implements the interface assertion method according to any one of claims 1-7.

Images