Test case generation method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a test case generation method and device, electronic equipment and storage medium, relates to the technical field of computers, and particularly relates to the technical fields of artificial intelligence, large models, software product testing, maps and the like. The specific implementation scheme comprises: obtaining test requirement description information for a target software product; obtaining business description information of the target software product; obtaining a target test template corresponding to the test requirement description information; and using a first large model to generate a first test case based on the test requirement description information and the business description information and on the basis of the target test template. The present disclosure can improve the generation quality and maintenance efficiency of test cases.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of artificial intelligence, large models, software testing, and mapping, specifically to a test case generation method, apparatus, electronic device, and storage medium. Background Technology

[0002] In the context of increasingly complex software product architectures and continuously diversified business scenarios, the stable operation of software products highly depends on reliable and efficient testing assurance.

[0003] However, currently, generating test cases for software products typically requires multiple rounds of communication between the testing team and product managers and developers, or consulting a large amount of technical documentation to determine test requirements and verification logic. Based on this, test cases are then manually designed and written, a process that is time-consuming and wastes significant human resources. At the same time, due to individual differences in programming habits and knowledge backgrounds among testing team members, test cases lack unified standards in terms of data source dependencies, code architecture, naming conventions, function design, and documentation comments, which seriously affects the quality of test case generation and maintenance efficiency. Summary of the Invention

[0004] This disclosure provides a test case generation method, apparatus, electronic device, and storage medium.

[0005] According to a first aspect of this disclosure, a test case generation method is provided, comprising: Obtain test requirement descriptions for the target software product; Obtain the business description information of the target software product; Obtain the target test template corresponding to the test requirement description information; Using the first major model, based on the test requirement description information and business description information, the first test case is generated on the basis of the target test template.

[0006] According to a second aspect of this disclosure, a test case generation apparatus is provided, comprising: The first information acquisition unit is used to acquire test requirement description information for the target software product. The second information acquisition unit is used to acquire business description information of the target software product; The template acquisition unit is used to acquire the target test template corresponding to the test requirement description information. The first test case generation unit is used to generate the first test cases based on the test requirement description information and business description information, using the first major model and the target test template.

[0007] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; Memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by at least one processor, which are executed by at least one processor to enable the at least one processor to perform the method provided in the first aspect of this disclosure.

[0008] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions; wherein the computer instructions are used to cause a computer to perform the method provided in the first aspect of this disclosure.

[0009] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program; wherein, when executed by a processor, the computer program is capable of implementing the method provided in the first aspect of this disclosure.

[0010] Using this disclosure can improve the quality of test case generation and maintenance efficiency.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 A flowchart illustrating a test case generation method provided in this embodiment of the disclosure; Figure 2 This is a complete flowchart illustrating a test case generation method provided in an embodiment of the present disclosure; Figure 3 This is a schematic diagram illustrating an application scenario of a test case generation method provided in an embodiment of this disclosure; Figure 4 A schematic structural block diagram of a training device for a large model provided in an embodiment of this disclosure; Figure 5 This is a schematic structural block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0013] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0014] This disclosure provides a test case generation method, which can be applied to electronic devices, specifically to a test case generation system installed on an electronic device. The electronic device can be a service device or a terminal device. Here, the service device can be a server, workbench, mainframe computer, or other similar computing device; the terminal device can be a workbench, mainframe computer, conventional computer (e.g., desktop computer, laptop computer, tablet computer, etc.), or other similar computing device. The following will be combined with… Figure 1 The flowchart shown illustrates a test case generation method provided in this disclosure. It should be noted that although the flowchart shows a logical order, in some cases, the steps shown or described in the flowchart may be executed in a different order.

[0015] Step S101: Obtain the test requirement description information for the target software product.

[0016] The target software product can be a software product with testing requirements, such as, but not limited to, vehicle networking server systems, e-commerce transaction systems, financial risk control systems, enterprise resource planning systems, and medical and health information systems.

[0017] In this embodiment of the disclosure, the test requirement description information can be used to characterize the test objectives for the target software product. For example, it can be used to characterize which product line, functional module, or interface to be tested of the target software product needs to be tested. The test requirement description information can be in text, image, table, or other forms, and this embodiment of the disclosure does not impose any limitations on this.

[0018] Step S102: Obtain the business description information of the target software product.

[0019] The business description information can include at least one of business information and interface information. Here, business information can include requirement documents maintained by product managers, technical documents maintained by developers, and historical test documents and business architecture information maintained by testers; interface information can include interface protocol documents and input / output parameter information maintained by developers.

[0020] Step S103: Obtain the target test template corresponding to the test requirement description information.

[0021] It is understood that a test template library will be provided in advance in this embodiment of the disclosure.

[0022] In this embodiment, the test template library stores multiple candidate test templates, and each candidate test template may include multiple framework constraint elements to ensure that the generated test cases have consistent style, maintainability, and reusability. The multiple framework constraint elements may include at least one of the following: fixed structure, convention code, dependency imports, decorator tags, initialization logic, and public assertion patterns. Here, the fixed structure can be used to characterize the test code organization form that the test cases need to follow; the convention code can be used to characterize the naming rules, method order, comment format, etc., that need to be followed when writing test cases; dependency imports can be used to characterize the libraries that need to be imported when writing test cases; decorator tags can be used to tag or add descriptions to test cases; initialization logic can be used to prepare the test environment; and the public assertion pattern can be a pre-defined, general assertion statement to ensure that each test case can at least verify its own basic correctness.

[0023] In this embodiment of the disclosure, when obtaining the target test template corresponding to the test requirement description information, a candidate test template corresponding to the test requirement description information (that is, a candidate test template adapted to the test requirement description information) can be determined from multiple candidate test templates, and the candidate test template corresponding to the test requirement description information is determined as the target test template.

[0024] Step S104: Using the first main model, based on the test requirement description information and business description information, generate the first test case on the basis of the target test template.

[0025] The first major model can be a Large Language Model (LLM) or a trained LLM. Here, an LLM can be a pre-trained neural network model (e.g., an autoregressive generative model with a Transformer architecture) that possesses general language knowledge, world knowledge, and domain-specific expertise (e.g., expertise in the field of computer technology).

[0026] In this embodiment of the disclosure, after obtaining the test requirement description information for the target software product, the business description information of the target software product, and the target test template corresponding to the test requirement description information, the target test template, as a "basic test framework" for generating the first test case, already includes multiple framework limiting elements, and these multiple framework limiting elements are fixed content. Therefore, the first model can be used to generate "fill-in-the-blank" or "fill-in-the-blank" combined with "expansion" test cases based on the test requirement description information and the business description information, in order to obtain the first test case.

[0027] The test case generation method provided in this disclosure firstly automatically acquires test requirement description information and business description information for the target software product. This transforms the test requirements and business knowledge that previously required multiple rounds of communication between testers, product managers, and developers into structured input information that can be directly read by the first-level model, providing multi-source information support for test case generation. Furthermore, after acquiring the target test template corresponding to the test requirement description information, the first-level model generates first test cases based on the test requirement description information and business description information, eliminating the need for testers to manually write them. This frees testers from tedious requirements communication and programming work, avoiding waste of human resources and significantly shortening the test case design and generation cycle, thus improving test case generation efficiency.

[0028] Secondly, addressing the technical problems of inconsistent test case quality and low maintenance efficiency caused by individual differences in programming habits and knowledge backgrounds among test team members in traditional solutions, this embodiment of the disclosure, after automatically acquiring test requirement description information and business description information for the target software product, uses the target test template corresponding to the test requirement description information as a fixed "basic test framework." This ensures that regardless of the programming habits or knowledge background of the testers initiating the test case generation request, the resulting first test cases possess style consistency, maintainability, and reusability. Based on this, the first major model, based on the test requirement description information and business description information, generates "fill-in-the-blank" or "fill-in-the-blank" combined with "expansion" test cases on the target test template to obtain the first test cases. This retains the style consistency, maintainability, and reusability provided by the target test template while leveraging the first major model's ability to understand complex business logic, thereby significantly improving the quality of test case generation and maintenance efficiency.

[0029] In this embodiment of the disclosure, the test requirement description information may include multiple sub-description information divided according to hierarchy. For example, it may include product lines, functional modules, interfaces under test, output and input parameters, and verification points in a hierarchical order from high to low.

[0030] Here, a product line can be a business unit or subsystem of the target software product at the business level, usually corresponding to a specific business domain; a functional module can be a sub-module within a product line, divided according to technical responsibilities or business scenarios; the interface to be tested can be an Application Programming Interface (API) or Remote Procedure Call (RPC) method that needs to be tested; input and output parameters can include input parameters (i.e., the request data that needs to be provided when calling the interface to be tested) and output parameters (i.e., the response data returned after calling the interface to be tested); and verification points can be the specific content that needs to be verified after the test case is executed, in order to determine whether the interface function of the interface to be tested meets expectations.

[0031] For example, when the target software product is a vehicle networking server system and the product line is "navigation service", the functional module can be "RoutePlanningService"; the interface to be tested can include " / RoutePlanningService / GetRoute"; the input parameters can include at least one of the following: starting coordinates, ending coordinates, preference settings, license plate number, and specified waypoints; the output parameters can include at least one of the following: route identifier, route length and route steps (including multiple road segments with sequential relationships) and estimated arrival time; the verification points can include at least one of the following: returning a valid route, avoiding restricted areas, and passing through specified waypoints.

[0032] For example, when the target software product is a vehicle networking server system and the product line is "user and vehicle services", the functional module can be "VehicleBindService"; the interface to be tested can include " / VehicleBindService / BindVehicle"; the input parameters can include at least one of user identifier, vehicle identification number (VIN) and verification code; the output parameters can include at least one of binding status, binding time and authorization information; the verification points can include at least one of binding success, duplicate binding error, and illegal VIN error.

[0033] Furthermore, in some optional implementations, step S101, namely, "obtaining test requirement description information for the target software product", may include one of the following: (1) Respond to the triggering event of the pipeline for the target software product and obtain the test requirement description information.

[0034] The pipeline can be a Continuous Integration / Continuous Deployment (CI / CD) pipeline. Therefore, it is understood that in this embodiment of the disclosure, test requirement description information can be automatically obtained through the CI / CD pipeline.

[0035] For example, in the development process of a target software product, the CI / CD pipeline is automatically triggered when developers submit code changes (e.g., Git push operations) or merge requests to the code repository. At this time, the CI / CD pipeline system can call the test case generation system and send the code change information obtained based on the code change or merge request as test requirement description information to the test case generation system. Specifically, in this embodiment of the disclosure, the CI / CD pipeline system can determine the product line, functional module, interface to be tested, input / output parameters, and verification points based on the code change or merge request, and send these as test requirement description information to the test case generation system.

[0036] In other words, in this embodiment of the disclosure, test case generation can be seamlessly embedded into the CI / CD pipeline. Upon detecting a code change or merge request, the test case generation system can automatically identify the affected interface as the interface to be tested. At the same time, it determines the product line, functional module, input / output parameters, and verification points to obtain test requirement description information. After obtaining the business description information of the target software product and the target test template corresponding to the test requirement description information, it triggers the automatic generation of the corresponding test cases, so as to bring the testing process forward to the development stage, thereby improving the defect discovery efficiency of the target software product and reducing its repair cost.

[0037] (2) Respond to the call operation of the test case generation interface to obtain test requirement description information.

[0038] In this embodiment of the disclosure, the test case generation system can expose at least one test case generation interface. Other systems or services (e.g., test management platform, automated test framework, etc.) can send test requirement description information (including product line, functional module, interface to be tested, output and input parameters and verification points) to the test case generation interface through Hypertext Transfer Protocol (HTTP) requests, Hypertext Transfer Protocol Secure (HTTPS) requests, RPC method calls, message queues, etc.

[0039] For example, in a test management platform, testers can select the interface for which test cases need to be generated as the interface to be tested through the platform interface and click the "Smart Generation" button. At this time, the test management platform, as the interface caller, encapsulates the relevant information of the interface to be tested (e.g., interface name, input / output parameters, verification points, belonging functional module, and product line) into a request body, and uses this to call the test case generation interface of the test case generation system. After receiving the request body, the test case generation system can parse the request body to obtain the test requirement description information.

[0040] In other words, this embodiment exposes a test case generation interface, enabling the service-oriented encapsulation of test case generation capabilities. This allows test management platforms, automated testing frameworks, and other systems or services to quickly integrate test case generation capabilities by calling the interface via HTTP requests, HTTPS requests, RPC method calls, message queues, etc. This open design allows the test case generation system to seamlessly interface with test management platforms, automated testing frameworks, and other systems or services without altering the existing technology stack, significantly reducing the integration difficulty and promotion costs of the test case generation system.

[0041] (3) Respond to the test case generation request sent by the digital employee platform and obtain test requirement description information.

[0042] The digital employee platform (e.g., chatbot, virtual assistant, etc.) can provide testers with an entry point for generating test cases based on natural language interaction. Specifically, in this embodiment of the disclosure, testers can interact with the digital employee through text, images, tables, or voice to send test case generation requests to the test case generation system via the digital employee platform. The test case generation system then obtains test requirement description information based on these requests.

[0043] For example, the dialogue between the tester and the digital employee could be: "Please help me generate test cases for the ' / RoutePlanningService / GetRoute' interface of the 'RoutePlanningService' function module under the 'Navigation Service' product line. Input parameters include starting coordinates, ending coordinates, preference settings, license plate number, and specified waypoints; output parameters include route identifier, route length, route steps, and estimated arrival time; verification points include returning a valid route, avoiding restricted areas, and passing through specified waypoints."

[0044] In other words, in this embodiment of the disclosure, the test case generation entry point can be expanded from traditional command line or interface operation to natural language interaction scenarios by responding to test case generation requests sent by the digital employee platform. Thus, testers, and even personnel without a programming background, only need to describe test requirements using natural methods such as text, images, tables, and voice to trigger the automatic generation of test cases. This significantly reduces the difficulty of automated testing of the target software product, enabling more roles to participate in the design and maintenance of test cases, and further unleashing the efficiency of the testing team.

[0045] Furthermore, through the above methods, in this embodiment of the disclosure, on the one hand, test requirement description information can be obtained in response to pipeline trigger events for the target software product; on the other hand, test requirement description information can be obtained in response to the call operation of the test case generation interface; and furthermore, test requirement description information can be obtained in response to test case generation requests sent by the digital employee platform. This is equivalent to building a flexible, universal, and low-threshold test case generation access system, enabling testers to find the most suitable access path for their own technical architecture regardless of whether their business scenario leans towards development collaboration, platform integration, or human-machine collaboration. This effectively avoids the technical implementation obstacles caused by a single access method for the test case generation system, laying a solid foundation for the large-scale promotion of intelligent testing capabilities.

[0046] Furthermore, in this embodiment of the disclosure, when the test requirement description information includes multiple sub-description information divided according to hierarchy, step S103, namely, "obtaining the target test template corresponding to the test requirement description information", may include: Determine the current sub-description information from multiple sub-description information in ascending order of hierarchy; Perform a template query operation on the current sub-description information to obtain the template query results; If a candidate test template corresponding to the current sub-description information exists in the template query result representation test template library, the candidate test template corresponding to the current sub-description information will be determined as the target test template, and template query operations for other sub-description information will no longer be performed.

[0047] In this embodiment of the disclosure, the current sub-description information can be determined starting from a specified sub-description information among multiple sub-description information in a hierarchical order from low to high. As mentioned above, in this embodiment of the disclosure, the multiple sub-description information and their hierarchical order from high to low can be: product line > functional module > interface under test > output and input parameters > verification point.

[0048] At this point, the specified sub-description information can be "the interface to be tested".

[0049] For example, the multiple sub-description information and their hierarchical order from high to low are: Product Line > Functional Module > Interface Under Test > Input / Output Parameters > Verification Point, with the specified sub-description information being "Interface Under Test". First, "Interface Under Test" can be determined as the current sub-description information from the multiple sub-description information in ascending order of hierarchy, and a template query operation for "Interface Under Test" can be performed to obtain the template query results. If the template query results indicate that a candidate test template corresponding to "Interface Under Test" exists in the test template library, the candidate test template corresponding to "Interface Under Test" is determined as the target test template, and template query operations for other sub-description information (i.e., "Product Line" and "Functional Module") are not performed. If the template query results indicate that no candidate test template corresponding to "Interface Under Test" exists in the test template library, "Functional Module" can be determined as the current sub-description information from the multiple sub-description information in ascending order of hierarchy, and a template query operation for "Functional Module" can be performed to obtain the target test template. If the template query results show that a candidate test template corresponding to the "functional module" exists in the test template library, then the candidate test template corresponding to the "functional module" is determined as the target test template, and template query operations for other sub-description information (i.e., "product line") are no longer executed. If the template query results show that no candidate test template corresponding to the "functional module" exists in the test template library, then "product line" can be determined as the current sub-description information from multiple sub-description information in ascending order of hierarchy, and a template query operation for "product line" is executed to obtain the template query results. If the template query results show that a candidate test template corresponding to the "product line" exists in the test template library, then the candidate test template corresponding to the "product line" is determined as the target test template.

[0050] It is understood that, in this embodiment of the disclosure, the multiple candidate test templates stored in the test template library can be divided into at least product line-level templates, functional module-level templates, and interface-level templates according to their corresponding levels. Among these, the candidate test templates at different corresponding levels differ in the level of detail of the multiple framework-defining elements they include.

[0051] The following section will further explain the differences in the level of detail among the various framework-defining elements included in product line-level templates, functional module-level templates, and interface-level templates.

[0052] (1) Product line level template Product line level templates correspond to the highest-level sub-description information of "product line". They encapsulate the framework-defining elements common to all test cases within a specific business domain, and have the widest applicability.

[0053] Taking the "Navigation Service" product line in the vehicle-to-everything (V2X) server system as an example, its corresponding product line-level templates can include: Fixed structure: The most basic test code organization form of the "Navigation Service" product line is: file header comments → dependency imports → decorator markup → basic test class definition → empty setup_method → ​​placeholder test method. This level of fixed structure is relatively loose, leaving a large space for filling or expansion. Conventional code: Pre-defined common naming rules for the "Navigation Service" product line (e.g., test classes start with Test followed by the product line name), file header comment format (e.g., copyright, author, date), and common decorator usage conventions (e.g., @pytest.mark.product line name); Dependency imports: Pre-built common libraries for the "Navigation Service" product line, such as import route_pb2, fromtools import nav_headers, etc. Decorator markup: Add the @pytest.mark.NaviService markup, which is consistent across the "Navigation Service" product line, to facilitate the filtering of test cases by product line later. Initialization logic: In setup_method, pre-configure the request header acquisition method specific to the "Navigation Service" product line (e.g., self.header = nav_headers.get_header("NAVI")), general test data generation method, etc. Public assertion pattern: Pre-defined response structure validation common to the "Navigation Service" product line, such as assert res_dict['code'] == 0, assert res_dict['msg'] == 'ok', etc.

[0054] In other words, in this embodiment of the disclosure, the product line-level template only includes the "basic test framework" of test cases that can be shared by all functional modules under that product line, and does not involve specific functional modules or interfaces.

[0055] (2) Functional module-level template The functional module-level template corresponds to the sub-description information of the intermediate level of "functional module". Based on inheriting the product line-level template corresponding to the upper-level product line of the "functional module", it further solidifies the exclusive framework limiting elements of the functional module, and its applicability is narrower than that of the product line-level template.

[0056] Taking the "RoutePlanningService" function module under the "Navigation Service" product line in the vehicle-to-everything (V2X) server system as an example, in addition to inheriting the product line-level template corresponding to the "Navigation Service" product line, it can also include: Fixed structure: Further refine the organization of test code: file header comments → product line common dependencies + functional module specific dependencies → module-level decorators → module test classes that inherit from product line test classes → module-level setup_method → ​​module common helper methods → placeholder test methods; Code conventions: Further refine the naming rules specific to the "RoutePlanningService" functional module (e.g., test method names begin with test_module name), the naming style of functional module-level constants (e.g., uppercase letters with underscores), and the placement order of auxiliary methods within the functional module (e.g., placed after setup_method and before test methods). Dependency import: Added import of protocols specific to the "RoutePlanningService" feature module, for example, import route_planning_pb2; Initialization logic: Add data pre-setting steps specific to the "RoutePlanningService" function module to the setup_method, such as obtaining the starting coordinates; Request Construction: Pre-defined request construction methods common to the "RoutePlanningService" functional module, such as encapsulating the build_route_request() function for generating common parameters for route planning requests; Public assertion mode: Add assertion statements specific to the "RoutePlanningService" feature module, such as verifying whether the response contains the "route_id" field (assert 'route_id' in res_dict).

[0057] In other words, in this embodiment of the disclosure, the functional module-level template includes a "basic test framework" of test cases that can be shared by all interfaces under the functional module, but it has not yet been refined for specific interfaces.

[0058] (3) Interface-level template Interface-level templates correspond to the lowest level of sub-description information, namely "interface to be tested". Based on inheriting the functional module-level templates corresponding to the upper-level functional modules of the "interface to be tested", they further refine the framework limiting elements of a specific interface. They have the narrowest scope of applicability, but the highest degree of business relevance.

[0059] Taking the " / RoutePlanningService / GetRoute" interface in the "RoutePlanningService" function module under the "Navigation Service" product line in the vehicle-to-everything (V2X) server system as an example, in addition to inheriting the function module-level template corresponding to the "RoutePlanningService" function module, it can also include: Fixed structure: Further refine the organization of test code for the " / RoutePlanningService / GetRoute" interface: file header comments → complete dependency imports → interface-level decorators → interface test classes that inherit from functional module test classes → interface-level setup_method → ​​interface public helper methods → complete test method definitions (e.g., a complete structure including step division, request construction, response parsing, and assertion verification). Code conventions: Further refine the naming rules for the test methods of the " / RoutePlanningService / GetRoute" interface (e.g., test_interface_name_scenario_description), the comment format for step division (with allure.step("Step X: Action Description")), the writing order of assertion statements (first verify the response structure, then verify the business fields), and the format of error message messages (e.g., 'code is not equal to 0'). Default values ​​for request parameters: Preset typical request parameters for the " / RoutePlanningService / GetRoute" interface, such as req.start = "39.9042,116.4074" (address of Y1 in City X1), req.end = "31.2304,121.4737" (address of Y2 in City X2), and req.avoid_traffic = True; Response parsing path: Pre-defined access paths for response fields specific to the " / RoutePlanningService / GetRoute" interface, such as res_dict['route_list'][0]['route_id'] and res_dict['route_list'][0]['duration']. Verification point skeleton: The core verification logic framework of the " / RoutePlanningService / GetRoute" interface is pre-defined, such as assert route_id is not None and assert duration>0, which are left to be dynamically generated by the first major model based on the test requirement description information and business description information; Step structure: Predefined test step division, for example, with allure.step("Step 1: Construct route planning request") and with allure.step("Step 2: Call GetRoute interface").

[0060] The interface-level template already includes a relatively complete basic testing framework for the interface to be tested. The first major model only needs to be filled in with "fill-in-the-blank" or "fill-in-the-blank" combined with "expansion" information based on the test requirement description information and business description information.

[0061] Furthermore, it should be noted that in this embodiment of the present disclosure, for the aforementioned example, if the template query result indicates that there is no candidate test template corresponding to "product line" in the test template library, a fallback test template can also be obtained (e.g., obtained from the test template library) to determine the fallback test template as the target test template. In other words, in this embodiment of the present disclosure, when obtaining the target test template corresponding to the test requirement description information, if there are no candidate test templates corresponding to multiple sub-description information in the test template library, a fallback test template can also be obtained to determine the fallback test template as the target test template.

[0062] Among them, the fallback test template can be a product-level general test template used when there is no candidate test template in the test template library that corresponds to any level of sub-description information (product line, functional module, interface to be tested). It is aimed at the entire target software product and can provide a unified and most basic basic test framework for all product lines, functional modules or interfaces in the target software product that have not yet accumulated historical test cases.

[0063] In this embodiment, the fallback test template is consistent with the product line-level template, functional module-level template, and interface-level template in terms of functional positioning. That is, they all serve to provide complete test cases. The difference is that the fallback test template does not include any specific product line, functional module, or interface business knowledge. It only includes the framework-limiting elements that can be shared by all test cases under the target software product. Therefore, it requires the most fill-in or expansion content in the first major model and has the highest degree of freedom in generation.

[0064] Continuing with the example of a vehicle-to-everything (V2X) server system, its corresponding fallback test template could include: Fixed structure: The most basic test code organization form for the vehicle network server system is pre-defined: file header comments (reserved placeholders) → basic dependency imports → basic decorators → basic test class definitions → empty setup_methods → empty test method frameworks. This fixed structure provides clear code arrangement guidelines for the first model. However, all content related to specific product lines, functional modules or interfaces must be filled in by the first model based on test requirement description information and business description information. Code conventions: Adopt the naming rules common to vehicle networking server systems. For example, test classes are named TestDefault and test methods are named test_default. No naming rules related to specific product lines or functional modules are preset. Placeholders can be reserved for copyright, author, date, etc. in the header comments. Dependency imports: Only import the most basic libraries that can be used by all test cases under the vehicle networking server system, for example: import pytest import requests (HTTP request library) import json (JSON data parsing) import allure (test report framework) from typing import Dict, Any (type annotation) No protobuf definitions, custom tool libraries, or product-line specific dependency modules are imported. All interface-related dependency imports are dynamically generated by the first model based on test requirement description information and business description information. Decorator markers: Only include the most basic decorator markers common to the vehicle networking server system, such as: @pytest.mark.auto (marks an automated test case) @allure.story("To be filled") (This is left for the larger model to fill in the specific story description according to testing requirements) @allure.title("To be filled") (This will be used to fill in the specific title in the large model according to the testing requirements) @allure.description_html("To be populated") (This is for use case descriptions to be populated in the larger model) This excludes any tags associated with a specific product line or functional module (e.g., @pytest.mark.NaviService), which are dynamically generated by the first major model based on test requirement description information and business description information; Initialization logic: The setup_method contains no preset business logic, only an empty implementation or a placeholder comment (e.g., # TODO: Add initialization logic based on the interface to be tested); all interface-related initialization operations (e.g., obtaining request headers, establishing database connections, generating random identifiers, loading configuration files, etc.) are dynamically generated by the first model based on the test requirement description information and business description information; Common assertion mode: No specific assertion statements are pre-defined, only a placeholder for assertion statements is provided (e.g., # TODO: add assertions based on verification points). Unlike product line-level templates, functional module-level templates, and interface-level templates, the fallback test template does not contain any "assertion statements". That is, neither general status code verification nor functional module-specific field verification is pre-defined. All assertion statements are dynamically generated by the first major model based on test requirement description information and business description information. Request Construction: No request construction methods or default parameters are preset. The request construction logic related to the interface (e.g., constructing the request body, setting the request header, serializing data, processing authentication information, etc.) is dynamically generated by the first model based on the test requirement description information and business description information. Response parsing: No response parsing path is pre-defined. The logic for accessing response fields related to the interface (e.g., res_dict['data']['result']) is dynamically generated by the first model based on the test requirement description information and business description information.

[0065] In this embodiment of the present disclosure, the current sub-description information can be determined from multiple sub-description information in ascending order of hierarchy. A template query operation is then performed on the current sub-description information to obtain the template query result. If the template query result indicates that a candidate test template corresponding to the current sub-description information exists in the test template library, the candidate test template corresponding to the current sub-description information is determined as the target test template, and no further template query operations are performed on other sub-description information. In other words, in this embodiment of the present disclosure, test template queries can be performed in ascending order of hierarchy to prioritize the selection of the candidate test template with the finest granularity and highest business relevance as the target test template. This minimizes the workload of the first major model while ensuring the quality of test case generation, and avoids invalid queries on higher-level test templates, thus improving the efficiency and accuracy of test template acquisition.

[0066] In this embodiment of the disclosure, when obtaining the target test template corresponding to the test requirement description information, if there are no candidate test templates in the test template library corresponding to multiple sub-description information, a fallback test template can be obtained and determined as the target test template. In other words, this embodiment of the disclosure ensures that a usable target test template can be obtained in any testing scenario. Specifically, the introduction of the fallback test template in this embodiment of the disclosure enables a unified basic testing framework for new product lines, functional modules, or interfaces even when there are no candidate test templates in the test template library that match the current test requirements, ensuring the usability and robustness of the test case generation method.

[0067] Furthermore, in some optional implementations, step S104, namely, "using the first large model, based on the test requirement description information and business description information, to generate the first test case on the basis of the target test template," may include: Code change identification is performed on the target software product to obtain the change identification results; When the change identification result indicates that the target software product has a changed interface, and the changed interface is not the interface to be tested in the test requirement description information, the first model is used to generate the first test case based on the test requirement description information and business description information, on the basis of the target test template. Alternatively, if the change identification result indicates that the target software product has a changed interface, and the changed interface is the interface to be tested in the test requirement description information, the first model is used to generate the first test case based on the test requirement description information, business description information, and code information of the changed interface, on the basis of the target test template.

[0068] In this embodiment of the disclosure, when identifying code changes in a target software product to obtain change identification results, the code repository of the target software product can be scanned and detected to identify whether code changes exist. For example, based on a code version control system, the current code version of the target software product can be obtained and compared with the code version of the target software product during the previous stage of testing to obtain change identification results. The change identification results can be used to characterize whether the target software product has changed interfaces. If the change identification results indicate that the target software product has changed interfaces, the change identification results also include the change type of the changed interface. The change type can be "added" or "modified." Here, "added" can be understood as adding a new interface; "modified" can include modifying the interface code of an old interface, for example, adding new input parameters, new output parameters, or new functional logic to an old interface; or, for example, deleting some old input parameters, old output parameters, or some old functional logic from an old interface.

[0069] In this embodiment of the disclosure, after identifying code changes in the target software product to obtain the change identification results, different test case generation strategies can be adopted based on different change identification results to generate the first test case. Specifically: (1) The change identification results indicate that the target software product has a changed interface, and the changed interface is not the interface to be tested in the test requirement description information. In this scenario, it indicates that the interface under test, which is targeted by the current testing requirements, has not undergone code changes. Therefore, the business logic of the interface under test remains unaffected. The first main model can be directly used to generate the first test case based on the test requirement description and business description information, building upon the target test template. This generation process does not require introducing code information related to the changed interface, thus avoiding redundant information interfering with the generation results of the first test case.

[0070] Furthermore, it should be noted that in this embodiment of the disclosure, when the change identification result indicates that the target software product does not have a changed interface, the first major model will also be used to generate the first test case based on the test requirement description information and business description information, on the basis of the target test template.

[0071] (2) The change identification results indicate that the target software product has a changed interface, and the changed interface is the interface to be tested in the test requirement description information. In this situation, it indicates that the code of the interface to be tested, which is the target of the current testing requirements, has been changed. Therefore, in order to ensure that the generated first test case can accurately cover these changes, the first model can be used to generate the first test case based on the test requirement description information, business description information, and code information of the changed interface, on the basis of the target test template.

[0072] Through the above methods, this embodiment of the disclosure achieves intelligent perception and differentiated processing of code changes to the target software product. On the one hand, by accurately identifying whether there are code changes to the interface under test, when code changes occur, the changed code information can be automatically introduced as the basis for generating the first test case, ensuring that the generated first test case can effectively cover these change points and improve the targeting and defect detection capability of the first test case. On the other hand, when there are no code changes to the interface under test, redundant information is avoided, simplifying the generation process of the first test case and ensuring its generation efficiency. Therefore, this embodiment of the disclosure deeply integrates code change identification and test case generation, realizing dynamic adaptation of test cases to code changes, and further improving the intelligence level and practicality of test case generation.

[0073] Furthermore, in some optional implementations, the test case generation method provided in this disclosure may further include: If the change identification result indicates that the target software product has a changed interface, and the changed interface is not the interface to be tested in the test requirement description information, determine the change type of the changed interface; If the change type is "Add", retrieve the basic test template; Using the first model, based on the code information of the changed interface, generate the second test case on the basis of the basic test template.

[0074] The basic test template can be used to generate basic functional verification test cases for a changed interface when the change type is "new". It differs from product line-level templates, functional module-level templates, interface-level templates and fallback templates in its functional positioning: the basic test template focuses on the minimum verification goal of "interface availability" and aims to quickly generate test cases including basic connectivity verification for changed interfaces with a change type of "new" to ensure that the changed interface has at least basic responsiveness after deployment.

[0075] Continuing with the example of the vehicle-to-everything (V2X) server system, the change identification result indicates that the V2X server system has a changed interface " / NewService / GetStatus", and this changed interface " / NewService / GetStatus" is not the interface to be tested in the test requirement description information. Furthermore, the change type of the changed interface " / NewService / GetStatus" is "new". Therefore, a basic test template can be obtained, and using the first main model, based on the code information of the changed interface " / NewService / GetStatus", a second test case can be generated based on the basic test template. The basic test template may include: Fixed structure: Pre-defined general test code organization format: file header comments (reserved placeholders) → basic dependency imports → basic decorators → basic test class definitions → empty setup_method → ​​test method framework including basic request and status code verification.

[0076] Conventional code: Pre-defined general naming rules, for example, test classes are named Test{interface name} and test methods are named test_{interface name}_basic, without pre-setting any naming rules related to specific product lines or functional modules; placeholders can be reserved for copyright, author, date, etc. in the header comments.

[0077] Dependency import: Import only the minimal dependency libraries required to generate basic connectivity use cases, such as: import pytest Import requests (used for sending HTTP requests) import allure (for test reports) It does not import any protobuf definitions, custom tool libraries, or product line-specific dependency modules related to a specific product line; Decorator tags: Only include generic decorator tags, such as: @pytest.mark.auto (marks an automated test case) @pytest.mark.smoke (marks a smoke test case) @allure.title("Added basic connectivity test for the new interface") (Reserved title) Excludes any tags associated with a specific product line or feature module (e.g., @pytest.mark.NaviService); Initialization logic: The setup_method only contains general initialization operations, such as obtaining basic request headers (e.g., if there is a globally unified authentication method), or it is left empty; all initialization logic related to specific business logic is not pre-defined. Public assertion pattern: Pre-defined basic validation logic for interface responses, for example: assert response.status_code == 200 (to verify the HTTP status code) assert response is not None (verify that the response is not empty) assert 'code' in response.json() or 'error' not in response.text (validates the basic response structure; the specifics depend on the API protocol specification). No pre-defined field-level assertions related to specific business semantics (e.g., assert 'tag' in res_dict); Request construction: No default values ​​are preset for specific request parameters; the first model can be used to dynamically generate basic request construction code based on the code information of the changed interface " / NewService / GetStatus" (e.g., the parameter list in the interface definition). For example, an empty parameter request can be generated for a GET interface, and a default request body containing required fields can be generated for a POST interface. Response parsing: No specific response parsing path is predefined; the first model can be used to dynamically generate basic response parsing code based on the code information of the changed interface " / NewService / GetStatus" (e.g., return value type definition), for example, res = response.json().

[0078] Furthermore, it should be noted that in this embodiment of the disclosure, after generating a second test case based on the code information of the changed interface using the first major model and on the basis of the basic test template, the second test case can be merged into the first test case to obtain a new first test case, and subsequent processes can be executed based on the new first test case. For example, the process of "using the second major model to verify the first test case to obtain the verification result; if the verification result indicates that the first test case is usable, the first test case is determined as the target test case" is executed.

[0079] Through the above methods, in this embodiment of the disclosure, when the change identification result indicates that the target software product has a changed interface, and the changed interface is not the interface to be tested in the test requirement description information, the change type of the changed interface can be determined. If the change type is "new", a basic test template can be obtained. Then, using the first main model, based on the code information of the changed interface, a second test case can be generated based on the basic test template. In this way, basic functional assurance can be provided for the new interface before or in the early stages of its deployment, ensuring that the new interface can be called normally and return the expected status code. Later, with the gradual accumulation of business knowledge, more comprehensive business-level test cases can be generated based on the actual situation of the new interface, thereby achieving progressive test assurance from "basic availability verification" to "complete business coverage".

[0080] Furthermore, in some optional implementations, the test case generation method provided in this disclosure may further include: The first test case is validated using the second model to obtain the validation results; If the verification results indicate that the first test case is usable, then the first test case is identified as the target test case.

[0081] The second largest model can be another LLM different from the first largest model, or it can be a trained LLM.

[0082] In one example, "using the second largest model to validate the first test case to obtain the validation result" could include: Using the second model, verify whether the first test case covers all the verification points in the test requirement description information; Using the second model, verify whether the first test case contains erroneous logic that conflicts with the business description information; If the first test case covers all the verification points in the test requirement description information and there is no erroneous logic in the first test case that conflicts with the business description information, a verification result is obtained to characterize the usability of the first test case. Alternatively, if the first test case does not cover all the verification points in the test requirement description information or if the first test case contains erroneous logic that conflicts with the business description information, a verification result is obtained to characterize that the first test case is unusable.

[0083] The second major model determines whether the first test case contains erroneous logic that conflicts with the business description information by semantically comparing the business description information (e.g., the field types, value ranges, and mandatory constraints related to the interface under test as defined in the interface protocol document, and the business rules and state transition conditions related to the interface under test as described in the requirements document) with the request construction logic and assertion statements in the first test case. For example, in an e-commerce system, the business description information clearly states that "users must log in first and have at least one item in their shopping cart to successfully create an order." If the first test case directly calls the create order interface but does not include a login step or add an item to the shopping cart, the second major model determines that the first test case contains erroneous logic that conflicts with the business description information because it violates the business rules. Conversely, if the first test case includes the complete steps of logging in to obtain login credentials, adding an item to the shopping cart, and then calling the create order interface, then the first test case is determined to not contain erroneous logic that conflicts with the business description information. For example, if the business description specifies that the order amount must be greater than 0, but the order amount constructed in the first test case is negative, then it can also be determined that the first test case contains erroneous logic that conflicts with the business description.

[0084] In this embodiment, after using the second model to verify whether the first test case covers all verification points in the test requirement description information, and to verify whether the first test case has any erroneous logic that conflicts with the business description information, a verification result indicating the usability of the first test case can be obtained if the first test case covers all verification points in the test requirement description information and does not have any erroneous logic that conflicts with the business description information; or, if the first test case does not cover all verification points in the test requirement description information or has erroneous logic that conflicts with the business description information, a verification result indicating the unusability of the first test case can be obtained. In other words, this embodiment, by introducing the second model for independent verification, achieves a collaborative mechanism for test case generation and verification, effectively improving the accuracy and reliability of the generated test cases and avoiding the impact of omissions or logical errors that may exist in a single model on the quality of test case generation.

[0085] Furthermore, in some optional implementations, the test case generation method provided in this disclosure may further include: If the verification results indicate that the first test case is unavailable, obtain the verification feedback information from the output of the second largest model; Using the first model and based on the verification feedback information, the first test case is modified to obtain the third test case; In response to the availability confirmation operation for the third test case, the third test case is identified as the target test case.

[0086] The verification feedback information may include a list of missing verification points, the specific locations of logical conflicts and a description of the conflicts, as well as suggestions for correction.

[0087] In this embodiment, after obtaining the verification feedback information output by the second large model, the first test case and the verification feedback information can be input together into the first large model. Using the first large model and the verification feedback information, the first test case can be modified to obtain the third test case. Subsequently, the test case generation system can display the third test case to the tester and wait for the tester to perform a usability confirmation operation on the third test case. Then, in response to the usability confirmation operation on the third test case, the third test case is identified as the target test case. The usability confirmation operation can be a "click to confirm" operation triggered by the tester, or an "edit + click to confirm" operation triggered by the tester.

[0088] Through the above methods, a complete closed loop of "generation-verification-correction-confirmation" is formed in this embodiment. When the first test case fails verification, verification feedback information can be automatically obtained, and the first large model can be driven to make targeted corrections to the first test case, significantly reducing the workload of manual intervention. At the same time, by introducing a usability confirmation operation triggered by the tester, the quality controllability of the test cases is ensured, providing a more reliable quality assurance for the intelligent generation of test cases.

[0089] Furthermore, in some optional implementations, the test case generation method provided in this disclosure may further include: Using the target test cases, execute the test process for the interface to be tested as described in the test requirements information.

[0090] Through the above methods, this embodiment of the disclosure can achieve a seamless connection from test case generation to test case execution, ensuring that the generated test cases can be quickly deployed to actual test scenarios, forming an efficient test closed loop of "generation-execution", further shortening the test cycle and improving the quality assurance efficiency for the target software product.

[0091] Furthermore, in some optional implementations, the test case generation method provided in this disclosure may further include a first template control process or a second template control process.

[0092] The first template control process may include: Based on the target test cases, generate new test templates that correspond to the interfaces to be tested in the test requirement description information; Store new test templates that correspond to the interface under test in the test template library.

[0093] In this embodiment of the disclosure, after obtaining the target test case, the target test case can be processed. That is, multiple framework-defining elements of the target test case (e.g., including at least one of fixed structure, convention code, dependency import, decorator markup, initialization logic, and public assertion pattern) can be extracted to form a new test template. The correspondence between the new test template and the interface to be tested is established, and the new test template with the correspondence with the interface to be tested is stored in the test template library.

[0094] It is understood that in this embodiment of the disclosure, the new test template generated by the first template management process belongs to the interface-level template. Based on this, in this embodiment of the disclosure, a corresponding template upward extraction mechanism can also be introduced for the first template management process. Specifically, when the number of interface-level templates stored under the same functional module is greater than or equal to a first quantity threshold, a commonality analysis can be performed on these interface-level templates periodically. When common framework limiting elements are detected among these interface-level templates (e.g., they all import the same functional module-specific library, all include the same initialization logic, all use the same decorator markup, etc.), a functional module-level template is generated based on these common framework limiting elements, and the correspondence between the functional module-level template and its corresponding functional module is established, and then it is stored in the test template library. Similarly, when the number of functional module-level templates accumulated under the same product line is greater than or equal to a second quantity threshold, these functional module-level templates can also be extracted upward to generate a product line-level template, and the correspondence between the product line-level template and its corresponding product line is established, and then it is stored in the test template library. The first quantity threshold and the second quantity threshold can be set according to application requirements, and this embodiment of the disclosure does not limit them.

[0095] Through the above methods, in this embodiment of the disclosure, new test templates corresponding to the interface under test can be generated based on the target test cases, and these new test templates can be stored in the test template library to expand the test template library. Furthermore, in this embodiment of the disclosure, a template upward refinement mechanism for the first template management process can be introduced, enabling the first template management process not only to accumulate interface-level templates, but also to automatically generate higher-level functional module-level templates and product line-level templates based on the accumulation of interface-level templates, thereby enriching the hierarchical structure of the template library. When encountering new interfaces subsequently, even if there is no corresponding interface-level template, high-quality test cases can be generated by matching the corresponding functional module-level template or product line-level template, thereby effectively improving the self-growth capability of the template library.

[0096] The second template management process may include: The sub-description information used when obtaining the target test template is determined as the target sub-description information; Based on the target test cases, generate new test templates that correspond to the target sub-description information; New test templates that correspond to the target sub-description information are stored in the test template library.

[0097] The target sub-description information can be one of the following: product line, functional module, and interface to be tested.

[0098] In this embodiment of the disclosure, after obtaining the target test case, the target test case can be processed. That is, multiple framework limiting elements of the target test case (e.g., including at least one of fixed structure, convention code, dependency import, decorator markup, initialization logic and public assertion pattern) can be extracted to form a new test template, and a correspondence between the new test template and the target sub-description information can be established. Then, the new test template with the correspondence with the target sub-description information is stored in the test template library.

[0099] In this embodiment of the disclosure, a corresponding template deepening mechanism can be introduced for the second template control process. Specifically, when the number of target test cases accumulated under the same target sub-description information (e.g., product line) is greater than or equal to a third quantity threshold, cluster analysis can be performed on these target test cases. If it is detected that at least some of these target test cases have common framework limiting elements (e.g., all importing libraries specific to the same functional module, all including the same initialization logic, all using the same decorator tags, etc.), a test template corresponding to the next-level sub-description information (e.g., functional module) of the target sub-description information is generated based on these common framework limiting elements, and the correspondence between the test template and its corresponding sub-description information is established, and then stored in the test template library. The third quantity threshold and the second quantity threshold can be set according to application requirements, and this embodiment of the disclosure does not limit them.

[0100] Through the above methods, in this embodiment of the disclosure, the sub-description information used when obtaining the target test template can be determined as the target sub-description information. Based on the target test cases, a new test template corresponding to the target sub-description information is generated. The new test template corresponding to the target sub-description information is then stored in the test template library to expand the test template library. Moreover, in this embodiment of the disclosure, a template downward deepening mechanism can be introduced to enable the second template management process to achieve "top-down" refinement of the test template library. In this way, even if there are only high-level templates initially, as test cases accumulate, common elements can be automatically identified to generate more granular lower-level templates, thereby continuously enriching the hierarchical structure of the test template library and providing more accurate template selection for the generation of subsequent test cases, so as to further improve the generation quality and efficiency of test cases.

[0101] Furthermore, in this embodiment of the disclosure, a third template management process that integrates the first template management process and the second template management process can be used to expand the test template library.

[0102] The third template management process may include: Based on the target test cases, generate a first new test template that corresponds to the interface to be tested in the test requirement description information; Store the first new test template that corresponds to the interface under test in the test template library; In addition, the sub-description information used when obtaining the target test template is determined as the target sub-description information; Based on the target test cases, a second new test template is generated that corresponds to the target sub-description information; A second new test template that corresponds to the target sub-description information is stored in the test template library.

[0103] Simultaneously, a template upward refinement mechanism and a template downward deepening mechanism can be introduced to process the test templates stored in the test template library (including the first and second new test templates) to expand the test template library. During this process, it is also possible to periodically check whether duplicate test templates exist in the test template library to obtain deduplication detection results. If the deduplication detection indicates the presence of duplicate test templates in the library, then duplicate test templates are deduplicated. The deduplication process can be based on the quality score of the test templates (e.g., the pass rate of generated test cases, maintenance frequency, etc.) to determine whether to retain or merge them, ensuring the conciseness and high quality of the test template library.

[0104] In this embodiment of the present disclosure, the test template library can be collaboratively expanded by utilizing a third template management process that integrates the first template management process and the second template management process, thereby further improving the self-growth capability of the template library.

[0105] The following, combined with Figure 2 The complete process of a test case generation method provided in this disclosure embodiment will be described.

[0106] Step S201: Obtain the test requirement description information for the target software product.

[0107] The test requirement description letter may include multiple sub-description information divided according to hierarchy. For example, it may include product lines, functional modules, interfaces under test, input and output parameters, and verification points in a hierarchical order from high to low.

[0108] Step S202: Obtain the business description information of the target software product, and obtain the target test template corresponding to the test requirement description information.

[0109] The business description information may include business information and interface information.

[0110] Step S203: Identify code changes in the target software product to obtain the change identification results.

[0111] In this embodiment of the disclosure, if the change identification result indicates that the target software product does not have a changed interface, step S204 can be executed; if the change identification result indicates that the target software product has a changed interface and the changed interface is not the interface to be tested in the test requirement description information, steps S204 and S205 can be executed; if the change identification result indicates that the target software product has a changed interface and the changed interface is the interface to be tested in the test requirement description information, step S207 can be executed.

[0112] Step S204: Using the first major model, based on the test requirement description information and business description information, generate the first test case on the basis of the target test template.

[0113] Step S205: Determine the change type of the changed interface, and if the change type is "new", obtain the basic test template. Then, using the first main model, based on the code information of the changed interface, generate the second test case on the basis of the basic test template.

[0114] Step S206: Merge the second test case into the first test case to obtain a new first test case.

[0115] Step S207: Using the first major model, based on the test requirement description information, business description information, and code information of the changed interface, generate the first test case on the basis of the target test template.

[0116] Step S208: Validate the first test case using the second large model to obtain the validation result. If the validation result indicates that the first test case is usable, then determine the first test case as the target test case.

[0117] Furthermore, it should be noted that the specific functions and examples of the above steps in this embodiment can be found in the relevant descriptions of the corresponding steps in the aforementioned test case generation embodiment, and will not be repeated here.

[0118] Further, please refer to Figure 3 This is a schematic diagram illustrating an application scenario of a test case generation method provided in this embodiment of the disclosure.

[0119] The test case generation method provided in this disclosure can be applied to electronic devices, specifically to a test case generation system installed on an electronic device. The electronic device can be a service device or a terminal device. Here, the service device can be a server, workbench, mainframe computer, or other similar computing device; the terminal device can be a workbench, mainframe computer, conventional computer, or other similar computing device.

[0120] In this embodiment of the disclosure, the electronic device is used for: Obtain test requirement descriptions for the target software product; Obtain the business description information of the target software product; Obtain the target test template corresponding to the test requirement description information; Using the first major model, based on the test requirement description information and business description information, the first test case is generated on the basis of the target test template.

[0121] It should be noted that, in the embodiments disclosed herein, Figure 3 The application scenario diagrams shown are for illustrative purposes only and are not restrictive. Those skilled in the art can use them as a basis for their own interpretation. Figure 3 The examples may be modified in various obvious ways and / or substitutions, and the resulting technical solutions still fall within the scope of the disclosure of the embodiments of this disclosure.

[0122] To better implement the test case generation method, this disclosure also provides a test case generation apparatus, which can be integrated into an electronic device, specifically into a test case generation system installed on the electronic device. The electronic device can be a service device or a terminal device. Here, the service device can be a server, workbench, mainframe computer, or other similar computing device; the terminal device can be a workbench, mainframe computer, conventional computer, or other similar computing device. The following will be combined with… Figure 4 The schematic block diagram shown illustrates a test case generation device 400 provided in the disclosed embodiment.

[0123] Test case generation device 400, including: The first information acquisition unit 401 is used to acquire test requirement description information for the target software product. The second information acquisition unit 402 is used to acquire business description information of the target software product; Template acquisition unit 403 is used to acquire the target test template corresponding to the test requirement description information; The first test case generation unit 404 is used to generate the first test cases based on the test requirement description information and business description information, using the first large model and the target test template.

[0124] In some optional implementations, the test requirement description information includes multiple sub-description information divided according to hierarchy; the template acquisition unit 403 is used for: Determine the current sub-description information from multiple sub-description information in ascending order of hierarchy; Perform a template query operation on the current sub-description information to obtain the template query results; If a candidate test template corresponding to the current sub-description information exists in the template query result representation test template library, the candidate test template corresponding to the current sub-description information will be determined as the target test template, and template query operations for other sub-description information will no longer be performed.

[0125] In some optional implementations, the template acquisition unit 403 is used for: If no candidate test templates corresponding to multiple sub-description information exist in the test template library, a fallback test template is obtained and determined as the target test template.

[0126] In some optional implementations, the first test case generation unit 404 is used for: Code change identification is performed on the target software product to obtain the change identification results; When the change identification result indicates that the target software product has a changed interface, and the changed interface is not the interface to be tested in the test requirement description information, the first model is used to generate the first test case based on the test requirement description information and business description information, on the basis of the target test template. Alternatively, if the change identification result indicates that the target software product has a changed interface, and the changed interface is the interface to be tested in the test requirement description information, the first model is used to generate the first test case based on the test requirement description information, business description information, and code information of the changed interface, on the basis of the target test template.

[0127] In some optional implementations, the test case generation apparatus 400 further includes a second test case generation unit, used for: If the change identification result indicates that the target software product has a changed interface, and the changed interface is not the interface to be tested in the test requirement description information, determine the change type of the changed interface; If the change type is "new", retrieve the basic test template; Using the first model, based on the code information of the changed interface, generate the second test case on the basis of the basic test template.

[0128] In some optional implementations, the test case generation apparatus 400 further includes a test case verification unit, used for: The first test case is validated using the second model to obtain the validation results; If the verification results indicate that the first test case is usable, then the first test case is identified as the target test case.

[0129] In some optional implementations, the test case verification unit is used for: Using the second model, verify whether the first test case covers all the verification points in the test requirement description information; Using the second model, verify whether the first test case contains erroneous logic that conflicts with the business description information; If the first test case covers all the verification points in the test requirement description information and there is no erroneous logic in the first test case that conflicts with the business description information, a verification result is obtained to characterize the usability of the first test case. Alternatively, if the first test case does not cover all the verification points in the test requirement description information or if the first test case contains erroneous logic that conflicts with the business description information, a verification result is obtained to characterize that the first test case is unusable.

[0130] In some optional implementations, the test case generation apparatus 400 further includes a test case modification unit, used for: If the verification results indicate that the first test case is unavailable, obtain the verification feedback information from the output of the second largest model; Using the first model and based on the verification feedback information, the first test case is modified to obtain the third test case; In response to the availability confirmation operation for the third test case, the third test case is identified as the target test case.

[0131] In some optional implementations, the test case generation apparatus 400 further includes a test execution unit for: Using the target test cases, execute the test process for the interface to be tested as described in the test requirements information.

[0132] In some alternative implementations, the test case generation apparatus 400 further includes a first template control unit, used for: Based on the target test cases, generate new test templates that correspond to the interfaces to be tested in the test requirement description information; Store new test templates that correspond to the interface under test in the test template library.

[0133] In some alternative implementations, the test case generation apparatus 400 further includes a second template control unit, used for: The sub-description information used when obtaining the target test template is determined as the target sub-description information; Based on the target test cases, generate new test templates that correspond to the target sub-description information; New test templates that correspond to the target sub-description information are stored in the test template library.

[0134] In some optional implementations, the first information acquisition unit 401 is used for one of the following: In response to pipeline trigger events for the target software product, obtain test requirement description information; In response to the call to the test case generation interface, obtain test requirement description information; In response to a test case generation request sent by the digital employee platform, obtain test requirement description information.

[0135] In this embodiment of the disclosure, the specific functions and examples of each unit in the test case generation device 400 can be found in the relevant descriptions of the corresponding steps in the aforementioned test case generation method embodiment, and will not be repeated here.

[0136] The collection, storage, use, processing, transmission, provision, and disclosure of any type of information, such as user personal information, in this technical solution comply with relevant laws and regulations and do not violate public order and good morals.

[0137] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0138] Figure 5 A schematic structural block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. Electronic device 500 is intended to represent various forms of digital computers, such as in-vehicle computing devices, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 500 may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0139] like Figure 5 As shown, the electronic device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 502 or a computer program loaded from a storage unit 508 into a random access memory (RAM) 503. The RAM 503 can also store various programs and data required for the operation of the electronic device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0140] Multiple components in electronic device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of renderers, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows electronic device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0141] The computing unit 501 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated AI computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the test case generation method. For example, in some embodiments, the test case generation method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the test case generation method described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured as a test case generation method by any other suitable means (e.g., by means of firmware).

[0142] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transferring data and instructions to the storage system, the at least one input device, and the at least one output device.

[0143] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data optimization device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0144] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM) or flash memory, optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0145] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a rendering device (e.g., a cathode ray tube (CRT) renderer or a liquid crystal display (LCD)) for rendering information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices are also used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0146] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0147] A computer system can include client and server components. Clients and servers are generally located far apart and typically interact via a communication network. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, a server in a distributed system, or a server incorporating blockchain technology.

[0148] This disclosure also provides a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute a test case generation method.

[0149] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements a test case generation method.

[0150] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure is achieved, and this is not limited herein. Furthermore, in this disclosure, relational terms such as "first," "second," and "third" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Additionally, "multiple" in this disclosure can be understood as at least two.

[0151] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A test case generation method, comprising: Obtain test requirement descriptions for the target software product; Obtain the business description information of the target software product; Obtain the target test template corresponding to the test requirement description information; Using the first model, based on the test requirement description information and the business description information, the first test case is generated on the basis of the target test template.

2. The method according to claim 1, wherein, The test requirement description information includes multiple sub-description information divided according to hierarchy; obtaining the target test template corresponding to the test requirement description information includes: The current sub-description information is determined from the plurality of sub-description information in ascending order of hierarchy. Perform a template query operation on the current sub-description information to obtain the template query results; If a candidate test template corresponding to the current sub-description information exists in the template query result characterization test template library, the candidate test template corresponding to the current sub-description information is determined as the target test template, and template query operations for other sub-description information are no longer performed.

3. The method according to claim 2, wherein, The step of obtaining the target test template corresponding to the test requirement description information further includes: If no candidate test template corresponding to the plurality of sub-description information exists in the test template library, a fallback test template is obtained to determine the fallback test template as the target test template.

4. The method according to any one of claims 1 to 3, wherein, The first model, based on the test requirement description information and the business description information, generates the first test case on the basis of the target test template, including: Code change identification is performed on the target software product to obtain the change identification results; If the change identification result indicates that the target software product has a changed interface and the changed interface is not the interface to be tested in the test requirement description information, the first test case is generated based on the test requirement description information and the business description information using the first large model and the target test template. Alternatively, if the change identification result indicates that the target software product has a changed interface, and the changed interface is the interface to be tested in the test requirement description information, the first test case is generated based on the test requirement description information, the business description information, and the code information of the changed interface, using the first large model and the target test template.

5. The method according to claim 4, further comprising: If the change identification result indicates that the target software product has a changed interface, and the changed interface is not the interface to be tested in the test requirement description information, then the change type of the changed interface is determined. If the change type is "new", obtain the basic test template; Using the first large model and based on the code information of the changed interface, a second test case is generated on the basis of the basic test template.

6. The method according to any one of claims 1 to 3, further comprising: The first test case is validated using the second model to obtain the validation results; If the verification results indicate that the first test case is available, the first test case is identified as the target test case.

7. The method according to claim 6, wherein, The process of using the second major model to verify the first test case and obtain verification results includes: Using the second major model, verify whether the first test case covers all the verification points in the test requirement description information; Using the second major model, verify whether the first test case contains erroneous logic that conflicts with the business description information; If the first test case covers all the verification points in the test requirement description information and the first test case does not have any erroneous logic that conflicts with the business description information, a verification result is obtained to characterize the usability of the first test case. Alternatively, if the first test case does not cover all the verification points in the test requirement description information or if the first test case contains erroneous logic that conflicts with the business description information, a verification result is obtained to characterize that the first test case is unusable.

8. The method according to claim 6, further comprising: If the verification result indicates that the first test case is unavailable, obtain the verification feedback information output by the second large model; Using the first large model and based on the verification feedback information, the first test case is modified to obtain the third test case; In response to the availability confirmation operation for the third test case, the third test case is identified as the target test case.

9. The method according to claim 6, further comprising: Using the target test cases, execute the test process for the interface to be tested in the test requirement description information.

10. The method of claim 6, further comprising: Based on the target test cases, generate new test templates that correspond to the interfaces to be tested in the test requirement description information; The new test template that corresponds to the interface to be tested is stored in the test template library.

11. The method of claim 6, further comprising: The sub-description information used when obtaining the target test template is determined as the target sub-description information; Based on the target test cases, generate a new test template that corresponds to the target sub-description information; The new test templates that correspond to the target sub-description information are stored in the test template library.

12. The method according to claim 1, wherein, The acquisition of test requirement description information for the target software product includes one of the following: In response to a trigger event in the pipeline for the target software product, the test requirement description information is obtained; In response to the call to the test case generation interface, obtain the test requirement description information; In response to a test case generation request sent by the digital employee platform, the test requirement description information is obtained.

13. A test case generation apparatus, comprising: The first information acquisition unit is used to acquire test requirement description information for the target software product. The second information acquisition unit is used to acquire the business description information of the target software product; The template acquisition unit is used to acquire the target test template corresponding to the test requirement description information; The first test case generation unit is used to generate first test cases based on the test requirement description information and the business description information, using the first large model and the target test template.

14. An electronic device comprising: At least one processor; A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method according to any one of claims 1 to 12.

15. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 12.

16. A computer program product comprising a computer program; wherein, When the computer program is executed by a processor, it can implement the method of any one of claims 1 to 12.

Images