Interface testing method and device, electronic equipment and medium

Abstract

The invention relates to the technical field of interface testing, and provides an interface testing method and device, electronic equipment and a medium. The method comprises the steps of obtaining a test request of a service interface and test specification data of the service interface; analyzing the test request through a large language model to obtain business logic information of the business interface; performing analysis processing on the test specification data through a large language model to obtain test index data of the service interface; generating a test case of the service interface based on a large language model according to the service logic information of the service interface and the test index data of the service interface; and calling a preset test tool to execute the test case to obtain a test result of the test case.

Description

Technical Field

[0001] The present disclosure relates to the technical field of interface testing, and in particular, to an interface testing method, apparatus, electronic device, and medium. Background Art

[0002] In the field of software testing, API (Application Programming Interface) testing is an important part of ensuring the quality of software systems. With the rapid development of microservice architectures and cloud services, the number and complexity of APIs are constantly increasing, which poses higher requirements for automated testing. However, traditional API testing methods usually rely on manually writing test cases, which is not only time-consuming but also error-prone, affecting the efficiency and accuracy of testing.

[0003] In recent years, some automated testing tools have emerged on the market. These tools can automatically generate test cases based on API specifications (such as OpenAPI). The emergence of these tools aims to improve testing efficiency and reduce manual intervention. However, these tools still have some significant limitations in practical applications. First, existing tools mainly rely on API specifications, which often cannot comprehensively cover the details of business logic. Business logic is a key part of API testing. The lack of in-depth understanding of business requirements and context awareness capabilities makes the generated test cases unable to comprehensively cover actual business scenarios, resulting in the inability to effectively detect potential semantic errors. In addition, existing tools usually can only test a single API endpoint and cannot simulate complex business processes involving multiple endpoints. This limitation leads to insufficient test coverage and cannot truly reflect the actual usage situation. Due to the need for a large amount of manual intervention to adjust and improve the generated test cases, the usage cost and time cost of existing tools increase significantly, thereby increasing the total cost of ownership (TCO). Summary of the Invention

[0004] In view of this, embodiments of the present disclosure provide an interface testing method, apparatus, electronic device, and computer-readable storage medium to solve the technical problem that traditional API testing methods in the prior art usually rely on manually writing test cases, which is not only time-consuming but also error-prone, affecting the efficiency and accuracy of testing.

[0005] In a first aspect of the embodiments of the present disclosure, an interface testing method is provided, including: obtaining a test request for a service interface and test specification data of the service interface; parsing and processing the test request through a large language model to obtain business logic information of the service interface; parsing and processing the test specification data through a large language model to obtain test metric data of the service interface; generating a test case for the service interface based on the large language model according to the business logic information of the service interface and the test metric data of the service interface; and invoking a preset test tool to execute the test case to obtain a test result of the test case.

[0006] In the second aspect of the embodiments of the present disclosure, an interface testing device is provided, including: an acquisition module, configured to acquire a test request for a service interface and test specification data of the service interface; a logic parsing module, configured to parse and process the test request through a large language model to obtain service logic information of the service interface; a metric data parsing module, configured to parse and process the test specification data through a large language model to obtain test metric data of the service interface; a generation module, configured to generate a test case for the service interface based on the large language model according to the service logic information of the service interface and the test metric data of the service interface; and a testing module, configured to call a preset testing tool to execute the test case to obtain a test result of the test case.

[0007] In the third aspect of the embodiments of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the steps of the above method when executing the computer program.

[0008] In the fourth aspect of the embodiments of the present disclosure, a computer-readable storage medium is provided, where the computer-readable storage medium stores a computer program, and the computer program implements the steps of the above method when executed by a processor.

[0009] The beneficial effects of the embodiments of the present disclosure compared with the prior art are as follows: The embodiments of the present disclosure can parse and process the test request through a large language model, and can deeply extract the service logic information of the service interface. This enables the generated test cases to better reflect the actual business scenarios, improving the accuracy and effectiveness of testing. The parsing and processing of the test specification data enables the generated test cases to be based not only on the basic functions of the API, but also combined with specific test metrics. This comprehensive coverage ensures that the test cases can cover more business requirements, thereby effectively reducing the risk of missed testing. Through the application of the large language model, the process of generating test cases has achieved a high degree of automation, reducing the dependence on manual intervention. This not only improves the testing efficiency, but also reduces the possibility of human errors and enhances the reliability of testing. This method can handle complex business scenarios involving multiple endpoints. Through the comprehensive analysis of service logic and test metrics, the generated test cases can simulate real business processes, enhancing the coverage and depth of testing. Due to the reduction of manual intervention and the improvement of testing automation, the time and cost required for testing are effectively reduced, thereby reducing the total cost of ownership (TCO). Enterprises can obtain higher testing quality and efficiency with lower investment. Through the context awareness ability of the large language model, the generated test cases are more targeted, can effectively detect potential semantic errors, and reduce the false positive rate. This feature makes the test results more accurate, thereby enhancing the overall quality of the software. Description of the Drawings

[0010] To more clearly illustrate the technical solutions in the embodiments of the present disclosure, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings in the following description are only some embodiments of the present disclosure. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0011] Figure 1 The figure shows a schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of the present invention can be applied;

[0012] Figure 2 It is a flowchart of an interface testing method provided by an embodiment of the present disclosure;

[0013] Figure 3 It is a block diagram of an interface testing device provided by an embodiment of the present disclosure;

[0014] Figure 4 It is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure. Detailed implementation manners

[0015] In the following description, specific details such as specific system structures and technologies are presented for the purpose of illustration rather than limitation, so as to thoroughly understand the embodiments of the present disclosure. However, those skilled in the art should clearly understand that the present disclosure can also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to avoid unnecessary details from interfering with the description of the present disclosure.

[0016] It should be noted that the user information (including but not limited to terminal device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in the present disclosure are all information and data that have been authorized by the user or fully authorized by all parties.

[0017] Figure 1 The figure shows a schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of the present invention can be applied.

[0018] As Figure 1 shown, the system architecture 100 may include one or more of the first terminal device 101, the second terminal device 102, and the third terminal device 103, a network 104, and a server 105. The network 104 is used as a medium to provide a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0019] It should be understood, Figure 1The numbers of the terminal devices, the network, and the server in it are merely illustrative. According to the implementation requirements, there can be any number of terminal devices, networks, and servers. For example, the server 105 can be a server cluster composed of multiple servers, etc.

[0020] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send data, etc. The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with a display screen, including but not limited to smartphones, tablets, portable computers, desktop computers, and so on.

[0021] The server 105 can be a server that provides various services. For example, the server 105 can obtain a test request for a service interface and test specification data for the service interface from the first terminal device 103 (which can also be the second terminal device 102 or the third terminal device 103); parse and process the test request through a large language model to obtain the service logic information of the service interface; parse and process the test specification data through a large language model to obtain the test index data of the service interface; generate test cases for the service interface based on the large language model according to the service logic information of the service interface and the test index data of the service interface; and call a preset test tool to execute the test cases to obtain the test results of the test cases.

[0022] In some embodiments, the interface testing method provided by the embodiments of the present invention is generally executed by the server 105. Correspondingly, the interface testing device is generally set in the server 105. In other embodiments, some terminal devices can have functions similar to those of the server and thus execute this method. Therefore, the interface testing method provided by the embodiments of the present invention is not limited to being executed on the server side.

[0023] The following will describe in detail the interface testing method and device according to the embodiments of the present disclosure with reference to the accompanying drawings.

[0024] Figure 2 is a flowchart of an interface testing method provided by an embodiment of the present disclosure. The method provided by the embodiment of the present disclosure can be executed by any electronic device with computer processing capabilities. For example, the electronic device can be Figure 1 the server shown.

[0025] As Figure 2 shown, the interface testing method includes steps S210 to S250.

[0026] In step S210, obtain a test request for a service interface and test specification data for the service interface.

[0027] Step S220: Parse and process the test request through a large language model to obtain the business logic information of the business interface.

[0028] In step S230, parse and process the test specification data through a large language model to obtain the test metric data of the business interface.

[0029] In step S240, based on the large language model, generate test cases for the business interface according to the business logic information of the business interface and the test metric data of the business interface.

[0030] In step S250, call a preset test tool to execute the test cases and obtain the test results of the test cases.

[0031] This method can parse and process the test request through a large language model, and can deeply extract the business logic information of the business interface. This enables the generated test cases to better reflect the actual business scenario, improving the accuracy and effectiveness of testing. The parsing and processing of the test specification data enables the generated test cases to be based not only on the basic functions of the API, but also combined with specific test metrics. This comprehensive coverage ensures that the test cases can cover more business requirements, thus effectively reducing the risk of missed testing. Through the application of the large language model, the process of generating test cases has achieved a high degree of automation, reducing the dependence on manual intervention. This not only improves the testing efficiency, but also reduces the possibility of human errors and enhances the reliability of testing. This method can handle complex business scenarios involving multiple endpoints. Through the comprehensive analysis of business logic and test metrics, the generated test cases can simulate real business processes, enhancing the coverage and depth of testing. Due to the reduction of manual intervention and the improvement of testing automation, the time and cost required for testing are effectively reduced, thereby reducing the total cost of ownership (TCO). Enterprises can obtain higher testing quality and efficiency with lower investment. Through the context awareness ability of the large language model, the generated test cases are more targeted, can effectively detect potential semantic errors, and reduce the false positive rate. This feature makes the test results more accurate, thus enhancing the overall quality of the software.

[0032] In some embodiments of the present disclosure, in software development, such as in API testing, test requests for business interfaces typically describe business requirements in natural language. This description makes requirements more intuitive and easier for development and testing teams to understand. A detailed description of a specific business requirement: Imagine developing an e-commerce platform where users want to easily query inventory information for specific products. An example business requirement: A user of an online shopping platform wants to query the inventory quantity of a specific product by entering its ID to determine whether there is sufficient stock for their purchase. The user enters the product's unique identifier (product ID), and the system returns the current inventory quantity. If the product exists, the inventory quantity is displayed; if not, a corresponding error message is returned. Specifically, the user enters a product ID, such as "12345," in the search box. Upon receiving the request, the system searches the database for inventory information for the corresponding product. If the product exists and the inventory quantity is greater than 0, the system returns: "The current inventory quantity of the product with product ID 12345 is 10 units." If the product does not exist, the system returns: "The product with product ID 12345 does not exist." By describing business requirements in natural language, the development and testing teams can more clearly understand the user's desired functionality. This description method not only improves the readability of the requirements, but also provides a basis for the subsequent generation of API test cases, enabling the test cases to better cover actual business scenarios, thereby improving the quality of the API and user experience.

[0033] In some embodiments of the present disclosure, in API testing, test specification data refers to a detailed technical description and parsing details of the business interface. These specification data are usually in a standardized format to facilitate understanding and use by automated tools and testers. The following is a detailed description of the business interface test specification data, which describes the API technical details in the OpenAPI specification format. OpenAPI is a standard format for describing RESTful APIs, which aims to provide a machine-readable way to define the structure and behavior of the API. Through the OpenAPI specification, developers and testers can clearly understand all aspects of the API, including endpoints, request and response formats, parameters, authentication methods, etc. The main components of the OpenAPI specification: the name of the API, such as "E-commerce Platform Product Inventory Query API". The version number of the API, such as "v1.0.0". A brief description of the API, including its functions and uses. Server URL: the basic access address of the API. Path: a detailed description of each API endpoint, including the request method (such as GET, POST, etc.) and path.

[0034] In some embodiments of the present disclosure, the large language model is used to parse and process the test request to obtain the business logic information of the business interface, including: extracting the business background information and business target information from the test request through the large language model; generating the business logic information of the business interface based on the business background information and business target information through the large language model. For example, in software development and testing, using the large language model (LLM) to parse and process the test request can effectively extract and generate the logical information related to the business interface, which not only improves the intelligence level of testing but also enhances the understanding of business requirements. Specifically, assume a test request described as follows: "As a user of an online shopping platform, I hope to query the inventory quantity of a specific product by the product ID to see if there is enough inventory for me to purchase." Through the large language model, the business-related background information can be extracted from the test request. These information usually includes: identifying the user role in the request, such as "a user of an online shopping platform". Understanding the background of the request, such as "online shopping platform" refers to an e-commerce environment. Identifying the entities mentioned in the request, such as "product ID" and "inventory quantity". Extraction example: Role: a user of an online shopping platform. Context: e-commerce platform. Entities: product ID, inventory quantity. Then the business target information can be extracted, which refers to the specific goals that the user hopes to achieve through the interface. Usually includes: Target action: the operation that the user hopes to perform, such as "query". Target result: the result that the user expects to obtain, such as "inventory quantity". Extraction example: Target action: query. Target result: the inventory quantity of a specific product. After extracting the business background information and business target information, the large language model can generate the business logic information of the business interface based on these information. These logical information usually includes: Interface function description: clearly define the purpose and function of the interface. Input and output definition: define the input parameters (such as product ID) and output results (such as inventory quantity) of the interface. Business rules: describe the rules related to the business, such as the calculation method of inventory quantity, the available status of products, etc. Generation example: Interface function description: "This interface allows users to query the inventory quantity of a specific product by the product ID." Input and output definition: Input: product ID (string). Output: inventory quantity (integer), if the product does not exist, return the corresponding error message. Business rules: "If the inventory quantity is greater than 0, return the inventory quantity; if the product ID is invalid, return a 404 error." Through this process, the detailed documentation of the business interface can be quickly generated, improving the efficiency of development and testing. For example: Automatic test case generation: automatically generate test cases according to the generated business logic information to ensure that the functions of the interface meet the business requirements. Interface document update: quickly update the document when the interface function or business logic changes to ensure that developers and testers always use the latest information.

[0035] By parsing and processing test requests through large language models, business background information and business objective information can be efficiently extracted, and business logic information for business interfaces can be generated based on this information. This process not only improves the understanding of business requirements but also provides a reliable foundation for subsequent testing and development, enhancing the flexibility and responsiveness of software development.

[0036] In some embodiments of the present disclosure, the large language model is used to parse and process the test specification data to obtain the test metric data of the service interface, including: extracting the endpoint information of the service interface from the test specification data through the large language model; extracting the parameter information of the service interface from the test specification data through the large language model; extracting the expected response information of the service interface from the test specification data through the large language model. For example, in API testing, the test specification data is the key to ensuring the correctness and reliability of the interface. By parsing and processing these test specification data through the large language model (LLM), the test metric data of the service interface, including endpoint information, parameter information, and expected response information, can be effectively extracted. Specifically, the test specification data usually includes a detailed description of the API, such as functions, parameters, response formats, etc. Taking the OpenAPI specification as an example, the test specification data may include the following content: Endpoint information: the URL and request method of the API. Parameter information: the parameters required in the request and their types. Expected response information: the data structure and status code returned after the API call. Through the large language model, the endpoint information of the API can be extracted from the test specification data. These information usually include: Endpoint URL: the access address of the API. Request method: such as GET, POST, PUT, etc. Parameter information refers to the input parameters required in the API request, including path parameters, query parameters, and request body parameters. The large language model can identify and extract these information, specifically including: Parameter name: such as productId. Parameter type: such as string, integer, etc. Whether required: indicates whether the parameter is a required item. Description: a detailed description of the parameter. Expected response information refers to the data structure and status code returned after the API call. Through the large language model, the following information can be extracted: Status code: such as 200, 404, 500, etc. Response body format: describes the structure of the returned data. Example response: provides one or more response examples for easy understanding. By using the extracted test metric data, and leveraging the extracted endpoints, parameters, and expected response information, test cases are automatically generated to ensure that the functions of the interface meet the expectations. According to the extracted information, the API documentation is automatically generated or updated to ensure the accuracy and consistency of the documentation. Based on the extracted parameters and response information, the coverage of the test cases is analyzed to ensure that all important paths and boundary conditions are tested. By parsing and processing the test specification data through the large language model, the test metric data of the service interface, including endpoint information, parameter information, and expected response information, can be efficiently extracted. This process not only improves the automation level of testing, but also provides clear and accurate interface information for the development and testing teams, enhancing the quality and efficiency of software development.

[0037] In some embodiments of the present disclosure, generating test cases for a service interface based on a large language model according to the service logic information of the service interface and the test metric data of the service interface includes: generating test cases for the service interface based on the service logic information of the service interface, the endpoint information of the service interface, the parameter information of the service interface, and the expected response information of the service interface by the large language model. For example, in software development and testing, automatically generating test cases is a key step in improving efficiency and accuracy. Through a large language model (LLM), high-quality test cases can be automatically generated based on the service logic information and test metric data of the service interface. Specifically, the service logic information describes the function of the interface, the input and output definitions, and the business rules. By understanding this information, the LLM can generate test cases that are consistent with the business requirements. Example: Interface function description: Query the inventory quantity of a specific product. Input and output definitions: Input: Product ID (string). Output: Inventory quantity (integer). Business rule: If the product ID is invalid, return a 404 error. The test metric data includes endpoint information, parameter information, and expected response information, which provide specific context for generating test cases. Example: Endpoint information: URL:

[0038] / products / {productId}. Request method: GET. Parameter information: Name: productId. Type: string. Required: Yes. Description: The unique identifier of the product. Expected response information: Status code: 200.

[0039] Response body format:

[0040] {

[0041] "productId":"12345",

[0042] "inventory":10

[0043] }

[0044] Based on the extracted service logic information and test metric data, the LLM can generate test cases according to the following steps:

[0045] Step 1: Define the test case structure. Each test case should contain the following basic information: Test case ID: Unique identifier. Test case description: Briefly describe the purpose of the test. Preconditions: Conditions that need to be met before executing the test. Input data: Request parameters and their values. Expected result: Expected response status code and response body. Execution steps: Specific steps to execute the test

[0046] Step 2: Generate specific test cases. The LLM generates multiple test cases based on the business logic information and test metric data to cover different scenarios and boundary conditions. Example generated test cases: Test case ID: TC001. Test case description: Query the inventory quantity of valid products. Prerequisite: The product ID is a valid value. Input data: productId: "12345". Expected result: Status code: 200. Response body:

[0047] {

[0048] "productId": "12345",

[0049] "inventory": 10

[0050] }

[0051] Execution steps: Send a GET request to / products / 12345. Verify that the response status code is 200 and verify that the response body content meets the expectations. Test case ID: TC002. Test case description: Query the inventory quantity of invalid products. Prerequisite: The product ID is an invalid value. Input data: productId: "invalid-id". Expected result: Status code: 404. Response body: Empty or error message. Execution steps: Send a GET request to / products / invalid-id. Verify that the response status code is 404. Test case ID: TC003. Test case description: Query a request missing the product ID. Prerequisite: None. Input data: None. Expected result: Status code: 400 (if the API is designed to require a product ID). Execution steps: Send a GET request to

[0052] / products / . Verify that the response status code is 400. By using the generated test cases, use a test framework (such as JUnit, pytest, etc.) to automatically execute the generated test cases to ensure the correctness of the interface. Analyze the generated test cases to ensure that all important business scenarios and boundary conditions are covered. Integrate the generated test cases into the CI / CD process to ensure that the functionality of the interface can be automatically verified after each code change. By generating test cases based on the business logic information and test metric data of the business interface through the large language model, test cases that meet the business requirements can be created efficiently. This process not only improves the automation level of testing but also ensures the comprehensiveness and accuracy of the test cases, thus improving the quality and efficiency of software development.

[0053] In some embodiments, the method further includes: traversing a preset verification data table based on the business logic information of the service interface to verify whether the preset verification data table contains the business logic information of the service interface; traversing the preset verification data table based on the test index data of the service interface to verify whether the preset verification data table contains the test index data of the service interface. For example, in software testing, verifying the integrity and accuracy of data is an important part of ensuring the normal operation of the service interface. By traversing the preset verification data table, it can be checked whether the table contains the business logic information and test index data of the service interface. The preset verification data table is a structured data set used to store verification data related to the service interface. These data usually include: Business logic information: Describes the functions of the interface, input and output definitions, business rules, etc. Test index data: Includes endpoint information, parameter information, expected response information, etc.

[0054] Specifically, step 1: Define the business logic information, which usually includes the following aspects:

[0055] Interface function: The main function description of the interface.

[0056] Input and output definitions: The input parameters required by the interface and their types, as well as the returned output results.

[0057] Business rules: The behavior description of the interface under specific conditions.

[0058] Example:

[0059] Suppose the business logic information of the service interface is as follows:

[0060] Interface function: Query the product inventory

[0061] Input parameter: productId (string)

[0062] Output result: Return the inventory quantity of the product

[0063] Step 2: Traverse the preset verification data table

[0064] Traverse the preset verification data table to check whether it contains the above business logic information. The specific operations include: Read the preset verification data table: Load the preset verification data table from the database or file. Traverse each row of data: Check whether each row contains the interface function, input and output definitions, and business rules.

[0065] Verify the match: For each piece of business logic information, check whether it exists in the preset verification data table.

[0066] If there is a row in the preset verification data table described as "Query the product inventory, with the parameter being productId, and return the inventory quantity", the verification passes. If the corresponding description is not found, it is recorded as a verification failure and the missing information is output.

[0067] Verification test metric data

[0068] Step 1: Define the test metric data

[0069] The test metric data includes:

[0070] Endpoint information: The URL and request method of the API.

[0071] Parameter information: The parameters required in the request and their types.

[0072] Expected response information: The data structure and status code returned after the API call.

[0073] Example:

[0074] Suppose the test metric data is as follows:

[0075] Endpoint: / products / {productId}

[0076] Request method: GET

[0077] Parameter: productId (string, required)

[0078] Expected response: Status code 200, return format is JSON.

[0079] Step 2: Traverse the preset verification data table

[0080] Similarly, traverse the preset verification data table to check if it contains the above test metric data. The specific operations include: Read the preset verification data table: Load the preset verification data table from the database or file. Traverse each row of data: Check if each row contains endpoint information, parameter information, and expected response information.

[0081] Verification matching: For each test metric data, check if it exists in the preset verification data table. If there is a row in the preset verification data table described as "GET request to / products / {productId}, with the parameter being productId, and return status code 200", the verification passes. If the corresponding description is not found, it is recorded as a verification failure and the missing information is output.

[0082] After completing the verification, it is necessary to record the verification results and generate a report for subsequent analysis and improvement. Record the passed business logic information and test metric data. Record the missing business logic information and test metric data and provide detailed explanations. Summarize the verification results to generate a verification report for the team to review and improve.

[0083] By verifying the preset verification data table, the consistency between test cases and business logic and test metric data can be ensured, avoiding omissions or errors. Through verification, ensure that all key business logics and test metrics have been fully tested. In the CI / CD process, regularly verify the preset verification data table to ensure the accuracy and integrity of the data. By traversing the preset verification data table based on the business logic information and test metric data of the business interface, the integrity and accuracy of the data can be effectively verified. This process not only improves the reliability of testing but also provides clear feedback to the development and testing teams, supporting continuous improvement and optimization.

[0084] In some embodiments of the present disclosure, the method further includes: analyzing the test results of test cases through a large language model to determine the endpoint coverage, parameter coverage, and response coverage of the business interface; determining whether the endpoint coverage, parameter coverage, and response coverage of the business interface meet the coverage conditions, and generating feedback information for the business interface according to the determination results. For example, by analyzing the test results of test cases through a large language model (LLM), the endpoint coverage, parameter coverage, and response coverage of the business interface can be effectively evaluated, and corresponding feedback information can be generated.

[0085] Specifically, 1. Define the coverage metrics. Before analyzing the test results, it is necessary to clarify the definition of coverage:

[0086] Endpoint coverage: It refers to the proportion of the API endpoints being tested covered among all possible endpoints.

[0087] Parameter coverage: It refers to the proportion of the parameters covered by the test cases among all possible request parameters.

[0088] Response coverage: It refers to the proportion of the responses verified by the test cases among all possible response scenarios.

[0089] 2. Collect test cases and test results

[0090] Step 1: Collect test cases

[0091] Collect all test cases related to the business interface, including: test case ID, endpoint information, input parameters, and expected responses.

[0092] Step 2: Collect the execution results of each test case, including: test case ID, execution status (passed / failed), actual response.

[0093] 3. Analyze the test results

[0094] Step 1: Analyze the endpoint coverage

[0095] Extract all endpoints: Extract all available API endpoints from the business interface document or code.

[0096] Count the endpoints under test: According to the execution of test cases, count the number of endpoints actually under test and calculate the coverage.

[0097] Step 2: Analyze the parameter coverage

[0098] Extract all parameters: Extract all possible request parameters and their types from the business interface document.

[0099] Count the parameters under test: According to the execution of test cases, count the number of parameters actually under test and calculate the coverage.

[0100] Step 3: Analyze the response coverage

[0101] Extract all response situations: List all possible response status codes and response formats according to the business logic definition. Count the verified responses: According to the test results, count the actual verified response situations and calculate the coverage.

[0102] 4. Judge whether the coverage meets the conditions

[0103] Step 1: Set the coverage conditions

[0104] According to the project requirements, set the coverage thresholds for endpoints, parameters, and responses. For example:

[0105] Endpoint coverage: ≥90%

[0106] Parameter coverage: ≥85%

[0107] Response coverage: ≥90%

[0108] Step 2: Judge the coverage

[0109] Compare the calculated coverage with the set conditions to judge whether the requirements are met. If a certain coverage is lower than the conditions, record it as not met. If all coverages meet the conditions, record it as met.

[0110] 5. Generate feedback information for the business interface

[0111] Step 1: Build a feedback information template

[0112] Based on the judgment result of coverage, construct a template for feedback information, including interface name: the name of the business interface. Endpoint coverage: the calculated endpoint coverage and its judgment result. Parameter coverage: the calculated parameter coverage and its judgment result. Response coverage: the calculated response coverage and its judgment result. Suggestion: If the coverage does not meet the conditions, provide improvement suggestions.

[0113] Step 2: Generate feedback information

[0114] Use a large language model to integrate the collected information and judgment results to generate feedback information. An example of feedback information is as follows:

[0115] Interface name: Query product inventory interface

[0116] - Endpoint coverage: 85% (not satisfied, it is recommended to add test cases for other endpoints)

[0117] - Parameter coverage: 90% (satisfied)

[0118] - Response coverage: 75% (not satisfied, it is recommended to add test cases for different response situations)

[0119] Overall suggestion: Please add test cases to improve the coverage of endpoints and responses to ensure comprehensive testing of the interface.

[0120] In the CI / CD process, regularly analyze the test results and generate feedback information to ensure the quality of the interface. Use the feedback information to guide the test team to optimize the test cases and improve the coverage. Provide a regular report on the interface quality to the project management for decision-making support. Analyzing the test results of test cases through a large language model can systematically evaluate the endpoint coverage, parameter coverage, and response coverage of business interfaces. This process can not only ensure comprehensive testing of the interface but also provide clear feedback information to the development and test teams to support continuous improvement and optimization.

[0121] In some embodiments, the method further includes: when the feedback information of the business interface indicates that the coverage condition is not met, call the test script for improving the test cases; update the test cases according to the feedback information of the business interface through the test script. For example, analyze the feedback information of the business interface to identify which coverage metrics do not meet the set conditions. The feedback information usually includes: Endpoint coverage: endpoints below the threshold. Parameter coverage: uncovered parameters. Response coverage: un-verified response situations.

[0122] Example feedback information:

[0123] Interface name: Query product inventory interface

[0124] - Endpoint coverage: 85% (not satisfied, it is recommended to add test cases for other endpoints)

[0125] - Parameter coverage: 90% (met)

[0126] - Response coverage: 75% (not met, it is recommended to increase test cases for different response situations)

[0127] From the above feedback information, it is identified that the "endpoint coverage" and "response coverage" do not meet the conditions.

[0128] Call the test script for improving test cases, and the function of this script is to automatically generate or update test cases according to the feedback information. The test script should have the following functions:

[0129] Receive feedback information: Be able to receive and parse feedback information.

[0130] Generate new test cases: Generate new test cases according to the uncovered endpoints and response situations.

[0131] Update existing test cases: Update the existing test cases according to the feedback information to ensure the improvement of their coverage.

[0132] After updating the test cases, it is necessary to verify again to ensure that the new test cases can improve the coverage: Re-run the tests: Execute all test cases and check the new coverage metrics. Generate new feedback information: Analyze the results of the new round of tests and generate new feedback information. Record the process of updating test cases, including: the number of added test cases, the number of updated existing test cases, and the change in coverage. Generate a test update report, including the following content: comparison of coverage before and after the update, list of newly added test cases, and list of updated test cases.

[0133] In the CI / CD process, automatically call the test script to ensure the continuous update and coverage of test cases. By automatically updating test cases, improve the test coverage of the interface and ensure software quality. By calling the test script for improving test cases, it is possible to effectively update test cases according to the feedback information of business interfaces. This process not only improves the test coverage but also ensures the continuous improvement of software quality, providing an efficient solution for the development and test teams.

[0134] Figure 3 It is a block diagram of an interface test device provided by an embodiment of the present disclosure.

[0135] As Figure 3 shown, the interface test device 300 includes an acquisition module 310, a logic parsing module 320, a metric data parsing module 330, a generation module 340, and a test module 350.

[0136] Specifically, an acquisition module 310 is configured to acquire a test request for a service interface and test specification data of the service interface.

[0137] A logic parsing module 320 is configured to parse and process the test request through a large language model to obtain business logic information of the service interface.

[0138] An index data parsing module 330 is configured to parse and process the test specification data through a large language model to obtain test index data of the service interface.

[0139] A generation module 340 is configured to generate test cases for the service interface based on the business logic information of the service interface and the test index data of the service interface according to a large language model.

[0140] A testing module 350 is configured to call a preset testing tool to execute the test cases and obtain test results of the test cases.

[0141] The interface testing device 300 can parse and process the test request through a large language model, and can deeply extract the business logic information of the service interface. This enables the generated test cases to better reflect the actual business scenario, improving the accuracy and effectiveness of testing. The parsing and processing of the test specification data enables the generated test cases to be based not only on the basic functions of the API, but also on specific test metrics. This comprehensive coverage ensures that the test cases can cover more business requirements, thus effectively reducing the risk of missed testing. Through the application of the large language model, the process of generating test cases has achieved a high degree of automation, reducing the dependence on manual intervention. This not only improves testing efficiency, but also reduces the possibility of human errors and enhances the reliability of testing. This method can handle complex business scenarios involving multiple endpoints. Through the comprehensive analysis of business logic and test metrics, the generated test cases can simulate real business processes, enhancing the coverage and depth of testing. Due to the reduction of manual intervention and the improvement of testing automation, the time and cost required for testing are effectively reduced, thereby reducing the total cost of ownership (TCO). Enterprises can obtain higher testing quality and efficiency with lower investment. Through the context awareness ability of the large language model, the generated test cases are more targeted, can effectively detect potential semantic errors, and reduce the false positive rate. This feature makes the test results more accurate, thus enhancing the overall quality of the software.

[0142] In some embodiments of the present disclosure, the logic parsing module 320 is configured to: extract business background information and business objective information from the test request through a large language model; generate business logic information of the service interface based on the business background information and the business objective information through a large language model.

[0143] In some embodiments of the present disclosure, the index data parsing module 330 is configured to: extract the endpoint information of the service interface from the test specification data through a large language model; extract the parameter information of the service interface from the test specification data through a large language model; extract the expected response information of the service interface from the test specification data through a large language model.

[0144] In some embodiments of the present disclosure, the generation module 340 is configured to: generate test cases for the service interface based on the business logic information of the service interface, the endpoint information of the service interface, the parameter information of the service interface, and the expected response information of the service interface according to a large language model.

[0145] In some embodiments of the present disclosure, the interface testing device 300 is further configured to: traverse a preset verification data table based on the business logic information of the service interface to verify whether the preset verification data table contains the business logic information of the service interface; traverse the preset verification data table based on the test index data of the service interface to verify whether the preset verification data table contains the test index data of the service interface.

[0146] In some embodiments of the present disclosure, the interface testing device 300 is further configured to: analyze the test results of the test cases through a large language model to determine the endpoint coverage, parameter coverage, and response coverage of the service interface; determine whether the endpoint coverage, parameter coverage, and response coverage of the service interface meet the coverage conditions, and generate feedback information for the service interface according to the determination result.

[0147] In some embodiments of the present disclosure, the interface testing device 300 is further configured to: when the feedback information of the service interface indicates that the coverage conditions are not met, call a test script for improving the test cases; update the test cases according to the feedback information of the service interface through the test script.

[0148] Figure 4 is a schematic diagram of the electronic device 4 provided by the embodiments of the present disclosure. As Figure 4 shown, the electronic device 4 of this embodiment includes: a processor 401, a memory 402, and a computer program 403 stored in the memory 402 and executable on the processor 401. When the processor 401 executes the computer program 403, the steps in the above-mentioned method embodiments are implemented. Alternatively, when the processor 401 executes the computer program 403, the functions of the respective modules in the above-mentioned device embodiments are implemented.

[0149] The electronic device 4 may be a desktop computer, a notebook, a palm computer, a cloud server, and other electronic devices. The electronic device 4 may include, but is not limited to, a processor 401 and a memory 402. Those skilled in the art can understand, Figure 4This is only an example of the electronic device 4, which does not constitute a limitation on the electronic device 4. It may include more or fewer components than those shown in the figure, or different components.

[0150] The processor 401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0151] The memory 402 may be an internal storage unit of the electronic device 4, for example, the hard disk or memory of the electronic device 4. The memory 402 may also be an external storage device of the electronic device 4, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc., equipped on the electronic device 4. The memory 402 may also include both an internal storage unit and an external storage device of the electronic device 4. The memory 402 is used to store computer programs and other programs and data required by the electronic device.

[0152] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0153] When an integrated module is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, to implement all or part of the processes in the above-described embodiment methods of the present disclosure, it can also be completed by a computer program instructing relevant hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above-described various method embodiments can be implemented. The computer program can include computer program code, and the computer program code can be in the form of source code, object code, an executable file, or some intermediate form, etc. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a mobile hard disk, a magnetic disk, an optical disc, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc. It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0154] The above embodiments are only used to illustrate the technical solutions of the present disclosure, and are not intended to limit them; although the present disclosure has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the various embodiments of the present disclosure, and should all be included in the protection scope of the present disclosure.

Claims

1. An interface testing method, characterized in that Including: Obtain a test request for the service interface and test specification data for the service interface; Parse and process the test request through a large language model to obtain the business logic information of the service interface; Parse and process the test specification data through the large language model to obtain the test index data of the service interface; Based on the large language model, generate test cases for the service interface according to the business logic information of the service interface and the test index data of the service interface; Invoke a preset test tool to execute the test cases and obtain the test results of the test cases.

2. The method according to claim 1, wherein Parsing and processing the test request through a large language model to obtain the business logic information of the service interface includes: Extract business background information and business objective information from the test request through the large language model; Based on the business background information and the business objective information, generate the business logic information of the service interface through the large language model.

3. The method according to claim 1, wherein Parsing and processing the test specification data through the large language model to obtain the test index data of the service interface includes: Extract the endpoint information of the service interface from the test specification data through the large language model; Extract the parameter information of the service interface from the test specification data through the large language model; Extract the expected response information of the service interface from the test specification data through the large language model.

4. The method according to claim 3, characterized in that, The generating the test cases for the service interface based on the business logic information of the service interface and the test index data of the service interface according to the large language model includes: Based on the large language model, according to the business logic information of the service interface, the endpoint information of the service interface, the parameter information of the service interface, and the expected response information of the service interface, generate the test cases for the service interface.

5. The method according to claim 1, characterized in that, The method further includes: Traverse a preset verification data table based on the business logic information of the service interface to verify whether the preset verification data table contains the business logic information of the service interface; Traverse the preset verification data table based on the test index data of the service interface to verify whether the preset verification data table contains the test index data of the service interface.

6. The method according to claim 1, characterized in that, The method further includes: Analyze the test results of the test cases through the large language model to determine the endpoint coverage, parameter coverage, and response coverage of the service interface; Judge whether the endpoint coverage, parameter coverage, and response coverage of the service interface meet the coverage conditions, and generate feedback information for the service interface according to the judgment result.

7. The method according to claim 6, wherein The method further includes: When the feedback information of the service interface indicates that the coverage conditions are not met, invoke a test script for improving the test cases; Update the test cases according to the feedback information of the service interface through the test script.

8. An interface testing device, characterized in that, Including: An acquisition module for acquiring a test request for the service interface and test specification data for the service interface; A logic parsing module for parsing and processing the test request through a large language model to obtain the business logic information of the service interface; An index data parsing module, configured to parse the test specification data through the large language model to obtain the test index data of the service interface; A generation module, configured to generate test cases for the service interface based on the business logic information of the service interface and the test index data of the service interface according to the large language model; A test module, configured to call a preset test tool to execute the test cases to obtain the test results of the test cases.

9. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images