Use case testing method, system and device

Abstract

The application discloses a use case test method, system and device, relates to the technical field of data processing, and comprises the following steps: performing document analysis and SQL identification extraction on an application programming interface document uploaded by a user to obtain interface metadata and SQL identification; checking the interface metadata based on a preset triple verification rule, and determining test running parameters according to the interface metadata that passes the verification; generating full-amount test cases according to the interface metadata, the SQL identification and the test running parameters; and executing the test based on the full-amount test cases to obtain a test result. Compared with the prior art, the application focuses on a single test dimension, has low test pertinence and coverage, and is difficult to meet the API automatic test demand in the micro-service field. The application forms a set of API full-process automatic test scheme which is highly adaptive, highly reliable and can be automatically iterated and optimized, significantly improves the pertinence, comprehensiveness and stability of the test, and meets the API automatic test demand in the Web / micro-service field.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to test case testing methods, systems and devices. Background Technology

[0002] In the field of API (Application Programming Interface) automated testing, APIs are the core interaction carriers of Web / microservice architectures, and their functional stability directly determines the system's operational quality. Related automated testing technologies have become a key focus of industry research and application. Multi-agent collaboration technology, due to its modular and collaborative advantages, has been applied to this scenario, automating the testing process, reducing manual intervention, and improving basic testing efficiency. However, existing technologies often focus on a single testing dimension and lack deep adaptation to the business characteristics of RESTful APIs. They lack sufficient support for requirements such as SQL (Structured Query Language) verification for interfaces ending in / query, multi-environment configuration management, and dynamic optimization of test strategies. This results in low test targeting and coverage, making it difficult to meet the Web / microservice domain's demand for fully automated, highly adaptable testing of RESTful APIs. Summary of the Invention

[0003] The main purpose of this application is to provide a test case testing method, system and device, which aims to solve the technical problems that existing solutions focus on a single testing dimension, have low testing relevance and coverage, and are difficult to meet the API automation testing needs of the microservice domain.

[0004] To achieve the above objectives, this application proposes a test case testing method, the method comprising: The application programming interface (API) documentation uploaded by users is parsed and SQL identifiers are extracted to obtain API metadata and SQL identifiers. The interface metadata is verified based on a preset triple verification rule, and the test running parameters are determined based on the interface metadata that passes the verification. Generate a full set of test cases based on the interface metadata, the SQL identifier, and the test execution parameters; Tests are executed based on the full set of test cases to obtain test results.

[0005] In one implementation, the step of parsing the user-uploaded application programming interface (API) document and extracting the SQL identifier to obtain interface metadata and the SQL identifier includes: Perform document integrity verification on the application programming interface documents uploaded by users and obtain the integrity verification results; Based on the integrity verification result, the application programming interface document is parsed to obtain interface metadata; The query-type interfaces that meet the preset conditions in the interface metadata are identified by the SQL field to obtain the SQL identifier.

[0006] In one implementation, the preset triple verification rules include format compliance verification rules, business rationality verification rules, and SQL identifier adaptation verification rules. The step of verifying the interface metadata based on the preset triple verification rules and determining test execution parameters based on the verified interface metadata includes: Based on the format compliance verification rules, the parameter data type and value range corresponding to the interface metadata are verified for compliance, and the format compliance verification result is obtained. Based on the business-appropriate verification rules, the parameters corresponding to the interface metadata are verified to be compatible with the interface business scenario to obtain the business-appropriate verification result. Based on the SQL identifier adaptation verification rules, the parameters corresponding to the interface metadata are verified to match the SQL identifier, and the SQL identifier adaptation verification result is obtained. When the format compliance verification result, the business rationality verification result, and the SQL identifier adaptation verification result all pass, the test run parameters are determined based on the interface metadata that has passed the verification.

[0007] In one implementation, generating a full set of test cases based on the interface metadata, the SQL identifier, and the test execution parameters includes: Generate a full set of test cases based on the interface metadata, the SQL identifier, the test execution parameters, and the preset test case generation template; The preset test case generation module includes a basic test case generation template, a security test case generation template, and a large language model enhanced test case generation template.

[0008] In one implementation, generating a full set of test cases based on the interface metadata, the SQL identifier, the test execution parameters, and a preset test case generation template includes: Generate general basic test cases based on the interface metadata, the SQL identifier, the test run parameters, and the basic test case generation template, and generate SQL basic verification test cases for the interface with the SQL identifier; Generate SQL-specific security test cases based on the interface metadata, the SQL identifier, the test execution parameters, and the security test case generation template; Based on the interface metadata, the SQL identifier, the test run parameters, and the large language model enhanced test case generation template, generate complex business scenario test cases, combined parameter test cases, and personalized edge scenario test cases; Generate a full set of test cases based on the general basic test cases, the SQL basic verification test cases, the SQL-specific security test cases, the complex business scenario test cases, the combined parameter test cases, and the personalized edge scenario test cases.

[0009] In one implementation, the step of executing tests based on the full set of test cases to obtain test results includes: Based on the test execution and result verification agent, the request method verification, basic response verification and data format verification are performed on the full set of test cases to obtain the first verification result; Perform SQL-specific verification on the interface carrying the SQL identifier to obtain the second verification result; The test result is determined based on the first verification result and the second verification result.

[0010] In one implementation, after executing the test based on the full set of test cases and obtaining the test results, the method further includes: Generate a test report using the test results, the SQL identifier, and all test cases. Based on the test report, an association optimization strategy bound to the SQL identifier is generated; The test process is executed based on the aforementioned correlation optimization strategy.

[0011] In one implementation, the step of executing the test process based on the correlation optimization strategy includes: Valid optimization rules are selected based on the aforementioned correlation optimization strategy; The test execution parameters are adjusted based on the effective optimization rules, and the test process is executed based on the adjusted test execution parameters.

[0012] Furthermore, to achieve the above objectives, this application also proposes a use case testing system, which includes: The text parsing agent is used to parse user-uploaded application programming interface (API) documents and extract SQL identifiers to obtain API metadata and SQL identifiers. A configuration management intelligent agent is used to verify the interface metadata based on a preset triple verification rule, and to determine the test running parameters based on the verified interface metadata. A test case generation agent is used to generate a full set of test cases based on the interface metadata, the SQL identifier, and the test run parameters. The test execution and result verification agent is used to execute tests based on the full set of test cases and obtain test results.

[0013] In addition, to achieve the above objectives, this application also proposes a use case testing device, which includes: a memory, a processor, and a use case testing program stored in the memory and executable on the processor, wherein the use case testing program is configured to implement the use case testing method described above.

[0014] One or more technical solutions proposed in this application have at least the following technical effects: This application obtains interface metadata and SQL identifiers by parsing user-uploaded application programming interface (API) documents and extracting SQL identifiers. It then verifies the interface metadata based on preset triple verification rules and determines test execution parameters based on the verified metadata. Finally, it generates a full set of test cases based on the interface metadata, SQL identifiers, and test execution parameters. The application executes the tests based on these test cases to obtain test results. Compared to existing solutions that often focus on a single test dimension and have low test relevance and coverage, making it difficult to meet the API automation testing needs of the microservices domain, this application provides a complete closed loop from document parsing, test case generation, test execution, result verification to strategy optimization. This forms a highly adaptable, highly reliable, and automatically iteratively optimized API end-to-end automated testing solution, significantly improving the relevance, comprehensiveness, and stability of testing, and meeting the API automation testing needs of the Web / microservices domain. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating the first embodiment of the test case testing method in this application. Figure 2 This is a schematic diagram of the overall system architecture provided in Embodiment 1 of the test case testing method of this application; Figure 3 This is a flowchart illustrating the second embodiment of the test case testing method in this application. Figure 4 This is a flowchart illustrating the test case testing method embodiment three of this application; Figure 5This is a flowchart illustrating the workflow of Embodiment 3 of the test case testing method in this application. Figure 6 This is a schematic diagram of the module structure provided in Embodiment 1 of the test case testing system of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the test case testing method in this application embodiment.

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

[0019] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] The main solution of this application embodiment is as follows: by parsing the application programming interface document uploaded by the user and extracting the SQL identifier, the interface metadata and SQL identifier are obtained; the interface metadata is verified based on the preset triple verification rules, and the test running parameters are determined based on the verified interface metadata; a full set of test cases are generated based on the interface metadata, SQL identifier and test running parameters; the test is executed based on the full set of test cases to obtain the test results.

[0022] Existing solutions often focus on a single testing dimension, resulting in low testing relevance and coverage, which makes it difficult to meet the needs of the microservice domain for API automated testing.

[0023] This application provides a solution that parses user-uploaded application programming interface (API) documents and extracts SQL identifiers to obtain API metadata and SQL identifiers. It then verifies the API metadata based on preset triple verification rules and determines test execution parameters based on the verified metadata. Finally, it generates a full set of test cases based on the API metadata, SQL identifiers, and test execution parameters. The application executes the tests based on these test cases to obtain test results. Compared to existing solutions that often focus on a single test dimension and have low test relevance and coverage, making it difficult to meet the API automation testing needs of the microservices domain, this application provides a complete closed loop from document parsing, test case generation, test execution, result verification to strategy optimization. This forms a highly adaptable, highly reliable, and automatically iteratively optimized API end-to-end automated testing solution, significantly improving the relevance, comprehensiveness, and stability of testing, and meeting the API automation testing needs of the Web / microservices domain.

[0024] It should be noted that the execution subject in this embodiment can be a test case testing device. This device can be a device equipped with an intelligent agent, such as a user-used mobile terminal, personal computer, server, or other electronic device, or other devices capable of performing the same or similar functions. This embodiment does not impose any limitations on this; in this embodiment and the following embodiments, the test case testing method is described using a test case testing device.

[0025] The test case equipment can also be an electronic device that can control and detect devices equipped with intelligent agents; this embodiment does not impose any restrictions on this.

[0026] Based on this, the embodiments of this application provide a test case testing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the test case testing method of this application.

[0027] In this embodiment, the test case testing method includes steps S10 to S40: Step S10: Parse the application programming interface document uploaded by the user and extract the SQL identifier to obtain interface metadata and SQL identifier.

[0028] It should be noted that this application adopts a multi-agent collaborative architecture, using a unified scheduling module as the central hub to build a fully automated API testing system, forming a complete closed loop from document parsing, test case generation, test execution, result verification to strategy optimization. This application employs a three-layer collaborative architecture consisting of a scheduling layer, a business intelligence layer, and an optimization feedback layer, referencing... Figure 2 The system architecture diagram shown depicts five dedicated intelligent agents within the business intelligence layer: text parsing agent, configuration management agent, test generation agent, test execution and result verification agent, and report generation and optimization iteration agent. The scheduling layer serves as the global unified collaborative scheduling hub, responsible for task distribution, parameter flow, and operational monitoring among the agents. It unifies the JSON communication protocol between modules, dynamically allocates tasks according to the business priorities of parsing, generation, execution, and reporting, distributes tasks based on real-time load balancing across agents, synchronously records the status of tasks throughout the entire process, and triggers a retry alarm mechanism when anomalies occur, providing a standardized data flow foundation for the entire testing chain. The business intelligence layer comprises five core functional agents: text parsing agent1, configuration management agent2, test case generation agent3, test execution and result verification agent4, and report generation and optimization iteration agent5. These agents are assigned tasks according to their business logic: parsing, parameter verification, test case generation, test execution, analysis, and report output, providing execution support for the entire process.

[0029] The specific details of each intelligent agent are as follows: Text parsing intelligent agent (agent1): The entry point for the test process and the starting point for the entire SQL identifier chain. It has three built-in dedicated parsers: YAPI, Swagger, and API Blueprint. It automatically verifies document integrity, identifies document types, extracts interface metadata, and automatically identifies query-type interfaces ending with " / query," assigning them a unique SQL field verification identifier. This forms a progressive logic of "document verification, metadata extraction, and SQL identifier marking," providing a unified identifier for subsequent SQL-specific verification test cases and SQL security test case generation. Configuration management intelligent agent (agent2): Manages parameters throughout the entire process, performing triple matching verification on the runtime parameters in the test cases based on format, business logic, and SQL identifier. This provides compliant parameters for test case generation and test execution. The triple verification includes: 1) Format compliance verification: checking whether the parameter data type and value range conform to preset specifications; 2) Business rationality verification: checking the adaptability of parameters to the API interface business scenario; 3) SQL identifier adaptability verification: checking the matching of parameters with the SQL identifier marked by the text parsing intelligent agent, ensuring that the parameters support subsequent SQL-specific verification and security test case generation. The test case generation agent (agent3) is the core module for test case generation. It uses three sub-modules—basic test case generation template, security test case generation template, and large language model (LLM) intelligent enhanced test case generation template—to generate a full set of test cases in parallel. Combined with the LLM's automatic exception degradation mechanism, it ensures uninterrupted test case generation. In particular, each SQL-specific verification test case and security test case in the / query type interface is bound to an SQL identifier. The / query type interface is a query interface specifically used for performing data retrieval, filtering, or statistical operations. The full test case generation mechanism of the basic test case generation template, security test case generation template, and LLM intelligent enhanced test case generation template includes: 1) The basic test case generation template is the core part of test case generation. Based on general rules such as interface parameter type, length, and required fields, it generates general basic test cases such as normal requests, missing parameters, type errors, and out-of-bounds values. For interfaces with SQL identifiers, it also generates additional SQL-related basic verification test cases such as SQL field value anomalies and empty fields, covering the basic functions and exception scenarios of all interfaces.2) The security test case generation template is specifically designed for / query-type query interfaces identified by the text parsing agent1. Based on template rules, it generates SQL-specific security test cases such as SQL injection, unauthorized queries, and illegal concatenation. Interfaces without SQL identifiers do not generate such test cases. This is the foundational capability for generating security scenario test cases. 3) The large language model enhanced test case generation template, as an intelligent enhancement module, is only activated when the large language model service is normal. Leveraging the semantic understanding and scenario expansion capabilities of the large language model, it generates complex business, combined parameter, and personalized edge scenario test cases that are difficult to cover with traditional rules for all interfaces. At the same time, it supplements / query-type interfaces with higher-level security test cases that are more in line with business semantics (such as complex SQL injection variants and business logic-based unauthorized query test cases), further improving test case coverage and relevance. When the large language model service is abnormal, the large language model automatic degradation mechanism is activated, automatically downgrading to using the basic test case generation template and the security test case generation template to generate test cases. Test execution and result verification agent4: The core module for test execution, generating HTTP clients adapted to different types of interfaces, and sequentially completing the interface request type, basic response, and data format verification. For interfaces carrying SQL identifiers, additional security checks are performed on SQL field integrity, data accuracy, and injection risk. All check results are bound to the SQL identifier and test case ID record. Finally, all test results are sent back to the scheduling layer to provide data for report generation and iterative optimization. The report generation and optimization iteration intelligent agent (agent5) is responsible for result output and optimization instruction generation, outputting reports in both HTML and JSON formats. It uses its built-in analysis engine to identify uncovered scenarios and high-frequency failure causes, and generates associated optimization instructions bound to the SQL identifier for specific test cases, providing input for closed-loop optimization.

[0030] Understandably, the text parsing agent parses the application programming interface (API) documents uploaded by the user and extracts the SQL identifiers to obtain the API metadata and SQL identifiers.

[0031] Step S10 further includes: performing document integrity verification on the application programming interface document uploaded by the user to obtain an integrity verification result; performing interface parsing on the application programming interface document based on the integrity verification result to obtain interface metadata; and identifying the query-type interfaces in the interface metadata that meet preset conditions with SQL fields to obtain SQL identifiers.

[0032] It should be noted that the text parsing agent has three built-in dedicated parsers: a YAPI parser, a Swagger parser, and an API Blueprint parser. When a user uploads an application programming interface (API) document, the text parsing agent first calls the corresponding parser to perform a document integrity check on the API document, screening it for core information such as the API path and request method. If the check passes, it automatically identifies the document type and calls the corresponding parser to extract the API metadata, which includes at least the API path, request method, parameter types, return format, and field constraints.

[0033] Understandably, the text parsing agent automatically identifies query-type interfaces ending with " / query" in the interface path and assigns a unique SQL field verification identifier, i.e., an SQL identifier, to each identified query-type interface. The SQL identifier includes the interface ID, a list of SQL fields, field data types, legal value ranges, and associated constraints. The text parsing agent forms a progressive logic of document verification, metadata extraction, and SQL identifier marking, providing a unified identifier for the subsequent generation of SQL-specific verification test cases and SQL security test cases. The SQL identifier can be a JSON object with a three-level nested structure. When the API document is updated, the text parsing agent (agent1) calculates the SQL identifier fingerprint of the new version of the API document, compares it with the fingerprint of the historical version, and if the fingerprint changes, generates an incremental SQL identifier, marking only the changed fields and constraints. The incremental SQL identifier is then associated and stored with the historical SQL identifier, forming a version chain of SQL identifiers. The SQL identifier fingerprint serves as a data association anchor point across agents in subsequent test case generation, test execution, report analysis, and optimization feedback stages. Since the SQL identifier fingerprint is calculated based on the interface path, field list and constraint expression, even if two interfaces have similar paths but different field constraints, their fingerprints will also be different, thus ensuring the accuracy of one-to-one correspondence. The fingerprint algorithm realizes the global uniqueness and cross-process traceability of the SQL identifier.

[0034] In one implementation, when a user-uploaded application programming interface (API) document contains a query interface with the path " / api / user / query", the text parsing agent automatically recognizes that the path of the interface ends with " / query" and generates a unique SQL identifier for the interface. The SQL identifier includes the interface ID (e.g., "API_User_Query_001"), a list of SQL fields (e.g., "user_id, user_name, user_status"), the data type of each field (e.g., "INT, VARCHAR, INT"), the range of valid values, and the association constraints between fields (e.g., "user_name cannot be empty when user_status is 1"). The text parsing agent associates the interface metadata and the SQL identifier and sends them to the scheduling layer.

[0035] Step S20: Verify the interface metadata based on the preset triple verification rules, and determine the test running parameters based on the verified interface metadata.

[0036] It should be noted that the configuration management agent is responsible for end-to-end parameter control, performing triple verification of the runtime parameters in test cases based on format, business logic, and SQL identifiers, providing compliant parameters for test case generation and test execution. The preset triple verification rules include format compliance verification rules, business logic compliance verification rules, and SQL identifier adaptation verification rules.

[0037] Understandably, the interface metadata is validated based on format compliance validation rules, business rationality validation rules, and SQL identifier adaptation validation rules to obtain format compliance validation results, business rationality validation results, and SQL identifier adaptation validation results. When all three validation results pass, the test execution parameters are determined based on the validated interface metadata.

[0038] Step S30: Generate a full set of test cases based on the interface metadata, the SQL identifier, and the test run parameters.

[0039] It should be noted that a full set of test cases is generated based on the interface metadata, the SQL identifier, the test execution parameters, and the preset test case generation template. The preset test case generation module includes a basic test case generation template, a security test case generation template, and a large language model-enhanced test case generation template. The test case generation agent is the core module for test case generation. It uses three sub-modules—the basic test case generation template, the security test case generation template, and the large language model-enhanced test case generation template—to generate a full set of test cases in parallel. This is complemented by an automatic degradation mechanism for large language model anomalies to ensure uninterrupted test case generation.

[0040] Understandably, the test case generation agent uses the interface metadata, SQL identifier, and test execution parameters to generate a full set of test cases in parallel using three test case generation templates. For query-type interfaces whose paths end with " / query", each SQL-specific verification test case and each security test case for that interface are bound to the aforementioned SQL identifier.

[0041] Step S40: Execute tests based on the full set of test cases to obtain test results.

[0042] It should be noted that the test execution and result verification agent is used to execute tests based on the full set of test cases and obtain test results.

[0043] This embodiment provides a test case testing method. It parses user-uploaded application programming interface (API) documents and extracts SQL identifiers to obtain API metadata and SQL identifiers. The API metadata is then validated based on preset triple-validation rules, and test execution parameters are determined based on the validated metadata. A full set of test cases is generated based on the API metadata, SQL identifiers, and test execution parameters. Tests are then executed based on these test cases to obtain test results. Compared to existing solutions that often focus on a single test dimension, have low test relevance and coverage, and struggle to meet the API automation testing needs of the microservices domain, this embodiment provides a complete closed loop from document parsing, test case generation, test execution, result verification to strategy optimization. This forms a highly adaptable, highly reliable, and automatically iteratively optimized API end-to-end automated testing solution, significantly improving the relevance, comprehensiveness, and stability of testing, and meeting the API automation testing needs of the Web / microservices domain.

[0044] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, the embodiments of this application provide a use case testing method. (Refer to...) Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the test case testing method of this application. In this embodiment, the preset triple verification rules include format compliance verification rules, business rationality verification rules, and SQL identifier adaptation verification rules. Step S20 further includes: Step S201: Perform compliance verification on the parameter data type and value range corresponding to the interface metadata based on the format compliance verification rules to obtain the format compliance verification result; It should be noted that the first layer is format compliance verification, which uses a recursive verification algorithm to verify the compliance of the parameter data types and value ranges corresponding to the interface metadata. The configuration management agent checks whether the parameter data types and value ranges corresponding to the interface metadata conform to preset specifications. For example, for parameters with the data type "INT", it verifies whether their values ​​are within the preset integer range; for parameters with the data type "VARCHAR", it verifies whether their string length exceeds the preset length limit.

[0045] Step S202: Based on the business reasonable verification rules, perform a compatibility verification on the parameters corresponding to the interface metadata and the interface business scenario to obtain the business reasonable verification result. Understandably, the second layer is business rationality verification, which can be accomplished through a scenario matching score mechanism. Scenario matching is determined by parameter weights and the matching coefficient between the parameter and the scenario. The parameter weight is determined by the importance of the parameter in the API interface's business scenario, and the matching coefficient is determined by whether the parameter value falls within the typical value range of that business scenario. When the scenario matching score is lower than a preset threshold (e.g., 0.7), the business rationality verification is deemed unsuccessful.

[0046] For example, the configuration management agent checks the compatibility between the parameters corresponding to the interface metadata and the API interface business scenario. For instance, for a user login interface, it verifies whether its parameters contain the necessary username and password fields; for an order query interface, it verifies whether its parameters contain valid order status values. For example, for a user login interface, the password parameter has a weight of 0.6, and the username parameter has a weight of 0.4. If the password parameter value conforms to a typical password format, the matching coefficient is 1.0; if the username parameter value conforms to a typical username format, the matching coefficient is 1.0. Then, the scenario matching degree is (0.6 × 1.0 + 0.4 × 1.0) / (0.6 + 0.4) = 1.0, and the verification passes. If the password parameter value is too simple (e.g., "123456"), the matching coefficient is 0.3. Then, the scenario matching degree is (0.6 × 0.3 + 0.4 × 1.0) / 1.0 = 0.58, which is lower than the threshold of 0.7, and the verification fails. The above values ​​are for illustrative purposes only and are not intended to limit the specific scope.

[0047] Step S203: Based on the SQL identifier adaptation verification rules, the parameters corresponding to the interface metadata are verified to match the SQL identifier, and the SQL identifier adaptation verification result is obtained. It should be understood that the third layer is the SQL identifier compatibility check, which compares the field list in the interface metadata with the field constraint set in the SQL identifier field by field to obtain the difference set. If the difference set is empty, the SQL identifier compatibility check passes; otherwise, the difference set is returned to the scheduling layer as the reason for the check failure.

[0048] The configuration management agent verifies the matching between the parameters corresponding to the interface metadata and the SQL identifier marked by the text parsing agent, ensuring that the parameters can support subsequent SQL-specific verification and security test case generation. For example, it verifies whether the field list in the interface metadata is consistent with the SQL field list in the SQL identifier, whether the field data types match, and whether the parameter value range falls within the legal value range in the SQL identifier.

[0049] Step S204: When the format compliance verification result, the business rationality verification result, and the SQL identifier adaptation verification result all pass, determine the test run parameters based on the interface metadata that has passed the verification.

[0050] In one implementation, when the format compliance verification result, the business rationality verification result, and the SQL identifier adaptation verification result all pass, the configuration management agent determines the test execution parameters based on the verified interface metadata and sends the test execution parameters to the test case generation agent. If any verification fails, the configuration management agent returns verification failure information to the scheduling layer, which then triggers an alarm mechanism. This triple verification process achieves accurate verification of API parameters. Through recursive verification and field-level difference comparison, inconsistencies between interface metadata and SQL identifiers can be accurately located.

[0051] In this embodiment, step S30 further includes: Step S301: Generate general basic test cases based on the interface metadata, the SQL identifier, the test run parameters, and the basic test case generation template, and generate SQL basic verification test cases for the interface with the SQL identifier; It should be noted that the test case generation agent (agent3) constructs a task dependency graph. The task for the basic test case generation template is the root node and has no prerequisites. The task for the security test case generation template depends on the SQL identifier output by the text parsing agent (agent1) and is executed only on interfaces with SQL identifiers. The task for the LLM enhancement test case generation template depends on the output of the basic test case generation template to avoid generating duplicate test cases. Tasks are allocated according to the topological order of the task dependency graph. Tasks without dependencies are executed in parallel, while tasks with dependencies are executed serially. Since test cases may be duplicated, a feature vector is extracted from each test case. A hash index is built using the feature vector as the key. All test cases are traversed; if the feature vector already exists in the hash index, it is marked as a duplicate test case. For duplicate test cases, the version with the highest priority is retained. The priority setting can be LLM enhancement > security > basic. The deduplicated test cases are grouped by interface ID and merged into a full test case set.

[0052] In one implementation, the basic test case generation template is the core component of test case generation. The test case generation agent generates general basic test cases such as normal requests, missing parameters, type errors, and out-of-bounds values ​​based on common rules such as interface parameter types, parameter lengths, and required fields. For each API interface, the basic test case generation template generates at least the following general basic test cases: Normal request test case: generates a normal request containing all required parameters with values ​​within the legal range, according to the parameter specifications in the interface documentation; Missing parameter test case: generates a parameter missing exception request for each missing required parameter; Type error test case: generates a type error exception request by modifying the parameter's data type to an incorrect type; Out-of-bounds value test case: generates an out-of-bounds value exception request by modifying the parameter's value to a value outside the legal range. Additionally, for interfaces with the SQL identifier (i.e., query interfaces), the basic test case generation template also generates basic SQL validation test cases. These basic SQL validation test cases include, but are not limited to, SQL field value anomaly test cases (e.g., modifying the SQL field value to an illegal value) and SQL field empty test cases (e.g., setting the SQL field value to an empty value), covering basic SQL-related functions and abnormal scenarios.

[0053] Step S302: Generate SQL-specific security test cases based on the interface metadata, the SQL identifier, the test run parameters, and the security test case generation template; Understandably, the security test case generation template is specifically designed for query-type interfaces (i.e., interfaces whose paths end with " / query") identified by the text parsing agent. The test case generation agent generates SQL-specific security test cases for interfaces with the SQL identifier based on the security test case generation template. Interfaces without the SQL identifier do not generate such test cases. The SQL-specific security test cases include, but are not limited to: SQL injection test cases: injecting malicious SQL code (such as 'OR '1'='1、'; DROP TABLE users; -- etc.) into SQL fields to detect whether the interface has SQL injection vulnerabilities; Unauthorized query test cases: attempting to query high-privilege data using the credentials of a low-privilege user to detect whether the interface has unauthorized access vulnerabilities; and illegal concatenation test cases: concatenating illegal characters or SQL keywords into SQL fields to detect whether the interface has SQL statement concatenation vulnerabilities.

[0054] Step S303: Generate complex business scenario test cases, combined parameter test cases, and personalized edge scenario test cases based on the interface metadata, the SQL identifier, the test run parameters, and the large language model enhanced test case generation template. It should be understood that the Large Language Model (LLM) enhanced test case generation template, as an intelligent enhancement module, is only enabled when the Large Language Model (LLM) service is functioning normally. The test case generation agent leverages the semantic understanding and scenario expansion capabilities of the Large Language Model to generate complex business scenario test cases, combined parameter test cases, and personalized edge scenario test cases for all interfaces, which are difficult to cover with traditional rules. For ordinary interfaces (without SQL identifiers), the Large Language Model enhanced test case generation template generates the following enhanced test cases based on the Large Language Model's understanding of the interface's business semantics: Complex business scenario test cases: Simulating complex business logic scenarios under multiple parameter combinations, such as simultaneously testing combinations of different payment methods, different amounts, and different user levels in the order payment interface; Combined parameter test cases: Generating combined test cases where multiple parameters simultaneously take boundary values ​​or outliers, covering the mutual influence between parameters; Personalized edge scenario test cases: Based on the Large Language Model's understanding of the business domain, generating edge scenario test cases that are difficult to predict with traditional rules but may occur in actual business. For query-type interfaces (with SQL identifiers), the large language model enhanced test case generation template also supplements higher-level security test cases that are more in line with business semantics, including but not limited to: complex SQL injection variant test cases: based on the large language model's in-depth understanding of SQL syntax and business logic, it generates complex SQL injection variants that are difficult to cover by traditional template rules; business logic-type privilege escalation query test cases: based on the large language model's understanding of business permission models, it generates privilege escalation query test cases at the business logic level.

[0055] Step S304: Generate a full set of test cases based on the general basic test cases, the SQL basic verification test cases, the SQL-specific security test cases, the complex business scenario test cases, the combined parameter test cases, and the personalized edge scenario test cases.

[0056] In one implementation, assume that the application programming interface document to be tested contains three interfaces: Interface A is " / api / user / login" (a regular interface without SQL identifier), Interface B is " / api / user / query" (a query interface with SQL identifier), and Interface C is " / api / order / list" (a query interface with SQL identifier). When the large language model service is normal, the test case generation agent 203 calls three templates in parallel: the basic test case generation template generates general basic test cases for Interface A, and general basic test cases and basic SQL validation test cases for Interfaces B and C; the security test case generation template generates SQL-specific security test cases for Interfaces B and C, but does not generate security test cases for Interface A; the large language model enhancement test case generation template generates enhancement test cases for all interfaces and supplements high-level security test cases for Interfaces B and C. The three test case generation streams are executed in parallel and are finally merged into a full set of test cases. When the large language model service is abnormal, the large language model enhancement test case generation template is automatically deactivated, and test case generation is completed solely by the basic test case generation template and the security test case generation template. In all generated test cases, each SQL-specific verification case and each security test case for Interface B and Interface C are bound to a corresponding SQL identifier, facilitating correlation and tracing in subsequent execution and reporting stages.

[0057] In one implementation, during the test case merging process, the SQL identifier binding relationship can also be generated according to the following rules: If the SQL basic validation test case generated by the basic test case generation template and the SQL security test case generated by the security test case generation template have the same SQL identifier, the merged test case retains the SQL identifier; if the high-order security test case generated by the LLM enhanced test case generation template and the SQL security test case generated by the security test case generation template have the same SQL identifier, the merged test case retains the SQL identifier and is marked with an LLM enhanced tag; all test cases bound to SQL identifiers are uniformly written to the sql_identifier field in the test case metadata after merging. Through the above parallel scheduling and merging mechanism, this scheme ensures the efficiency and lack of redundancy in test case generation, while guaranteeing the binding relationship of SQL identifiers in all test cases.

[0058] This embodiment provides a test case testing method. This embodiment obtains interface metadata and SQL identifiers by parsing the application programming interface (API) documentation uploaded by the user and extracting the SQL identifiers; it performs compliance verification on the parameter data types and value ranges corresponding to the interface metadata based on format compliance verification rules, obtaining format compliance verification results; it performs adaptability verification on the parameters corresponding to the interface metadata and the API interface business scenario based on business rationality verification rules, obtaining business rationality verification results; it performs adaptability verification on the parameters corresponding to the interface metadata and the SQL identifier based on SQL identifier adaptation verification rules, obtaining SQL identifier adaptation verification results; when the format compliance verification result, business rationality verification result, and SQL identifier adaptation verification result all pass, the test execution parameters are determined based on the verified interface metadata; a general basic test case is generated based on the interface metadata, SQL identifier, test execution parameters, and basic test case generation template, and SQL basic verification test cases are generated for interfaces with SQL identifiers; based on the interface metadata, SQL identifier, and test... This approach generates SQL-specific security test cases based on runtime parameters and security test case generation templates. It also generates complex business scenario test cases, combined parameter test cases, and personalized edge scenario test cases based on interface metadata, SQL identifiers, test runtime parameters, and large language model-enhanced test case generation templates. Finally, it generates a full set of test cases based on general basic test cases, SQL basic verification test cases, SQL-specific security test cases, complex business scenario test cases, combined parameter test cases, and personalized edge scenario test cases. Tests are then executed based on these full set of test cases to obtain test results. Compared to existing solutions that often focus on a single test dimension and have low test targeting and coverage, making it difficult to meet the API automation testing needs of the microservices domain, this embodiment provides a complete closed loop from document parsing, test case generation, test execution, result verification to strategy optimization. This forms a highly adaptable, highly reliable, and automatically iteratively optimized API end-to-end automated testing solution, significantly improving the targeting, comprehensiveness, and stability of testing, and meeting the API automation testing needs of the Web / microservices domain.

[0059] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Based on this, this application provides a use case testing method, the third embodiment of which is described below. (Refer to...) Figure 4 , Figure 4 This is a flowchart illustrating the third embodiment of the test case testing method of this application. In this embodiment, step S40 further includes: Step S401: Based on the test execution and result verification agent, perform request method verification, basic response verification, and data format verification on the full set of test cases to obtain the first verification result; It should be noted that the test execution and result verification agent receives the full set of test cases distributed by the scheduling layer, first adapts to the corresponding HTTP client, generates the corresponding HTTP request according to the request method specified in each test case (such as GET, POST, PUT, DELETE, etc.) and executes it.

[0060] In one implementation, for each test case, the test execution and result verification agent sequentially performs the following basic checks: First, request method verification: verifying whether the HTTP status code returned by the server meets expectations (e.g., 200 for a successful request, 400 for incorrect parameters, 401 for unauthorized requests, etc.). Second, basic response verification: verifying whether the server provides a normal response and whether the response time is within a preset threshold range. Third, data format verification: verifying whether the data format of the response body is consistent with the return format defined in the interface documentation (e.g., whether the JSON format is correct, whether the field names and levels match, etc.). The test execution and result verification agent summarizes the results of the above three basic checks into the first verification result.

[0061] Step S402: Perform SQL-specific verification on the interface carrying the SQL identifier to obtain the second verification result; Understandably, for interfaces carrying the SQL identifier (i.e., query interfaces), the test execution and result verification agent also performs additional SQL-specific verification to obtain a second verification result. The SQL-specific verification includes: SQL field integrity verification: verifying whether the returned result contains all SQL fields marked in the SQL identifier; data accuracy verification: verifying whether the data type and value of each SQL field in the returned result are within the legal value range of the SQL identifier; and injection risk-specific security verification: verifying whether there are any signs of successful SQL injection in the returned result (such as returning unexpected database data, database error messages, etc.).

[0062] Step S403: Determine the test result based on the first verification result and the second verification result.

[0063] In one implementation, the test execution and result verification agent merges the first verification result and the second verification result as the final test result of the test case. All verification results are recorded by binding the SQL identifier and the test case ID. After all test cases have been executed, the test execution and result verification agent sends all test results back to the scheduling layer, providing a data foundation for report generation and iterative optimization.

[0064] In this embodiment, after step S40, the method further includes: generating a test report from the test results, the SQL identifier, and the full set of test cases; generating an association optimization strategy bound to the SQL identifier based on the test report; and executing the test process based on the association optimization strategy.

[0065] Understandably, the report generation and optimization iteration agent is responsible for outputting results and generating optimization instructions. This agent receives the test results, SQL identifiers, and full test case information summarized by the scheduling layer and generates a test report. The test report is a dual-format report in both HTML and JSON formats. The HTML format report is used for user visualization, while the JSON format report is used for inter-system data exchange and automated processing. The report generation and optimization iteration agent has a built-in intelligent analysis engine that identifies uncovered scenarios and high-frequency failure causes.

[0066] In one implementation, the report generation and optimization iteration agent generates an associated optimization instruction bound to a specific use case carrying an SQL identifier. The optimization instruction includes at least: the SQL identifier to be optimized, the specific problem type occurring in the interface corresponding to the SQL identifier (e.g., abnormal field values, SQL injection risk, unauthorized query risk, etc.), and suggested optimization directions (e.g., adjusting parameter value ranges, adding security filtering rules, etc.). The report generation and optimization iteration agent sends the dual-format test report and the associated optimization instruction to the scheduling layer, which then distributes them to the optimization feedback layer.

[0067] The test process based on the correlation optimization strategy includes: selecting effective optimization rules based on the correlation optimization strategy; adjusting the test running parameters based on the effective optimization rules; and executing the test process based on the adjusted test running parameters.

[0068] In one embodiment, to further illustrate the process of this application, refer to Figure 5The workflow diagram shown is as follows: Step 1: Document Parsing and SQL Identifier Extraction. 1) The text parsing agent 1 receives the application programming interface (API) document uploaded by the user. It automatically identifies the document type using its built-in YAPI, Swagger, and API Blueprint parsers, performing document integrity verification (screening core information such as interface path and request method) to avoid invalid parsing. After successful verification, it accurately extracts the interface metadata (including interface path, request method, parameter type, return format, field constraints, etc.). 2) It identifies query-type interfaces ending in / query and automatically marks the SQL field verification unique identifier for this type of interface based on the extracted metadata (including interface ID, SQL field list, field data type, legal value range, and association constraints), achieving a one-to-one correspondence between metadata and SQL identifiers. 3) The text parsing agent 1 synchronizes the "interface metadata and SQL identifiers" to the scheduling layer. 4) The scheduling layer calls the triple verification rules of the configuration management agent 2 to perform format, field integrity, and adaptability verification on the data packet. After successful verification, the data is distributed to the test case generation agent 3, laying the foundation for subsequent test case generation. Step 2: Full Test Case Generation. The test case generation agent (agent3) generates a full set of test cases in parallel using the triple-verified parameters provided by the SQL identifier, interface metadata, and configuration management agent (agent2). This is achieved through three methods: 1) generating SQL-specific verification and security test cases for interfaces with SQL identifiers, and generating only general basic test cases for interfaces without SQL identifiers; 2) monitoring the large language model service status throughout the process, disabling the large language model enhanced test case generation function in case of anomalies, and relying solely on the basic and security test case generation templates to generate all test cases, ensuring uninterrupted workflow. The third step is test execution and related verification. The scheduling layer synchronizes all test cases and SQL identifiers to the test execution and result verification agent (agent4). This agent adapts to the corresponding HTTP client, performs request method, basic response, and data format verification, and performs SQL-specific verification on interfaces with SQL identifiers. It executes all test cases in parallel and synchronizes the test results and related information to the scheduling layer. The fourth step is report generation and in-depth analysis. The scheduling layer distributes the aggregated data (test results, SQL identifiers, and test case information) to the report generation and optimization iteration agent (agent5), generating reports in both HTML and JSON formats. It then uses the intelligent analysis engine to generate specific optimization instructions associated with the SQL identifiers, which are synchronized to the scheduling layer. Step 5: Closed-loop optimization and strategy iteration (optimizing the feedback layer and each agent).The optimization feedback layer receives the optimization instructions output by the report generation and optimization iteration intelligent agent agent5. Based on the association relationship of "optimization instruction - SQL identifier - test case", it filters effective optimization rules and sends them back to the scheduling layer. The scheduling layer distributes them to the configuration management intelligent agent agent2 and the test case generation intelligent agent agent3. The configuration management intelligent agent agent2 adjusts the running parameters of the corresponding SQL identifier, and the test case generation intelligent agent agent3 regenerates the test cases and enters the test process, forming an automated iteration closed loop.

[0069] The optimization feedback layer receives the associated optimization instructions from the scheduling layer, filters valid optimization rules through a "optimization instruction-SQL identifier-test case" association verification, and then sends the results back to the scheduling layer. For each received optimization instruction, the optimization feedback layer performs the following association verifications: verifying whether the optimization instruction is bound to a corresponding SQL identifier; verifying whether the SQL identifier in the optimization instruction corresponds to an executed test case; and verifying whether the problem described in the optimization instruction matches the execution result of the corresponding test case. Through these association verifications, the optimization feedback layer filters out valid optimization rules, performs deduplication on the valid optimization rules, and sends the processed valid optimization rules back to the scheduling layer. After receiving the valid optimization rules, the scheduling layer distributes them to the configuration management agent and the test case generation agent. The configuration management agent adjusts the runtime parameters corresponding to the SQL identifier according to the valid optimization rules (e.g., adjusting parameter value ranges, modifying field constraints), and stores the adjusted runtime parameters in a parameter library for subsequent testing. The test case generation agent regenerates the corresponding test cases based on the valid optimization rules and the adjusted runtime parameters, entering a new round of the "parsing, verification, generation, execution, and reporting" testing process. The optimization feedback layer only performs targeted parameter adjustments and optimizations for abnormal test cases with SQL identifiers, forming an automated iterative closed loop of "test-analysis-optimization-retest," effectively solving the technical problems of rigid test strategies and uncontrollable optimization effects.

[0070] This embodiment parses user-uploaded application programming interface (API) documents and extracts SQL identifiers to obtain API metadata and SQL identifiers. It then verifies the API metadata based on preset triple verification rules and determines test execution parameters based on the verified metadata. Finally, it generates a full set of test cases based on the API metadata, SQL identifiers, and test execution parameters. The test is then executed based on these test cases to obtain test results. Compared to existing solutions that often focus on a single test dimension, have low test relevance and coverage, and struggle to meet the API automation testing needs of the microservices domain, this embodiment provides a complete closed loop from document parsing, test case generation, test execution, result verification to strategy optimization. This forms a highly adaptable, highly reliable, and automatically iteratively optimized API end-to-end automated testing solution, significantly improving the relevance, comprehensiveness, and stability of testing, and meeting the API automation testing needs of the Web / microservices domain.

[0071] This application also provides a test case testing system; please refer to [link / reference]. Figure 6 , Figure 6 This is a schematic diagram of the module structure of a test case testing system provided in Implementation Example 1. The test case testing system includes: The text parsing agent 10 is used to parse the application programming interface (API) documents uploaded by users and extract the SQL identifiers to obtain API metadata and SQL identifiers. Configuration management agent 20 is used to verify the interface metadata based on preset triple verification rules, and determine test run parameters based on the verified interface metadata. Test case generation agent 30 is used to generate a full set of test cases based on the interface metadata, the SQL identifier and the test run parameters; The test execution and result verification agent 40 is used to execute tests based on the full set of test cases and obtain test results.

[0072] In one embodiment, the text parsing agent 10 is further configured to perform document integrity verification on the application programming interface (API) document uploaded by the user and obtain an integrity verification result; perform interface parsing on the API document based on the integrity verification result to obtain interface metadata; and identify query-type interfaces in the interface metadata that meet preset conditions by marking them with SQL fields to obtain SQL identifiers.

[0073] In one implementation, the preset triple verification rules include format compliance verification rules, business rationality verification rules, and SQL identifier adaptation verification rules. The configuration management intelligent agent 20 is further configured to perform compliance verification on the parameter data type and value range corresponding to the interface metadata based on the format compliance verification rules to obtain a format compliance verification result; perform adaptation verification on the parameters corresponding to the interface metadata and the interface business scenario based on the business rationality verification rules to obtain a business rationality verification result; perform adaptation verification on the parameters corresponding to the interface metadata and the SQL identifier based on the SQL identifier adaptation verification rules to obtain an SQL identifier adaptation verification result; and when the format compliance verification result, the business rationality verification result, and the SQL identifier adaptation verification result all pass, the test running parameters are determined based on the verified interface metadata.

[0074] In one implementation, the test case generation agent 30 is further configured to generate a full set of test cases based on the interface metadata, the SQL identifier, the test run parameters, and the preset test case generation template. The preset test case generation module includes a basic test case generation template, a security test case generation template, and a large language model enhanced test case generation template.

[0075] In one implementation, the test case generation agent 30 is further configured to generate general basic test cases based on the interface metadata, the SQL identifier, the test execution parameters, and the basic test case generation template, and generate SQL basic verification test cases for interfaces with the SQL identifier; generate SQL-specific security test cases based on the interface metadata, the SQL identifier, the test execution parameters, and the security test case generation template; generate complex business scenario test cases, combined parameter test cases, and personalized edge scenario test cases based on the interface metadata, the SQL identifier, the test execution parameters, and the large language model enhanced test case generation template; and generate a full set of test cases based on the general basic test cases, the SQL basic verification test cases, the SQL-specific security test cases, the complex business scenario test cases, the combined parameter test cases, and the personalized edge scenario test cases.

[0076] In one implementation, the test execution and result verification agent 40 is further configured to perform request method verification, basic response verification, and data format verification on the full set of test cases based on the test execution and result verification agent, and obtain a first verification result; perform SQL-specific verification on the interface carrying the SQL identifier, and obtain a second verification result; and determine the test result based on the first verification result and the second verification result.

[0077] In one embodiment, the test case testing system further includes a report generation and optimization iteration agent, which is further configured to: generate a test report from the test results, the SQL identifier, and the full set of test cases; generate an association optimization strategy bound to the SQL identifier based on the test report; and execute a test process based on the association optimization strategy.

[0078] In one implementation, the report generation and optimization iteration agent is further configured to: filter effective optimization rules based on the correlation optimization strategy; adjust the test running parameters based on the effective optimization rules; and execute the test process based on the adjusted test running parameters.

[0079] The test case testing system provided in this application, employing the test case testing method described in the above embodiments, can solve the technical problems of existing solutions focusing on a single testing dimension, having low testing relevance and coverage, and failing to meet the API automation testing needs of the microservice domain. Compared with the prior art, the beneficial effects of the test case testing system provided in this application are the same as those of the test case testing method provided in the above embodiments, and other technical features of the test case testing system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0080] This application provides a use case testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the use case testing method in Embodiment 1 above.

[0081] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a test device suitable for implementing embodiments of this application. The test device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The test equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0082] like Figure 7As shown, the test case testing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the test case testing device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the test case device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows a test case device with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0083] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0084] The test case testing device provided in this application, employing the test case testing method described in the above embodiments, can solve the technical problems of existing solutions focusing on a single testing dimension, having low testing relevance and coverage, and being unable to meet the API automation testing needs of the microservice domain. Compared with the prior art, the beneficial effects of the test case testing device provided in this application are the same as those of the test case testing method provided in the above embodiments, and other technical features of this test case testing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0085] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0086] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0087] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the use case testing method in the above embodiments.

[0088] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0089] The aforementioned computer-readable storage medium may be included in the test case testing device; or it may exist independently and not assembled into the test case testing device.

[0090] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the test case testing device, the test case testing device performs the following actions: parses the application programming interface (API) document uploaded by the user and extracts the SQL identifier to obtain interface metadata and SQL identifier; verifies the interface metadata based on a preset triple verification rule and determines the test execution parameters based on the verified interface metadata; generates a full set of test cases based on the interface metadata, SQL identifier, and test execution parameters; and executes the tests based on the full set of test cases to obtain the test results.

[0091] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Python, Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0092] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0093] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0094] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described test case testing method. This addresses the technical problems of existing solutions, which often focus on a single testing dimension, have low test targeting and coverage, and are unable to meet the API automation testing needs of the microservices domain. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the test case testing method provided in the above embodiments, and will not be repeated here.

[0095] All user-related data involved in this application (such as user privacy data, user behavior data, etc.) were obtained with the user's permission or consent; that is to say, when this application is used in a specific product or technology, user permission is required to obtain and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0096] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A test case testing method, characterized in that, include: The application programming interface (API) documentation uploaded by users is parsed and SQL identifiers are extracted to obtain API metadata and SQL identifiers. The interface metadata is verified based on a preset triple verification rule, and the test running parameters are determined based on the interface metadata that passes the verification. Generate a full set of test cases based on the interface metadata, the SQL identifier, and the test execution parameters; Tests are executed based on the full set of test cases to obtain test results.

2. The method as described in claim 1, characterized in that, The process of parsing the user-uploaded application programming interface (API) document and extracting the SQL identifier to obtain API metadata and SQL identifiers includes: Perform document integrity verification on the application programming interface documents uploaded by users and obtain the integrity verification results; Based on the integrity verification result, the application programming interface document is parsed to obtain interface metadata; The query-type interfaces that meet the preset conditions in the interface metadata are identified by the SQL field to obtain the SQL identifier.

3. The method as described in claim 1, characterized in that, The preset triple verification rules include format compliance verification rules, business rationality verification rules, and SQL identifier adaptation verification rules. The process of verifying the interface metadata based on these preset triple verification rules and determining test execution parameters based on the verified interface metadata includes: Based on the format compliance verification rules, the parameter data type and value range corresponding to the interface metadata are verified for compliance, and the format compliance verification result is obtained. Based on the business-appropriate verification rules, the parameters corresponding to the interface metadata are verified to be compatible with the interface business scenario to obtain the business-appropriate verification result. Based on the SQL identifier adaptation verification rules, the parameters corresponding to the interface metadata are verified to match the SQL identifier, and the SQL identifier adaptation verification result is obtained. When the format compliance verification result, the business rationality verification result, and the SQL identifier adaptation verification result all pass, the test run parameters are determined based on the interface metadata that has passed the verification.

4. The method as described in claim 3, characterized in that, The process of generating a full set of test cases based on the interface metadata, the SQL identifier, and the test execution parameters includes: Generate a full set of test cases based on the interface metadata, the SQL identifier, the test execution parameters, and the preset test case generation template; The preset test case generation module includes a basic test case generation template, a security test case generation template, and a large language model enhanced test case generation template.

5. The method as described in claim 4, characterized in that, The process of generating a full set of test cases based on the interface metadata, the SQL identifier, the test execution parameters, and the preset test case generation template includes: Generate general basic test cases based on the interface metadata, the SQL identifier, the test run parameters, and the basic test case generation template, and generate SQL basic verification test cases for the interface with the SQL identifier; Generate SQL-specific security test cases based on the interface metadata, the SQL identifier, the test execution parameters, and the security test case generation template; Based on the interface metadata, the SQL identifier, the test run parameters, and the large language model enhanced test case generation template, generate complex business scenario test cases, combined parameter test cases, and personalized edge scenario test cases; Generate a full set of test cases based on the general basic test cases, the SQL basic verification test cases, the SQL-specific security test cases, the complex business scenario test cases, the combined parameter test cases, and the personalized edge scenario test cases.

6. The method as described in claim 1, characterized in that, The process of executing tests based on the full set of test cases to obtain test results includes: Based on the test execution and result verification agent, the request method verification, basic response verification and data format verification are performed on the full set of test cases to obtain the first verification result; Perform SQL-specific verification on the interface carrying the SQL identifier to obtain the second verification result; The test result is determined based on the first verification result and the second verification result.

7. The method as described in claim 6, characterized in that, After executing the tests based on the full set of test cases and obtaining the test results, the process further includes: Generate a test report using the test results, the SQL identifier, and all test cases. Based on the test report, an association optimization strategy bound to the SQL identifier is generated; The test process is executed based on the aforementioned correlation optimization strategy.

8. The method as described in claim 7, characterized in that, The test process based on the correlation optimization strategy includes: Valid optimization rules are selected based on the aforementioned correlation optimization strategy; The test execution parameters are adjusted based on the effective optimization rules, and the test process is executed based on the adjusted test execution parameters.

9. A test case testing system, characterized in that, include: Text parsing agent, configuration management agent, test case generation agent, test execution and result verification agent; The text parsing agent is used to parse the application programming interface document uploaded by the user and extract the SQL identifier to obtain interface metadata and SQL identifier. The configuration management intelligent agent is used to verify the interface metadata based on a preset triple verification rule, and to determine the test running parameters based on the verified interface metadata. The test case generation agent is used to generate a full set of test cases based on the interface metadata, the SQL identifier, and the test run parameters. The test execution and result verification agent is used to execute tests based on the full set of test cases and obtain test results.

10. A test case testing device, characterized in that, The test case device includes: a memory, a processor, and a test case program stored in the memory and executable on the processor, the test case program being configured to implement the test case method as described in any one of claims 1 to 8.

Images