A method for generating test code, an electronic device, and a storage medium

Abstract

The present disclosure relates to the technical field of computers, and particularly relates to a test code generation method, an electronic device and a storage medium, the method comprising: obtaining target natural language description information, sending a target scene name and a product identifier to a second device; receiving a target dependency graph matched with the target scene name and the product identifier found in a graph database by the second device, and determining interface information of each target interface in a plurality of target interfaces required by a target business scene, a calling sequence between the plurality of target interfaces and parameter transmission information based on the target dependency graph; and generating test code corresponding to the target business scene according to the calling sequence, the parameter transmission information, the interface information and a preset code template of each target interface. The present application can solve the problems that interface test code generation cannot automatically identify interface dependencies, cannot support complex dependency scenarios, and parameter transmission and dependency relationships have poor reusability.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method for generating test code, an electronic device, and a storage medium. Background Technology

[0002] In various business scenarios across different business products, each scenario typically requires the collaborative completion of multiple interfaces. For example, in a business scenario (e.g., placing an order to buy goods) within a business product (e.g., a shopping platform), multiple interfaces (e.g., user information query interface, product inventory verification interface, shopping cart query interface, order creation interface, payment interface, and logistics information synchronization interface) need to be called collaboratively to achieve data interaction, business flow, and functional collaboration. As a key carrier for inter-system communication and business linkage, the correctness, stability, and reliability of interfaces directly determine the overall system's functional availability, smooth business processes, and service quality.

[0003] Traditional testing processes typically rely on manual analysis of API dependencies, meticulously outlining call order and parameter passing logic based on API documentation, and manually writing and maintaining test code. Alternatively, API dependencies can be defined through configuration files and parameter passing implemented using environment variables, but these dependencies require hard-coding and manual maintenance. Some tools generate API code based on API documentation, but this still necessitates manual implementation of dependencies and parameter passing. However, manual analysis is inefficient, error-prone, costly to maintain, and difficult to reuse. Configuration-based solutions rely on manual definition, cannot automatically discover dependencies, and struggle with complex parameter mappings and dynamic dependencies. Code generation tools can only generate basic API code and lack dependency handling capabilities. All these methods fail to automatically identify API dependencies, struggle to support complex dependency scenarios, and exhibit poor reusability in parameter passing and dependency relationships. Summary of the Invention

[0004] To address the aforementioned technical issues, this disclosure provides a method for generating test code, an electronic device, and a storage medium to resolve problems such as the inability to automatically identify interface dependencies, difficulty in supporting complex dependency scenarios, and poor reusability of parameter passing and dependency relationships during interface test code generation.

[0005] In a first aspect, this disclosure provides a method for generating test code, applied to a first device. The method includes: acquiring target natural language description information, which indicates the target scenario name corresponding to the target business scenario to be tested and the product identifier of the target business product to which the target business scenario belongs; sending the target scenario name and product identifier to a second device; receiving a target dependency graph matching the target scenario name and product identifier found in a graph database from the second device, and determining, based on the target dependency graph, the interface information of each target interface among multiple target interfaces required by the target business scenario, the calling order among multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with dependencies; and generating test code corresponding to the target business scenario according to the calling order, parameter passing information, interface information, and a preset code template for each target interface.

[0006] In some optional implementations, the target dependency graph stores the interface attributes of each interface node among multiple interface nodes, and each interface node corresponds to a target interface. Based on the target dependency graph, the interface information of each target interface among multiple target interfaces required by the target business scenario, the calling order among multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with dependencies are determined, including: based on the target dependency graph, using a topology sorting algorithm to determine the calling order among multiple target interfaces, and reading the interface information and parameter passing information of each target interface from the interface attributes of each target interface.

[0007] In some optional implementations, test code corresponding to the target business scenario is generated based on the call order, parameter passing information, interface information, and a preset code template for each target interface. This includes: generating structured execution chain information for each target interface based on the call order, parameter passing information, and interface information. Each execution chain information includes the step number, interface information, and dependency information for each target interface. The dependency information indicates the dependency direction and parameter passing information of the dependent interfaces that have a dependency relationship with each target interface. The parameter passing information for each dependent interface includes the interface name, interface identifier, parameter mapping identifier, and at least one passing parameter associated with the parameter mapping identifier. The parameter mapping identifier indicates whether a parameter mapping exists for each dependent interface. Test code is then generated based on the execution chain information and the preset code template for each target interface.

[0008] In some optional implementations, structured execution chain information corresponding to each target interface is generated based on the call order, parameter passing information, and interface information. This includes: determining the step number of each target interface according to the call order; determining at least one dependent interface that has a dependency relationship with each target interface and the dependency information of each dependent interface according to the call order and parameter passing information, wherein each dependent interface is an upstream dependent interface or a downstream dependent interface; and generating structured execution chain information corresponding to each target interface based on the step number, dependency information, and interface information.

[0009] In some optional implementations, test code is generated based on the execution chain information of each target interface and a preset code template, including: generating structured upstream dependency description text and structured downstream dependency description text corresponding to each target interface based on the execution chain information of each target interface; inputting the interface information, upstream dependency description text and downstream dependency description text of each target interface into the preset code template in the order of invocation, and outputting the code component file corresponding to each target interface to obtain the test code.

[0010] Secondly, this disclosure provides a method for generating test code, applied to a second device. The method includes: receiving a target scenario name corresponding to a target business scenario to be tested, and a product identifier of a target business product to which the target business scenario belongs, sent by a first device; searching a graph database for a target dependency graph that matches the target scenario name and product identifier, wherein the target dependency graph is used to indicate the interface information of each target interface among multiple target interfaces required by the target business scenario, the calling order among multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with dependencies; and sending the target dependency graph to the first device, so that the first device generates test code corresponding to the target business scenario based on the calling order, parameter passing information, interface information, and a preset code template for each target interface.

[0011] In some optional implementations, before searching for a target dependency graph matching the target scenario name and product identifier in the graph database, the method further includes: acquiring multiple sample natural language descriptions; inputting each sample natural language description into a large language model, and outputting the business scenario corresponding to each sample natural language description, the business product corresponding to each business scenario, the interface call order of multiple interfaces required by each business scenario, and the parameter passing information between two interfaces with dependencies; establishing a mapping relationship between each business product, each business scenario, and each interface; acquiring the interface document corresponding to each business product, with each interface document recording the interface information of each interface; and establishing a dependency graph belonging to each business scenario of each business product based on the mapping relationship, interface call order, parameter passing information, and interface information, thereby obtaining a graph database corresponding to multiple business products.

[0012] In some optional implementations, multiple business products include a first business product, a first business scenario belongs to the first business product, and the first business scenario needs to call multiple preset interfaces. Based on mapping relationships, interface call order, parameter passing information, and interface information, a dependency graph belonging to each business scenario of each business product is established, including: if at least one historical dependency graph exists, and at least one historical dependency graph does not contain a first business product identifier corresponding to the first business product, a first product node corresponding to the first business product is created, and product attributes of the first product node are set. Product attributes include the business product identifier and business product name of the product node. Based on the first business product identifier and the scenario name of the first business scenario, a first scenario identifier for the first business scenario is generated, and a first scenario node corresponding to the first business scenario is created, and the first scenario node is set. The process includes: establishing scenario attributes, including the scenario name and scenario identifier of the first business scenario; establishing a first mapping relationship between the first scenario node and the first product node; generating an interface identifier for each preset interface based on the first business product identifier and the interface information of each preset interface, creating a preset interface node corresponding to each preset interface, and setting the interface attributes of each preset interface node, including the interface identifier, step number, and step name of each preset interface; establishing a second mapping relationship between each preset interface node and the first scenario node; establishing interface dependency relationships between multiple preset interfaces based on the first interface call order, and adding first parameter transmission information to the interface attributes; and establishing a first dependency graph based on the first product node, the first scenario node, multiple preset interface nodes, the first mapping relationship, the second mapping relationship, and the interface dependency relationship.

[0013] Thirdly, the present invention provides a test code generation apparatus, comprising a first transceiver module for acquiring target natural language description information, wherein the target natural language description information indicates the target scenario name corresponding to the target business scenario to be tested and the product identifier of the target business product to which the target business scenario belongs; sending the target scenario name and product identifier to a second device; receiving a target dependency graph matching the target scenario name and product identifier found in a graph database by the second device, and determining, based on the target dependency graph, the interface information of each target interface among the multiple target interfaces required by the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with dependencies; and a generation module for generating test code corresponding to the target business scenario according to the calling order, parameter passing information, interface information, and a preset code template for each target interface.

[0014] Fourthly, the present invention provides a test code generation apparatus, comprising a second transceiver module for receiving, from a first device, the target scenario name corresponding to the target business scenario to be tested, and the product identifier of the target business product to which the target business scenario belongs. A processing module is used to search a graph database for a target dependency graph matching the target scenario name and product identifier. The target dependency graph indicates the interface information of each of the multiple target interfaces required by the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information for parameter passing between two dependent target interfaces. The second transceiver module is also used to send the target dependency graph to the first device, so that the first device generates test code corresponding to the target business scenario based on the calling order, parameter passing information, interface information, and a preset code template for each target interface.

[0015] Fifthly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the test code generation method of the first aspect or any corresponding embodiment described above.

[0016] In a sixth aspect, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the method for generating test code of the first aspect or any corresponding embodiment thereof.

[0017] In a seventh aspect, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute a method for generating test code according to the first aspect or any corresponding embodiment thereof.

[0018] The technical solution provided in this disclosure has the following advantages compared with the prior art: The test code generation method provided in this embodiment can match the target dependency graph from a graph database by obtaining the target scenario name and product identifier. This ensures that the obtained interface information, call order, and parameter passing information match the target business scenario, eliminating the need for manual dependency analysis. This solves the problems of time-consuming and error-prone manual interface analysis in traditional methods, significantly improving the overall efficiency and effectiveness of test code generation. Furthermore, based on the target dependency graph stored in the graph database, it can efficiently handle complex interface dependency scenarios with multiple levels and branches. The dependencies stored in the graph database can be reused by multiple business scenarios, adapting to the test code generation needs of multiple business scenarios and products, overcoming the shortcomings of traditional methods in reusing dependencies. When the interface call logic of the target business scenario changes, only the dependency graph in the graph database needs to be updated to quickly regenerate test code adapted to the new logic, improving the timeliness of business iteration. Attached Figure Description

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

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

[0021] Figure 1 This is a topology diagram of a test code generation system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a method for generating test code according to an embodiment of this application; Figure 3 This is a flowchart illustrating another method for generating test code according to an embodiment of this application; Figure 4 This is a flowchart illustrating another method for generating test code according to an embodiment of this application; Figure 5 This is a structural block diagram of a test code generation device provided according to an embodiment of this application; Figure 6 This is a structural block diagram of another test code generation apparatus provided according to an embodiment of this application; Figure 7 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0022] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0023] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0024] This application embodiment is applied to a scenario where interface testing is performed on a business product in a specific business context, and test code needs to be generated.

[0025] In related technologies, traditional API testing processes typically rely on manual analysis of API dependencies, outlining the call order and parameter passing logic based on API documentation, manually writing test code, and maintaining parameter passing. Alternatively, API dependencies are defined through configuration files, and parameter passing is implemented using environment variables, but dependencies need to be hard-coded and manually maintained. Some tools generate API code based on API documentation, but dependencies and parameter passing still require manual implementation. However, manual analysis is inefficient, error-prone, costly to maintain, and difficult to reuse; configuration-based solutions rely on manual definition, cannot automatically discover dependencies, and struggle to handle complex parameter mappings and dynamic dependencies; code generation tools can only generate basic API code and lack dependency handling capabilities. All these methods fail to automatically identify API dependencies, struggle to support complex dependency scenarios, and have poor reusability in parameter passing and dependency relationships.

[0026] To address the aforementioned technical issues, this application proposes a method for generating test code. This method pre-generates a graph database containing the dependencies and parameter passing relationships of each interface to be tested. When multiple interfaces required for a target business scenario need to be tested, the method retrieves a matching target dependency graph from the graph database based on the target scenario name and the product identifier of the business product to which it belongs, thereby generating test code. This approach can automatically identify interface dependencies, accurately identify parameter passing and dependency relationships between interfaces even in complex dependency scenarios, and offers strong reusability and high identification efficiency, thus improving the accuracy and efficiency of test code generation.

[0027] The following is based on Figure 1 Taking the test code generation system shown as an example, the method provided in the embodiments of this application will be described.

[0028] like Figure 1 As shown, Figure 1 This is a topology diagram of a test code generation system provided in an embodiment of this application. Figure 1 In the test code generation system 100, there are a first device 101, a second device 102, and a client 103.

[0029] The first device 101 can be any device with communication and computing capabilities. For example, the first device 101 can be a server or a cloud server. The first device is used to generate test code corresponding to the target business scenario.

[0030] The second device 102 can be any device with communication and computing functions. For example, the second device 102 can be a server or a cloud server. The second device is used to pre-generate the graph database.

[0031] Client 103 can be any device with communication and display functions. Client 103 is used to respond to user input operations, display and transmit natural language description information corresponding to the input operation to the first device 101 or the second device 102.

[0032] Figure 1 The test code generation system shown is for illustrative purposes only and is not intended to limit the technical solutions of this application. Those skilled in the art should understand that in specific implementations, the test code generation system may include more devices, without limitation.

[0033] This embodiment provides a method for generating test code, which can be used in the first device described above. Figure 2 This is a flowchart illustrating a method for generating test code according to an embodiment of this application; as shown below. Figure 2 As shown, the process includes the following steps: S201, Obtain the target natural language description information.

[0034] The target natural language description information is used to indicate the target scenario name corresponding to the target business scenario to be tested, and the product identifier of the target business product to which the target business scenario belongs. For example, the target natural language description information is "Place an order to purchase the first product on the first shopping platform".

[0035] In one example, the first device responds to the user's input operation on the client, obtains the target natural language description information corresponding to the input operation, inputs the target natural language description information into the large language model, and outputs the target business scenario and target business product corresponding to the target natural language description information.

[0036] For example, taking the target natural language description information as "order the first product on the first shopping platform", the first device responds to the user's input operation on the client, obtains the target natural language description information "order the first product on the first shopping platform" corresponding to the input operation, inputs the target natural language description information into the large language model, and outputs the target business scenario "product purchase scenario" and the target business product "first shopping platform" corresponding to the target natural language description information.

[0037] S202, send the target scene name and product identifier to the second device.

[0038] In one example, a task request is generated using the target scene name and product identifier, and then sent to a second device. Based on the task request, the second device searches a graph database for a target dependency graph that matches the target scene name and product identifier, and then sends the target dependency graph to the first device.

[0039] S203, receive the target dependency graph sent by the second device, which matches the target scenario name and product identifier found in the graph database, and based on the target dependency graph, determine the interface information of each target interface among the multiple target interfaces required by the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with dependencies.

[0040] The graph database can be a Network Exploration and Optimization 4 Java (Neo4j) database. The graph database stores dependency graphs for each of the multiple business scenarios. Each dependency graph stores multiple interface nodes, multiple scenario nodes, and one product node. Each dependency graph also stores the interface attributes for each interface node, the scenario attributes for each scenario node, and the product attributes for each product node.

[0041] Each interface node corresponds to one interface; each scenario node corresponds to one business scenario. Product nodes correspond to business products belonging to multiple business scenarios.

[0042] In this embodiment, the interface information includes the interface step number, interface name, interface type, and interface attributes for each interface. The interface attributes include the interface's request method, access endpoint path, request parameters, request body data, and response body data. Optionally, the interface attributes may also include other information, without limitation.

[0043] In this embodiment of the application, the parameter transmission information includes the transmission direction of parameter transmission between two target interfaces and at least one parameter being transmitted.

[0044] In some alternative implementations, based on the target dependency graph, a topology sorting algorithm is used to determine the calling order among multiple target interfaces, and the interface information and parameter passing information of each target interface are read from the interface attributes of each target interface.

[0045] Specifically, based on the target dependency graph, the in-degree of each target interface is calculated. Interfaces with an in-degree of zero are designated as starting interfaces and added to the processing queue. After processing of these interfaces, they are removed from the target dependency graph, the in-degree of each interface in the graph is updated, and the process repeats. When the number of processed interfaces matches the total number of interfaces, multiple processing queues corresponding to the target interfaces are determined. The order in which interfaces are added to these queues determines the calling order among the multiple target interfaces, and the interface information and parameter passing information for each target interface are read from its interface attributes.

[0046] In this context, in-degree indicates how many other interfaces depend on an interface.

[0047] Optionally, during repeated execution, if the number of processed interfaces is less than the total number of interfaces, it indicates that there are circular dependencies between the unprocessed interfaces. All unprocessed interfaces with circular dependencies are filtered out, and a depth-first search is performed on these interfaces: starting from any unvisited circular interface, all its dependent interfaces are recursively traversed until all interfaces in the loop are traversed. During the traversal, the interfaces are added to the final call order according to the rule of "recursively processing dependencies first, then recording the current interface".

[0048] Understandably, the interface call order calculated based on the dependency graph of a graph database is a call order generated through topological sorting. This fundamentally avoids call failures, data loss, and system anomalies caused by incorrect interface call order (such as calling a downstream interface that depends on a preceding interface first). It also avoids system deadlocks and interface call chain blockages caused by unidentified circular dependencies, thus improving the robustness of interface calls. In addition, the parameter passing information extracted from the dependency graph can avoid parameter omissions or redundant passing. When problems occur in the execution of business scenarios, the specific interface call node or parameter passing link can be quickly traced, reducing the cost of problem localization. Moreover, there is no need to manually sort out the dependencies, call order, and parameter passing rules of multiple interfaces, improving the efficiency of test code generation. When the interface dependencies of the target business scenario change, only the dependencies in the graph database need to be updated. Without large-scale modifications to the code logic, the call order and parameter passing information can be recalculated through algorithms, making it faster to adapt to business changes. The interface dependencies, call order, and parameter passing rules are no longer coupled to the business code, which facilitates the reuse of subsequent interfaces and further improves the efficiency of test code generation.

[0049] S204 generates test code corresponding to the target business scenario based on the call order, parameter passing information, interface information, and the preset code template for each target interface.

[0050] In some optional implementations, structured execution chain information corresponding to each target interface is generated based on the call order, parameter passing information, and interface information; test code is generated based on the execution chain information of each target interface and a preset code template.

[0051] Each execution chain information includes the step number, interface information, and dependency information for each target interface.

[0052] In this embodiment of the application, dependency information is used to indicate the dependency direction and transmission parameter information of the dependent interfaces that have a dependency relationship with each target interface.

[0053] The parameter information for each dependent interface includes the interface name, interface identifier, parameter mapping identifier, and at least one parameter associated with the parameter mapping identifier.

[0054] The parameter mapping identifier is used to indicate whether a parameter mapping exists for each dependent interface. For example, when the parameter mapping identifier is the first identifier, it indicates that the dependent interface has a parameter mapping; when the parameter mapping identifier is the second identifier, it indicates that the dependent interface does not have a parameter mapping.

[0055] Understandably, structured execution chain information includes step numbers, interface information, and dependency information, which can clearly identify complex multi-level and multi-branch interface dependencies. Furthermore, the integration of complete dependency information in the execution chain ensures the accuracy of generated test code. In addition, generating test code based on unified execution chain information and preset code templates guarantees standardized code style and logic. Simultaneously, structured execution chain information can be reused in different business scenarios, solving the problem of unreusable existing technology dependencies and reducing the development and maintenance costs of subsequent test code.

[0056] In one example, the step number of each target interface is determined according to the calling order; based on the calling order and parameter passing information, at least one dependent interface that has a dependency relationship with each target interface and the dependency information of each dependent interface are determined; based on the step number, dependency information and interface information, structured execution chain information corresponding to each target interface is generated.

[0057] Each dependency interface can be either an upstream dependency interface or a downstream dependency interface.

[0058] Understandably, by constructing execution chain information for each interface according to the call order, recording the step number, interface name, interface type, and interface attributes for each interface, as well as the upstream interfaces that each interface depends on and their parameter mapping relationships, and recording the downstream interfaces that each interface depends on and their parameter mapping relationships, a structured execution chain information for the target interface can be constructed. Furthermore, the step number can solidify the interface call order, and the structured execution chain information unifies the expression of dependency relationships. In addition, the structured execution chain information is used to represent common interface execution and dependency rules, which can be reused across different business scenarios, eliminating the need for repeated analysis of interface dependencies and reducing the development and maintenance costs of test code. The standardized execution chain information can be directly used as input data for preset code templates, replacing the process of manually writing dependency logic, significantly improving the automation and efficiency of test code generation.

[0059] In one example, based on the execution chain information of each target interface, a structured upstream dependency description text and a structured downstream dependency description text corresponding to each target interface are generated; according to the calling order, the interface information, upstream dependency description text, and downstream dependency description text of each target interface are input into a preset code template in sequence, and the code component file corresponding to each target interface is output to obtain the test code.

[0060] Specifically, based on the execution chain information of each target interface, the upstream dependencies of each target interface are traversed. For dependencies with parameter mappings, source and target parameters are extracted to generate a structured upstream dependency description text for each target interface, indicating which parameters of the current interface need to be read from the parameter pool and from which upstream interface these parameters originate. Similarly, the downstream dependencies of each target interface are traversed. For dependencies with parameter mappings, the output parameters of the current interface are extracted to generate a structured downstream dependency description text, indicating which output parameters of the current interface need to be saved to the parameter pool for use by downstream interfaces. Then, according to the calling order, the interface information, upstream dependency description text, and downstream dependency description text of each target interface are sequentially input into a preset code template, outputting the code component file corresponding to each target interface to obtain the test code.

[0061] The code component files can include: interface definition class code component files, request / response class code component files, client request class code component files, test class code component files, code component files for reading parameter values ​​from the parameter pool (upstream dependent interfaces), code component files for saving response parameters to the parameter pool (downstream interface dependencies), and parameter passing logic code component files. Specifically, the interface definition class code component files define the request and response structures of the interface; the request / response class code component files implement object data serialization and deserialization; the client request class code component files encapsulate request logic; the test code component files define dependency handling logic; and the parameter passing logic code component files define the interface call order and parameter passing.

[0062] Understandably, each target interface generates a corresponding code component file independently, and the component encapsulates the complete dependency information of that interface. If different business scenarios call the same interface, the code component file of that interface can be reused directly, without having to repeatedly write dependency-related logic, thus improving the reusability of test code and facilitating independent maintenance and iteration of the test logic for individual interfaces. When interface dependencies change, only the execution chain information needs to be updated and the structured description text needs to be regenerated to quickly adapt the code template and generate new code components, reducing the maintenance cost of test code.

[0063] based on Figure 2The method shown can obtain target natural language description information; send the target scenario name and product identifier to the second device; receive the target dependency graph matching the target scenario name and product identifier found in the graph database sent by the second device, and based on the target dependency graph, determine the interface information of each target interface among the multiple target interfaces required by the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with dependencies; and generate test code corresponding to the target business scenario according to the calling order, parameter passing information, interface information, and the preset code template of each target interface.

[0064] By matching the target dependency graph from the graph database using the target scenario name and product identifier, it ensures that the obtained interface information, call order, and parameter passing information match the target business scenario. This eliminates the need for manual dependency analysis, solving the problems of time-consuming and error-prone manual interface analysis in traditional methods, and significantly improving the overall efficiency and effectiveness of test code generation. Furthermore, the target dependency graph stored in the graph database can efficiently handle complex interface dependency scenarios with multiple levels and branches. The dependencies stored in the graph database can be reused across multiple business scenarios, adapting to the test code generation needs of multiple business scenarios and products, overcoming the difficulty of reusing dependencies in traditional methods. When the interface call logic of the target business scenario changes, only the dependency graph in the graph database needs to be updated to quickly regenerate test code adapted to the new logic, improving the timeliness of business iteration.

[0065] This embodiment provides another method for generating test code, which can be used in the second device described above. Figure 3 This is a flowchart illustrating another method for generating test code according to an embodiment of this application; as shown below. Figure 3 As shown, the process includes the following steps: S301, receive the target scenario name corresponding to the target business scenario to be tested, and the product identifier of the target business product to which the target business scenario belongs, sent by the first device.

[0066] For details on the execution process of S301, please refer to the specific execution process of S201 above, which will not be repeated here.

[0067] S302, search the graph database for the target dependency graph that matches the target scene name and product identifier.

[0068] The target dependency graph is used to indicate the interface information of each target interface among the multiple target interfaces required by the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information between two target interfaces with dependencies.

[0069] For details on the execution process of S302, please refer to the specific execution process of S202 above, which will not be repeated here.

[0070] S303, send the target dependency graph to the first device so that the first device can generate test code corresponding to the target business scenario based on the call order, parameter passing information, interface information and the preset code template of each target interface.

[0071] For details on the execution process of S303, please refer to the specific execution process of S203 above, which will not be repeated here.

[0072] Based on the above Figure 3 The method shown involves the second device receiving the target scenario name corresponding to the target business scenario to be tested, and the product identifier of the target business product to which the target business scenario belongs, sent by the first device; searching for a target dependency graph that matches the target scenario name and product identifier in the graph database; and sending the target dependency graph to the first device.

[0073] Because the target dependency graph can be retrieved from the graph database by the target scenario name and product identifier, and then sent to the first device, it ensures that the interface information, call order, and parameter passing information obtained by the first device match the target business scenario. This eliminates the need for manual dependency analysis, solving the problems of time-consuming and error-prone manual methods in traditional approaches, and significantly improving the overall efficiency and effectiveness of test code generation. Furthermore, the target dependency graph stored in the graph database can efficiently handle complex interface dependency scenarios with multiple levels and branches. The dependencies stored in the graph database can be reused across multiple business scenarios, adapting to the test code generation needs of multiple business scenarios and products, overcoming the difficulty of reusing dependencies in traditional methods. When the interface call logic of the target business scenario changes, only the dependency graph in the graph database needs to be updated to quickly regenerate test code adapted to the new logic, improving the timeliness of business iteration.

[0074] Before searching the target dependency graph in the graph database that matches the target scene name and product identifier, this embodiment provides another method for generating test code, such as... Figure 4 As shown, Figure 4 This is a flowchart illustrating another method for generating test code according to an embodiment of this application; the process includes the following steps: S401, obtain natural language description information for multiple samples.

[0075] In one example, in response to user input on the client, multiple sample natural language descriptions corresponding to the input are obtained.

[0076] S402, input the natural language description information of each sample into the large language model, and output the business scenario corresponding to the natural language description information of each sample, the business product corresponding to each business scenario, the interface call order of multiple interfaces required for each business scenario, and the parameter passing information between two interfaces with dependencies.

[0077] Specifically, by constructing prompt words for a large language model, the natural language description information of each sample is input into the large language model, and the business scenario corresponding to the natural language description information of each sample, the business product corresponding to each business scenario, the interface call order of multiple interfaces required for each business scenario, and the parameter passing information between two interfaces with dependencies are output.

[0078] The prompts can include system prompts and user prompts. System prompts define the roles and analysis requirements of the large language model; user prompts define the list of available interfaces and natural language descriptions.

[0079] S403 establishes the mapping relationship between each business product, each business scenario, and each interface.

[0080] S404, retrieve the interface documentation for each business product.

[0081] Each interface document records the interface information for each interface. Interface documents can be Open Application Programming Interfaces (OpenAPIs).

[0082] S405, based on the mapping relationship, interface call order, parameter passing information and interface information, establishes a dependency graph belonging to each business scenario of each business product, and obtains a graph database corresponding to multiple business products.

[0083] Among them, multiple business products include the first business product, the first business scenario belongs to the first business product, and the first business scenario needs to call multiple preset interfaces.

[0084] In one example, a first dependency graph belonging to the first business scenario is established based on the first business product, the first business scenario, the first mapping relationship between multiple preset interfaces, the first interface call order of multiple preset interfaces, the first parameter passing information between two preset interfaces with dependencies, and the interface information of each preset interface.

[0085] Specifically, given the existence of at least one historical dependency graph, and the absence of a first business product identifier corresponding to the first business product in at least one historical dependency graph, a first product node corresponding to the first business product is created, and the product attributes of the first product node are set; based on the first business product identifier and the scenario name of the first business scenario, a first scenario identifier for the first business scenario is generated, and a first scenario node corresponding to the first business scenario is created, and the scenario attributes of the first scenario node are set; based on the first business product identifier and the interface information of each preset interface, an interface identifier for each preset interface is generated, and a preset interface node corresponding to each preset interface is created, and the interface attributes of each preset interface node are set; a second mapping relationship is established between each preset interface node and the first scenario node; based on the first interface call order, an interface dependency relationship is established between multiple preset interfaces, and first parameter transmission information is added to the interface attributes; based on the first product node, the first scenario node, multiple preset interface nodes, the first mapping relationship, the second mapping relationship, and the interface dependency relationship, a first dependency graph is established.

[0086] The product attributes include the business product identifier and business product name of the product node.

[0087] The scenario attributes include the scenario name and the first scenario identifier of the first business scenario, and establish the first mapping relationship between the first scenario node and the first product node.

[0088] The interface attributes include the interface identifier for each preset interface, the step number and the step name corresponding to each preset interface.

[0089] Understandably, if there is at least one historical dependency graph and at least one historical dependency graph contains a first business product identifier corresponding to the first business product, the first scenario identifier of the first business scenario can be generated directly based on the first business product identifier and the scenario name of the first business scenario, and the first scenario node corresponding to the first business scenario can be created without creating a new first product node.

[0090] Understandably, transforming the relationships between business products, business scenarios, and interfaces into product nodes, scenario nodes, interface nodes, and their associated relationships in a graph database allows for the establishment of a mapping between interface call relationships and business scenarios, facilitating the subsequent determination of interface call logic under different business scenarios. Constructing a dependency graph independently for each business scenario accurately determines the interface call order, parameter passing rules, and upstream and downstream dependencies within that scenario. Furthermore, when a business scenario changes, only the interface associations under the corresponding scenario node need to be updated, without altering the dependencies of the entire product, thus improving the efficiency of interface dependency management. In addition, product identifiers, scenario identifiers, and interface identifiers ensure the uniqueness of each node (product node / scenario node / interface node), facilitating problem localization.

[0091] This embodiment also provides a test code generation apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0092] This embodiment provides a test code generation device, applied to a first device; such as Figure 5 As shown, Figure 5 This is a structural block diagram of a test code generation apparatus according to an embodiment of this application; the apparatus includes: The first transceiver module 501 is used to obtain target natural language description information, which indicates the target scenario name corresponding to the target business scenario to be tested and the product identifier of the target business product to which the target business scenario belongs; send the target scenario name and product identifier to the second device; receive the target dependency relationship graph that matches the target scenario name and product identifier found in the graph database by the second device; and based on the target dependency relationship graph, determine the interface information of each target interface among the multiple target interfaces required by the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with dependencies. The generation module 502 is used to generate test code corresponding to the target business scenario based on the call order, parameter passing information, interface information, and the preset code template for each target interface.

[0093] In some optional implementations, the target dependency graph stores the interface attributes of each interface node among multiple interface nodes, and each interface node corresponds to a target interface; the first transceiver module 501 is specifically used to determine the calling order among multiple target interfaces based on the target dependency graph using a topology sorting algorithm, and to read the interface information and parameter transmission information of each target interface from the interface attributes of each target interface.

[0094] In some optional implementations, the generation module 502 is specifically used to generate structured execution chain information corresponding to each target interface based on the call order, parameter passing information, and interface information. Each execution chain information includes the step number, interface information, and dependency information of each target interface. The dependency information is used to indicate the dependency direction and parameter passing information of the dependent interfaces that have a dependency relationship with each target interface. The parameter passing information of each dependent interface includes the interface name, interface identifier, parameter mapping identifier, and at least one passing parameter associated with the parameter mapping identifier of each dependent interface. The parameter mapping identifier is used to indicate whether there is a parameter mapping for each dependent interface. Based on the execution chain information of each target interface and the preset code template, test code is generated.

[0095] In some optional implementations, the generation module 502 is specifically used to determine the step number of each target interface according to the calling order; determine at least one dependent interface that has a dependency relationship with each target interface and the dependency information of each dependent interface according to the calling order and parameter passing information, wherein each dependent interface is an upstream dependent interface or a downstream dependent interface; and generate structured execution chain information corresponding to each target interface according to the step number, dependency information and interface information.

[0096] In some optional implementations, the generation module 502 is specifically used to generate structured upstream dependency description text and structured downstream dependency description text corresponding to each target interface based on the execution chain information of each target interface; according to the calling order, the interface information, upstream dependency description text and downstream dependency description text of each target interface are sequentially input into a preset code template, and the code component file corresponding to each target interface is output to obtain the test code.

[0097] This embodiment provides another test code generation device, which uses a second device; such as Figure 6 As shown, Figure 6 This is a structural block diagram of another test code generation apparatus provided according to an embodiment of this application; the apparatus includes: The second transceiver module 601 is used to receive the target scenario name corresponding to the target business scenario to be tested, and the product identifier of the target business product to which the target business scenario belongs, sent by the first device.

[0098] The processing module 602 is used to search for a target dependency graph in the graph database that matches the target scenario name and product identifier. The target dependency graph is used to indicate the interface information of each target interface among the multiple target interfaces required by the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information between two target interfaces with dependencies.

[0099] The second transceiver module 601 is also used to send the target dependency graph to the first device, so that the first device can generate test code corresponding to the target business scenario based on the call order, parameter passing information, interface information and the preset code template of each target interface.

[0100] In some optional implementations, before searching for a target dependency graph matching the target scenario name and product identifier in the graph database, the second transceiver module 601 is further configured to acquire multiple sample natural language descriptions; the processing module 602 is further configured to input each sample natural language description into the large language model, output the business scenario corresponding to each sample natural language description, the business product corresponding to each business scenario, the interface call order of multiple interfaces required by each business scenario, and the parameter passing information between two interfaces with dependencies; establish a mapping relationship between each business product, each business scenario, and each interface; acquire the interface document corresponding to each business product, with each interface document recording the interface information of each interface; and establish a dependency graph belonging to each business scenario of each business product based on the mapping relationship, interface call order, parameter passing information, and interface information, thereby obtaining a graph database corresponding to multiple business products.

[0101] In some optional implementations, multiple business products include a first business product, a first business scenario belongs to the first business product, and the first business scenario needs to call multiple preset interfaces; the processing module 602 is specifically used to create a first product node corresponding to the first business product and set the product attributes of the first product node when there is at least one historical dependency graph and there is no first business product identifier corresponding to the first business product in at least one historical dependency graph, including the business product identifier and business product name of the product node; generate a first scenario identifier for the first business scenario based on the first business product identifier and the scenario name of the first business scenario, create a first scenario node corresponding to the first business scenario, and set the scenario attributes of the first scenario node, including the scenario name of the first business scenario. The process involves: identifying the first scenario node; establishing a first mapping relationship between the first scenario node and the first product node; generating an interface identifier for each preset interface based on the first business product identifier and the interface information of each preset interface, creating a preset interface node corresponding to each preset interface, and setting the interface attributes of each preset interface node, including the interface identifier, step number, and step name of each preset interface; establishing a second mapping relationship between each preset interface node and the first scenario node; establishing interface dependency relationships between multiple preset interfaces based on the first interface call order, and adding first parameter transmission information to the interface attributes; and establishing a first dependency graph based on the first product node, the first scenario node, multiple preset interface nodes, the first mapping relationship, the second mapping relationship, and the interface dependency relationship.

[0102] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0103] In this embodiment, the test code generation device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0104] This invention also provides an electronic device having the above-described features. Figure 5 or Figure 6 The device for generating the test code shown.

[0105] Please see Figure 7 , Figure 7 This is a schematic diagram of the hardware structure of the electronic device according to an embodiment of this application, such as... Figure 7 As shown, the electronic device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise as required. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 7 Take a processor 10 as an example.

[0106] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0107] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0108] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0109] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0110] The electronic device also includes a communication interface 30 for communicating with other devices or communication networks.

[0111] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0112] This invention provides a computer program product, which includes computer instructions for causing a computer to execute the method of any embodiment of this invention.

[0113] It should be noted that, in this document, relational terms such as "first" and "second" 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. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0114] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of generating a test code, characterized by, Applied to a first device, the method includes: Obtain target natural language description information, which is used to indicate the target scenario name corresponding to the target business scenario to be tested and the product identifier of the target business product to which the target business scenario belongs. Send the target scene name and the product identifier to the second device; The system receives a target dependency graph from the second device, which is found in the graph database and matches the target scene name and the product identifier. Based on the target dependency graph, the system determines the interface information of each target interface among the multiple target interfaces required by the target business scene, the calling order among the multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with a dependency relationship. Based on the calling order, the parameter passing information, the interface information, and the preset code template for each target interface, test code corresponding to the target business scenario is generated.

2. The method of claim 1, wherein, The target dependency graph stores the interface attributes of each of the multiple interface nodes, and each interface node corresponds to a target interface. The step of determining, based on the target dependency graph, the interface information of each target interface among the multiple target interfaces required for the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information for parameter passing between two target interfaces with dependencies includes: Based on the target dependency graph, the calling order among multiple target interfaces is determined using a topology sorting algorithm, and the interface information and parameter passing information of each target interface are read from the interface attributes of each target interface.

3. The method according to claim 1 or 2, characterized in that, The step of generating test code corresponding to the target business scenario based on the call order, the parameter passing information, the interface information, and the preset code template for each target interface includes: Based on the invocation order, the parameter passing information, and the interface information, structured execution chain information corresponding to each target interface is generated. Each execution chain information includes the step number, interface information, and dependency information of each target interface. The dependency information is used to indicate the dependency direction and parameter passing information of the dependent interfaces that have a dependency relationship with each target interface. The parameter passing information of each dependent interface includes the interface name, interface identifier, parameter mapping identifier, and at least one passing parameter associated with the parameter mapping identifier of each dependent interface. The parameter mapping identifier is used to indicate whether there is a parameter mapping for each dependent interface. The test code is generated based on the execution chain information and preset code template for each target interface.

4. The method of claim 3, wherein, The step of generating structured execution chain information for each target interface based on the call order, the parameter passing information, and the interface information includes: According to the calling order, determine the step number for each target interface; Based on the calling order and parameter passing information, at least one dependent interface that has a dependency relationship with each target interface and the dependency item information of each dependent interface are determined, wherein each dependent interface is an upstream dependent interface or a downstream dependent interface. Based on the step number, the dependency information, and the interface information, generate structured execution chain information corresponding to each target interface.

5. The method according to claim 3, characterized in that, The step of generating the test code based on the execution chain information and preset code template of each target interface includes: Based on the execution chain information of each target interface, generate a structured upstream dependency description text and a structured downstream dependency description text corresponding to each target interface; According to the calling order, the interface information, upstream dependency description text, and downstream dependency description text of each target interface are sequentially input into the preset code template, and the code component file corresponding to each target interface is output to obtain the test code.

6. A method for generating test code, characterized in that, Applied to a second device, the method includes: Receive the target scenario name corresponding to the target business scenario to be tested, sent by the first device, and the product identifier of the target business product to which the target business scenario belongs; The target dependency graph is searched in the graph database to match the target scenario name and the product identifier. The target dependency graph is used to indicate the interface information of each of the multiple target interfaces required by the target business scenario, the calling order among the multiple target interfaces, and the parameter passing information between two target interfaces with a dependency relationship. The target dependency graph is sent to the first device so that the first device can generate test code corresponding to the target business scenario based on the call order, the parameter passing information, the interface information, and the preset code template for each target interface.

7. The method according to claim 6, characterized in that, Before searching the graph database for a target dependency graph that matches the target scene name and the product identifier, the method further includes: Obtain natural language descriptions of multiple samples; Input each sample natural language description information into the large language model, and output the business scenario corresponding to each sample natural language description information, the business product corresponding to each business scenario, the interface calling order of multiple interfaces required for each business scenario, and the parameter passing information between two interfaces with dependencies. Establish a mapping relationship between each of the aforementioned business products, each of the aforementioned business scenarios, and each of the aforementioned interfaces; Obtain the interface document corresponding to each of the aforementioned business products; each interface document records the interface information of each of the aforementioned interfaces. Based on the mapping relationship, the interface call order, the parameter passing information, and the interface information, a dependency graph belonging to each of the business scenarios of each of the business products is established, resulting in the graph database corresponding to multiple business products.

8. The method according to claim 7, characterized in that, The multiple business products include a first business product, a first business scenario belongs to the first business product, and the first business scenario needs to call multiple preset interfaces; the step of establishing a dependency graph for each business scenario belonging to each business product based on the mapping relationship, the interface call order, the parameter passing information, and the interface information includes: If at least one historical dependency graph exists, and at least one of the historical dependency graphs does not contain a first business product identifier corresponding to the first business product, a first product node corresponding to the first business product is created, and the product attributes of the first product node are set, wherein the product attributes include the business product identifier and the business product name of the product node. Based on the first business product identifier and the scenario name of the first business scenario, a first scenario identifier for the first business scenario is generated, a first scenario node corresponding to the first business scenario is created, and the scenario attributes of the first scenario node are set, wherein the scenario attributes include the scenario name of the first business scenario and the first scenario identifier. Establish a first mapping relationship between the first scene node and the first product node; Based on the first business product identifier and the interface information of each preset interface, an interface identifier for each preset interface is generated, and a preset interface node corresponding to each preset interface is created. The interface attributes of each preset interface node are set, including the interface identifier of each preset interface, the step number and the step name corresponding to each preset interface. Establish a second mapping relationship between each of the preset interface nodes and the first scene node; Based on the first interface call order, establish interface dependency relationships between multiple preset interfaces, and add the first parameter to the interface attributes to pass information; Based on the first product node, the first scenario node, multiple preset interface nodes, the first mapping relationship, the second mapping relationship, and the interface dependency relationship, establish the first dependency relationship graph.

9. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the method for generating test code according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to execute the method for generating the test code according to any one of claims 1 to 8.

Images