API interface test method, system and equipment based on large model and medium

Abstract

The invention relates to the technical field of software testing, and discloses an API interface testing method, system and device based on a large model and a medium, and the method comprises the following steps: obtaining one or more known correct historical responses of an API interface as training samples; and instructing a preset large model to carry out inductive analysis on the training sample to generate a group of invariance rules, verifying a response body of the to-be-tested response based on the invariance rules, obtaining the to-be-tested response returned by the to-be-tested API interface, and sending the to-be-tested response to the to-be-tested API interface under the condition that the HTTP state code of the to-be-tested response indicates success. And judging whether the response content has a logical defect violating the invariance rule or not. According to the invention, the verification dimension is deepened from the HTTP response code in the prior art to a plurality of semantic levels of the internal structure, type, data association and the like of the response body. Through deep semantic verification, a large number of logic layer defects can be accurately captured, and the missing report rate of software defects is remarkably reduced.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to API interface testing methods, systems, devices, and media based on large models. Background Technology

[0002] This invention belongs to the fields of software testing technology and artificial intelligence technology, specifically relating to a method and system for automated testing of application programming interfaces (APIs), and in particular a technology for intelligent verification of test results using a large language model.

[0003] Currently, applying artificial intelligence, especially Large Language Models (LLM), to API testing to improve automation efficiency is a hot research topic in the industry. Existing technologies mainly focus on the following two directions: 1. Generating test cases using large models. This type of technology obtains the user's natural language description of the interface or the interface definition file, and calls a large model to automatically generate test input data or test scripts. Its core lies in using a large model to assist in the generation of test input.

[0004] 2. Using large models or machine learning for simple result prediction. Some of these techniques use large models to generate abnormal scenario test cases based on positive test cases, while others learn from historical data to predict the HTTP response codes that may be returned after the test cases are executed. The core of these techniques lies in using AI technology to expand test cases or predict the shallow state of test results.

[0005] However, while the aforementioned existing technologies have made progress in test case generation and initial screening, they still have the following shortcomings that urgently need to be addressed: 1. The verification dimensions of the test results are too superficial, resulting in a high risk of false negatives. Both of the above-mentioned solutions only assess the correctness of the test results at a superficial level. For example, the verification endpoint is merely the HTTP response code (such as 200, 404, 500, etc.). In practical applications, many software defects are hidden in successful HTTP responses with a status code of 200 OK. These defects may include incorrect data structures, data content that does not conform to business logic, missing key fields, or incompatible data types. Existing technologies lack effective automated verification capabilities for such "logical" defects, leading to a high false negative rate and ultimately requiring significant manpower for manual review.

[0006] 2. The generation and maintenance of "Test Oracles" are costly. In automated testing, the logic or data used to determine whether a test result is correct is called a "Test Oracle." Traditionally, oracles are manually written and maintained by testers, which is costly and logically rigid. While existing AI solutions attempt to address this issue, the knowledge bases they rely on or the historical datasets used for model training often suffer from significant cold-start problems (i.e., a lack of initial data for new interfaces or systems) and high data preparation and maintenance costs.

[0007] Therefore, how to achieve in-depth and automated logical correctness verification of API response content and reduce the construction and maintenance costs of test oracles is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0008] To address the problems existing in the prior art, this invention provides an intelligent API response verification method and system based on large model self-learning invariant rules, specifically including: API interface testing methods based on large models include the following steps: Obtain one or more known correct historical responses from the API interface as training samples; The pre-defined large model of instruction 1 performs inductive analysis on the training samples to generate a set of invariant rules, wherein the invariant rules are used to define the paradigm that the correct response body of the API interface should follow in terms of internal structure, data type or data association; Based on the invariance rule, the response body of the response to be tested is verified, and the response to be tested returned by the API interface to be tested is obtained. If the HTTP status code of the response to be tested indicates success, it is determined whether there is a logical defect in the response content that violates the invariance rule.

[0009] Preferably, the invariance rule includes at least one or more of the following: Structural invariance rules are used to define the keys and their hierarchical relationships that the response body must contain; Type invariance rules are used to define the data type that the values ​​of specific fields in the response body must conform to; Range or enumeration invariance rules are used to define a preset set or range of values ​​that a specific field in the response body must belong to. Association invariance rules are used to define the logical or arithmetic relationships that must be satisfied between the values ​​of two or more fields in the response body.

[0010] Preferably, after generating the invariant rule, the method further includes: associating the invariant rule with the unique identifier of the API interface and storing it in a rule base for querying and loading by the response verification step.

[0011] Preferably, it also includes the following steps: When a response to be tested is determined to have a logical defect, a user interface is provided for testers to perform manual arbitration to confirm whether it is a real defect or a false alarm. The invariance rule is updated based on feedback that the result of the manual arbitration is a false alarm.

[0012] Preferably, the step of updating the invariance rule includes at least one of the following methods: Disable one or more invariant rules that cause the false positives; The test responses that are judged as false alarms are used as one or more counterexamples, and together with the original training samples, are provided to the large model again to trigger the relearning of the invariant rules.

[0013] Preferably, the method for generating a set of invariant rules by performing inductive analysis on the training samples using a pre-defined large model includes: The instruction states that the large model analyzes the training samples to inductively generate a set of formalized invariant rules; Provide a definition of the type of the invariant rule to guide the large model in generating rules that meet expectations.

[0014] Preferably, the method for determining whether the response content has a logical defect that violates the invariance rule includes: The response body of the test response is verified one by one using the aforementioned invariance rules; When the response body of the response to be tested violates at least one of the invariance rules, it is determined that the response content has a logical defect.

[0015] This invention also provides an API interface testing system based on a large model, including: The invariance rule learning module is configured for: Obtain one or more known correct historical responses from an API interface as training samples; and, The pre-defined large model of instruction 1 performs inductive analysis on the training samples to generate a set of invariant rules, wherein the invariant rules are used to define the paradigm that the correct response body of the API interface should follow in terms of internal structure, data type or data association; The response verification module is configured for: Obtain the test response from the API interface; and, Based on the invariance rule, the response body of the response to be tested is verified, so as to determine whether there is a logical defect in the response content that violates the invariance rule if the HTTP status code of the response to be tested indicates success.

[0016] The present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0017] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described method.

[0018] Beneficial effects 1. Significantly improves defect detection capabilities and reduces false negative rates. This invention deepens the verification dimension from existing HTTP response codes to multiple semantic levels, including the structure, type, and data relationships within the response body. Through deep semantic verification, it can accurately capture a large number of logical layer defects hidden beneath the 200 OK success response, which are often missed by traditional automated testing methods, significantly reducing the false negative rate of software defects.

[0019] 2. Significantly improves automation efficiency and testing depth. This invention automates the most time-consuming and experience-dependent stages of the testing process—result analysis and assertion—through large-scale model learning to generate rules. This not only frees testers from tedious response data comparison but also enables in-depth verification of complex business logic, greatly improving the efficiency and depth of automated testing.

[0020] 3. Adaptive evolution of verification logic is achieved. This invention introduces a closed-loop process of "human arbitration-feedback-rule optimization," enabling the verification system to continuously learn and improve itself. Verification rules can adaptively evolve along with the rapid iteration of the tested business, ensuring the long-term accuracy and effectiveness of the verification logic and giving it greater vitality. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating an API interface testing method based on a large model provided in a preferred embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of an API interface testing system based on a large model, provided in a preferred embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this disclosure clearer, the disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this disclosure.

[0023] Furthermore, it should be noted that, unless otherwise expressly specified and limited, the terms "set," "install," "connect," "link," and "fix" in this disclosure should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this disclosure according to the specific circumstances.

[0024] Throughout this specification, references to "an embodiment," "some embodiments," "an example," "a specific example," or "some specific examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this disclosure. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0025] Example 1 This embodiment provides a method for testing API interfaces based on a large model. (Refer to...) Figure 1 The figure illustrates a method flowchart according to an embodiment of the present disclosure. The method steps provided in this disclosure will now be described in detail with reference to a specific, consistent example.

[0026] Example scenario: Suppose we need to test an API for retrieving user information, with the URI GET / api / v1 / users / {userId}.

[0027] Phase 1: Learning and Generating Invariant Rules Step S201: Obtain one or more known correct historical responses from the API interface as training samples.

[0028] This step aims to prepare high-quality input data for rule learning. In one implementation, this step can be performed by a data acquisition and preprocessing module 101 (see [reference]). Figure 2This module can be configured to connect to one or more data sources, such as the logging systems of a production environment (where the underlying instance could be ELK Stack, Splunk) or the logging of an API gateway (where the underlying instance could be Kong, Apigee).

[0029] This step can further include filtering historical responses based on the API's unique identifier (e.g., a combination of the GET method and the path / api / v1 / users / *). To obtain "known correct" responses, the filtering criteria could be "HTTP status code 200" and "response latency below a certain preset threshold (e.g., 200ms)" to initially filter out responses with obvious errors and performance anomalies.

[0030] Step S202: Instruction 1 uses a pre-defined large model to perform inductive analysis on the training samples to generate a set of invariant rules.

[0031] This step is the purpose of this method to automatically extract the paradigm that the API response body should follow. In one implementation, this step can be accomplished by an invariant rule learning module 102 (see [reference]). Figure 2 The core task of this module is to construct a valid instruction (e.g., a prompt or hint) and call a pre-configured large model 1021 to generate rules.

[0032] The large model 1021 can be a pre-trained artificial intelligence model with advanced natural language understanding and logical induction capabilities. For example, the model can be a general-purpose large language model based on the Transformer architecture (such as OpenAI's GPT series models, Meta's Llama series models, Google's Gemini series models, etc.), or any other open-source or commercial model with similar capabilities.

[0033] Preferably, this step may specifically include: 1. Provide a definition of the type of the invariant rule to guide the large model in generating rules that meet expectations.

[0034] 2. The instruction states that the large model analyzes the training samples to summarize and generate a set of formal invariant rules.

[0035] Here is a structured hint example that can be used for instruction big model 1021: ###Role### You are a top-tier API test automation expert and software architect, proficient in RESTful API design patterns, JSON Schema, and data consistency verification.

[0036] ###Task### Your task is to analyze the following set of successful API response JSON samples. Based on these samples, summarize and generate a set of formalized "invariant rules" for this API. These rules need to capture the common structural, type, format, and logical constraints that must be followed in all samples.

[0037] ###Rule Type Definition### The rules you generate must belong to one of the following four types: 1. **STRUCTURAL**: Structural invariance. Used to define the keys that the response body must contain and their hierarchical relationships. Please use JSON Schema format to express this.

[0038] 2. **TYPE**: Type immutability. Used to define the data type (such as string, number, boolean, array, object) that the numeric values ​​in a specific field must conform to.

[0039] 3. **RANGE_ENUM**: Range or enumeration invariance. Used to define a preset set, range of values, or specific format (such as a regular expression) that a particular field's values ​​must belong to.

[0040] 4. **RELATIONAL**: Association Invariance. Used to define the logical or arithmetic relationship that must be satisfied between the values ​​of two or more fields.

[0041] ###Output Format### Please strictly adhere to the following JSON array format when outputting the rule list. Each rule object must contain three fields: "rule_id", "rule_type", and "expression". - For "STRUCTURAL" rules, the "expression" field should be a JSON Schema object. - For other rules, the "expression" field should be a string describing the constraint.

[0042] ###API Response Samples to be Analyzed### {"code":0,"message":"Success","data":{"user_id":101,"username":"test_user_1","email_verified":true,"level":3,"credits":150,"profile":{"age":28,"city":"Beijing"},"tags":["premium","active"]}}, {"code":0,"message":"Success","data":{"user_id":102,"username":"test_user_2","email_verified":false,"le vel":5,"credits":480,"profile":{"age":35,"city":"Shanghai"},"tags":["premium","active","beta_tester"]}} Based on the above instructions and samples, after inductive analysis, the large model 1021 can generate the following formalized set of invariant rules, which supports the above-mentioned multiple rule types.

[0043] Specifically, invariance rules can include one or more of the following: 1. Structural Invariance Rules: For example, a rule could define that the root node of the response body must contain two keys, "data" and "pagination," and the value of "data" must be an array. This defines the keys that the response body must contain and their hierarchical relationships.

[0044] 2. Type Invariance Rules: For example, a rule could define that the value of the "userId" field in each element of the "data" array must be a number. This is used to define the data type that a specific field value must conform to.

[0045] 3. Range or Enumeration Invariance Rules: For example, a rule could define that the "status" field value of each element in the "data" array must be one of the three strings: ['active', 'inactive', 'suspended']. This is used to define a preset set or range of values ​​that a specific field value must belong to.

[0046] 4. Association Invariance Rules: For example, a rule can define that the value of the "pagination.total" field must be greater than or equal to the number of elements in the "data" array. This is used to define a logical or arithmetic relationship that must be satisfied between the values ​​of two or more fields in the response body.

[0047] Step S203: Associate the invariance rule with the unique identifier of the API interface and store it in a rule base.

[0048] This step is optional and its purpose is to persistently store and manage the generated rules for subsequent verification steps to query and load. In one implementation, the rules can be stored in a rule base 103 (see...). Figure 1 This rule base can be implemented using any persistent storage system, such as a relational database (e.g., MySQL), a document database (e.g., MongoDB), or a key-value store (e.g., Redis). In one embodiment, a table named `api_invariants` can be designed in the rule base 103 to store the rules. The invariant rule learning module 102 can store each rule generated in the previous step into this table and associate it with the API identifier GET: / api / v1 / users.

[0049] Phase Two: Real-time Response Verification Step S204: Based on the invariance rule, verify the response body of the response to be tested.

[0050] This stage involves applying learned rules to identify potential defects. In one implementation, this process can be performed by a real-time response verification module 104 (see reference). Figure 1 ) to execute.

[0051] This verification step is performed under the premise that the test response is obtained from the API interface under test. If the HTTP status code of the test response indicates success, subsequent logical defect judgment is performed. The "success" status code here can be any status code in the range of 200-299, such as 200 OK or 201 Created.

[0052] Specifically, this verification step may include: 1. Based on the unique identifier of the API under test, load all associated and active immutability rules from rule base 103.

[0053] 2. Verify the response body of the test response by applying the invariance rules one by one.

[0054] 3. When the response body of the response to be tested violates at least one of the invariance rules, it is determined that the response content has a logical defect.

[0055] In a preferred embodiment, a specific example of verification is given, assuming that the following response to be tested (with an HTTP status code of 200 OK) is obtained in an automated testing process: "code":0, "message":"Success", "data":{ "user_id":205, "username":"new_user", "email_verified":true, "level":4, "credits":180, / / <-- There is a logical flaw here. "profile":["age":25,"city":"Xian", "tags":["active"] The verification process is as follows: Rule STR-001 (structure): Validation passed.

[0056] Rule TYPE-001 (Type): Validation passed.

[0057] Rule ENUM-001 (enumeration): Validation passed.

[0058] Rule REL-001 (Association): Validation failed. Because the actual credits value of 180 does not meet the condition of >= level value 4 multiplied by 50 (i.e., 200).

[0059] Because the response violated rule REL-001, it was determined that the response content had a logical flaw, and a detailed report could be generated that clearly pointed out the business logic error hidden behind the successful response.

[0060] Phase 3: Human Feedback and Model Optimization To enable the method to be adaptive, in a preferred embodiment, the method may further include steps of manual feedback and model optimization. These steps may be performed by a feedback and model optimization module 105 (see reference). Figure 2 ( ) to assist in implementation.

[0061] Step S207: Provide a user interface for testers to perform manual arbitration.

[0062] When a response under test is determined to have a logical defect, a user interface (such as a web dashboard) can be provided to the tester to display the failure details, allowing them to arbitrate whether the determination is a genuine defect or a false alarm.

[0063] Step S208: Update the invariance rule based on the feedback that the result of the manual arbitration is a false alarm.

[0064] Furthermore, this update step may include at least one of the following methods: Simple Mode (Rule Disabled): Disables one or more invariant rules that caused the false positive. If a tester deems rule REL-001 too harsh or outdated, they can disable it directly in the UI. This is done by updating the rule's is_active field to false in rule base 103.

[0065] Advanced mode (rule relearning): Test responses judged as false positives are used as one or more counterexamples, along with the original training samples, and then fed back to the large model to trigger the relearning of the invariant rules. This approach can drive the large model to generate more accurate rules; for example, it might optimize the REL-001 expression to data.credits>=data.level*40.

[0066] In another optional implementation, when step S206 determines that the response content has a logical defect, the real-time response verification module 104 will also generate a detailed verification report. This report can clearly indicate the specific invariant rule violated (e.g., rule ID and rule content), as well as the actual content in the response under test that does not conform to the rule (e.g., expecting "userId" to be a number, but actually being the string "null"), so that developers can quickly locate and fix the defect.

[0067] Example 2 like Figure 2 As shown, this embodiment provides an API interface testing system based on a large model, which is used to execute the method described in Embodiment 1 above.

[0068] Reference Figure 1 In one implementation, the system may include: The invariance rule learning module 102 is configured to perform the steps in the above method, such as obtaining training samples (or cooperating with the data acquisition module) and inductively generating invariance rules.

[0069] The response verification module 104 is configured to perform steps such as verifying and judging the response to be tested based on invariance rules in the above method.

[0070] In a preferred embodiment, the system may further include: The data acquisition and preprocessing module 101, as one of the system's input terminals, connects to an external log system or API gateway via a network connection (e.g., via HTTP API calls or database connections). It periodically or on demand pulls raw response data, processes it, and then transmits formatted training sample data (e.g., a JSON array) to the invariant rule learning module 102 via internal function calls or message queues (such as RabbitMQ, Kafka).

[0071] Rule base 103, a persistent storage facility, is configured to store and manage invariant rules generated by invariant rule learning module 102 and to respond to query requests from response verification module 104. It is a persistent storage facility. It is bidirectionally connected to both invariant rule learning module 102 and response verification module 104.

[0072] Write operation connection: After generating rules, the invariant rule learning module 102 establishes a database connection to the rule base 103 and executes write operations (e.g., SQL INSERT or UPDATE commands) to write the new rule data to the rule base 103.

[0073] Read operation connection: Before starting the verification, the response verification module 104 establishes a database connection to the rule base 103 and performs a read operation (e.g., a SQL SELECT command) to read the rule data that matches the current API identifier into its memory.

[0074] The feedback and model optimization module 105 is configured to provide a human-computer interaction interface and, based on user feedback, execute updates to the rules in the rule base 103 or trigger a relearning process in the invariant rule learning module 102. This module serves as a central hub for human-computer interaction and control, and is connected to several other modules.

[0075] Input connection: After determining the logical defect, the response verification module 104 can send a verification report containing the response to be tested and failure details to the feedback and model optimization module 105 for display on the user interface.

[0076] Control output connection 1: When the user selects "Disable rule" on the interface, the feedback and model optimization module 105 sends an update instruction to the rule base 103 (for example, an SQLUPDATE command that sets the is_active field of a specific rule to false).

[0077] Control output connection 2: When the user selects "relearn", the feedback and model optimization module 105 will send the response data as a counterexample along with a relearning instruction to the invariant rule learning module 102 to trigger a new round of rule generation process.

[0078] Within the entire system, the response verification module 104 also has a primary external input connection: it receives real-time test response data from the running automated testing framework via function calls, method hooks, or network requests. Simultaneously, it also has a primary external output connection: it returns the final verification conclusion ("normal" or "abnormal" and a report) to the testing framework or outputs it to the logging system.

[0079] These modules can be independent software services or different functional components integrated into the same testing platform. Their specific interactions and functions have been described in detail in the above method description and will not be repeated here.

[0080] Other implementation methods This disclosure is not limited to the embodiments described above. Those skilled in the art can make various equivalent modifications or substitutions. For example, regarding the implementation of the verification engine, in an alternative embodiment, the response verification module 104 can directly compile formal invariant rules into executable assertion code snippets (e.g., generate Python assert statements or Java assertion methods) and dynamically inject them into the post-test hook of a test execution framework (such as Pytest, JUnit) for execution, thereby achieving tighter integration with existing test frameworks.

[0081] The methods described above in this disclosure can be implemented by a computer program. Therefore, this disclosure also provides a computer device including a memory and a processor. The memory is used to store a computer program, and the processor is used to execute the computer program to implement the method steps of any one of claims 1 to 7. This computer device can be a server, a personal computer, an embedded system, or any other computing device capable of executing programs.

[0082] This disclosure also provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, it implements the method steps of any one of claims 1 to 7. The storage medium may be non-volatile, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or it may be volatile, such as random access memory (RAM).

[0083] The above description is merely a preferred embodiment of this disclosure and is not intended to limit this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the protection scope of this disclosure.

Claims

1. An API interface testing method based on a large model, characterized in that, Including the following steps: Obtain one or more known correct historical responses from the API interface as training samples; The pre-defined large model of instruction 1 performs inductive analysis on the training samples to generate a set of invariant rules, wherein the invariant rules are used to define the paradigm that the correct response body of the API interface should follow in terms of internal structure, data type or data association; Based on the invariance rule, the response body of the response to be tested is verified, and the response to be tested returned by the API interface to be tested is obtained. If the HTTP status code of the response to be tested indicates success, it is determined whether there is a logical defect in the response content that violates the invariance rule.

2. The method according to claim 1, characterized in that, The invariance rules include at least one or more of the following: Structural invariance rules are used to define the keys and their hierarchical relationships that the response body must contain; Type invariance rules are used to define the data type that the values ​​of specific fields in the response body must conform to; Range or enumeration invariance rules are used to define a preset set or range of values ​​that a specific field in the response body must belong to. Association invariance rules are used to define the logical or arithmetic relationships that must be satisfied between the values ​​of two or more fields in the response body.

3. The method according to claim 1, characterized in that, After generating the invariant rule, the method further includes associating the invariant rule with the unique identifier of the API interface and storing it in a rule base for querying and loading by the response verification step.

4. The method according to claim 1, characterized in that, It also includes the following steps: When a response to be tested is determined to have a logical defect, a user interface is provided for testers to perform manual arbitration to confirm whether it is a real defect or a false alarm. The invariance rule is updated based on feedback that the result of the manual arbitration is a false alarm.

5. The method according to claim 4, characterized in that, The step of updating the invariant rule includes at least one of the following methods: Disable one or more invariant rules that cause the false positives; The test responses that are judged as false alarms are used as one or more counterexamples, and together with the original training samples, are provided to the large model again to trigger the relearning of the invariant rules.

6. The method according to claim 1, characterized in that, The method for generating a set of invariant rules by performing inductive analysis on the training samples using a pre-defined large model includes: The instruction states that the large model analyzes the training samples to inductively generate a set of formalized invariant rules; Provide a definition of the type of the invariant rule to guide the large model in generating rules that meet expectations.

7. The method according to claim 1, characterized in that, The method for determining whether the response content has a logical flaw that violates the invariance rule includes: The response body of the test response is verified one by one using the aforementioned invariance rules; When the response body of the response to be tested violates at least one of the invariance rules, it is determined that the response content has a logical defect.

8. An API interface testing system based on a large model, characterized in that, include: The invariance rule learning module is configured for: Obtain one or more known correct historical responses from an API interface as training samples; as well as, The pre-defined large model of instruction 1 performs inductive analysis on the training samples to generate a set of invariant rules, wherein the invariant rules are used to define the paradigm that the correct response body of the API interface should follow in terms of internal structure, data type or data association; The response verification module is configured for: Obtain the test response from the API interface; and, Based on the invariance rule, the response body of the response to be tested is verified, so as to determine whether there is a logical defect in the response content that violates the invariance rule if the HTTP status code of the response to be tested indicates success.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images