Test case generation method and system, terminal and storage medium

Abstract

The invention provides a test case generation method and system, a terminal and a storage medium, and the method comprises the steps: obtaining a target Git code warehouse, scanning the target Git code warehouse to locate a source code file related to each API, analyzing the source code file to extract annotation information of each API, and storing the annotation information in the target Git code warehouse; and automatically generating a Mock data configuration file corresponding to each field according to field type information in the annotation information, randomly generating Mock data used for each API test and corresponding to each field based on the Mock data configuration file, and obtaining an API test case. According to the method, the Git code warehouse is automatically scanned, the annotation information is extracted, and the Mock data configuration file and the API test case are automatically generated, so that higher-degree automation is realized, the human error risk is reduced, the test coverage rate is greatly increased, and the flexibility of the test process is enhanced.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and particularly to a test case generation method, system, terminal and storage medium. Background Art

[0002] Currently, traditional automated test case generation usually relies on fixed rules and templates. For example, keyword extraction technology based on requirement documents identifies and parses specific vocabulary in functional requirements, and generates steps and expected results of test cases according to preset patterns. Additionally, some tools record users' operation behaviors based on software interface elements and operation processes, and convert them into repeatable test scripts. To a certain extent, this method realizes the automated generation of test cases. However, this method usually can only cover common functional paths and operation scenarios, and has limited ability to generate test cases for various combined conditions, abnormal situations and boundary values in complex systems, resulting in low test coverage, and many potential software defects are difficult to be discovered. That is, for complex business logics and changing system states, its flexibility and coverage are limited. Another example is in the model-based testing method, where an abstract model of a software system, such as a finite state machine model, a data flow model, etc., is constructed, and test cases are derived from the model. However, the model construction process may be complex and time-consuming, and for large systems, the model maintenance cost is high. That is, for the test case generation technology based on a fixed model, the model construction is complex and lacks flexibility. Once the system requirements change, the cost of modifying and maintaining the model is high, and it is difficult to quickly adapt to software iteration and update. In addition, in some existing test case generation technologies, historical test data is used for analysis and mining. By statistically learning from past successful and failed test cases, new test cases are attempted to be generated. However, this method may be affected by the limitations of historical data, and it is difficult to discover new potential problems and boundary situations. Moreover, most existing test case generation methods require manual intervention for rule formulation, model construction, and a large amount of manual adjustment and supplementation of the generation results. This not only consumes manpower and material resources, but also easily introduces human errors.

[0003] In summary, the existing test case generation technologies have problems such as incomplete test case coverage, poor flexibility, and high dependence on manual labor. Therefore, how to provide a solution to the above technical problems is what those skilled in the art need to solve currently. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a test case generation method, system, terminal and storage medium for the above-mentioned defects of the prior art, aiming to solve the problems of incomplete test case coverage, poor flexibility, and high dependence on manual labor in the prior art.

[0005] The technical solution adopted by the present invention to solve the technical problem is as follows:

[0006] A test case generation method, wherein the method includes:

[0007] Obtain a target Git code repository, and scan the target Git code repository to locate source code files related to each API;

[0008] Parse the source code files to extract annotation information of each API, and automatically generate a Mock data configuration file corresponding to each field according to the field type information in the annotation information;

[0009] Randomly generate Mock data corresponding to each field for testing each API based on the Mock data configuration file corresponding to each field, and obtain corresponding API test cases.

[0010] In one implementation, the scanning of the target Git code repository to locate source code files related to each API includes:

[0011] Use a preset Git scanning tool to automatically scan the target Git code repository to locate source code files related to each API.

[0012] In one implementation, the parsing of the source code files to extract annotation information of each API includes:

[0013] Use a preset syntax analysis and semantic understanding algorithm to parse the source code files to extract annotation information of each API.

[0014] In one implementation, the automatically generating a Mock data configuration file corresponding to each field according to the field type information in the annotation information includes:

[0015] Automatically generate a Mock data configuration corresponding to each field according to the field type information in the annotation information, and save the Mock data configuration as a file in the mock.js format to obtain the corresponding Mock data configuration file.

[0016] In one implementation, after automatically generating a Mock data configuration file corresponding to each field according to the field type information in the annotation information, it further includes:

[0017] Obtain metadata related to each API test, and store the metadata in a pre-constructed database; wherein the metadata includes data related to each API test in the annotation information and the Mock data configuration file.

[0018] In one implementation, the test case generation method further includes:

[0019] Group the APIs according to the API paths in the annotation information corresponding to each of the APIs to obtain a plurality of API test case groups.

[0020] In one implementation, after randomly generating Mock data corresponding to each field for testing each of the APIs based on the Mock data configuration file corresponding to each field to obtain corresponding API test cases, it further includes:

[0021] When the user triggers the API test case or the API test case group, use the Mock data to simulate real network requests and responses to obtain corresponding test results.

[0022] The present invention also discloses a test case generation system, wherein the system includes:

[0023] A code repository scanning module, configured to obtain a target Git code repository and scan the target Git code repository to locate source code files related to each API;

[0024] A code parsing module, configured to parse the source code files to extract the annotation information of each of the APIs;

[0025] A Mock data configuration generation module, configured to automatically generate a Mock data configuration file corresponding to each field according to the field type information in the annotation information;

[0026] A Mock data generation module, configured to randomly generate Mock data corresponding to each field for testing each of the APIs based on the Mock data configuration file corresponding to each field to obtain corresponding API test cases.

[0027] The present invention also discloses a terminal, which includes: a memory, a processor, and a test case generation program stored on the memory and executable on the processor. When the test case generation program is executed by the processor, the steps of the test case generation method described above are implemented.

[0028] The present invention also discloses a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program can be executed to implement the steps of the test case generation method described above.

[0029] A test case generation method, system, terminal, and storage medium provided by the present invention. The test case generation method includes: obtaining a target Git code repository, and scanning the target Git code repository to locate source code files related to each API; parsing the source code files to extract annotation information of each API, and automatically generating a Mock data configuration file corresponding to each field according to the field type information in the annotation information; randomly generating Mock data corresponding to each field for testing each API based on the Mock data configuration file corresponding to each field, to obtain corresponding API test cases. It can be seen that the present invention locates source code files related to each API by automatically scanning the code repository, parses the source code files to extract annotation information of the API, automatically generates a Mock data configuration file and API test cases according to the field type information in the annotation information, realizes a higher degree of automation, reduces manual operation links, and reduces the risk of human errors, thereby significantly reducing the time and cost of manually writing test cases. Among them, by automatically scanning the Git code repository, a comprehensive analysis of the API interface can be realized, so as to automatically generate more accurate API test cases, greatly improving the test coverage rate. And automatically generating a reasonable Mock data configuration file according to the field type information can ensure that the test parameter values in the API test cases conform to the actual business scenario, enhance the reliability of the test results, and can also realize that the Mock data configuration file can be dynamically adjusted according to the real-time changes of the source code files, effectively improving the adaptability to requirement changes, enhancing the flexibility of the test process, and also avoiding the cumbersome model reconstruction process. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 is a flowchart of a preferred embodiment of the test case generation method in the present invention;

[0031] Figure 2 is a logical schematic block diagram of a preferred embodiment of the test case generation method in the present invention;

[0032] Figure 3 is a functional principle block diagram of a preferred embodiment of the test case generation system in the present invention;

[0033] Figure 4 is a functional principle block diagram of a preferred embodiment of the terminal in the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0034] To make the objectives, technical solutions, and advantages of the present invention clearer and more definite, the following further describes the present invention in detail with reference to the accompanying drawings and by way of examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0035] Please refer toFigure 1 , Figure 1 is the flowchart of the test case generation method in the present invention. As Figure 1 shown, the test case generation method described in the embodiments of the present invention includes:

[0036] Step S11: Obtain a target Git code repository, and scan the target Git code repository to locate source code files related to each API.

[0037] In this embodiment, a specified Git code repository, that is, the target Git code repository, is selected, and then the target Git code repository is automatically scanned to locate source code files related to each API (Application Programming Interface). Specifically, a preset Git scanning tool is used to automatically scan the target Git code repository to locate source code files related to each API. It can be understood that by introducing Git scanning technology, various possible states and condition combinations of the system can be comprehensively analyzed, that is, a comprehensive analysis of the API is realized, so that API test cases with more accurate coverage can be automatically generated, greatly improving the test coverage rate.

[0038] For example, a customized Git scanning tool is used to traverse the code libraries in the Git code repository, so as to accurately locate source code files related to the API, such as code files and code segments related to the interface, which may specifically include, but are not limited to, interface definitions, function declarations, and routing configurations in various programming languages.

[0039] Step S12: Parse the source code files to extract annotation information of each API, and automatically generate a Mock data configuration file corresponding to each field according to the field type information in the annotation information.

[0040] In this embodiment, the source code files are parsed to extract the annotation information of each API. Specifically, a preset syntax analysis and semantic understanding algorithm is used to parse the source code files to extract the annotation information of each API, that is, a preset syntax analysis and semantic understanding algorithm is used to parse the code related to the interface to extract the key information (i.e., annotation information) of the interface, such as interface name, request method (HTTP method), parameter list (parameter name, data type, whether required, etc.), return value type, request body structure (field name, field type, whether required, etc.), path parameters, query parameters, etc. It can be understood that directly parsing the API and its field type and other information from the annotation information in the code can ensure that the generated test cases are highly consistent with the actual business logic. Compared with the traditional method that relies on documents or oral descriptions, it can more accurately reflect the actual behavior of the API and avoid test deviations caused by inconsistent information.

[0041] It should be noted that the key information of the interface extracted by the parsing code can also provide a comprehensive and accurate data source for the subsequent automatic generation of interface documents. For example, when a developer modifies the parameters or return value type of an interface, through the automatic generation tool, the interface document can be immediately updated under the next build or specific trigger conditions, keeping the document in sync with the code, so that the interface document can be updated in a timely manner when the code changes, which can improve the efficiency of document generation.

[0042] In this embodiment, after extracting the annotation information of each API by parsing the source code related to the API, the Mock data configuration corresponding to each field can be automatically generated according to the field type information in the annotation information, and the Mock data configuration is saved as a file in the mock.js format to obtain the corresponding Mock data configuration file. It can be understood that the Mock data configuration corresponding to each field is generated according to the extracted field type information, and then the generated Mock data configuration is saved as a file in the mock.js format to obtain the Mock data configuration file. That is to say, by analyzing the field type, a reasonable Mock data configuration is automatically generated, ensuring that the parameter values in the API test cases conform to the actual business scenarios, not only improving the test coverage rate, but also enhancing the reliability of the test results.

[0043] In this embodiment, after automatically generating the Mock data configuration file corresponding to each field according to the field type information in the annotation information, the metadata related to each API test can also be obtained and stored in a pre-constructed database; among them, the metadata includes the data related to each API test in the annotation information and the Mock data configuration file. That is to say, all the metadata related to API testing, such as API paths, methods, Mock configuration files, etc., are stored in a pre-constructed database to ensure the security and accessibility of the data, so as to provide persistent support for test case management and execution.

[0044] Step S13: Randomly generate Mock data corresponding to each field for each of the API tests based on the Mock data configuration file corresponding to each field, to obtain corresponding API test cases.

[0045] In this embodiment, Mock data corresponding to each field for API testing is randomly generated based on the Mock data configuration file corresponding to each field. It can be understood that by using the dynamic data generation strategy and according to the field type information in the parsed annotation information, intelligent generation of mock data based on the field type is realized. For example, for common basic data types such as integers, strings, and booleans, reasonable mock data can be generated according to their data ranges and common value-taking patterns; for complex data types such as arrays and objects, the corresponding mock data structures can be recursively generated according to the types of sub-fields, and example data that conforms to the business logic can be filled in. Among them, through the technical solution of this application, test cases covering various scenarios such as normal requests, abnormal requests, and boundary conditions can be automatically generated, so as to ensure that all functional points of the API are fully tested and verified.

[0046] And after generating mock data based on the Mock data configuration file corresponding to each field, it is also possible to further optimize and constrain the generated mock data according to the context information and business rules of the interface, so as to be able to provide high-quality mock data for interface testing, ensure that the testing can proceed smoothly without relying on the real backend service, speed up the testing speed, and improve the independence and repeatability of the testing.

[0047] In this embodiment, the APIs can also be grouped according to the API paths in the annotation information corresponding to each API to obtain multiple API test case groups. For example, the APIs are grouped according to the common prefix of the API paths to form multiple API test case groups. Among them, each API test case group contains a set of related API test cases, which helps to organize and manage a large number of test scenarios. Then, when the user triggers an API test case or an API test case group, the corresponding parameters are mocked according to the mock data configuration file to obtain Mock data, and the Mock data is used to simulate real network requests and responses to obtain the corresponding test results. That is to say, the user can select specific test cases or test case groups for execution, and during the execution process, the Mock data randomly generated based on the Mock data configuration file can be used to replace the actual parameter values to simulate real network requests and responses. After the test execution is completed, the corresponding test results are returned. Among them, the test results include information such as the success status or failure status, comparison between the expected result and the actual result, etc., so that the user can evaluate the quality of the API with the help of the test results, quickly locate problems, improve the debugging efficiency, and after the test is completed, the test cases and test results can also be stored in the database, thus providing a complete test history record, facilitating developers to trace the root cause of problems and optimize the API design.

[0048] It should be noted that once the API changes, such as being added, modified, or deleted, the Git code repository can be automatically rescanned and the corresponding test cases can be updated. That is, this application can also monitor in real time whether the API has changed, and trigger the rescan of the Git code repository and the update of the Mock data configuration file when the monitoring result indicates that the API has changed. Compared with the method of manually maintaining test cases, this application can keep the consistency between test cases and code in real time, reduce the maintenance cost, and is easy to maintain. Moreover, this application can be seamlessly integrated with version control systems such as Git, support the generation of test cases for code under different branches or tags, enabling developers to flexibly select test cases at different development stages to ensure that each version of the API can be fully tested and verified. Developers can also generate and execute test cases immediately after each code submission to promptly discover potential problems, enabling developers to complete multiple iterations in a short time, accelerating the development cycle, and improving the development speed. Multiple developers can also use this application to generate and execute test cases simultaneously without affecting each other, which helps team collaboration and improves the overall development efficiency.

[0049] It can be seen that in the embodiments of the present invention, by automatically scanning the code repository to locate the source code files related to each API and parsing the source code files to extract the annotation information of the API, and automatically generating the Mock data configuration file and API test cases according to the field type information in the annotation information, a higher degree of automation is achieved, reducing the manual operation links and the risk of human errors. Thus, the time and cost of manually writing test cases are significantly reduced, and a large number of high-quality test cases can be quickly generated, greatly improving the test efficiency. Among them, by automatically scanning the Git code repository, a comprehensive analysis of the API interface can be realized, thereby automatically generating more accurate API test cases to greatly improve the test coverage rate. And by automatically generating a reasonable Mock data configuration file according to the field type information, it can ensure that the test parameter values in the API test cases conform to the actual business scenarios, enhance the reliability of the test results, and can also realize that the Mock data configuration file can be dynamically adjusted according to the real-time changes of the source code files, effectively improving the adaptability to requirement changes, enhancing the flexibility of the test process, and also avoiding the cumbersome model reconstruction process.

[0050] For example, see Figure 2As shown in the figure, the user clicks the "Click to Enter" button on the front - end interface, thereby triggering the generation process of API test cases. Then, it starts to scan the Git code repository with the corresponding configuration, that is, connects to the specified Git code repository, and automatically scans the Git code repository to locate the source code files related to the APIs. Then, it parses the source code files to obtain the annotation information of the APIs. Then, according to the field type information in the annotation information, it generates reasonable Mock data configurations for each field, saves these Mock data configurations as files in the mock.js format to obtain Mock data configuration files, randomly generates Mock data corresponding to each field for each API test based on the Mock data configuration files to obtain the corresponding API test cases, thus completing the generation of test cases. Finally, when the user triggers an API test case or an API test case group, it mocks the corresponding parameters according to the Mock data configuration file to obtain Mock data, and uses the Mock data to simulate real network requests and responses to obtain the corresponding test results. That is to say, the user can select specific test cases or test case groups for execution, and during the execution process, it can use the Mock data randomly generated based on the Mock data configuration file to replace the actual parameter values, simulate real network requests and responses, and after the test execution is completed, it returns the corresponding test results (response results). It can be seen from this that the user only needs to click the "Enter" button once to automatically complete the whole process from code parsing to test case generation and provide instant feedback, which enables developers to conduct tests at any time during the development process, discover and fix problems in a timely manner. Moreover, through providing an intuitive user interface, the present application enables the user to trigger the entire test case generation and execution process with simple operations, which reduces the user's usage threshold and enables non - technical personnel to easily get started.

[0051] In one embodiment, as Figure 3 shown, based on the above - mentioned test case generation method, the present invention also correspondingly provides a test case generation system, including:

[0052] A code repository scanning module, configured to obtain a target Git code repository and scan the target Git code repository to locate the source code files related to each API;

[0053] A code parsing module, configured to parse the source code files to extract the annotation information of each API;

[0054] A Mock data configuration generation module, configured to automatically generate a Mock data configuration file corresponding to each field according to the field type information in the annotation information;

[0055] A Mock data generation module, which is used to randomly generate Mock data corresponding to each field for each of the API tests based on the Mock data configuration file corresponding to each field, and obtain corresponding API test cases.

[0056] For example, the test case generation system may further include a user interface module. The user interface module includes a "click to enter" button, which is used to start the entire process. That is, the user interface module can provide a user operation entry, allowing the user to trigger the generation process of API test cases. Then, through the code repository scanning module, it connects to a specified Git code repository to read and parse the source code files, thereby identifying and extracting annotation information related to the API. And through the Mock data configuration generation module, according to the extracted field type information, it generates corresponding Mock data configurations for each field, saves the generated Mock data configurations as files in the mock.js format to obtain the Mock data configuration files. Finally, through the Mock data generation module, it randomly generates Mock data corresponding to each field for each API test based on the Mock data configuration file corresponding to each field, and obtains corresponding API test cases. Moreover, the test case generation system may further include a database storage module, a test case grouping module, and a test execution module. Through the database storage module, it obtains metadata related to each API test and stores the metadata in a pre-constructed database. Through the test case grouping module, it groups each API according to the API path in the annotation information corresponding to each API to obtain multiple API test case groups. And through the test execution module, it executes the specific API test cases or API test case groups selected by the user. During the execution process, it can use the Mock data randomly generated based on the Mock data configuration file to replace the actual parameter values, simulate real network requests and responses. After the test execution is completed, it returns the corresponding test results, where the test results include information such as success status or failure status, comparison between expected results and actual results. Furthermore, the test case generation system can also be integrated with a continuous integration (CI, Continuous Integration) tool to implement an automated test process. Then, after each code submission, the system will automatically run all relevant test cases to ensure the stability and reliability of the API.

[0057] Figure 4 The structural schematic diagram of the terminal provided by the embodiment of the present application. The terminal may include:

[0058] A memory 501, a processor 502, and a computer program stored on the memory 501 and executable on the processor 502.

[0059] When the processor 502 executes the program, it implements the test case generation method provided in the above embodiment.

[0060] Furthermore, the terminal further includes:

[0061] A communication interface 503 for communication between the memory 501 and the processor 502.

[0062] A memory 501 for storing a computer program that can run on the processor 502.

[0063] The memory 501 may include a high-speed RAM memory and may also include a non-volatile memory, such as at least one disk memory.

[0064] If the memory 501, the processor 502, and the communication interface 503 are implemented independently, the communication interface 503, the memory 501, and the processor 502 can be interconnected through a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity, only one line is shown in the figure, but it does not mean that there is only one bus or one type of bus.

[0065] Optionally, in a specific implementation, if the memory 501, the processor 502, and the communication interface 503 are integrated on a single chip, the memory 501, the processor 502, and the communication interface 503 can communicate with each other through an internal interface.

[0066] The processor 502 may be a Central Processing Unit (CPU), or an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0067] This embodiment also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the above test case generation method is implemented.

[0068] Those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention, which follow the general principles of the present invention and include known common general knowledge or conventional technical means in the technical field not disclosed in this application. The specification and examples are only regarded as exemplary, and the true scope and spirit of the present invention are pointed out by the claims.

[0069] In the description of this specification, the descriptions referring to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0070] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a definite sequence list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can read and execute instructions from the instruction execution system, apparatus, or device), or in combination with these instruction execution systems, apparatus, or devices.

[0071] It should be understood that the various parts of this application can be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. If implemented by hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0072] It should be understood that the application of the present invention is not limited to the above examples. For those of ordinary skill in the art, improvements or transformations can be made according to the above description, and all such improvements and transformations should fall within the protection scope of the appended claims of the present invention.

Claims

1. A test case generation method, characterized in that, The method includes: Obtain a target Git code repository, and scan the target Git code repository to locate source code files related to each API; Parse the source code files to extract annotation information of each API, and automatically generate a Mock data configuration file corresponding to each field according to the field type information in the annotation information; Randomly generate Mock data corresponding to each field for testing each API based on the Mock data configuration file corresponding to each field, and obtain corresponding API test cases.

2. The test case generation method according to claim 1, wherein The scanning of the target Git code repository to locate source code files related to each API includes: Automatically scan the target Git code repository using a preset Git scanning tool to locate source code files related to each API.

3. The test case generation method according to claim 1, wherein The parsing of the source code files to extract annotation information of each API includes: Parse the source code files using a preset syntax analysis and semantic understanding algorithm to extract annotation information of each API.

4. The test case generation method according to claim 1, wherein The automatically generating a Mock data configuration file corresponding to each field according to the field type information in the annotation information includes: Automatically generate a Mock data configuration corresponding to each field according to the field type information in the annotation information, and save the Mock data configuration as a file in the mock.js format to obtain the corresponding Mock data configuration file.

5. The test case generation method according to claim 1, wherein After automatically generating a Mock data configuration file corresponding to each field according to the field type information in the annotation information, it further includes: Obtain metadata related to testing each API, and store the metadata in a pre-constructed database; wherein, the metadata includes data related to testing each API in the annotation information and the Mock data configuration file.

6. The test case generation method according to any one of claims 1 to 5, characterized in that, It further includes: Group each API according to the API path in the annotation information corresponding to each API to obtain multiple API test case groups.

7. The test case generation method according to claim 6, wherein After randomly generating Mock data corresponding to each field for testing each API based on the Mock data configuration file corresponding to each field to obtain corresponding API test cases, it further includes: When the user triggers the API test case or the API test case group, use the Mock data to simulate real network requests and responses to obtain corresponding test results.

8. A test case generation system, characterized in that, The system includes: A code repository scanning module, configured to obtain a target Git code repository, and scan the target Git code repository to locate source code files related to each API; A code parsing module, configured to parse the source code files to extract annotation information of each API; A Mock data configuration generation module, configured to automatically generate a Mock data configuration file corresponding to each field according to the field type information in the annotation information; The Mock data generation module is used to randomly generate Mock data corresponding to each field for each of the API tests based on the Mock data configuration file corresponding to each field, and obtain corresponding API test cases.

9. A terminal, characterized in that, It includes: A memory, a processor, and a test case generation program stored on the memory and executable on the processor. When the test case generation program is executed by the processor, it implements the steps of the test case generation method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, and the computer program can be executed to implement the steps of the test case generation method according to any one of claims 1 to 7.

Images