Interface testing method, device and equipment

Abstract

This invention relates to the field of software testing technology and discloses an interface testing method, apparatus, and device. The method includes: responding to a test instruction from a target interface, invoking a database query method, passing in target parameters, and performing a database query operation. The target parameters include at least: a maximum waiting time for query assertions, a query retry interval, and assertion rules. After performing the database query operation, according to the assertion rules, verifying whether the query result meets the set expectations; if the query result does not meet the set expectations, waiting for the query retry interval, and then re-executing the database query operation; if the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, terminating the database query operation. Applying the technical solution of this invention can improve the efficiency and accuracy of interface testing results.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, specifically to an interface testing method, apparatus, and device. Background Technology

[0002] Currently, in the API automated testing process, API assertions are a core step in verifying the correctness of API functionality. After an API call, a database query is needed to verify the state of the target data in the database, thereby confirming whether the API's business logic has been executed correctly. However, in practical applications, APIs often involve asynchronous processing logic. Specifically, to improve processing efficiency, backend services often employ asynchronous database writes and message queue delayed distribution architectures. These asynchronous mechanisms mean that the target data cannot be queried immediately after the API call is completed, directly affecting the accuracy of assertions.

[0003] In related technologies, a fixed waiting time is set in the code before executing a database query. The query is then executed and assertions are performed after the fixed waiting time has expired.

[0004] However, if the asynchronous processing time of the interface is shorter than the fixed waiting time, the extra waiting time will waste the efficiency of automated test execution. Especially in large-scale interface automation scenarios, the accumulated wasted time will significantly extend the test cycle. Alternatively, if the asynchronous processing time is longer than the fixed waiting time, the target data cannot be found after the fixed waiting time has expired, which will lead to assertion failure and thus affect the accuracy of the test results. Summary of the Invention

[0005] In view of the above problems, embodiments of the present invention provide an interface testing method, apparatus and device to solve the problems of low interface testing efficiency and inaccurate interface testing results caused by using a fixed waiting time for database data query in the prior art.

[0006] According to one aspect of the present invention, an interface testing method is provided, the method comprising: In response to the test command of the target interface, call the database query method, pass in the target parameters and execute the database query operation. The target parameters include at least: the maximum wait time for query assertion, the query retry interval, and the assertion rules. After executing a database query, the query results are verified to meet the set expectations according to the assertion rules. If the query results do not meet the set expectations, wait for the query retry interval and then re-execute the database query operation; If the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, the database query operation will be terminated.

[0007] According to another aspect of the present invention, an interface testing apparatus is provided, comprising: The response module is used to respond to the test commands of the target interface, call the database query method, and execute the database query operation after passing in the target parameters. The target parameters include at least: the maximum wait time for query assertion, the query retry interval, and the assertion rules. The validation module is used to validate whether the query result meets the set expectations according to the assertion rules after the database query operation is executed. If the query result does not meet the set expectations, the database query operation is re-executed after waiting for the query retry interval. If the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, the database query operation is terminated.

[0008] According to another aspect of the present invention, an interface testing device is provided, comprising: a processor, a memory, a communication interface, and a communication bus, wherein the processor, the memory, and the communication interface communicate with each other through the communication bus; The memory is used to store at least one executable instruction that causes the processor to perform the operations described above for the interface testing method.

[0009] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein at least one executable instruction is stored in the storage medium, the executable instruction causing an interface testing device / apparatus to perform the following operations: In response to the test command of the target interface, call the database query method, pass in the target parameters and execute the database query operation. The target parameters include at least: the maximum wait time for query assertion, the query retry interval, and the assertion rules. After executing a database query, the query results are verified to meet the set expectations according to the assertion rules. If the query results do not meet the set expectations, wait for the query retry interval and then re-execute the database query operation; If the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, the database query operation will be terminated.

[0010] This invention, through a database query method, inputs the maximum waiting time for query assertions and the query retry interval. After a query, if the verification result meets expectations, the query and waiting immediately terminate, unlike related technologies which require a fixed waiting time. This maximizes interface testing efficiency. Secondly, compared to related technologies where asynchronous processing completion time exceeds a fixed waiting time, leading to assertion failures due to unwritten / updated data and misjudgments of interface functionality, resulting in inaccurate test results, this application does not execute a single query. Instead, it repeatedly queries at retry intervals until the data meets expectations or a timeout occurs, provided the cumulative waiting time has not reached the maximum waiting time. This ensures that premature queries do not lead to missed judgments. Upgrading the fixed waiting time to a maximum waiting threshold provides sufficient time for asynchronous processing, avoiding misjudgments due to insufficient waiting, and prevents infinite loops by terminating after the cumulative time reaches the target. After each database query operation, the result is verified according to the assertion rules, ensuring that data is detected as soon as it is available, rather than being verified all at once after a fixed waiting time, significantly improving the accuracy of assertions.

[0011] The above description is merely an overview of the technical solutions of the embodiments of the present invention. In order to better understand the technical means of the embodiments of the present invention and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0012] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a first embodiment of the interface testing method provided by the present invention is shown. Figure 2 This invention illustrates the overall architecture of the interface testing method provided by the present invention. Figure 3 A schematic diagram of the structure of a first embodiment of the interface testing device provided by the present invention is shown; Figure 4 A schematic diagram of an embodiment of the interface testing device provided by the present invention is shown. Detailed Implementation

[0013] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0014] In the field of software testing, interface assertions are a core step in verifying the correctness of interface functionality within the interface automated testing process. After an interface is called, database queries, such as the SELECT statement in SQL, are used to verify the target data's status in the database, such as data writing or data modification, to confirm whether the interface's business logic has been executed correctly.

[0015] However, APIs in real-world applications often involve asynchronous processing logic. Specifically, to improve processing efficiency, backend services frequently employ architectural designs such as asynchronous database writes and delayed message queue distribution. For example, after receiving a request, the API may only return a response status, while the data write operation to the database is performed asynchronously by a background thread or a distributed queue. Another example is that in high-concurrency scenarios, databases use batch commit strategies to avoid lock conflicts, resulting in a certain delay in data updates. These asynchronous mechanisms mean that after an API call is completed, the target data cannot be queried immediately, directly affecting the accuracy of assertions.

[0016] To address this issue, the primary approach in related technologies is a fixed-wait scheme. This scheme sets a fixed wait time before executing a database query using code such as the `time.sleep(n)` function in Python. The query is then executed and assertions are performed only after the fixed wait time has elapsed. However, this scheme has significant drawbacks: Firstly, if the asynchronous processing time is shorter than the fixed wait time, the extra waiting time wastes the efficiency of automated test execution, especially in large-scale API automation scenarios, where the accumulated wasted time can significantly extend the test cycle. Secondly, if the asynchronous processing time is longer than the fixed wait time, the target data may still not be found after the fixed wait time has elapsed, leading to assertion failures and affecting the accuracy of the test results. Furthermore, the fixed wait time requires manual configuration based on experience, making it unsuitable for different APIs and environments with varying asynchronous processing times, resulting in extremely poor flexibility and making it difficult to meet the needs of complex API automation testing scenarios.

[0017] To address the aforementioned issues, this application proposes an interface testing method. The main technical solution includes: responding to a test command from the target interface, calling a database query method, passing in target parameters, and executing a database query operation. The target parameters include at least: the maximum waiting time for query assertions, the query retry interval, and assertion rules. After executing the database query operation, based on the assertion rules, verifying whether the query result meets the set expectations; if the query result does not meet the set expectations, waiting for the query retry interval before re-executing the database query operation; if the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, terminating the database query operation.

[0018] This invention, through a database query method, inputs the maximum waiting time for query assertions and the query retry interval. After a query, if the verification result meets expectations, the query and waiting immediately terminate, unlike related technologies which require a fixed waiting time. This maximizes interface testing efficiency. Secondly, compared to related technologies where asynchronous processing completion time exceeds a fixed waiting time, leading to assertion failures due to unwritten / updated data and misjudgments of interface functionality, resulting in inaccurate test results, this application does not execute a single query. Instead, it repeatedly queries at retry intervals until the data meets expectations or a timeout occurs, provided the cumulative waiting time has not reached the maximum waiting time. This ensures that premature queries do not lead to missed judgments. Upgrading the fixed waiting time to a maximum waiting threshold provides sufficient time for asynchronous processing, avoiding misjudgments due to insufficient waiting, and prevents infinite loops by terminating after the cumulative time reaches the target. After each database query operation, the result is verified according to the assertion rules, ensuring that data is detected as soon as it is available, rather than being verified all at once after a fixed waiting time, significantly improving the accuracy of assertions.

[0019] The essence of the technical solution in this application is that the fixed waiting time of related technologies is a static adaptation, meaning that the fixed waiting time cannot match the randomness of asynchronous processing time under different interfaces and environments. This application defines the longest acceptable waiting boundary with the maximum waiting time and achieves high-frequency, low-time-consuming proactive detection with retry intervals. This not only accommodates the uncertainty of asynchronous processing time and prevents failure due to time fluctuations, but also ensures the timeliness and efficiency of detection. The embedding of assertion rules further ensures that the detection has clear standards, avoids the blindness of simply waiting without verification, and ensures that the termination condition is that the data meets expectations rather than that the time has expired, thus guaranteeing the accuracy of the test results.

[0020] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or interface testing device capable of performing the above functions. The following description uses an interface testing device as an example to illustrate this embodiment and the subsequent embodiments.

[0021] It should be noted that the interface testing method in this application refers to a testing approach that verifies the functionality, performance, and compatibility of interfaces between different modules in a software system or between the system and external systems, in order to ensure that the interfaces respond normally according to preset rules. The interfaces in this application can be Python interfaces, or other types of interfaces, and are not limited here.

[0022] The interface testing methods of this application will be described in detail below.

[0023] Figure 1A flowchart of a first embodiment of the interface testing method of the present invention is shown, which is executed by an interface testing device. Figure 1 As shown, the method includes the following steps: Step 110: In response to the test command of the target interface, call the database query method, pass in the target parameters and execute the database query operation. The target parameters include at least: the maximum wait time for query assertion, the query retry interval, and the assertion rules.

[0024] The target interface refers to the specific interface to be tested and verified, and is the core object of this test operation. It can be a Python interface or other types of interfaces; this embodiment does not specifically limit the type of the target interface.

[0025] The test instruction refers to the instruction that triggers the start of the interface testing process. It can be initiated manually by testers, triggered by automated test scripts, or sent periodically by the test system. This embodiment does not specifically limit the triggering method of the test instruction; it can be any triggering method.

[0026] Among them, database query methods refer to functions or program modules that encapsulate database query logic, are able to receive parameters and execute corresponding database query operations, and return query results.

[0027] Among them, the target parameters refer to the set of key parameters passed to the database query method during the test process. They are used to control the query logic, assertion rules and retry mechanism, and are the core basis for the standardization of the test process.

[0028] The maximum wait time for query assertions refers to the maximum cumulative time that the test process is allowed to wait for a query result that meets expectations. If this time is exceeded, the query will be terminated to avoid infinite waiting.

[0029] The query retry interval refers to the waiting time before re-executing the query operation if the result of a single query does not meet expectations; in other words, the waiting time between two database query operations. This query retry interval can be adaptively set according to the type of the target interface, the asynchronous processing time, etc.

[0030] Assertion rules are predefined standards or conditions used to determine whether query results meet test expectations; they are the core basis for verifying the validity of query results. These assertion rules can be set according to the type of interface, and there is no specific limit to the number of assertion rules; at least one assertion rule can be set.

[0031] In one alternative approach, a test automation framework can listen for test commands on the target interface. Upon detecting a command triggered by manually clicking the "Start Test" button, the framework's built-in function call module invokes a pre-defined database query method, such as a JDBC-based query function. Simultaneously, the parameter configuration module passes in pre-entered parameters in key-value pairs: a maximum wait time (e.g., 30 seconds), a retry interval (e.g., 5 seconds), and assertion rules. A SELECT statement is then executed to complete the database query, and the query start time is recorded. Specifically, the asynchronous maximum wait time, retry interval, and assertion rules can be encapsulated at the database query method level rather than the business script level. The upper-level script only needs to call the method and pass in the parameters. This logical encapsulation of the method layer and the upper-level call represents a key difference from existing technologies that require writing loop / wait logic at the business layer, simplifying the script structure and improving code cleanliness and maintainability.

[0032] In another alternative approach, a test script, such as a Python script, receives the target interface test command sent by the scheduled task system. The script calls a custom database query class method through an import statement. When calling the method, the maximum waiting time (e.g., 60 seconds), the query retry interval (e.g., 3 seconds), and assertion rules read from a configuration file (e.g., a JSON file) are passed as parameters. The loop logic is initialized through a while loop statement, the preset SQL query statement is executed, the result set returned by the database is obtained, and the cumulative waiting time is initialized to 0.

[0033] Step 120: After executing the database query operation, verify whether the query results meet the set expectations according to the assertion rules.

[0034] The query result refers to the dataset or status information returned from the database after executing a database query operation, and is the direct object of assertion verification.

[0035] In one alternative approach, after each database query operation is completed, the test system calls the assertion verification module. This module reads the passed assertion rules and compares the query results with the preset expected values ​​field by field. For example, if the assertion rule is "data is not empty", the system verifies whether there are valid data entries in the returned result set. If they exist, the system is determined to meet the expectations; if they are empty, the system is determined to not meet the expectations. At the same time, the verification result is logged.

[0036] In another alternative approach, after the database query operation is completed, the assertion rules are parsed using the script's built-in validation function. The query results are then converted into a standardized format, such as JSON, and compared with the hash values ​​of the expected results pre-stored in the test cases. For example, if the assertion rule is "matching specific field values", the value of the target field in the query results is extracted, its hash value is calculated, and compared with the hash value of the expected result. If they match, the result meets the expectation; otherwise, it does not meet the expectation, and a validation detail report is generated.

[0037] Step 130: If the query result does not meet the set expectations, wait for the query retry interval and then re-execute the database query operation; Here, the set expectation refers to the query result standard that is predefined before testing and meets the requirements for the normal operation of the interface function. It serves as the reference benchmark for assertion verification. This set expectation can be adaptively set for different assertion rules, meaning that the set expectation is different for different assertion rules.

[0038] In one optional approach, when the verification result shows that the query result does not meet the set expectations, the test system starts the timing module and begins a countdown according to the input query retry interval. Before the countdown ends, the current test process is paused and other operations are prohibited. After the countdown ends, the timing module sends a trigger signal to call the database query method to re-execute the same query operation, and at the same time updates the retry count statistics.

[0039] In another alternative approach, if the verification result is not as expected, the script pauses program execution at retry intervals using the time.sleep() function (for example, in Python). During the pause, it continuously monitors the database connection status to ensure that the connection is not broken. After the pause ends, it automatically re-initiates the database query request, reusing the previously passed target parameters to avoid duplicate parameter configuration, and marks the retry record in the test log.

[0040] Step 140: If the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, terminate the database query operation.

[0041] The cumulative wait time, measured in seconds, refers to the maximum allowed cumulative wait time for database queries. It serves as a safety net for asynchronous processing waits. This cumulative wait time can be a preset value or a dynamic value. For example, in scenarios involving asynchronous API processing, the cumulative wait time can be the maximum time window reserved for asynchronous processing, ensuring sufficient time for asynchronous data to be written to the database and preventing assertion failures due to insufficient waiting.

[0042] In one optional approach, after each retry, the test system adds the current waiting time to the cumulative waiting time and compares the cumulative waiting time with the maximum waiting time in real time. When the cumulative waiting time is equal to or exceeds the maximum waiting time, and the current query result still does not meet expectations, the system calls the termination module, actively closes the database query connection, stops the query process, marks the test status as "timeout failure", and saves the current query result.

[0043] In another alternative approach, a timer is used to track the cumulative waiting time in real time. When the cumulative waiting time reaches the maximum waiting time threshold, a timeout detection mechanism is triggered. This mechanism first re-verifies whether the current query result meets expectations. If it still does not meet expectations, a termination command is sent to the database query module to terminate the query thread, release database connection resources, and generate a timeout alarm message to notify the testers.

[0044] In this embodiment, by calling the database query method and passing in the maximum waiting time for the query assertion and the query retry interval, the query and waiting will terminate immediately once the verification result meets expectations after a query, without having to wait for a fixed waiting time as in related technologies. This maximizes the efficiency of interface testing. Secondly, compared to related technologies where the asynchronous processing completion time exceeds the fixed waiting time, a single query may fail due to data not being written / updated, leading to false judgments of interface functionality and inaccurate test results. This application does not execute a single query, but repeats the query at the retry interval as long as the cumulative waiting time has not reached the maximum waiting time, until the data meets expectations or a timeout occurs. This ensures that no missed judgments are caused by a single query being too early. Upgrading the fixed waiting time to a maximum waiting threshold provides sufficient time for asynchronous processing, avoiding false judgments due to insufficient waiting, and the rule of terminating when the cumulative time reaches the target avoids infinite loops. After executing the database query operation, the result is verified according to the assertion rules, ensuring that the data is detected as soon as it is available, rather than being verified all at once after a fixed waiting time, which greatly improves the accuracy of the assertion.

[0045] In one feasible implementation, the assertion rules include at least one of data existence rules, data update status rules, and data quantity rules; after executing a database query operation, verifying whether the query results meet the set expectations based on the assertion rules includes: Step 121: After executing the database query operation, verify whether the query result meets the set expectations based on at least one of the data existence rules, data update status rules, and data quantity rules; Among them, the data existence rule is used to verify whether there is data in the query results; the data update status rule is used to verify whether the data in the query results meets the expected value; and the data quantity rule is used to verify whether the data in the query results meets the quantity requirements.

[0046] Among them, the data existence rule is a type of assertion rule used to verify whether the database query results contain valid data entries, that is, to determine whether the result set is empty. It is one of the most basic assertion rules.

[0047] Among them, the data update status rule is a type of assertion rule used to verify whether the data in the query results has reached the preset update status. Specifically, it means that the data field value is consistent with the expected value, adapting to the scenario of database data update after interface operation.

[0048] Among them, the data quantity rule is a type of assertion rule used to verify whether the number of data entries in the query results meets the preset threshold. It can be divided into types such as quantity meeting the standard and quantity range matching, and is suitable for test scenarios that require statistical data on the number of data entries.

[0049] The expected value is a field value that is preset according to the data update status rules before the test and meets the interface function requirements. It is the benchmark for judging whether the data update status is qualified.

[0050] The quantity requirement is a pre-defined standard for the number of items in the data quantity rules before the test. It can be a specific value, a range of values, or a comparison condition such as greater than or equal to a certain value.

[0051] In one optional approach, after the database query operation is completed, the assertion module of the test system first parses the incoming assertion rule type. If it is a single rule, such as a data existence rule, the corresponding verification is executed directly. If it is a combination of multiple rules, such as data existence and data quantity rules, the rules are verified in sequence according to a preset priority. First, the existence of data is verified. If the data exists, the number of data entries is verified to meet the quantity requirements. If all rules pass, the system is deemed to meet expectations. If any rule fails, the system is deemed to not meet expectations. The verification results of each rule are recorded.

[0052] In another alternative approach, after the database query operation is completed, the script calls a multi-rule validation function. The function receives a set of assertion rules and performs parallel validation on the query results. For example, it enables data existence rules and data update status rules at the same time. On the one hand, it checks whether the result set is not empty, and on the other hand, it extracts the target field value and compares it with the expected value. If both rules are satisfied, it meets the expectation; if either one is not satisfied, it does not meet the expectation. After the validation is completed, the rule validation details are output.

[0053] This embodiment refines the types of assertion rules and provides multi-dimensional verification standards to adapt to different interface testing scenarios, such as verifying only the existence of data, verifying the effect of data updates, or counting data entries. This improves the versatility and adaptability of the interface testing method and solves the problem that traditional single assertion rules cannot cover complex testing requirements. Secondly, the multi-rule verification mechanism can more comprehensively verify the database data status, avoiding test vulnerabilities caused by single-dimensional verification, improving the rigor of interface testing, ensuring that the impact of interface operations on the database meets expectations, and guaranteeing the integrity of interface functionality.

[0054] In one feasible implementation, after performing a database query operation, verifying whether the query result meets the set expectations based on at least one of the data existence rule, data update status rule, and data quantity rule includes: Step 1211: After executing the database query operation, check if a key-value pair has been passed in; The key-value pair is a data structure consisting of a "key" and a "value". The "key" is used to identify the data field, and the "value" is the expected data of the corresponding field. Here, it is used to trigger the validation logic of a specific combination of assertion rules.

[0055] In one alternative approach, after the database query operation is completed, the parameter detection module of the test system scans the parameter set passed to the database query method to determine whether it contains data in key-value pair format; it matches the format feature of "key:value" using regular expressions. If a match is found, it is determined that a key-value pair has been passed; if no match is found, it is determined that no data has been passed, and a detection result identifier is generated.

[0056] In another alternative approach, after the database query operation is completed, the script checks the parameter set using a parameter type detection function. If a dictionary type, such as dict in Python, exists and the dictionary contains a preset "key" field, then it is determined that key-value pairs have been passed. If there is no dictionary type data in the parameter set, or the dictionary does not contain a preset "key" field, then it is determined that no data has been passed, and a parameter detection log is recorded.

[0057] Step 1212: If yes, use data existence rules and data update status rules to verify whether the query results meet the set expectations; In one optional approach, if an incoming key-value pair is detected, the assertion module first performs a data existence rule check to determine whether the query result set is not empty. If the result set is not empty, it then extracts the field corresponding to the "key" in the key-value pair, obtains the value of that field in the query result, and performs an exact match with the "value" in the key-value pair. If the two match, it meets expectations; if any step fails, it does not meet expectations, and a combined verification report is output.

[0058] In another alternative approach, once the input key-value pair is confirmed, the query results are first checked for valid entries using data existence rules. If the result is empty, it is determined that the query does not meet expectations. If a valid entry exists, the key-value pair is converted into a standardized format based on data update status rules and then fuzzy-matched with the corresponding field data in the query results, ignoring case sensitivity and spaces. If the match is successful, the query meets expectations; otherwise, it does not meet expectations, and the specific field that failed to match is marked.

[0059] Step 1213: If not, use the data existence rule to verify whether the query results meet the set expectations.

[0060] In one alternative approach, if no key-value pair is detected, the assertion module only initiates data existence rule verification, reads the number of entries in the query result set, and if the number of entries is greater than 0, it is determined that the set expectation is met; if the number of entries is 0, it is determined that the expectation is not met, and at the same time, it is noted in the test log that "no key-value pair was passed, only existence verification was performed".

[0061] In another alternative approach, when no key-value pair is detected, the script calls a simplified validation function to check only whether the query result is empty. By judging whether the length of the result set is greater than 0, or whether there are non-empty data entries, if they exist, it meets the expectation; if they are empty, it does not meet the expectation. There is no need to perform other dimension validations, thus improving validation efficiency.

[0062] In this embodiment, the assertion rule combination is dynamically selected based on the presence or absence of key-value pairs, achieving adaptive adjustment of the verification logic. This avoids executing redundant verification steps when no data update is required, improving the efficiency of assertion verification while ensuring the verification depth when precise data verification is needed. The relationship between key-value pairs and assertion rules is clearly defined, allowing testers to quickly switch verification modes by specifying whether or not key-value pairs are passed, simplifying test configuration operations, reducing the complexity of the test process, and improving the convenience of test configuration.

[0063] Furthermore, using data existence rules to verify whether the query results meet the set expectations includes: using data existence rules to verify whether the query results are empty; if not, determine that the query results meet the set expectations; if so, determine that the query results do not meet the set expectations.

[0064] Among them, the use of data existence rules to check whether the query result is empty includes: In one optional approach, after enabling the data existence rule, the assertion module reads the query result set returned by the database, counts the number of valid data entries in the result set, and if the number of entries is greater than 0, the query result is determined to be non-empty; if the number of entries is 0, the query result is determined to be empty, and the entry count statistics are recorded.

[0065] In another alternative approach, based on data existence rules, the script determines whether the query result set is an empty object (None) or whether the iterator of the result set has iterable elements. If the result set is None or the iterator has no elements, it is considered empty; if it has iterable elements, it is considered not empty, thus adapting to the result set formats returned by different databases.

[0066] If not, determining that the query results meet the set expectations includes: In one optional approach, if the verification result is that the query result is not empty, the assertion module generates a "verification passed" flag, writes the flag into the test result set, and updates the test status to "temporarily qualified".

[0067] In another optional approach, when the query result is determined to be non-empty, the script automatically records the time of the successful verification, the query result summary information, generates a verification success log, and returns a boolean value "True" to the upper-level test logic to trigger subsequent processes, ensuring the continuity of the test process.

[0068] If so, determining that the query results do not meet the set expectations includes: In one optional approach, if the validation result is that the query result is empty, the assertion module generates a "validation failed" flag, records the reason for failure as "the query result is empty and the data existence rule is not met", and feeds back the failure information to the retry control module to trigger the retry mechanism.

[0069] In another optional approach, when the query result is determined to be empty, the script returns a boolean value "False" to the upper-level logic, generates a failure alarm message, and notes the verification rules, query time and result set status. This message is saved to the test error log for subsequent troubleshooting. At the same time, the current verification process is paused, waiting for a retry or termination instruction.

[0070] This embodiment clarifies the specific verification process for data existence rules, standardizing and implementing the verification logic. This avoids inconsistencies in the interpretation of existence verification across different testing scenarios and improves the standardization of the testing method. The operation steps for data existence verification are simplified; verification can be completed simply by checking if the result set is empty, improving verification efficiency and making it suitable for scenarios with high testing speed requirements, while ensuring the accuracy of the verification results.

[0071] Furthermore, the data existence rule and data update status rule are used to verify whether the query results meet the set expectations. This includes: using the data existence rule to check whether the query results are empty; if so, it is determined that the query results do not meet the set expectations; if not, the data update status rule is used to extract the value of the target key from the first element in the query results; the value of the target key is converted into a string and matched with the string obtained by converting the value of the target key in the key-value pair; if they match, it is determined that the query results meet the set expectations; if they do not match, it is determined that the query results do not meet the set expectations.

[0072] The first element refers to the data entry that appears first in the database query results. It can be determined by the default sorting rule or the preset sorting rule and is the core object for extracting the target key value.

[0073] The target key is the "key" in the key-value pair used to identify the field of the data to be verified. It corresponds to a specific field name in the database table and is the index basis for extracting data.

[0074] String conversion refers to converting the values ​​corresponding to the target key in the query results and the values ​​of the target key in key-value pairs into string format, thereby eliminating the impact of empty values ​​on the matching results.

[0075] Among them, the use of data existence rules to check whether the query result is empty includes: In one optional approach, after enabling the data existence rule, the test system reads the metadata information of the query result set, determines whether the result set contains field definitions and corresponding data entries, and if both field definitions and data entries exist, it is determined to be non-empty; if only field definitions exist but no data entries exist, or no field definitions exist, it is determined to be empty, and the metadata verification result is recorded.

[0076] In another alternative approach, based on data existence rules, the script attempts to read the first data entry in the result set. If the read is successful, the query result is determined to be non-empty; if a "no data" exception is thrown during the read, the query result is determined to be empty, thus adapting to the exception feedback mechanisms of different databases.

[0077] If so, determining that the query results do not meet the set expectations includes: In one optional approach, if the verification result indicates that the query result is empty, the assertion module directly generates a verification failure result, specifying the reason for the failure as "data does not exist, and the update status verification cannot be performed". At the same time, the result is synchronized to the retry control module to trigger the retry process, without executing the subsequent data update status verification steps.

[0078] In another alternative approach, when the query result is determined to be empty, the script immediately terminates the current combined validation process and returns a failure message, which includes key-value pair information, validation rules, and result status. At the same time, the test report marks the validation as "precondition not met" to facilitate differentiation between failures caused by non-existent data and data mismatch.

[0079] If not, the data update status rule is used to extract the value of the target key from the first element of the query result, including: In one optional approach, if the query result is not empty, the assertion module locates the first data entry in the result set according to the database's default sorting rules. Based on the target key in the key-value pair, it extracts the value of the corresponding field under that entry by matching the field name. If the target key does not exist, it throws a "field not found" exception and records the extraction process log.

[0080] In another optional approach, when the query result is not empty, the script first sorts the result set according to the preset sorting field, obtains the first element after sorting, and extracts the value corresponding to the target key through dictionary indexing. If the extraction fails, it is determined to be a data anomaly and a field extraction failure alarm is generated.

[0081] The process of converting the value of the target key to a string and matching it with the string obtained by converting the value of the target key in the key-value pair includes: In one alternative approach, the UTF-8 encoding format is used to convert the target key value extracted from the query results into a string. At the same time, the value of the target key in the key-value pair is also converted into a string with the same encoding format. After removing leading and trailing spaces and special characters such as newline characters and tabs, a character-by-character exact match is performed. If they match completely, the match is successful; otherwise, it fails.

[0082] In another alternative approach, the values ​​of the target key, including those in the query results and the values ​​in the key-value pairs, are converted into strings with a uniform format. Data type differences are ignored, such as converting the number 123 into the string "23" and the date into the format string "YYYY-MM-DD". Fuzzy matching is then performed, and if a match is found, the query passes; otherwise, it fails.

[0083] If a match is found, the query result is determined to meet the set expectations; if a match is not found, the query result is determined to not meet the set expectations, including: In one optional approach, if the strings match, the assertion module generates a "combination verification passed" flag, records the successfully matched field value, the converted string, and the key-value pair information, and updates the test status to "qualified"; if the matching does not match, a "verification failed" flag is generated, indicating the reason for the failure as "target key-value mismatch", and the difference between the actual value and the expected value is recorded and fed back to the upper-level logic.

[0084] In another optional approach, when a match is found, the script returns a "verification passed" signal, triggering the subsequent testing process and saving the matching details to the test log; when a match is not found, the script generates a difference comparison report, clearly showing the target key, the actual value (converted string), and the expected value (converted string), which helps testers quickly locate the problem and triggers a retry mechanism.

[0085] In this embodiment, a progressive verification of data existence and data update status is implemented. Data existence is ensured before data status is verified, avoiding invalid update status verification for empty data and improving the rationality and efficiency of the verification logic. By using unified string conversion to eliminate the impact of null values ​​on the matching results, the problem of null values ​​not being able to be directly matched is solved, improving the accuracy and compatibility of data update status verification.

[0086] In one feasible implementation, after performing a database query operation, verifying whether the query result meets the set expectations based on at least one of the data existence rule, data update status rule, and data quantity rule includes: Step 1214: After performing the database query operation, count the number of records in the query results according to the data quantity rules, and compare the number of records with the preset quantity threshold; Among them, the number of records refers to the number of valid data entries contained in the database query result set, which is the core object of data quantity rule verification.

[0087] Among them, the preset quantity threshold benefit value is the standard for the number of items set for the data quantity rules before the test. It can be a specific value such as 5 items, a value range such as 3-10 items, or a comparison condition such as greater than or equal to 2 items. It is the benchmark for judging whether the data quantity meets the standard.

[0088] In one alternative approach, after the database query operation is completed, the assertion module calls a counting function to count the number of valid entries in the query result set based on the data quantity rules. At the same time, it reads a preset quantity threshold, such as "greater than or equal to 3", and compares the counted number of records with the threshold. If the threshold is an interval, it determines whether the number of records is within the interval; if it is a specific value, it determines whether they are equal and records the comparison process.

[0089] In another optional approach, after enabling the data quantity rule, the script re-executes the statistical query using the database's built-in COUNT() function to obtain the number of records in the query results. This number is then compared with a preset quantity threshold, supporting various comparison logics such as greater than, less than, equal to, and range inclusion, to generate the comparison results.

[0090] Step 1215: If the number of records is greater than or equal to the preset quantity threshold, then the query results are determined to meet the set expectations; In one optional approach, when the number of records is greater than or equal to a preset quantity threshold, the assertion module generates a "quantity verification passed" flag, records the difference between the actual number of records and the threshold, updates the test status to "qualified", triggers the next test process, and notes the quantity compliance information in the log.

[0091] In another optional approach, if the comparison result shows that the number of records is greater than or equal to the preset threshold, the script returns a boolean value "True" to the upper-level test logic and generates a quantity verification report, which includes the query statement, the number of records, the preset threshold, and the comparison result, to facilitate test review. At the same time, the current quantity verification process is terminated.

[0092] Step 1216: If the number of records is less than the preset threshold, then the query results do not meet the set expectations.

[0093] In one optional approach, when the number of records is less than a preset threshold, the assertion module generates a "count verification failed" flag, indicating that the reason for the failure is "insufficient number of records". It records the difference between the actual number of records and the threshold, and at the same time feeds back the failure information to the retry control module, triggering the retry process, and waits for the data to be replenished before re-verifying.

[0094] In another optional approach, if the comparison result shows that the number of records is less than the preset threshold, the script generates a failure alarm, indicating the data quantity rule, the preset threshold, and the actual number of records, and saves it to the error log. At the same time, the current verification process is paused, and a retry instruction is awaited. If the maximum waiting time is reached, the process is terminated to ensure that the test process does not wait indefinitely.

[0095] This embodiment clarifies the specific verification process for data quantity rules. Quantity verification is achieved by comparing the number of records with a preset threshold, adapting to interface testing scenarios that require verification of batch data generation and updates, thus improving the scenario coverage of the testing method. Triggering a retry or termination process based on the quantity verification result can adapt to scenarios with database batch data synchronization delays, ensuring sufficient waiting time before the data count reaches the target, while avoiding infinite waiting, thus balancing testing accuracy and efficiency.

[0096] In one feasible implementation, the target parameters also include a database query statement and database connection information; responding to the test command of the target interface, invoking the database query method, and performing the database query operation after passing in the target parameters includes: Step 111: In response to the interface test command, call the database query method and pass the database connection information to the database query method to establish a communication connection with the database. Among them, database query statements refer to SQL statements used to retrieve data from the database, such as SELECT statements, which contain information such as query conditions, query fields, and sorting rules, and are the core instructions for executing database query operations.

[0097] Database connection information refers to the key information used to establish a communication connection between the test system and the database, which typically includes the database address, port number, database name, username, password, connection protocol, etc.

[0098] Among them, the communication connection is a stable data transmission link established between the test system and the database based on network protocols such as TCP / IP, which is the basis for executing query statements and obtaining query results.

[0099] In one optional approach, upon receiving the interface test instruction, the test system calls the database query method, passing in pre-configured database connection information, including address, port, username, password, etc., as a parameter object. For relational databases, the connection information can be parsed through the JDBC driver, and a connection request can be initiated. If the connection is successful, a stable communication link is established and the connection object is saved. If the connection fails, a connection exception is thrown, the exception information is recorded, and the process is terminated.

[0100] In another alternative approach, after responding to the test command, the script calls the database query method, passing in encrypted database connection information to avoid plaintext leakage. The method internally parses the connection information using a decryption algorithm and establishes a connection with the database based on the ODBC protocol. During the connection process, the validity of the username and password and permissions, such as query permissions, are verified. If the permissions are insufficient, the connection is rejected; if the verification is successful, a communication connection is established, and a connection timeout, such as 10 seconds, is set.

[0101] Step 112: Pass the database query statement to the database query method and execute the database query operation using the database query statement.

[0102] In one alternative approach, after establishing a communication connection, the test system passes a preset database query statement to the query method. The method sends the query instruction to the database through the connection object. After the database executes the statement, it returns a result set. The test system receives the result set and stores it temporarily. Then, based on the verification result, it decides whether to trigger a retry. If a retry is needed, the same query statement is sent again through the connection object, reusing the connection resources.

[0103] In another alternative approach, the script passes the database query statement to the query method, which optimizes the statement syntax before sending it to the database. After receiving the query results, the script converts the result set into a locally processable format. When executing the query, it only resends the query statement without re-establishing a database connection, thus reducing connection overhead. At the same time, it monitors the connection status and automatically reconnects and executes the query if the connection is broken.

[0104] This embodiment clarifies the database connection establishment process and query statement execution logic. By passing in connection information and query statements, the query operation is standardized, avoiding query failures caused by chaotic connection configurations and non-standard statement execution, thus improving the stability of the testing method. Reusing database connection resources avoids re-establishing a connection for each database query operation, reducing connection overhead and network latency, improving database query efficiency, and is particularly suitable for scenarios requiring multiple query retries, thus optimizing test time.

[0105] In one feasible implementation, the interface testing method of this application further includes: if the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, returning the current query result and the assertion failure exception result.

[0106] Among them, assertion failure exception results refer to the abnormal data generated when the cumulative waiting time reaches the maximum waiting time and the query results still do not meet expectations. This data includes the reason for failure, verification details, parameter information, etc., and is used to provide feedback on the details of the test failure to facilitate troubleshooting.

[0107] The current query result refers to the result set obtained from the last database query operation when the maximum waiting time is reached, and it is the core basis for analyzing the reasons for failure.

[0108] In one alternative approach, when the cumulative waiting time reaches the maximum threshold and the result of the last query still does not meet expectations, the test system calls the result return module. This module collects the result set of the last query, which includes complete data entries and metadata. At the same time, it generates an assertion failure exception result, which includes information such as the reason for failure, cumulative waiting time, maximum waiting time, number of retries, and assertion rules. The two are packaged and returned to the test initiator, and the test process is terminated.

[0109] In another optional approach, if the timeout and assertion failure conditions are met, the script converts the current query results into a JSON format that is easy to parse, generates an assertion failure exception report, which includes exception stack information, verification details, target parameter configuration, database connection information summary, etc. The result set and exception report are fed back to the test management platform through the interface. At the same time, the database connection is closed, resources are released, and the test task is marked as "failed".

[0110] In this embodiment, detailed query results and exception information are returned after a timeout failure, providing testers with a complete basis for troubleshooting. This avoids the difficulties in troubleshooting caused by simply informing the tester of the failure without details, and improves the efficiency of problem localization. The clearly defined feedback mechanism after a timeout failure enables the test initiator to obtain failure information in a timely manner, triggering subsequent processing flows and improving the closed-loop nature and automation of the testing process.

[0111] To better understand the above technical solutions of this application, refer to Figure 2 , Figure 2 This is a schematic diagram of the overall architecture of this application. The system architecture of this application includes a data interaction layer, a core logic layer, and an access layer.

[0112] The data interaction layer includes a multi-database driver adaptation module and a database connection pool module. The multi-database driver adaptation module supports databases such as MySQL, PostgreSQL, and Oracle. The database connection pool module is used to improve database connection efficiency.

[0113] The core logic layer includes a parameter management module, a timing control module, a database query execution module, a multi-dimensional assertion validation module, an intelligent retry control module, and a result processing and exception handling module. Specifically, the parameter management module stores and retrieves extended parameters; the timing control module initializes or calculates the accumulated wait time; the database query execution module executes SQL queries and retrieves results; the multi-dimensional assertion validation module validates query results using assertion rules; the intelligent retry control module re-executes the database query operation after waiting for the specified retry interval if the query result does not meet the set expectations; and the result processing and exception handling module diagnoses results.

[0114] The access layer includes an automation framework adaptation module and a parameter parsing module. The automation framework adaptation module supports pytest / unittest. The parameter parsing module is used to validate the validity of parameters.

[0115] The aforementioned extended parameters include the maximum wait time for query assertions, the query retry interval, and assertion rules.

[0116] To better understand the above technical solutions of this application, the following explanation uses examples. We take the "remote unlocking interface" for new energy vehicles as the test object. After a user calls the "remote unlocking interface" through a mobile app, the vehicle network backend asynchronously writes the unlocking record to the database, including fields such as the vehicle VIN code, unlocking time, and unlocking status. We write interface test logic using Python to verify whether the database can generate the corresponding VIN code unlocking record as expected after the interface is called, and whether the unlocking status is "unlocked," thereby determining whether the interface function is normal.

[0117] First, setting the core test parameters: The maximum wait time for a query assertion is 25 seconds. If no record matching the expectation is found within this time, the query will be terminated. Query retry interval: 5 seconds. Wait 5 seconds after each failed check before retrying. Assertion rules: Data existence rule + data update status rule, input key-value pair: vin: LSVHC49FXPH008888, unlock_status: unlocked; Database query statements; Database connection information: Address 192.168.3.10, Port 3306, Database name ev_vehicle, Username ev_test, Password EvTest@2026.

[0118] Second, the Python test script first establishes a communication connection with the ev_vehicle library based on the database connection information, and then uses a loop controlled by two conditions: the cumulative waiting time is less than the maximum waiting time and the verification fails. Each time, it performs the operation of "querying, verifying, and determining whether to retry" until the termination condition is met.

[0119] First query (0 seconds, total waiting time: 0 seconds): Trigger query: The Python script responds to the "Vehicle remote unlocking interface test command", calls the custom database query method, passes in all the above parameters, and reuses the established database connection to execute the preset SELECT query statement; Query result: Returns an empty result set; Assertion validation: If a key-value pair (vin and unlock_status) is detected, the data existence rule validation is performed first: if the result set is empty, it is directly determined that the query result does not meet the set expectations, and there is no need to perform the data update status rule validation; Subsequent operations: If the cumulative waiting time (0 seconds) has not reached the maximum waiting time (25 seconds), the script will execute the waiting logic, pause for 5 seconds (retry interval), and update the cumulative waiting time to 5 seconds, preparing to query again.

[0120] Second query (5 seconds, total waiting time 5 seconds): Re-query: After waiting for 5 seconds, the script reuses the established database connection (to avoid repeatedly establishing connections and consuming resources) and executes the same unlock record query statement again; Query result: Still returning an empty result set (the synchronization of vehicle network backend data is not yet complete); Assertion verification: Data existence rule validation: The result set is empty; it is determined that the query result does not meet the set expectations. Subsequent steps: If the cumulative waiting time (5 seconds) is less than 25 seconds, continue waiting for 5 seconds, update the cumulative waiting time to 10 seconds, and prepare for the next query.

[0121] Third query (10 seconds, total waiting time 10 seconds): Re-query: After waiting 5 seconds, the script will execute the query statement again; Query results: The result set returned contains 1 unlock record, vin=LSVHC49FXPH008888, unlock_status="Pending unlock", unlock_time=2026-01-2610:05:30; Assertion verification: Data existence rule validation: Result set is not empty, pass; Perform data update status rule validation: Extract the value of unlock_status ("to be unlocked") from the first element of the result set and convert it to a string; also convert the expected value of unlock_status ("unlocked") in the key-value pair to a string, and find inconsistencies after matching character by character; The query results do not meet the expected settings. Subsequent actions: Cumulative waiting time (10 seconds) < 25 seconds, wait 5 seconds, cumulative waiting time updated to 15 seconds, prepare to query again.

[0122] Fourth query (15 seconds, total wait time 15 seconds): Re-query: After waiting 5 seconds, the script will execute the query statement again; Query results: The result set returned contains 1 unlock record, vin=LSVHC49FXPH008888, unlock_status="unlocked", unlock_time=2026-01-2610:05:35; Assertion verification: Data existence rule validation: Result set is not empty, pass; Perform data update status rule validation: extract the unlock_status value ("unlocked") of the first record, convert it into a string, and match it with the string converted from the expected value in the key-value pair; Confirm that the query results meet the set expectations; Subsequent actions: The script immediately terminates the loop query operation, closes the database connection, and marks "Vehicle remote unlocking interface test passed".

[0123] Third, assuming that in the first 5 queries (0 / 5 / 10 / 15 / 20 seconds), either the result set is empty or the unlock status remains "pending unlock", when executing the 6th query: 6th query (25 seconds, total wait time 25 seconds): After executing the query, the result set still displays unlock_status="Pending unlocking"; Assertion validation: The data existence rule passed, but the data update status rule failed to match, and the overall judgment did not meet expectations; The cumulative waiting time (25 seconds) has reached the maximum waiting time (25 seconds); Follow-up operations: The script terminates the database query operation, closes the database connection, and releases resources; Returns the current query results, including vin=LSVHC49FXPH008888, unlock_status="Pending unlock", and assertion failure exception results, including: failure reason="timeout and unlock status not updated to 'unlocked'", cumulative waiting time=25 seconds, number of retries=5 times, assertion rule="vin=LSVHC49FXPH008888 exists and unlock_status=unlocked", etc. Mark "Vehicle remote unlocking interface test failed" and trigger an alarm to notify testers to investigate data synchronization issues with the interface or the vehicle network backend.

[0124] Through the above operations, the Python script controls the loop using "cumulative wait time and verification status". Each loop first executes a database query, then verifies the result according to the assertion rules. If it fails, it waits for the retry interval and then queries again until the result meets expectations or times out. After executing the database query, the assertion rule is selected based on whether a key-value pair is passed. If the verification passes, the loop terminates; if it fails but does not time out, it waits for a retry; if it times out, it returns a failure message. This logic is adapted to the asynchronous characteristics of interface calls and data writing in the new energy vehicle scenario, avoiding misjudgments caused by data synchronization delays. At the same time, timeout control avoids infinite waiting and ensures testing efficiency.

[0125] Figure 3 A schematic diagram of an embodiment of the interface testing device of the present invention is shown. Figure 3 As shown, the device 300 includes a response module 310 and a verification module 320. Wherein: The response module is used to respond to the test commands of the target interface, call the database query method, and execute the database query operation after passing in the target parameters. The target parameters include at least: the maximum wait time for query assertion, the query retry interval, and the assertion rules. The validation module is used to validate whether the query result meets the set expectations according to the assertion rules after the database query operation is executed. If the query result does not meet the set expectations, the database query operation is re-executed after waiting for the query retry interval. If the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, the database query operation is terminated.

[0126] In one optional approach, the assertion rules include at least one of data existence rules, data update status rules, and data quantity rules. After executing a database query operation, verifying whether the query results meet the set expectations based on the assertion rules includes: after executing the database query operation, verifying whether the query results meet the set expectations based on at least one of the data existence rules, data update status rules, and data quantity rules; wherein, the data existence rule is used to verify whether the query results contain data; the data update status rule is used to verify whether the data in the query results meets the expected value; and the data quantity rule is used to verify whether the data in the query results meets the quantity requirements.

[0127] In one alternative approach, after executing a database query operation, verifying whether the query result meets the set expectations based on at least one of the data existence rules, data update status rules, and data quantity rules includes: after executing the database query operation, checking whether a key-value pair has been passed in; if so, using the data existence rules and data update status rules to verify whether the query result meets the set expectations; if not, using the data existence rules to verify whether the query result meets the set expectations.

[0128] In one alternative approach, using data existence rules to verify whether the query results meet the set expectations includes: using data existence rules to verify whether the query results are empty; if not, determining that the query results meet the set expectations; if so, determining that the query results do not meet the set expectations.

[0129] In one optional approach, using data existence rules and data update status rules to verify whether the query results meet the set expectations includes: using data existence rules to check whether the query results are empty; if so, determining that the query results do not meet the set expectations; if not, using data update status rules to extract the value of the target key from the first element in the query results; converting the value of the target key into a string and matching it with the string obtained by converting the value of the target key in the key-value pair; if they match, determining that the query results meet the set expectations; if they do not match, determining that the query results do not meet the set expectations.

[0130] In one optional approach, after executing a database query operation, verifying whether the query result meets the set expectations based on at least one of the data existence rule, data update status rule, and data quantity rule includes: after executing the database query operation, counting the number of records in the query result according to the data quantity rule, and comparing the number of records with a preset quantity threshold; if the number of records is greater than or equal to the preset quantity threshold, it is determined that the query result meets the set expectations; if the number of records is less than the preset quantity threshold, it is determined that the query result does not meet the set expectations.

[0131] In one alternative approach, the target parameters also include a database query statement and database connection information. Responding to the interface test command, invoking the database query method and passing in the target parameters to perform the database query operation includes: responding to the interface test command, invoking the database query method, and passing in the database connection information to the database query method to establish a communication connection with the database; passing in the database query statement to the database query method and performing the database query operation using the database query statement.

[0132] In one optional approach, if the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, the current query result and assertion failure exception result are returned.

[0133] This invention, through a database query method, inputs the maximum waiting time for query assertions and the query retry interval. After a query, if the verification result meets expectations, the query and waiting immediately terminate, unlike related technologies which require a fixed waiting time. This maximizes interface testing efficiency. Secondly, compared to related technologies where asynchronous processing completion time exceeds a fixed waiting time, leading to assertion failures due to unwritten / updated data and misjudgments of interface functionality, resulting in inaccurate test results, this application does not execute a single query. Instead, it repeatedly queries at retry intervals until the data meets expectations or a timeout occurs, provided the cumulative waiting time has not reached the maximum waiting time. This ensures that premature queries do not lead to missed judgments. Upgrading the fixed waiting time to a maximum waiting threshold provides sufficient time for asynchronous processing, avoiding misjudgments due to insufficient waiting, and prevents infinite loops by terminating after the cumulative time reaches the target. After each database query operation, the result is verified according to the assertion rules, ensuring that data is detected as soon as it is available, rather than being verified all at once after a fixed waiting time, significantly improving the accuracy of assertions.

[0134] Figure 4 The diagram shows a structural schematic of an embodiment of the interface testing device of the present invention. The specific embodiments of the present invention do not limit the specific implementation of the interface testing device.

[0135] like Figure 4 As shown, the interface testing device may include: a processor 402, a communications interface 404, a memory 406, and a communications bus 408.

[0136] The processor 402, communication interface 404, and memory 406 communicate with each other via communication bus 408. Communication interface 404 is used to communicate with other network elements such as clients or other servers. The processor 402 executes program 410, specifically performing the relevant steps described in the interface testing method embodiment.

[0137] Specifically, program 410 may include program code, which includes computer-executable instructions.

[0138] Processor 402 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention. The interface testing equipment includes one or more processors, which may be processors of the same type, such as one or more CPUs; or processors of different types, such as one or more CPUs and one or more ASICs.

[0139] Memory 406 is used to store program 410. Memory 406 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0140] Specifically, program 410 can be called by processor 402 to cause the interface test device to perform the following operations: In response to the test command of the target interface, call the database query method, pass in the target parameters and execute the database query operation. The target parameters include at least: the maximum wait time for query assertion, the query retry interval, and the assertion rules. After executing a database query, the query results are verified to meet the set expectations according to the assertion rules. If the query results do not meet the set expectations, wait for the query retry interval and then re-execute the database query operation; If the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, the database query operation will be terminated.

[0141] In one optional approach, the assertion rules include at least one of data existence rules, data update status rules, and data quantity rules. After executing a database query operation, verifying whether the query results meet the set expectations based on the assertion rules includes: after executing the database query operation, verifying whether the query results meet the set expectations based on at least one of the data existence rules, data update status rules, and data quantity rules; wherein, the data existence rule is used to verify whether the query results contain data; the data update status rule is used to verify whether the data in the query results meets the expected value; and the data quantity rule is used to verify whether the data in the query results meets the quantity requirements.

[0142] In one alternative approach, after executing a database query operation, verifying whether the query result meets the set expectations based on at least one of the data existence rules, data update status rules, and data quantity rules includes: after executing the database query operation, checking whether a key-value pair has been passed in; if so, using the data existence rules and data update status rules to verify whether the query result meets the set expectations; if not, using the data existence rules to verify whether the query result meets the set expectations.

[0143] In one alternative approach, using data existence rules to verify whether the query results meet the set expectations includes: using data existence rules to verify whether the query results are empty; if not, determining that the query results meet the set expectations; if so, determining that the query results do not meet the set expectations.

[0144] In one optional approach, using data existence rules and data update status rules to verify whether the query results meet the set expectations includes: using data existence rules to check whether the query results are empty; if so, determining that the query results do not meet the set expectations; if not, using data update status rules to extract the value of the target key from the first element in the query results; converting the value of the target key into a string and matching it with the string obtained by converting the value of the target key in the key-value pair; if they match, determining that the query results meet the set expectations; if they do not match, determining that the query results do not meet the set expectations.

[0145] In one optional approach, after executing a database query operation, verifying whether the query result meets the set expectations based on at least one of the data existence rule, data update status rule, and data quantity rule includes: after executing the database query operation, counting the number of records in the query result according to the data quantity rule, and comparing the number of records with a preset quantity threshold; if the number of records is greater than or equal to the preset quantity threshold, it is determined that the query result meets the set expectations; if the number of records is less than the preset quantity threshold, it is determined that the query result does not meet the set expectations.

[0146] In one alternative approach, the target parameters also include a database query statement and database connection information. Responding to the interface test command, invoking the database query method and passing in the target parameters to perform the database query operation includes: responding to the interface test command, invoking the database query method, and passing in the database connection information to the database query method to establish a communication connection with the database; passing in the database query statement to the database query method and performing the database query operation using the database query statement.

[0147] In one optional approach, if the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectations, the current query result and assertion failure exception result are returned.

[0148] This invention, through a database query method, inputs the maximum waiting time for query assertions and the query retry interval. After a query, if the verification result meets expectations, the query and waiting immediately terminate, unlike related technologies which require a fixed waiting time. This maximizes interface testing efficiency. Secondly, compared to related technologies where asynchronous processing completion time exceeds a fixed waiting time, leading to assertion failures due to unwritten / updated data and misjudgments of interface functionality, resulting in inaccurate test results, this application does not execute a single query. Instead, it repeatedly queries at retry intervals until the data meets expectations or a timeout occurs, provided the cumulative waiting time has not reached the maximum waiting time. This ensures that premature queries do not lead to missed judgments. Upgrading the fixed waiting time to a maximum waiting threshold provides sufficient time for asynchronous processing, avoiding misjudgments due to insufficient waiting, and prevents infinite loops by terminating after the cumulative time reaches the target. After each database query operation, the result is verified according to the assertion rules, ensuring that data is detected as soon as it is available, rather than being verified all at once after a fixed waiting time, significantly improving the accuracy of assertions.

[0149] The algorithms or displays provided herein are not inherently related to any particular computer, virtual system, or other device. Furthermore, the embodiments of this invention are not directed to any particular programming language.

[0150] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. Similarly, for the sake of brevity and to aid in understanding one or more aspects of the invention, in the description of exemplary embodiments of the invention above, various features of the embodiments are sometimes grouped together in a single embodiment, figure, or description thereof. The claims, which follow the detailed description, are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0151] Those skilled in the art will understand that the modules in the device of the embodiment can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiment can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components, except that at least some of such features and / or processes or units are mutually exclusive.

[0152] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names. The steps in the above embodiments, unless otherwise specified, should not be construed as limiting the order of execution.

Claims

1. An interface testing method, characterized in that, The interface testing method includes: In response to the test command of the target interface, the database query method is called, and the database query operation is executed after passing in the target parameters. The target parameters include at least: the maximum waiting time for query assertion, the query retry time interval, and the assertion rules. After executing the database query operation, the query results are verified to meet the set expectations according to the assertion rules. If the query result does not meet the set expectation, the database query operation will be re-executed after the query retry time interval. If the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectation, the database query operation is terminated.

2. The interface testing method according to claim 1, characterized in that, The assertion rules include at least one of the following: data existence rules, data update status rules, and data quantity rules; The step of verifying whether the query result meets the set expectations according to the assertion rules after executing the database query operation includes: After executing a database query operation, the query result is verified to meet the set expectation based on at least one of the data existence rule, the data update status rule, and the data quantity rule. The data existence rule is used to verify whether the query result contains data; the data update status rule is used to verify whether the data in the query result meets the expected value; and the data quantity rule is used to verify whether the data in the query result meets the quantity requirements.

3. The interface testing method according to claim 2, characterized in that, After performing a database query operation, verifying whether the query result meets the set expectation based on at least one of the data existence rule, data update status rule, and data quantity rule includes: After performing a database query, check if a key-value pair has been passed in. If so, the data existence rule and the data update status rule are used to verify whether the query result meets the set expectation; If not, the data existence rules are used to verify whether the query results meet the set expectations.

4. The interface testing method according to claim 3, characterized in that, The step of using the data existence rule to verify whether the query result meets the set expectation includes: The data existence rules are used to verify whether the query result is empty; If not, it is determined that the query result meets the set expectation; If so, it is determined that the query result does not meet the set expectations.

5. The interface testing method according to claim 3, characterized in that, The step of verifying whether the query result meets the set expectation using the data existence rule and the data update status rule includes: The data existence rules are used to verify whether the query result is empty; If so, determine that the query result does not meet the set expectation; If not, the data update status rule is used to extract the value of the target key from the first element of the query result; the value of the target key is converted into a string and matched with the string obtained by converting the value of the target key in the key-value pair; if the match is consistent, the query result is determined to meet the set expectation; if the match is inconsistent, the query result is determined to not meet the set expectation.

6. The interface testing method according to claim 2, characterized in that, After performing a database query operation, verifying whether the query result meets the set expectation based on at least one of the data existence rule, data update status rule, and data quantity rule includes: After performing a database query operation, the number of records in the query results is counted according to the data quantity rules, and the number of records is compared with a preset quantity threshold. If the number of records is greater than or equal to the preset quantity threshold, then the query result is determined to meet the set expectation; If the number of records is less than the preset quantity threshold, then the query result is determined to be inconsistent with the set expectation.

7. The interface testing method according to claim 1, characterized in that, The target parameters also include a database query statement and database connection information; the step of responding to the interface test command, calling the database query method, and performing the database query operation after passing in the target parameters includes: In response to the interface test command, the database query method is invoked, and the database connection information is passed to the database query method to establish a communication connection with the database through the database connection information; The database query statement is passed to the database query method, and the database query operation is executed through the database query statement.

8. The interface testing method according to claim 1, characterized in that, The interface testing method also includes: If the cumulative waiting time reaches the maximum waiting time, and the query result does not meet the set expectation, return the current query result and the assertion failure exception result.

9. An interface testing device, characterized in that, The device includes: The response module is used to respond to the test command of the target interface, call the database query method, and execute the database query operation after passing in the target parameters. The target parameters include at least: the maximum waiting time for query assertion, the query retry time interval, and the assertion rules. The verification module is used to verify whether the query result meets the set expectation according to the assertion rules after the database query operation is executed; if the query result does not meet the set expectation, the database query operation is re-executed after waiting for the query retry time interval; if the cumulative waiting time reaches the maximum waiting time and the query result does not meet the set expectation, the database query operation is terminated.

10. An interface testing device, characterized in that, include: The processor, memory, communication interface, and communication bus are provided, wherein the processor, memory, and communication interface communicate with each other via the communication bus. The memory is used to store at least one executable instruction that causes the processor to perform the operation of the interface testing method as described in any one of claims 1-8.

Images