Micro-service architecture automated testing method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of software testing, in particular to a micro-service architecture automatic testing method and device, an electronic device and a storage medium, wherein a Swagger or OpenApi interface document is configured and parsed, the parsed interface definition is stored persistently, an interface test case is generated, and difference data is recorded when interface definition data is inconsistent; interface version regression is supported, an interface master table is updated, global variables are configured and response body data is extracted, an interface test case is arranged based on a business scenario, interface context dependency transmission is realized, a test suite timing or immediate execution task is set by using a Spring Boot timing task function, an interface test task is quickly executed, and test efficiency and accuracy are improved.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to an automated testing method, apparatus, electronic device, and storage medium for microservice architecture. Background Technology

[0002] With the rapid development of information technology, the functional requirements of application systems are increasing daily, and the complexity of system architecture and business load are also increasing significantly. Traditional monolithic architectures often exhibit problems such as insufficient flexibility and high maintenance costs when facing high concurrency and high scalability requirements. To improve system flexibility and scalability, microservice architecture technology effectively reduces the business complexity of the system and improves its maintainability and scalability by splitting the system into multiple loosely coupled, independently deployed services.

[0003] However, a system may contain dozens to hundreds of microservices, each of which may contain multiple interfaces. For example, a permissions microservice may contain around 30 interfaces, requiring testing of tens of thousands of interfaces. In some business scenarios, multiple interface dependencies are involved, making testing extremely difficult, resulting in inefficient test scenario construction and execution, and significantly increasing testing complexity. Summary of the Invention

[0004] To overcome the shortcomings of existing technologies, this invention provides an automated testing method, device, electronic device, and storage medium for microservice architectures, which can efficiently perform interface testing and support full-process automation from development and design to interface integration and business scenario testing, ensuring the overall quality and stability of the microservice system.

[0005] A first aspect of this application provides an automated testing method for microservice architecture, the method comprising:

[0006] Configure the access address of the target interface document, parse the target interface document to persistently store the parsed interface definition in the interface main table, and generate interface test cases based on the target interface document, wherein the target interface document is a Swagger interface document or an OpenAPI interface document;

[0007] When it is determined that there is a data inconsistency between the target interface document and the interface main table, the interface definition difference data is obtained and the interface definition difference data is stored in a temporary table.

[0008] When a specific interface version is determined to be regressed, the specific version information of the specific interface version is obtained and the specific version information is updated to the interface main table;

[0009] Configure the global variable {{}} for the interface, and extract the data from the request header or request body of the returned response body;

[0010] In the test suite, test cases for the interface are orchestrated based on business scenarios, and dependency propagation of the interface context is achieved using a variable passing mechanism.

[0011] Use the scheduled task feature of the Spring Boot framework to set up scheduled tasks for the test suite or provide an immediate execution option;

[0012] The interface test task can be executed quickly according to the scheduled execution task or the immediate execution option.

[0013] In an optional implementation, after storing the difference data in a temporary table, the method further includes:

[0014] When a user's instruction to update the main interface table is received, the interface definition difference data in the temporary table is updated to the main interface table;

[0015] Once the main table of the interface is updated, delete the interface definition difference data in the temporary table;

[0016] A version identifier is generated based on the current system time, and the updated interface definition data is persistently stored in the interface version table. The interface definition data includes the interface definition difference data and the unchanged data in the main interface table.

[0017] In an optional implementation, the method further includes:

[0018] When a change in the source interface definition is detected, the interface status of the source interface is obtained;

[0019] When the interface status is determined to be under development, the interface information is automatically updated to the automated testing platform.

[0020] When the interface status is determined to be in another state, a change label is marked and the user is prompted to confirm the change information to update the interface information. The other states include the testing state or the released state.

[0021] In an optional implementation, after extracting the request headers or request body data from the returned response body, the method further includes:

[0022] Determine whether the extracted data needs processing;

[0023] When it is determined that the extracted data needs to be processed, a built-in method is called in the parameters or message body, and the extracted data is processed according to the built-in method. The built-in method is a preset code logic module for implementing specific data processing functions. The parameters are the parameters passed when the interface is called, and the message body is the data carrier in the interface request or response.

[0024] In an optional implementation, before configuring the access address of the Swagger interface document, the method further includes: calling the OpenAPIParser component through a Spring Boot scheduled task to collect the target interface document in real time, and persistently storing the parsed interface definition data to a MySQL database.

[0025] In an optional implementation, the method further includes:

[0026] The test suite can be used to orchestrate business scenario test cases, supporting inter-suite calls and batch assertion configuration;

[0027] Multiple test suites are combined based on the test plan, and their execution is triggered by Spring Boot scheduled tasks to generate visual test reports.

[0028] A second aspect of this application provides an automated testing apparatus for microservice architectures, the apparatus comprising:

[0029] The interface document parsing module is used to configure the access address of the target interface document, parse the target interface document to persistently store the parsed interface definition in the interface main table, and generate interface test cases based on the target interface document. The target interface document is either a Swagger interface document or an OpenAPI interface document.

[0030] The consistency check module is used to obtain interface definition difference data and store the interface definition difference data in a temporary table when it is determined that there is a data inconsistency between the target interface document and the interface main table.

[0031] The version regression update module is used to obtain specific version information of a specific interface version when it is determined to regress a specific interface version, and update the specific version information to the interface main table;

[0032] The interface configuration module is used to configure the global variable {{}} for the interface and to extract data from the request header or request body of the returned response body;

[0033] The test suite orchestration module is used to orchestrate the interface test cases based on business scenarios in the test suite, and to realize the dependency propagation of the interface context using the variable passing mechanism.

[0034] The scheduled task configuration module is used to set up scheduled tasks for the test suite or provide immediate execution options through the scheduled task function of the Spring Boot framework;

[0035] The interface test task execution module is used to quickly execute interface test tasks according to the scheduled task execution option or the immediate execution option.

[0036] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the automated testing method for the microservice architecture.

[0037] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the above-described automated testing method for microservice architecture.

[0038] In summary, the microservice architecture automated testing method, apparatus, electronic device, and storage medium provided in this application have at least one of the following beneficial effects:

[0039] 1. By automatically parsing the interface documentation, the interface definition can be quickly obtained and corresponding test cases can be generated, avoiding the tediousness and error-proneness of manually writing test cases and improving the efficiency of test case generation.

[0040] 2. By monitoring the consistency between the interface documentation and the main interface table in real time, changes to the interface definition can be detected and handled in a timely manner, ensuring the consistency between test cases and interface definitions and avoiding test failures caused by interface changes;

[0041] 3. The version rollback function allows for easy rollback to historical version interface definitions for compatibility testing or problem reproduction, improving the flexibility and traceability of testing.

[0042] 4. By configuring global variables, data can be easily shared across multiple test cases, improving the reusability of test cases; at the same time, data extraction from the response body can provide data support for subsequent test verification.

[0043] 5. Through test suite orchestration, multiple related test cases can be combined into a test scenario to simulate real business scenarios; at the same time, by utilizing the variable passing mechanism, data transfer and dependency relationships between interfaces can be realized, improving the realism and effectiveness of the test scenario.

[0044] 6. The scheduled task function allows test suites to be executed periodically for automated testing; at the same time, the immediate execution option is provided to easily trigger test execution manually to meet different testing needs.

[0045] 7. By quickly executing interface testing tasks, interface problems can be discovered in a timely manner, improving testing efficiency and ensuring the accuracy and reliability of testing. Attached Figure Description

[0046] Figure 1This is a flowchart illustrating an automated testing method for microservice architecture according to an embodiment of this application;

[0047] Figure 2 This is a schematic diagram of an interface for visualizing interface information in an automated testing platform, as shown in an embodiment of this application.

[0048] Figure 3 This is a schematic diagram of an interface for comparing interface changes and visualizing version management in an automated testing platform, as shown in an embodiment of this application.

[0049] Figure 4 This is a schematic diagram of an interface for visualizing the restoration of historical modification information in an automated testing platform, as shown in an embodiment of this application.

[0050] Figure 5 This is a schematic diagram of one architecture of an API asset management and automated testing framework shown in an embodiment of this application;

[0051] Figure 6 This is a schematic diagram of the interface for visualizing iterative regression test cases in an automated testing platform, as shown in an embodiment of this application.

[0052] Figure 7 This is a schematic diagram of the interface for visualizing scenario regression test cases in an automated testing platform, as shown in an embodiment of this application.

[0053] Figure 8 This is a schematic diagram of a test report visualization interface in an automated testing platform, as shown in an embodiment of this application.

[0054] Figure 9 This is a second architectural diagram of an API asset management and automated testing framework shown in an embodiment of this application;

[0055] Figure 10 This is a functional block diagram of an automated testing method apparatus for microservice architecture shown in an embodiment of this application;

[0056] Figure 11 This is a schematic diagram of the structure of an electronic device shown in an embodiment of this application. Detailed Implementation

[0057] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0058] The following will clearly and completely describe the concept, specific structure, and technical effects of the present invention in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are all within the scope of protection of the present invention. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this invention can be combined interactively without contradicting each other.

[0059] Reference Figure 1 The diagram shown is a flowchart illustrating an automated testing method for microservice architecture according to an embodiment of this application. The automated testing method for microservice architecture includes the following steps.

[0060] S11, Configure the access address of the target interface document, parse the target interface document to persistently store the parsed interface definition in the interface main table, and generate interface test cases based on the target interface document.

[0061] The target interface documentation is either Swagger interface documentation or OpenAPI interface documentation, and both Swagger interface documentation and OpenAPI interface documentation are based on the OpenAPI specification.

[0062] In some embodiments, the electronic device can define the URL address of the Swagger interface document or OpenAPI interface document in a configuration file (e.g., application.yml) and periodically call a Swagger / OpenAPI document parsing tool (such as swagger-parser or openapi-generator). Then, it uses OpenAPIParser to parse the Swagger2 / 3 and OpenAPI interface definitions. The Swagger2 / 3 and OpenAPI interface definitions are pre-created by developers in the development tools, enabling the interface definitions to be quickly and accurately written into the automated testing platform, generating and updating automated test cases. Specifically, when Swagger interface document information is obtained, the electronic device can parse the Swagger interface document information according to the OpenAPI specification to determine the fields of the request body and response body in the Swagger interface document information. Test cases are then generated based on the request body fields, and the request body fields, response body fields, and test case records are stored in the database.

[0063] To better understand the inventive concept of this application, the target interface document in this embodiment is illustrated using the Swagger interface document as an example. The interface information refers to... Figure 2 As shown.

[0064] S12, when it is determined that there is a data inconsistency in the main table of the target interface document, obtain the interface definition difference data and store the interface definition difference data in a temporary table.

[0065] The electronic device can predefine a temporary table (such as api_change_temp) to store changed interface definitions. Fields may include, but are not limited to: id (primary key), doc_id (document identifier), field_name (field name), original_value (original main table value), new_value (parsed value), created_at (record time), and version_timestamp (timestamp for version recording). Each time an interface document is parsed, the electronic device can compare the current parsing result with the interface definitions already stored in the database to find inconsistencies. When inconsistencies are identified, they are designated as interface definition discrepancies. In this embodiment, the electronic device can compare the request body fields of the Swagger interface document with the request body fields in the database. If they are inconsistent, it indicates interface definition discrepancies, and the interface definition discrepancies data is stored in the temporary table, generating a unique version_timestamp, i.e., using the current timestamp in YYYYMMDDHHMMSS format.

[0066] In an optional implementation, after storing the difference data in a temporary table, the method further includes:

[0067] When a user's instruction to update the main interface table is received, the interface definition difference data in the temporary table is updated to the main interface table;

[0068] Once the main table of the interface is updated, delete the interface definition difference data in the temporary table;

[0069] A version identifier is generated based on the current system time, and the updated interface definition data is persistently stored in the interface version table. The interface definition data includes the interface definition difference data and the unchanged data in the main interface table.

[0070] In some embodiments, when the front-end page receives a "Confirm Update" button clicked by the user, i.e., receives an instruction to update the main interface table, it queries the temporary table based on the record ID or batch_id to obtain the fields to be updated and their new values. An UPDATE operation is then performed on the main interface table, updating the corresponding field values ​​to the new values, thereby updating the interface definition difference data in the temporary table to the main interface table. Once the main interface table update is complete, the corresponding data in the temporary table is deleted, a new version number is generated using the current system time (e.g., YYYYMMDDHHMMSS_V1), or a version number incremented based on business rules, and the record is updated in the interface version table. The fields in the interface version table may include, but are not limited to: id (primary key), doc_id (document identifier), field_name (field name), original_value (original value), new_value (new value), updated_at (update time), version_number (version number), and updated_by (operator). After updating the main table of the API, the updated content is inserted into the version table, including: document identifier, field name, original value, new value, update time, version number, and operator (which can be obtained from the user session). If updating the main table fails (e.g., due to database lock conflicts or field constraint conflicts), the operation is rolled back, temporary table records are retained, and an error message is returned to the front end to prompt the user.

[0071] The above optional implementation methods enable automatic detection of data inconsistencies, secure updates after user confirmation, and version traceability, ensuring the accuracy and maintainability of system data.

[0072] S13, when it is determined that a specific interface version is being returned, obtain the specific version information of the specific interface version and update the specific version information to the interface main table.

[0073] In some embodiments, users can specify the version number to be rolled back (e.g., version_id=123) or version timestamp (e.g., timestamp=2023-10-01 12:00:00) through a front-end interface or API call. The electronic device then queries the interface version table to check if the specific interface version exists, verifies its interface status, and inserts a snapshot of the current interface main table's data (e.g., all field values) into a temporary table, recording the backup timestamp to prevent data loss in the main table if the rollback operation fails. Next, it queries the interface version table for the target version's data records, ensuring that the fields in the version table correspond one-to-one with the fields in the main table. Then, it uses UPDATE or REPLACE INTO statements to overwrite the data in the main table with the data in the version table, inserting a new record into the interface version table to mark the rollback operation. After the rollback of the specific interface version is complete, it compares the main table data with the target version data to ensure the rollback result is correct. A visual interface is provided, allowing users to compare the differences between the main table data and the version table data before and after the rollback.

[0074] In some embodiments, once a successful rollback of a specific interface version is confirmed, the electronic device can notify relevant personnel (such as a data administrator) via email, SMS, or system message to inform them that the rollback operation is complete. Detailed information about the rollback operation (such as operation time, user, target version, and rollback result) will be recorded in the operation log for auditing and troubleshooting purposes. Figure 3 As shown. When an exception occurs during the backfilling of the main table or insertion into the version table (such as database connection interruption, field constraint conflict), the transaction is immediately rolled back to ensure that the main table data is not corrupted, and an error message is returned to the front end (e.g., "Rollback failed, version number 123 does not exist"), and the exception log is logged. See also... Figure 4 Users can also view past modifications through the automated testing platform and manually restore them.

[0075] Through the above optional implementation methods, the system can safely and efficiently implement interface version rollback operations while ensuring data integrity and traceability.

[0076] Refer to together Figure 5In some embodiments, the automated testing platform may include a collaborative project module, an API asset module, a test case management module, an automated regression module, and an API monitoring module. The collaborative project module includes a Warehouse Management System (WMS), a User Service System (USS), and a monitoring system. The API asset module displays different versions of API interfaces, including multiple versions from WMS and USS, and these API interfaces are managed and tested. The test case management module manages API test cases, including creating, editing, and deleting test cases, such as interface test case 01, interface test case 02, interface test case 03, and interface test case 04, all used to test the API. An automatic synchronization function synchronizes API assets and test cases and assembles them into a test suite for regression testing. The automated regression module demonstrates different test scenarios, including purchase order entry operations, APP order acceptance and cancellation closure, relationship alerts, and relationship queries. These scenarios are used for automated regression testing to ensure the stability and correctness of the API under different conditions. The API monitoring module showcases various aspects of API monitoring, including pipeline triggers, business interface monitoring, and infrastructure interface monitoring. It monitors API performance and health in real time, ensuring stable system operation. By visualizing a complete API lifecycle management process, it ensures API stability and reliability, and improves development efficiency and system performance through automated tools and processes.

[0077] S14, configure the global variable {{}} for the interface, and extract the data from the request header or request body of the returned response body.

[0078] Global variables can be of various types, including date, random character, custom, non-plaintext, and enumeration. In this embodiment, to define specifications and distinguish global variables, the electronic device can configure global variables {{}} on the interface. Different types and formats of test data are used to construct automated test cases, facilitating unified management of test data by testers. Global variables are referenced through {{}}. After configuring global variables {{}} on the interface to be tested, the electronic device can use JSONPath or regular expressions to extract request headers or request bodies from the returned response. JSONPath is suitable for JSON-formatted response bodies, quickly locating data through path expressions, while regular expressions are suitable for unstructured text, extracting target data through pattern matching. Specifically, the electronic device can locate target fields in the interface response, select the extraction method (JSONPath or regular expression) for extraction, and assign the extraction result to a global variable (such as {{user_id}}).

[0079] To extract information from the interface response body and facilitate referencing by dependent interfaces, the electronic device in this embodiment uses variable passing. Response headers can be extracted using key names, and the response body can be extracted using JSONPath or regular expressions. The data can then be referenced in the request headers, parameters, message bodies, and assertions of the next interface using `${}`. That is, when extracting response headers, values ​​can be directly obtained and stored as variables using header key names; when extracting the response body, data nodes can be located using JSONPath expressions or content can be matched using regular expressions.

[0080] In some embodiments, when sending interface data, the electronic device can use OkHttp3 to encapsulate the interface information and return the encapsulated information to the caller. Assertions can be performed on the response body and response headers. The response body assertions extract the actual results using regular expressions and JSONPath to determine if the actual results match the expected results. The response body also supports data structure assertions to assert the data type of the entire response body. Specifically, the response header assertions primarily extract the actual results by the header names and match them with the expected results. If a match is found, the test case execution is successful; otherwise, execution fails.

[0081] In an optional implementation, after extracting the request headers or request body data from the returned response body, the method further includes:

[0082] Determine whether the extracted data needs processing;

[0083] When it is determined that the extracted data needs to be processed, a built-in method is called in the parameters or message body, and the extracted data is processed according to the built-in method. The built-in method is a preset code logic module for implementing specific data processing functions. The parameters are the parameters passed when the interface is called, and the message body is the data carrier in the interface request or response.

[0084] Built-in methods are pre-defined code logic modules used to implement specific data processing functions. To reduce code obfuscation and provide testers with rich functionality to meet business scenario testing needs, built-in methods provide UUID, MD5, and DateToTimestamp methods, referenced as ${UUID()}. In some embodiments, after data extraction is complete, the electronic device can use the built-in method ${methodName()} to determine whether further processing is needed based on business requirements, such as if the login password is RSA encrypted. Specifically, the electronic device can determine whether the extracted data conforms to a specific format (e.g., JSON, XML), whether it contains certain key fields (e.g., status, error), and whether it meets business rules (e.g., whether it is empty, whether it exceeds a threshold). When it is determined that specific data requires further processing, the built-in method is directly called in the code, passing the extracted data as a parameter, or the corresponding built-in method is dynamically called based on the parameters or identifier in the message body via reflection or configuration mapping. The parameters are additional information passed during the API call, used to specify the calling method of the built-in method or provide necessary context. For example, specifying the processing method: `method_name="to_uppercase"`, and providing the encryption key: `key="my_secret_key"`. The message body is the data carrier in the API request or response, which may contain data that needs to be processed. For example, a request message body: `{"data": "hello world", "method": "to_uppercase"}`, and a response message body: `{"status": "success", "result": "HELLO WORLD"}`. Then, by extracting the data and method identifier from the message body and dynamically calling the built-in method in conjunction with the parameters, the extracted data can be processed.

[0085] Through the above optional implementation methods, flexible data processing logic is achieved by extracting data, determining processing requirements, and dynamically calling built-in methods.

[0086] S15, in the test suite, the test cases of the interface are orchestrated based on the business scenario, and the dependency propagation of the interface context is realized by using the variable passing mechanism.

[0087] In some embodiments, electronic devices can pre-build and define test plans, which consist of one or more test suites. Users can customize the execution time and the recipients of test report notifications. The automated testing platform's backend service will trigger the test using a Spring Boot scheduled task based on the user-defined time. Once the scheduled task completes, a test report will be generated, and relevant personnel will be notified. The test case management module orchestrates interface test cases according to business scenarios, and supports calls between test suites, as well as batch addition of request headers and assertions.

[0088] In API automated testing, test suites are used to orchestrate API test cases within business scenarios, and variable passing is used to implement context dependency propagation. Specifically, for electronic devices, the call order and dependencies between APIs can be analyzed. For example, after a user logs in, they obtain a token, which is then used to call other APIs. It's crucial to identify which API outputs need to be used as input parameters for other APIs; for instance, the token returned by the login API needs to be passed to subsequent APIs. Next, a test suite is created within a testing framework (such as Postman, JMeter, or Pytest) to organize the relevant API test cases. See also... Figure 6 By refining iterative use cases, the availability and reliability of the entire system are improved, and version iterations and updates enable the system to respond to business needs more quickly. (See also...) Figure 7 Using an interface composed of contexts, scenario regression can be performed according to project needs. This process is time-consuming and yields slow returns, but for continuously iterating versions, it can achieve high returns.

[0089] Furthermore, within each interface test case, data that needs to be passed to subsequent test cases is extracted, such as the token returned by the login interface. This extracted data is stored in variables provided by the test framework. For example, in Postman, `pm.environment.set()` or `pm.collectionVariables.set()` can be used to store variables; in Pytest, fixtures or global variables can be used. In dependent interface test cases, the previously stored variables are read as input parameters. Next, the test suite allows setting the execution order of interface test cases to ensure correct dependencies. For example, in Postman, the order can be adjusted by dragging and dropping test cases; in Pytest, `pytest.mark.dependency` can be used to manage dependencies. Then, parameterization techniques are used to provide different input data for the interface test cases to cover more business scenarios. Finally, the test suite is run to observe whether the execution order and dependency propagation of the interface test cases are correct. By checking the execution results of each interface test case, it is ensured that dependencies are passed correctly and the interface call is successful.

[0090] In some embodiments, electronic devices can optimize the design of test cases based on test results, reduce redundant code, improve testing efficiency, and regularly update test data to ensure the accuracy and reliability of test cases.

[0091] The above optional implementation methods can be used to orchestrate business scenarios for interface test cases in the test suite and use variable passing to achieve context dependency passing, thereby improving the efficiency and reliability of automated interface testing.

[0092] S16, using the scheduled task function of the Spring Boot framework, set up scheduled execution tasks for the test suite or provide an immediate execution option.

[0093] Spring Boot projects typically include scheduled task functionality by default (using the `spring-context` module), requiring no additional dependencies. Ensure the `@EnableScheduling` annotation is active (usually configured on the main startup class) and use the `@Scheduled` annotation to define the task's execution cycle, i.e., setting up scheduled task execution. This can include: fixed-frequency execution: `@Scheduled(fixedRate = 5000)` (executes every 5 seconds); fixed-delay execution: `@Scheduled(fixedDelay = 10000)` (executes 10 seconds after the previous task completes); Cron expressions: `@Scheduled(cron = "0 0 / 1 * * * ?")` (executes every minute), etc. Alternatively, a REST interface (e.g., ` / executeTestSuite`) can be provided to trigger the test suite's execution via an HTTP request, offering an immediate execution option. The test suite's execution method can be directly called within the interface implementation for manual triggering. In some embodiments, electronic devices can control the enabling / disabling of scheduled tasks through configuration files (e.g., `application.yml`), reading the configuration in the task method to dynamically control whether scheduled tasks are executed. The scheduled task execution or immediate execution option is executed through a test suite, sharing the same set of test logic to avoid code duplication. The scheduled task execution is only responsible for scheduling, while the immediate execution option, which is manually triggered, calls the same logic through an interface.

[0094] S17, quickly execute the interface test task according to the scheduled execution task or the immediate execution option.

[0095] In some embodiments, test tasks are executed concurrently through multiple processes (or threads) to fully utilize CPU and I / O resources and improve testing efficiency. Spring Boot itself does not directly provide multi-process support, but it can be achieved through Java concurrency tools (such as thread pools) or operating system-level process management. Specifically, the test suite is split into multiple independent test tasks, each task corresponding to the testing of one interface or a group of interfaces. For example, 100 interface test tasks can be split into 10 groups of 10 tasks each, and multi-process or multi-threaded solutions can be used to execute the interface test tasks. For multi-process solutions, electronic devices can use Java's ProcessBuilder or operating system commands (such as Runtime.getRuntime().exec()) to start child processes to execute test tasks. Each child process runs a test script independently, while the main process is responsible for collecting the results. For multi-threaded solutions, a thread pool (such as ExecutorService) is used to manage multiple threads, each thread executing one test task. The number of threads is reasonably set (e.g., CPU cores * 2) to avoid resource contention.

[0096] The above optional implementation methods enable automated scheduling and efficient execution of test suites. By combining scheduled tasks and manual triggering, both daily automation needs are met, and flexible manual testing scenarios are supported.

[0097] In an optional implementation, the method further includes:

[0098] When a change in the source interface definition is detected, the interface status of the source interface is obtained;

[0099] When the interface status is determined to be under development, the interface information is automatically updated to the automated testing platform.

[0100] When the interface status is determined to be in another state, a change label is marked and the user is prompted to confirm the change information to update the interface information. The other states include the testing state or the released state.

[0101] The automated testing platform is set up on an electronic device. In some embodiments, the electronic device can pre-define multiple interface states for the interface, including: under development, under testing, and released, with each interface state corresponding to different operation logic. The electronic device compares the fields of the Swagger interface document request body with the fields of the request body in the database in real time. If the interface information recorded in the database is inconsistent with the Swagger request body fields, it indicates that the Swagger interface document has changed, that is, the source interface definition has been changed. When it is determined that the source interface has changed, the interface state of the source interface is obtained. When the interface state is determined to be under development, the updated interface information is directly synchronized to the automated testing platform, and the change log is recorded after the update. When the interface state is under testing or other non-development states, a change label (e.g., "Added parameter", "Modified return value") is generated, and the change label is notified to the user in the form of a notification (e.g., email, pop-up window), requiring confirmation whether to update. Specifically, a change icon will appear in the interface list to let the user know which interfaces have changed, and clicking the change icon will display the change information in a pop-up window. After the user confirms, the interface information is updated and the log is recorded; if the user refuses, the current version remains unchanged.

[0102] Whenever the interface information changes, a new version is generated, recording the version number, changes, update time, and updater information, and a complete snapshot of the interface (e.g., in JSON / YAML format) is stored for recovery during rollback. The rollback function allows users to select any historical version to restore. After rollback, the current version number is updated to the selected version number, and the rollback operation log is recorded.

[0103] In an optional real-time mode, the method further includes:

[0104] The test suite can be used to orchestrate business scenario test cases, supporting inter-suite calls and batch assertion configuration;

[0105] Multiple test suites are combined based on the test plan, and their execution is triggered by Spring Boot scheduled tasks to generate visual test reports.

[0106] Each test suite corresponds to a business module or functional scenario, such as "user registration suite" or "order processing suite". Electronic devices can use test frameworks (such as JUnit and TestNG) to create test suite classes, define the test cases contained in the suite through annotations or configuration files, and achieve inter-suite collaboration through dependency injection or method calls. For example, the order processing suite depends on user data generated by the user registration suite and uses assertion libraries (such as AssertJ and Hamcrest) to batch verify multiple conditions.

[0107] Additionally, electronic devices can define test plans as collections of test suites, supporting combinations based on priority, environment, and other dimensions. Suite loading within the test plan can be dynamically performed using reflection or dependency injection frameworks (such as Spring). When executing automated API tests, scheduled tasks can be configured using Spring's `@Scheduled` annotation or the `TaskScheduler` interface, encapsulating the test plan execution logic and supporting concurrent suite execution. After automated API testing is complete, tools such as Allure and ExtentReports can be used to automatically generate corresponding test reports (which can be in HTML format) and visualize them. For example, test results can be displayed in charts, including the total number of test cases, test case skipping count, success rate, start time, execution time, and runtime environment. Downloading test reports, showing only failed test cases, is also supported. Figure 8 As shown.

[0108] Reference Figure 9 As shown, in some embodiments, the automated testing platform can display test reports, test execution, test suites, and test case management. Test reports can include different types of reports, such as interface test reports, performance test reports, data quality reports, and UI test reports, detailing test results and analysis. Test execution provides various methods and tools for test execution, including scheduled execution, direct execution, assertion logic, and variable management, supporting both automated and manual testing. Test suites are used to organize and execute a set of related test cases, including scenario coverage, data validation, multi-source validation, line-by-line validation, JSON comparison, regular expressions, and time comparison. Test case management provides functions such as test case creation, batch operations, manual creation, automatic entry, Swagger import, batch deletion, batch execution, and batch copying, supporting efficient management and maintenance of test cases.

[0109] Compared to manual API execution, this application achieves a 10-fold speed improvement in testing, significantly shortening the API testing cycle. Furthermore, it enables intuitive management of continuous API changes within microservices, allowing for timely detection and resolution of regression issues caused by API changes, ensuring software quality and business continuity. Simultaneously, it allows for early detection and resolution of API errors before business users, enabling testers to conduct automated API testing without writing code. This allows more testers to participate in automated testing practices, improving the team's overall testing capabilities, lowering the technical threshold, and reducing online bugs. The defect escape rate is reduced by an average of over 20%, significantly improving software quality. For API testing, this application utilizes frameworks such as Spring Boot, OkHttp3, Fastjson, Nacos, and Myatis, using a MySQL database and combining it with Redis and RocketMQ middleware. Multi-threaded concurrent processing of automated task execution enables automated API testing. For microservices with numerous and frequently updated APIs, it provides version rollback, change recording, and one-click triggering, thereby achieving management and large-scale automated testing of microservice APIs.

[0110] Reference Figure 10 The diagram shown is a functional block diagram of an automated testing device for microservice architecture according to an embodiment of this application.

[0111] In some embodiments, the microservice architecture automated testing device 10 may include multiple functional modules composed of computer program segments. The computer programs of each program segment of the microservice architecture automated testing device 10 may be stored in the memory of an electronic device and executed by at least one processor to perform (see details). Figure 1 (Description) Functionality of automated testing for microservice architecture. Based on the functions it performs, it can be divided into multiple functional modules. These modules may include: an interface document parsing module 101, a consistency check module 102, a version regression update module 103, an interface configuration module 104, a test suite orchestration module 105, a scheduled task configuration module 106, and an interface test task execution module 107. The term "module" in this application refers to a series of computer program segments that can be executed by at least one processor and perform a fixed function, stored in memory. In this embodiment, the functions of each module will be detailed in subsequent embodiments.

[0112] The interface document parsing module 101 is used to configure the access address of the target interface document, parse the target interface document to persistently store the parsed interface definition in the interface master table, and generate interface test cases based on the target interface document. The target interface document is a Swagger interface document or an OpenAPI interface document.

[0113] The consistency check module 102 is used to obtain interface definition difference data and store the interface definition difference data in a temporary table when it is determined that there is a data inconsistency between the target interface document and the interface main table.

[0114] The version regression update module 103 is used to obtain specific version information of the specific interface version when it is determined to regress to a specific interface version, and update the specific version information to the interface main table.

[0115] The interface configuration module 104 is used to configure the global variable {{}} of the interface and to extract the data of the request header or request body from the returned response body.

[0116] The test suite orchestration module 105 is used to orchestrate the interface test cases in the test suite based on the business scenario, and to realize the dependency propagation of the interface context using the variable passing mechanism.

[0117] The scheduled task configuration module 106 is used to set the scheduled execution tasks of the test suite or provide immediate execution options through the scheduled task function of the Spring Boot framework.

[0118] The interface test task execution module 107 is used to quickly execute the interface test task according to the scheduled execution task or the immediate execution option.

[0119] The consistency check module 102 is further configured to: when receiving a user's instruction to update the interface master table, update the interface definition difference data in the temporary table to the interface master table; when it is determined that the interface master table has been updated, delete the interface definition difference data in the temporary table; generate a version identifier based on the current system time, and persistently store the updated interface definition data in the interface version table, wherein the interface definition data includes the interface definition difference data and the unchanged data in the interface master table.

[0120] The version regression update module 103 is further configured to: when a change is detected in the source interface definition, obtain the interface status of the source interface; when the interface status is determined to be under development, automatically update the interface information to the automated testing platform; when the interface status is determined to be other status, mark a change tag and prompt the user to confirm the change information to update the interface information, wherein the other status includes under testing or released status.

[0121] The interface configuration module 104 is further configured to: determine whether the extracted data needs to be processed; when it is determined that the extracted data needs to be processed, call a built-in method in the parameters or message body, and process the extracted data according to the built-in method. The built-in method is a preset code logic module for implementing a specific data processing function. The parameters are the parameters passed when the interface is called, and the message body is the data carrier in the interface request or response.

[0122] The interface document parsing module 101 is further configured to: before configuring the access address of the Swagger interface document, the method further includes: calling the OpenAPIParser component through a Spring Boot scheduled task to collect the target interface document in real time, and persistently storing the parsed interface definition data to a MySQL database.

[0123] The test suite orchestration module 105 is also used to: orchestrate business scenario test cases through the test suite, support inter-suite calls and batch assertion configuration; combine multiple test suites based on the test plan, trigger execution through Spring Boot scheduled tasks, and generate visual test reports.

[0124] It should be understood that the various variations and specific embodiments of the microservice architecture automated testing method provided in the above embodiments are also applicable to the microservice architecture automated testing device of this embodiment. Through the foregoing detailed description of the microservice architecture automated testing method, those skilled in the art can clearly understand the implementation method of the microservice architecture automated testing device in this embodiment. For the sake of brevity, it will not be described in detail here.

[0125] See Figure 11 The diagram shown is a schematic representation of the structure of an electronic device according to an embodiment of this application. In a preferred embodiment of this application, the electronic device 11 includes a memory 111, at least one processor 112, and at least one communication bus 113.

[0126] Those skilled in the art should understand that Figure 11 The structure of the electronic device shown does not constitute a limitation of the embodiments of this application. It can be a bus structure or a star structure. The electronic device 11 may also include more or fewer other hardware or software than shown, or different component arrangements.

[0127] In some embodiments, the electronic device 11 is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital processors, and embedded devices. The electronic device 11 may also include user equipment, which includes, but is not limited to, any electronic product capable of human-computer interaction with a user via a keyboard, mouse, remote control, touchpad, or voice control device, such as a personal computer, tablet computer, smartphone, or digital camera.

[0128] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

[0129] The components described as separate parts may or may not be physically separate. The components shown as components may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the components can be selected to achieve the purpose of this embodiment according to actual needs.

[0130] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0131] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0132] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0133] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0134] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A microservices architecture automated testing method, characterized in that, The method includes: Configure the access address of the target interface document, parse the target interface document to persistently store the parsed interface definition in the interface main table, and generate interface test cases based on the target interface document, wherein the target interface document is a Swagger interface document or an OpenAPI interface document; When it is determined that there is a data inconsistency between the target interface document and the interface main table, the interface definition difference data is obtained and stored in a temporary table; the interface definition difference data is inconsistent data; when a user's instruction to update the interface main table is received, the interface definition difference data in the temporary table is updated to the interface main table; when it is determined that the interface main table update is complete, the interface definition difference data in the temporary table is deleted; a version identifier is generated based on the current system time, and the updated interface definition data is persistently stored in the interface version table, the interface definition data including the interface definition difference data and the unchanged data in the interface main table; When a specific interface version is determined to be rolled back, the specific version information of the specific interface version is obtained and updated to the interface main table. This includes: querying the interface version table to see if the specific interface version exists and verifying the interface status; inserting a data snapshot of the current interface main table into a temporary table and recording the backup timestamp; querying the specific version information of the specific interface version from the interface version table; and using an UPDATE or REPLACE INTO statement to overwrite the specific version information of the specific interface version into the interface main table, and inserting a new record in the interface version table to mark the rollback operation. Configure the global variable {{}} for the interface, and extract data from the request header or request body of the returned response body; determine whether the extracted data needs to be processed; when it is determined that the extracted data needs to be processed, call the built-in method in the parameters or message body, and process the extracted data according to the built-in method. The built-in method is a preset code logic module for implementing specific data processing functions. The parameters are the parameters passed when the interface is called, and the message body is the data carrier in the interface request or response. In the test suite, test cases for the interface are orchestrated based on business scenarios, and dependency propagation of the interface context is achieved using a variable passing mechanism. Use the scheduled task feature of the Spring Boot framework to set up scheduled tasks for the test suite or provide an immediate execution option; The interface test task can be executed quickly according to the scheduled execution task or the immediate execution option.

2. The automated testing method for microservice architecture according to claim 1, characterized in that, The method further includes: When a change in the source interface definition is detected, the interface status of the source interface is obtained; When the interface status is determined to be under development, the interface information is automatically updated to the automated testing platform. When the interface status is determined to be in another state, a change label is marked and the user is prompted to confirm the change information to update the interface information. The other states include the testing state or the released state.

3. The automated testing method for microservice architecture according to claim 1, characterized in that, Before configuring the access address of the Swagger interface document, the method further includes: calling the OpenAPIParser component through a Spring Boot scheduled task to collect the target interface document in real time, and persistently storing the parsed interface definition data to a MySQL database.

4. The automated testing method for microservice architecture according to claim 1, characterized in that, The method further includes: The test suite can be used to orchestrate business scenario test cases, supporting inter-suite calls and batch assertion configuration; Multiple test suites are combined based on the test plan, and their execution is triggered by Spring Boot scheduled tasks to generate visual test reports.

5. An automated testing device for microservice architecture, characterized in that, The device includes: The interface document parsing module is used to configure the access address of the target interface document, parse the target interface document to persistently store the parsed interface definition in the interface main table, and generate interface test cases based on the target interface document. The target interface document is either a Swagger interface document or an OpenAPI interface document. The consistency check module is used to, when it is determined that there is a data inconsistency between the target interface document and the interface main table, obtain the interface definition difference data and store the interface definition difference data in a temporary table; the interface definition difference data is inconsistent data; when a user's instruction to update the interface main table is received, the interface definition difference data in the temporary table is updated to the interface main table; when it is determined that the interface main table has been updated, the interface definition difference data in the temporary table is deleted; a version identifier is generated based on the current system time, and the updated interface definition data is persistently stored in the interface version table, the interface definition data including the interface definition difference data and the unchanged data in the interface main table; The version rollback update module is used to obtain specific version information of a specific interface version when it is determined to roll back to a specific interface version, and update the specific version information to the interface main table. This includes: querying the interface version table to see if the specific interface version exists and verifying the interface status; inserting a data snapshot of the current interface main table into a temporary table and recording the backup timestamp; querying the specific version information of the specific interface version from the interface version table; and using an UPDATE or REPLACE INTO statement to overwrite the specific version information of the specific interface version into the interface main table, inserting a new record in the interface version table, and marking the rollback operation. The interface configuration module is used to configure the global variable {{}} for the interface and extract data from the request header or request body of the returned response body; determine whether the extracted data needs to be processed; when it is determined that the extracted data needs to be processed, a built-in method is called in the parameters or message body, and the extracted data is processed according to the built-in method. The built-in method is a preset code logic module for implementing specific data processing functions. The parameters are the parameters passed when the interface is called, and the message body is the data carrier in the interface request or response. The test suite orchestration module is used to orchestrate the interface test cases based on business scenarios in the test suite, and to realize the dependency propagation of the interface context using the variable passing mechanism. The scheduled task configuration module is used to set up scheduled tasks for the test suite or provide immediate execution options through the scheduled task function of the Spring Boot framework; The interface test task execution module is used to quickly execute interface test tasks according to the scheduled task execution option or the immediate execution option.

6. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the microservice architecture automated testing method according to any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the microservice architecture automated testing method according to any one of claims 1 to 4.

Images