Interface test case generation method and device, storage medium and program product
By parsing the source code to extract interface information and call chain information, and using a large model to generate interface test cases, the problems of randomness and bias in interface test cases in existing technologies are solved, and test coverage and accuracy are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- IFLYTEK CO LTD
- Filing Date
- 2025-12-23
- Publication Date
- 2026-04-17
AI Technical Summary
Existing technologies generate interface test cases using large models, which are subject to randomness and bias, making it difficult to guarantee test coverage.
By parsing the source code of the software under test, we can extract the interface information and call chain information of the business interfaces, generate interface test cases using a large model, and consider the actual implementation path of the source code.
It reduces the randomness and bias in the generation of interface test cases, and improves test coverage and accuracy.
Smart Images
Figure CN121880185A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of testing technology, and in particular to a test case generation method, device, storage medium, and program product. Background Technology
[0002] With the rapid development of information technology and the widespread application of agile development and continuous integration / continuous delivery (CI / CD), the frequency of software version iterations has increased significantly. To ensure software quality, each version of the software needs to be tested, and testing business interfaces (such as interfaces that interact with users or interfaces that are called by third parties) is an important aspect.
[0003] With the development of artificial intelligence, generating interface test cases using large models has become a research hotspot. However, current methods for generating interface test cases using large models are prone to randomness and bias, making it difficult to guarantee test coverage.
[0004] Therefore, how to reduce the randomness and bias of large-scale model-generated interface test cases has become an urgent technical problem to be solved. Summary of the Invention
[0005] In view of the above problems, this application provides a method, device, storage medium, and program product for generating interface test cases to reduce the randomness and bias in the generation of interface test cases. The specific solution is as follows:
[0006] The first aspect of this application provides a method for generating interface test cases, including:
[0007] The controller classes in the source code of the software under test are parsed to obtain the interface information of each business interface. The interface information of each business interface includes: the request path of the business interface, the name of the entry method, and the parameter information.
[0008] The abstract syntax tree of the source code is parsed to obtain the call chain information corresponding to each business interface;
[0009] Select at least one business interface to be tested, and process the source code of at least one method in the interface information, call chain information and call chain information of each business interface to generate test cases corresponding to the business interface to be tested.
[0010] In one possible implementation, the parsing of each controller class in the source code of the software to be tested includes:
[0011] Parse the annotations in each controller class to obtain the request path of each business interface;
[0012] The name of the entry method for each business interface is determined based on the request path of that business interface.
[0013] The parameter list of the entry method for each business interface is parsed to determine the parameter structure and the position of the parameters in the interface request.
[0014] In one possible implementation, parsing any parameter list includes:
[0015] For any basic parameter in the parameter list, the parameter type is directly recorded.
[0016] For any data transfer object (DTO), inner class, and inheritance chain in the parameter list, recursively parse the fields to obtain the basic parameters and the relationships between them.
[0017] Determine the position of the parameter in the API request based on the annotations on the parameter and the API request method.
[0018] One possible implementation also includes:
[0019] For each business interface, generate an interface definition document for that business interface based on its interface information;
[0020] Accordingly, the source code of at least one method within the interface information, call chain information, and call chain information of each business interface to be tested is processed using a large model, including:
[0021] The large model processes the source code of at least one method in the interface definition document, call chain information, and call chain information of each business interface to be tested.
[0022] In one possible implementation, an interface definition document for any business interface is generated based on its interface information, including:
[0023] Add the interface information of any of the business interfaces to the FreeMarker template to obtain the interface definition document of any of the business interfaces;
[0024] The FreeMarker template defines the interface title, parameter table, example request, and example response.
[0025] In one possible implementation, at least one business interface to be tested is selected, including:
[0026] Obtain a coverage report for the source code;
[0027] The target method is determined based on the coverage report, and the target method includes uncovered methods.
[0028] The target method is retrieved from the call chain information corresponding to each business interface, and the business interface corresponding to the call chain information containing the target method is determined as the business interface to be tested.
[0029] In one possible implementation, the method further includes: validating the generated interface test cases using the interface information of the business interface to be tested, including:
[0030] Based on the parameter information in the interface information, detect whether the interface test cases have introduced non-existent fields;
[0031] Check if the field types match and if any required fields are missing;
[0032] If the interface test case introduces a non-existent field, or the field type does not match the parameter type in the parameter information, or a required field is missing, the interface test case will fail the validation; otherwise, the interface test case will pass the validation.
[0033] A second aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the interface test case generation method of the first aspect or any implementation thereof.
[0034] A third aspect of this application provides an electronic device, comprising at least one processor and a memory connected to the processor, wherein:
[0035] The memory is used to store computer programs;
[0036] The processor is used to execute the computer program so that the electronic device can implement the interface test case generation method of the first aspect or any implementation of the first aspect.
[0037] The fourth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to generate interface test cases according to the first aspect or any implementation thereof.
[0038] Using the above technical solution, the interface test case generation method, device, storage medium, and program product provided in this application parse each controller class in the source code of the software to be tested to obtain the interface information of each business interface. The interface information of each business interface includes the request path, the name of the entry method, and parameter information. The abstract syntax tree of the source code is parsed to obtain the call chain information corresponding to each business interface. At least one business interface to be tested is selected, and a large model processes the interface information, call chain information, and the source code of at least one method in the call chain information of each business interface to be tested, generating test cases corresponding to each business interface to be tested. This application extracts the interface information and call chain information of business interfaces from the source code, and calls a large model to generate test cases for the business interfaces to be tested based on the interface information, call chain information, and the source code of at least one method in the call chain information. Because the generation of interface test cases takes into account the source code of the software to be tested, the randomness and bias of interface test case generation are reduced. Attached Figure Description
[0039] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.
[0040] Figure 1 A flowchart illustrating an implementation of the interface test case generation method provided in this application;
[0041] Figure 2 A flowchart illustrating the parsing of controller classes in the source code of the software to be tested provided in this application;
[0042] Figure 3 A flowchart illustrating one implementation of selecting at least one business interface to be tested, provided in this application;
[0043] Figure 4 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation
[0044] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.
[0045] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.
[0046] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.
[0047] The inventors of this application have discovered that, although some testing platforms have attempted to introduce large models, they mostly remain at the level of automatically generating interface test cases from natural language requirements. That is, users edit natural language requirements for business interfaces, and the large model is called to process the user-edited natural language requirements and generate interface test cases. This lacks a direct connection with the actual code implementation, resulting in deviations between the generated interface test cases and the actual execution path, making it difficult to guarantee the effect of improving coverage.
[0048] To reduce the randomness and bias in the generation of interface test cases, this application proposes a solution.
[0049] like Figure 1 The diagram shown is a flowchart of one implementation of the interface test case generation method provided in this application, which may include:
[0050] Step S101: Parse each controller class in the source code of the software to be tested to obtain the interface information of each business interface. The interface information of each business interface includes: the request path of the business interface, the name of the entry method, and parameter information.
[0051] The source code of the software to be tested can be Java code.
[0052] The request path can include: the entry URL of the business interface and the interface request method (usually an HTTP method, such as get, post or delete).
[0053] Parameter information may include: parameter structure and the position of the parameter in the interface request (usually an HTTP request).
[0054] Step S102: Parse the abstract syntax tree of the source code to obtain the call chain information corresponding to each business interface. The call chain information records the methods that need to be called to implement the function of the business interface, as well as the call relationships between the methods.
[0055] The Java source code parsing library JavaParser can be used to convert source code into an Abstract Syntax Tree (AST).
[0056] Optionally, for each business interface, the entry method of the business interface can be searched in the abstract syntax tree according to its name. Recursive parsing can then be performed starting from the entry method. Specifically, this includes: identifying the entry method as the target method, performing statement-level traversal on the target method to extract the methods called within the target method (denoted as the called methods), establishing the call relationship between the target method and the called methods, identifying the called methods as the target method, returning to execute the steps of performing statement-level traversal on the target method to extract the called methods within the target method and subsequent steps, until the recursive parsing termination condition is met, thus obtaining the call chain information corresponding to the business interface.
[0057] Each time a called method is encountered, the method name, parameter types, class name, and package name of the class to which the called method belongs are recorded to uniquely identify the called method. The call chain information includes this information for uniquely identifying the called method. Specifically, in the source code, the class contains the definition of member methods (also called fields of interface type). These member methods have class declarations and annotations. By parsing the declaration type and annotations, it can be determined which class the member method is defined in. The definition of the member method can be found within that class through its function name (i.e., the name of the member method). Table 1 shows a Java code example provided in an embodiment of this application.
[0058] Table 1
[0059]
[0060] In the code shown in Table 1, two member methods are defined: getUser() and findById(). If these two member methods are parsed during the recursive parsing process, their definitions can be found in the abstract syntax tree based on their names (as shown in Table 1). Then, based on the class declaration of the called method getUser() (i.e., "public class UserServiceImpl implements UserService {…}") and the annotation @Service, it can be determined that the class to which the called method getUser() belongs is UserServiceImpl. By parsing the class declaration of the called method findById() (i.e., "public class UserDaoImpl implements UserDao {…}") and the annotation @Repository, it can be determined that the class to which the called method findById() belongs is UserDaoImpl.
[0061] Classes are defined within packages. Therefore, based on the class name, such as UserServiceImpl or UserDaoImpl in Table 1, the class definition can be found in the abstract syntax tree, thus determining the package name to which the class belongs.
[0062] Furthermore, for each called method, its technical role (controller layer, service layer, DAO layer) can be determined. Specifically, the technical role of the called method can be determined based on its package name (e.g., *.controller.*, *.service.*, *.dao.*) or its annotations (e.g., @Service, @Repository). The call chain information also includes the technical role of the called method.
[0063] Optionally, during the parsing of the abstract syntax tree (AST) of the source code, a multi-level call tree can be constructed based on the parsed methods. In the multi-level call tree, each node corresponds to a method, and each node stores information such as the method's name, input parameter types, corresponding class name, package name, and associated technical role. The method of each child node is the method called by the method of its parent node. After the AST is parsed, a depth-first strategy can be used to traverse the multi-level call tree, that is, traverse one path after another. After traversing each path, the nodes on that path are written into a list in traversal order (i.e., the actual execution order), and the unique identifier information of each method (e.g., the method name) is recorded.
[0064] Optionally, for nodes corresponding to common methods (e.g., utility methods or methods belonging to general components), a preset identifier can be marked to indicate that the method is a utility method or a general component, so that the call chain information can be selectively included or simplified later. For example, when calling a large model later, if there are common methods in the call chain, all information of the nodes corresponding to the common methods can be retained, or only the corresponding preset identifier can be retained instead of all information of the nodes corresponding to the common methods. This can simplify the input information of the large model.
[0065] Optionally, the termination condition for recursive resolution can include either of the following two conditions:
[0066] The newly identified called method does not call any other methods internally.
[0067] The target number of calls has been reached. Potential recursive or circular calls may exist in the source code. To prevent these calls from causing the recursive parsing to expand indefinitely and making it impossible to obtain the call chain information, the number of calls can be recorded during the parsing process. Based on this, if the target number of calls is reached, the recursive parsing is considered complete and will not continue.
[0068] Step S103: Select at least one business interface to be tested, and process the source code of at least one method in the interface information, call chain information and call chain information of each business interface to be tested through the large model to generate test cases corresponding to the business interface to be tested.
[0069] Testers can select the business interfaces to be tested based on their needs. If the source code of the software under test is the first version, there may not be any interface test cases yet. In this case, testers can designate all business interfaces as those to be tested. If the source code is not the first version, testers can select the test business interfaces associated with the modified code as the business interfaces to be tested. At least one method in the call chain can be specified by the testers.
[0070] The business interface to be tested can also be an untested business interface identified by the testing system based on the coverage report obtained after testing the software under test, or a business interface with insufficient code coverage. At least one method in the call chain can be an untested method in the coverage report.
[0071] The interface information, call chain information, and source code of at least one method from the call chain information of the business interface to be tested can be added to the prompt word template to obtain prompt words. These prompt words are then input into the large model to generate test cases for the business interface to be tested. The prompt word template also includes task instructions, which instruct the large model to generate structured interface test cases based on the interface information, call chain information, and source code of at least one method from the call chain information of the business interface to be tested. As an example, the structured format of the interface test cases may include, but is not limited to, fields such as request information, variable extraction, and assertions for each step.
[0072] The interface test case generation method provided in this application extracts the interface information and call chain information of the business interface from the source code. For the business interface to be tested, the large model is called to generate test cases for the business interface to be tested based on the source code of at least one method of the interface information, call chain information and call chain information of the business interface to be tested. Since the generation of interface test cases takes into account the source code of the software to be tested, the randomness and bias of the generation of interface test cases are reduced.
[0073] In an optional embodiment, a flowchart illustrating one approach to parsing the controller classes in the source code of the software under test is shown below. Figure 2 As shown, it may include:
[0074] Step S201: Parse the annotations in each controller class to obtain the request paths of each business interface.
[0075] Annotations in the controller class include class-level annotations and method-level annotations. Table 2 shows an example of Java code containing class-level and method-level annotations provided in this application.
[0076] Table 2
[0077]
[0078] In the example shown in Table 2, the URL of the entry method is obtained by combining the paths in the class-level annotation and the method-level annotation, specifically: / api / v1 / users / {id}; the request method (HTTP method) is obtained by the method-level annotation, specifically: get.
[0079] Step S202: Determine the name of the entry method of each business interface based on the request path of each business interface.
[0080] In the example shown in Table 2, the name of the entry method is: getUserById.
[0081] Step S203: Parse the parameter list of the entry method of each business interface to determine the parameter structure and the position of the parameters in the interface request.
[0082] In the source code, each business interface's entry method has a parameter list. Parsing this parameter list reveals the basic parameters required by the entry method of that business interface, the relationships between these basic parameters (e.g., whether they are independent parameters or nested), and the position of the parameters in the interface request.
[0083] Optionally, the process of parsing any parameter list may include:
[0084] For any parameter in any parameter list, if the parameter is a basic parameter, the parameter type is recorded directly.
[0085] Basic parameters can include: basic type parameters and strings. Among them, basic type parameters can include, but are not limited to, the following types: int, string, float, simple collections (i.e., arrays), etc.
[0086] For any parameter in any parameter list, if the parameter is a Data Transfer Object (DTO), an inner class, or an inheritance chain, recursively parse the fields to obtain the basic parameters and the relationships between them.
[0087] Data Transfer Objects (DTOs), inner classes, and inheritance chains are three common methods for organizing and transmitting data. Therefore, by recursively parsing fields in DTOs, inner classes, and inheritance chains respectively, we can obtain the basic parameters and the relationships between them.
[0088] In code, parameters are called fields. Therefore, by recursively parsing fields, we can obtain the basic parameters and the relationships between them. Recursive parsing may include, but is not limited to: for each field parsed, identifying it as the target field, determining whether the target field is a basic parameter, and if it is, ending the field parsing; if the target field is not a basic parameter, obtaining the subfields contained in the target field, using each subfield as a target field, and returning to execute the step of determining whether the target field is a basic parameter, until all target fields are basic parameters.
[0089] For each field parsed, metadata such as field name, type, whether it is required, default value, enumeration range, and description can be extracted and recorded. Based on this, parameter information can also include the parameter's metadata.
[0090] The basic parameters obtained from the above two steps and the relationships between these basic parameters constitute the parameter structure.
[0091] Determine the position of the parameter in the API request based on the annotations on the parameter and the API request method.
[0092] Table 3 shows an example of a piece of Java code containing parameter annotations provided in an embodiment of this application.
[0093] Table 3
[0094]
[0095] In the example shown in Table 3, the API request method is POST, and the parameter annotation is @RequestBody. Based on this, we can determine that the parameter is located in the body (request body) of the API request.
[0096] The position of parameters in an API request can be one of the following: query (query parameter, located after the question mark in the URL), path (request path URL), or header (request header), body (request body), etc.
[0097] Optionally, for parameters without annotations, the large model can be called to process the source code snippet containing the parameter and generate the position of the parameter in the API request.
[0098] The parsed interface information can be stored in JSON format.
[0099] In an optional embodiment, the interface test case generation method provided in this application may further include:
[0100] For each business interface, an interface definition document is generated based on the interface information of that business interface (i.e., request path, name of entry method, parameter structure and parameter position, etc.).
[0101] In this application, each business interface corresponds to an interface definition document, which is a document that can be read by users (e.g., technical personnel). For example, the interface definition document can be a document in Markdown format.
[0102] Optionally, one way to generate the interface definition document for any given business interface based on its interface information is as follows:
[0103] Add the interface information of any business interface to the FreeMarker template to obtain the interface definition document of that business interface.
[0104] The FreeMarker template defines the interface title, parameter list, sample request, and sample response.
[0105] Each business interface corresponds to a FreeMarker template. In any FreeMarker template for a business interface, the interface title section contains the name of the entry method for that business interface, the parameter list contains the parameter structure and parameter positions, the example request is a sample request for that business interface, and the example response is a sample response for that business interface. The request example can be obtained by adding default parameters to the entry method of that business interface, and the example response is the response corresponding to the default parameters.
[0106] Correspondingly, one implementation method that processes the source code of at least one method from the interface information, call path information, and call chain information of any business interface through a large model can be:
[0107] By processing the interface definition document, call chain information, and source code of at least one method in the call chain information of each business interface to be tested using a large model, test cases corresponding to any business interface can be obtained.
[0108] The interface definition document, call chain information, and source code of at least one method from the call chain information of the business interface to be tested can be added to the prompt word template to obtain prompt words. These prompt words are then input into the large model to generate test cases for the business interface to be tested. The prompt word template also includes task instructions, which instruct the large model to generate structured interface test cases based on the interface definition document, call chain information, and source code of at least one method from the call chain information of the business interface to be tested.
[0109] When collecting and analyzing source code coverage, the coverage needs to meet certain conditions, such as being greater than or equal to a preset threshold. If the coverage does not reach the preset threshold, additional test cases need to be added for supplementary testing. Based on this, in an optional embodiment, the flowchart for selecting at least one business interface to be tested is as follows: Figure 3 As shown, it may include:
[0110] Step S301: Obtain the source code coverage report.
[0111] The source code coverage report includes a full coverage report and an incremental coverage report; the coverage report here is the full coverage report.
[0112] The interface test cases for source code coverage analysis can be interface test cases generated based on the interface test case generation method of this application, or interface test cases obtained through other methods (such as user-written or automatically generated by other methods).
[0113] Step S302: Determine the target methods based on the coverage report. The target methods include uncovered methods.
[0114] The coverage report includes a list of uncovered methods; therefore, the methods in the list of uncovered methods can be identified as target methods.
[0115] Step S303: Retrieve the target method from the call chain information corresponding to each business interface, and determine the business interface corresponding to the call chain information containing the target method as the business interface to be tested.
[0116] Based on the name of the target method, the class and package to which the target method belongs, the target method can be retrieved from the call chain information corresponding to each business interface. If the name of the target method, the class and package to which the target method belongs are contained in a certain call chain information, it is determined that the business interface corresponding to that call chain is not the business interface to be tested.
[0117] The target method may be recorded in multiple call chain information. Therefore, there may be multiple call chain information containing the target method. Based on this, multiple business interfaces to be tested may be identified for a single target method.
[0118] Based on the coverage report, interface test cases required for supplementary testing can be automatically generated, improving the relevance of the generated test cases and the completeness of the tests, and effectively improving test coverage.
[0119] In an optional embodiment, to ensure the validity of the generated interface test cases, the generated interface test cases can be verified. Specifically, the generated interface test cases can be verified using the interface information of the business interface to be tested. The verification process may include:
[0120] The test case checks whether it has introduced a non-existent field based on the parameter information in the interface information. Optionally, if a field in the interface test case is not a parameter in the parameter information, then it is determined that a non-existent field has been introduced into the interface test case.
[0121] Check if the field types match and if any required fields are missing. In a valid API test case, the field types must match the parameter types recorded in the parameter information (i.e., the field types match the parameter types), and required fields cannot be missing.
[0122] If the interface test case introduces a non-existent field, or the field type does not match the parameter type in the parameter information, or a required field is missing, the interface test case will fail the validation; otherwise, the interface test case will pass the validation.
[0123] For interface test cases that pass validation, they can be imported into the testing platform for retesting the source code. Interface test cases that fail validation should be discarded.
[0124] Furthermore, for the business interfaces corresponding to the test cases that fail the verification, the interface information and call chain information of the business interface can be processed again through the large model to regenerate the test cases corresponding to the business interface to be tested.
[0125] Optionally, when processing the interface information and call chain information of the business interface again through the large model, the interface test cases that failed the validation, the reasons for the validation failure, etc., can be added to the prompt word template along with the interface information and call chain information of the business interface to obtain prompt words. The prompt words are then input into the large model so that the large model knows where the error is, thereby generating valid interface test cases.
[0126] Based on this application, an iterative closed loop of "test case execution → coverage report → automatic identification of test gaps (untested methods) → automatic generation of supplementary test cases → test case execution" can be realized, ensuring the accuracy and efficiency of testing.
[0127] Corresponding to the method embodiments, this application also provides an electronic device. (See reference...) Figure 4 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic device in these embodiments can be a terminal device (e.g., an in-vehicle infotainment system, a large-screen device, a mobile phone, a tablet computer, a laptop computer, a desktop computer, etc.) or a server (which can be a single server, a server cluster, or a cloud server, etc.). Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0128] like Figure 4 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage device 408 into a random access memory (RAM) 403. When the electronic device is powered on, the RAM 403 also stores various programs and data required for the operation of the electronic device. The processing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.
[0129] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, memory cards, hard drives, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.
[0130] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the interface test case generation methods provided in this application.
[0131] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the interface test case generation methods provided in this application.
[0132] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.
[0133] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0134] In the above embodiments, the functionality can be implemented entirely or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented entirely or partially as a computer program product. Those skilled in the art can use different methods to implement the described functions for each specific solution, but such implementation should not be considered beyond the scope of this application.
[0135] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).
[0136] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0137] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. 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 application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. An interface test case generation method characterized by, include: The controller classes in the source code of the software under test are parsed to obtain the interface information of each business interface. The interface information for each business interface includes: the request path of the business interface, the name of the entry method, and parameter information; The abstract syntax tree of the source code is parsed to obtain the call chain information corresponding to each business interface; Select at least one business interface to be tested, and process the source code of at least one method in the interface information, call chain information and call chain information of each business interface to generate test cases corresponding to the business interface to be tested.
2. The method of claim 1, wherein, The parsing of each controller class in the source code of the software under test includes: Parse the annotations in each controller class to obtain the request path of each business interface; The name of the entry method for each business interface is determined based on the request path of that business interface. The parameter list of the entry method for each business interface is parsed to determine the parameter structure and the position of the parameters in the interface request.
3. The method of claim 2, wherein, Parse any list of parameters, including: For any basic parameter in the parameter list, the parameter type is directly recorded. For any data transfer object (DTO), inner class, and inheritance chain in the parameter list, recursively parse the fields to obtain the basic parameters and the relationships between them. Determine the position of the parameter in the API request based on the annotations on the parameter and the API request method.
4. The method of claim 1, wherein, Also includes: For each business interface, generate an interface definition document for that business interface based on its interface information; Accordingly, the source code of at least one method within the interface information, call chain information, and call chain information of each business interface to be tested is processed using a large model, including: The large model processes the source code of at least one method in the interface definition document, call chain information, and call chain information of each business interface to be tested.
5. The method of claim 4, wherein, Generate an interface definition document for any given business interface based on its interface information, including: Add the interface information of any of the business interfaces to the FreeMarker template to obtain the interface definition document of any of the business interfaces; The FreeMarker template defines the interface title, parameter table, example request, and example response.
6. The method of claim 1, wherein, Select at least one business interface to be tested, including: Obtain a coverage report for the source code; The target method is determined based on the coverage report, and the target method includes uncovered methods. The target method is retrieved from the call chain information corresponding to each business interface, and the business interface corresponding to the call chain information containing the target method is determined as the business interface to be tested.
7. The method of claim 1, wherein, Also includes: The generated interface test cases are validated using the interface information of the business interface to be tested, including: Based on the parameter information in the interface information, detect whether the interface test cases have introduced non-existent fields; Check if the field types match and if any required fields are missing; If the interface test case introduces a non-existent field, or the field type does not match the parameter type in the parameter information, or a required field is missing, the interface test case will fail the validation; otherwise, the interface test case will pass the validation.
8. An electronic device, comprising: The electronic device includes at least one processor and a memory connected to the processor; wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the interface test case generation method as described in any one of claims 1 to 7.
9. A computer program product, characterised in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the interface test case generation method as described in any one of claims 1 to 7.
10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the interface test case generation method as described in any one of claims 1 to 7.