A method for automatically updating test cases based on interface version management
By automating the generation and updating of test cases, the problem of low efficiency in manually writing test cases by testers is solved, and the efficiency and accuracy of interface version management are achieved. It is suitable for microservice architecture and API-driven development environments.
Patent Information
- Application Number
- CN202411520347.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-29
- Publication Date
- 2025-11-28
- Estimated Expiration
- 2044-10-29
AI Technical Summary
In existing technologies, testers need to manually write a large number of test cases, resulting in low work efficiency, especially when there are many interfaces and complex parameters, making it difficult to efficiently manage interface versions.
By loading configuration files, parsing Swagger documentation and generating test cases, monitoring document changes, automatically updating test cases, and using Python programs and libraries such as swagger-parser, watchdog, requests, BeautifulSoup, and smtplib, test reports can be automatically generated and sent.
It enables automated generation and updating of test cases, improving testing efficiency, reducing labor costs, and enhancing the efficiency and accuracy of interface version management and testing. It is suitable for software development projects with frequent updates.
Smart Images

Figure CN119415432B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application relates to the technical field of computers, in particular to a method for automatically updating test cases based on interface version management. BACKGROUND
[0002] Before carrying out project development, R&D personnel need to write interface documents, with the popularization of OpenAI specification, Swagger has entered the 3.x stage, Swagger 3.x refers to the Swagger tool version supporting OpenAPI 3.0 specification, and more emphasizes the support and standardization of RESTful API, provides more rich and flexible definition methods, and can be used for automatically generating documents, client code, server code and test tools and the like;
[0003] At present, most of the R&D personnel of companies write interface documents by using Swagger, and Swagger generates Swagger documents based on OpenAPI 3.0 version and above; a small part of R&D personnel write interface documents by using word documents, and test personnel rely on Swagger documents provided by development to write test cases; due to the large number of interfaces and complex parameters, test personnel need to manually write a large number of test cases, which is time-consuming and laborious, and the work efficiency is low. SUMMARY
[0004] The application aims at solving the problems in the prior art and provides a method for automatically updating test cases based on interface version management.
[0005] To achieve the above-mentioned purpose, the application adopts the following technical scheme:
[0006] A method for automatically updating test cases based on interface version management comprises the following steps:
[0007] S1: loading a configuration file;
[0008] The user customizes the configuration file, and the configuration file comprises a URL address of a Swagger document and basic environment information;
[0009] The configuration file is a JSON file that can be stored in a local computer by user customization;
[0010] The URL address of the Swagger document and the basic environment information are extracted by loading the configuration file through a Python program main entrance;
[0011] The Python program main entrance refers to an entrance file of a Python program, wherein the entrance file follows a specific naming rule.
[0012] S2: Obtain the Swagger document and generate a V1 version of the Swagger document;
[0013] Initiate an http request according to the URL address of the Swagger document in the configuration file, and obtain the Swagger document;
[0014] Save the obtained Swagger document to the local, and generate a document containing a V1 version identifier locally, the document having a unique file name;
[0015] The format of the file name is: version identifier + date + self-incrementing serial number.
[0016] S3: Analyze the Swagger document and generate test cases;
[0017] Use the swagger-parser library to parse the document containing the V1 version identifier generated in step S2 into a Python object, and extract API paths and request information from the parsed Python object;
[0018] The request information includes request methods, request parameters, expected results, etc.
[0019] Iterate through the parsed API paths and request information, and generate a unique ID as an identifier for each API interface;
[0020] Use the requests library to build interface test cases, each interface test case including API paths, unique IDs, request methods, request parameters, and expected results;
[0021] Save the built interface test cases to an interface test case set.
[0022] S4: Monitor changes in the Swagger document;
[0023] Including the following sub-steps:
[0024] S41: Listen to Swagger document update events;
[0025] Use the watchdog library to listen to Swagger document update events;
[0026] Specifically, create an observer class in the watchdog library, specify the Swagger document path to be listened to in the observer class, monitor the Swagger document, and override the on_modified function in the observer class; when the Swagger document is modified, the on_modified method is triggered, and step S42 is entered;
[0027] S42: Obtain the latest Swagger document and generate a V2 version of the document;
[0028] The modified Swagger document is obtained using an HTTP GET request, and the timestamp of the modified Swagger document is obtained using the datetime component of the python program, and the Swagger document is saved as a document containing a V2 version identifier;
[0029] The format of the file name is: version identifier + date + self-incrementing serial number;
[0030] S43: Check whether the API path and request information in the V1 and V2 versions of the Swagger document have changed;
[0031] The following sub-steps are included:
[0032] S431: Compare whether the API path has changed;
[0033] The V1 and V2 versions of the Swagger document are parsed using a JSON library, and the parsed Swagger document is traversed to extract the API path of the V1 and V2 versions of the Swagger document, respectively;
[0034] The API paths of the V1 and V2 versions of the Swagger document are compared to determine whether they are the same, and if they are different, the changed API path is recorded;
[0035] S432: Compare whether the request method has changed;
[0036] The V1 and V2 versions of the Swagger document are parsed using a JSON library, and the parsed Swagger document is traversed to extract the request method of the V1 and V2 versions of the Swagger document, respectively;
[0037] The request methods of the V1 and V2 versions of the Swagger document are compared to determine whether they are the same, and if they are different, the changed request method is recorded;
[0038] S433: Compare whether the request parameters have changed;
[0039] The V1 and V2 versions of the Swagger document are parsed using a JSON library, and the parsed Swagger document is traversed to extract the request parameters of the V1 and V2 versions of the Swagger document, respectively;
[0040] The request parameters of the V1 and V2 versions of the Swagger document are compared to determine whether they are the same, and if they are different, the changed request parameter is recorded;
[0041] S44: Update the interface test case;
[0042] In the interface test case set, update the interface test case of any change of API path, request method and request parameter.
[0043] S5: execute the interface test case;
[0044] The interface test case contained in the interface test case set is executed, and the execution result of each interface test case is recorded, the execution result is compared with the expected result, if they are inconsistent, the test result is a failure case; if they are consistent, the test result is a success case.
[0045] S6: generate and send a test report;
[0046] The test report in HTML format is created by BeautifulSoup, and the test report contains interface test cases, execution results and test results.
[0047] The test report is sent to relevant personnel in the form of email by using the smtplib component.
[0048] Compared with the prior art, the beneficial effects of the present application are:
[0049] The method for automatically updating test cases based on interface version management provided by the present application can automatically generate test cases by identifying and monitoring the changes of the document through the swagger document address, without the need for test personnel to manually write test cases, thereby improving the test efficiency, reducing the test time and reducing the labor cost.
[0050] The method provided by the present application can identify the version change of the test case interface, significantly improve the efficiency of interface version management and the accuracy of test work, and is suitable for software development projects that need to frequently update interface versions, especially in the development environment of micro-service architecture and API driving, and can significantly improve the efficiency and quality of interface management and testing. BRIEF DESCRIPTION OF DRAWINGS
[0051] Figure 1 The step flow chart of the method for automatically updating test cases based on interface version management. DETAILED DESCRIPTION
[0052] In order to further understand the purpose, structure, features and functions of the present application, the following detailed description is provided with examples.
[0053] As shown in Figure 1 A method for automatically updating test cases based on interface version management, comprising the following steps:
[0054] S1: load the configuration file;
[0055] a user-defined configuration file, the configuration file including a URL address of a Swagger document and basic environment information;
[0056] the configuration file being a JSON file stored in a local computer and being user-definable;
[0057] loading the configuration file and extracting the URL address of the Swagger document and the basic environment information by a Python program main entry;
[0058] the Python program main entry referring to an entry file of the Python program, wherein the entry file follows a specific naming rule.
[0059] S2: obtaining a Swagger document and generating a V1 version of the Swagger document;
[0060] initiating an http request according to the URL address of the Swagger document in the configuration file to obtain the Swagger document;
[0061] saving the obtained Swagger document to a local computer and generating a document including a V1 version identifier locally, the document having a unique file name;
[0062] the file name having a format of version identifier+date+incremental serial number, for example, V1_202409230001.
[0063] S3: parsing the Swagger document and generating test cases;
[0064] parsing the document including the V1 version identifier generated in step S2 into a Python object using a swagger-parser library, and extracting API paths and request information from the parsed Python object;
[0065] the request information including a request method, request parameters, and expected results;
[0066] iterating through the parsed API paths and request information, and generating a unique ID as an identifier for each API interface;
[0067] constructing interface test cases using a requests library, each interface test case including an API path, a unique ID, a request method, request parameters, and expected results;
[0068] saving the constructed interface test cases to a set of interface test cases.
[0069] S4: monitoring changes in the Swagger document;
[0070] including the following sub-steps:
[0071] S41: Listen to the Swagger document update event;
[0072] Listen to the Swagger document update event using the watchdog library;
[0073] Specifically, an observer class is created in the watchdog library, the Swagger document path that needs to be monitored is specified in the observer class, the Swagger document is monitored, and the on_modified function is overridden in the observer class; when the Swagger document is modified, the on_modified method is triggered, and step S42 is entered;
[0074] S42: Get the latest Swagger document and generate a V2 version of the document;
[0075] Use the HTTP GET request to get the modified Swagger document, and use the datetime component of the python program to get the timestamp of the modified Swagger document, and save the Swagger document as a document containing the V2 version identifier;
[0076] The format of the file name is: version identifier + date + incremental serial number, for example, V2_202409230001;
[0077] S43: Check if the API path and request information in the V1 and V2 versions of the Swagger document have changed;
[0078] Including the following sub-steps:
[0079] S431: Compare if the API path has changed;
[0080] Parse the V1 and V2 versions of the Swagger document using the JSON library, traverse the parsed Swagger document, and extract the API path of the V1 and V2 versions of the Swagger document, respectively;
[0081] Compare if the API paths of the V1 and V2 versions of the Swagger document are the same, if there are differences, record the changed API path;
[0082] S432: Compare if the request method has changed;
[0083] Parse the V1 and V2 versions of the Swagger document using the JSON library, traverse the parsed Swagger document, and extract the request method of the V1 and V2 versions of the Swagger document, respectively;
[0084] comparing the request methods of the Swagger documents of the V1 and V2 versions, and recording the changed request methods if there are differences;
[0085] S433: comparing whether the request parameters change;
[0086] The Swagger documents of the V1 and V2 versions are parsed using a JSON library, and the parsed Swagger documents are traversed to extract the request parameters of the Swagger documents of the V1 and V2 versions respectively;
[0087] comparing the request parameters of the Swagger documents of the V1 and V2 versions, and recording the changed request parameters if there are differences;
[0088] S44: updating the interface test cases;
[0089] The API path, request method, and request parameter of any changed interface test case in the interface test case set are updated.
[0090] S5: executing the interface test cases;
[0091] The interface test cases contained in the interface test case set are executed, and the execution results of each interface test case are recorded, and the execution results are compared with the expected results, if they are inconsistent, the test result is a failed case; if they are consistent, the test result is a successful case.
[0092] S6: generating and sending a test report;
[0093] An HTML format test report is created by using BeautifulSoup, and the test report contains the interface test cases, execution results, and test results;
[0094] The test report is sent to relevant personnel in the form of an email by using an smtplib component.
[0095] The present application can be easily integrated into the continuous integration / continuous deployment (CI / CD) process by combining the automatic generation of test cases with the automatic test framework; it is helpful to find and fix problems in the early stages of software development, and improve the speed and quality of software delivery; in addition, the automated test can also perform repeated tests to ensure the stability and reliability of the software in different environments.
[0096] The present application has been described by the above-mentioned related embodiments, however, the above-mentioned embodiments are only examples for implementing the present application. It must be pointed out that the disclosed embodiments do not limit the scope of the present application. On the contrary, modifications and improvements made without departing from the spirit and scope of the present application are within the scope of the patent protection of the present application.
Claims
1. A method for automatically updating test cases based on interface version management, characterized in that: The method comprises the following steps: S1: loading a configuration file; a user-defined configuration file, which comprises a URL address of a Swagger document and basic environment information; the configuration file is a JSON file stored in a local computer and is user-definable; the configuration file is loaded by a main entrance of a Python program, and the URL address of the Swagger document and the basic environment information are extracted; S2: obtaining a Swagger document and generating a V1 version of the Swagger document; an http request is initiated according to the URL address of the Swagger document in the configuration file, and the Swagger document is obtained; the obtained Swagger document is saved locally, and a document containing a V1 version identifier is generated locally, and the document has a unique file name; S3: parsing the Swagger document and generating test cases; the document containing the V1 version identifier generated in step S2 is parsed into a Python object by using a swagger-parser library, and API paths and request information are extracted from the parsed Python object; the request information comprises a request method, request parameters and expected results; the parsed API paths and request information are traversed, and a unique ID is generated as an identifier for each API interface; interface test cases are constructed by using a requests library, and each interface test case comprises an API path, a unique ID, a request method, request parameters and expected results; the constructed interface test cases are saved in an interface test case set; S4: monitoring changes in the Swagger document; the following sub-steps are included: S41: listening to a Swagger document update event; S42: obtaining a latest Swagger document and generating a V2 version of the document; S43: checking whether API paths and request information in the V1 and V2 versions of the Swagger document have changed; S44: updating interface test cases; in the interface test case set, interface test cases in which API paths, request methods or request parameters have changed are updated; S5: executing interface test cases; interface test cases included in the interface test case set are executed, and execution results of each interface test case are recorded, the execution results are compared with expected results, if the execution results are inconsistent with the expected results, a test result is a failure case, and if the execution results are consistent with the expected results, the test result is a success case; S6: generating and sending a test report.
2. The method for automatically updating test cases based on interface version management according to claim 1, wherein: in step S41, a watchdog library is used to listen to a Swagger document update event; specifically, an observer class is created in the watchdog library, the Swagger document path to be listened to is specified in the observer class, the Swagger document is monitored, and an on_modified function is rewritten in the observer class; when the Swagger document is modified, the on_modified method is triggered, and step S42 is entered.
3. The method for automatically updating test cases based on interface version management according to claim 1, wherein: In step S42, the modified Swagger document is obtained by using the HTTP GET request, and the timestamp of the modified Swagger document is obtained by using the datetime component of the python program, and the Swagger document is saved as a document containing the V2 version identifier.
4. The method for automatically updating test cases based on interface version management according to claim 1, wherein: Step S43 comprises the following sub-steps: The following sub-steps are included: S431: Compare whether the API path has changed; The Swagger documents of V1 and V2 versions are parsed by using the JSON library, the parsed Swagger documents are traversed, and the API paths of the Swagger documents of V1 and V2 versions are extracted respectively; The API paths of the Swagger documents of V1 and V2 versions are compared to determine whether they are the same, and if there is a difference, the changed API path is recorded; S432: Compare whether the request method has changed; The Swagger documents of V1 and V2 versions are parsed by using the JSON library, the parsed Swagger documents are traversed, and the request methods of the Swagger documents of V1 and V2 versions are extracted respectively; The request methods of the Swagger documents of V1 and V2 versions are compared to determine whether they are the same, and if there is a difference, the changed request method is recorded; S433: Compare whether the request parameter has changed; The Swagger documents of V1 and V2 versions are parsed by using the JSON library, the parsed Swagger documents are traversed, and the request parameters of the Swagger documents of V1 and V2 versions are extracted respectively; The request parameters of the Swagger documents of V1 and V2 versions are compared to determine whether they are the same, and if there is a difference, the changed request parameter is recorded.
5. The method for automatically updating test cases based on interface version management according to claim 1, wherein: In step S6, the test report in HTML format is created by using BeautifulSoup, and the test report contains the interface test cases, the execution results, and the test results; The test report is sent to the relevant personnel in the form of email by using the smtplib component.
Citation Information
Patent Citations
Swager annotation generation method and device, equipment and storage medium
CN115878175A
Method and device for automatically generating and executing interface test case and application of method and device
CN118689777A