A method and system for scenario-based automated continuous testing of microservice continuous integration

Abstract

The present invention belongs to the field of software testing technology, and discloses a method and system for scene-based automated continuous testing of microservice continuous integration. The method includes: API interface management, test data preparation management, storage management of parameters of different deployment environments and test data of each environment, including deployment address information and global parameter configuration of test data; scene-based automated script management, test strategy management, continuous integration test execution, monitoring and reporting. The present invention reduces labor costs, automates scenarios for business use cases, and conducts online scheduled inspections around automation or implements automated access control. Coding efficiency, readability, and visual reporting; microservice landing quality assurance strategy, reducing later regression testing and maintenance costs.

Description

Technical Field

[0001] The present invention belongs to the technical field of software testing, and in particular, relates to a method and system for scenario-based automated continuous testing of microservice continuous integration. Background Art

[0002] The large-scale information system of the airport adopts the distributed microservice SpringCloud architecture. There are many registered microservices, and the developers are relatively scattered. The code integration and release deployment process adopts the continuous integration (CI) and continuous deployment (CD) methods. The code changes of each service will affect the overall system function. The traditional system test is to design test cases through the business system interface document and manually perform business process function tests. The testers need to spend a lot of time and energy to execute the test cases of each business scenario of the system, and the efficiency is low. It cannot meet the requirements of synchronous continuous testing (CT). It is also impossible to quickly complete the smoke test for switching to different airport environment deployment systems. The airport core information system has high business accuracy requirements for the normal flow and abnormal flow of the system scenario. The continuous testing of the continuous integration and deployment of the system to ensure the availability of the system is a problem to be solved.

[0003] Therefore, finding a microservice continuous integration automated testing method based on interface documents that can not only meet the needs of system continuous testing but also reduce risks and costs, complete scenario testing of the airport's core business system and intuitively see the test results is a problem that needs to be solved. Summary of the invention

[0004] To overcome the problems existing in the related art, the disclosed embodiments of the present invention provide a method and system for automated continuous testing of microservice continuous integration scenarios, and specifically relate to a method for automated continuous testing of microservice continuous integration scenarios based on interface documents.

[0005] The technical solution is as follows: A method for automated continuous testing of microservice continuous integration scenarios, including:

[0006] S1, API interface management, import the swagger interface documents of each microservice of the airport information system into the API interface management module. The API interface management module automatically generates API test cases by importing interface information, and automatically distinguishes interfaces that display post, put, del, and get attributes;

[0007] S2, test data preparation management, storage management of parameters of different deployment environments and test data of each environment, including deployment address information and test data global parameter configuration;

[0008] S3, scenario automation script management, imports automatically generated API test cases in the API interface management module, and combines scenario test cases according to the needs of the business system;

[0009] S4, test strategy management, formulates different automation execution strategies according to the business characteristics and interface ownership of each service in the microservice architecture;

[0010] S5, continuous integration test execution, configure Jenkins and Eolink's open API, set trigger conditions, build steps and test tasks, integrate Eolink's scenario automation scripts into the continuous integration pipeline, and configure triggers to support triggering builds after code submission;

[0011] S6, monitoring and reporting, collects and analyzes test results by configuring an automated test reporting platform, and continuously monitors single interfaces and API comprehensive monitoring through the API monitoring mechanism.

[0012] In step S1, the query parameters of the API test case automatically generate test preview data, the interface parameter data automatically generates preview data selection in various forms according to the interface requirements, and the request parameters and the normal flow and abnormal flow test data of the test case are manually edited.

[0013] In step S2, the global parameter configuration is managed by static storage and dynamic database query. The static storage method supports the storage of variable name and variable value mapping relationship. The dynamic database query method uses the front-script SQL logical query statement to store the input parameter global variable values ​​used by the interface use cases in different environment databases according to the environment address mapping relationship deployed at different airports. By comparing the use scenario of the test data, the test parameter management module is used to formulate the data object address and version in the test data preparation management module in the interface test case, and then the corresponding data is automatically obtained for testing during the test execution process.

[0014] In step S3, each scenario use case is composed of multiple interface steps, and the step type selects the post, put, get, delete, and patch interface types; the interface step binds the API or a new API that is not in the API interface management module, and the request parameters of the interface automation script are written according to the parameters in the interface document. The parameter variables in the test environment parameter management module are supported in the request body. The response result of the scenario script interface is parameterized by the post-script global variables, and the subsequent interface obtains the parameterized global variables through the pre-script to realize interface automation. Specifically, the subsequent interface writes and obtains the global variables in the pre-script of the interface, and the obtained global variables are used as the input parameters of this interface to execute this interface and output the interface execution results. The global variables are set in the following way:

[0015] var res=eo.json.decode(eo.http.response.get());

[0016] eo.globals.set("inid",res[0]).

[0017] Furthermore, the success or failure of script execution is judged by assertion. The assertion rules support multiple verification rules for http status code and response body. The status code is matched by the server status code. The response body verification method supports multiple verification methods such as jsonPath matching, xPath matching, json document structure verification, full-text matching, and regular expression matching. The matching verification of jsonPath, xPath, and json document structure uses json script to match the structure content in the label of the response result. If the match passes, the use case execution passes.

[0018] In step S4, different automated execution strategies are formulated according to the business characteristics and interface ownership of each service in the microservice architecture, including: adding the scenario use cases written in the scenario automation script management module to the test plan in the test strategy management module, supporting different environment addresses to execute different automated test strategies, automatically introducing the environment address maintained in the test environment parameter management module, combining test cases according to different deployment environments and business scenarios of the microservice architecture, the system automatically supports sharing cookies between use cases, and configuring different test environments to execute different automated execution test methods, including serial testing, parallel testing, and multi-environment execution. Serial testing is the sequential execution of execution results constrained by different use cases, parallel testing is the parallel execution of low-coupling use cases that do not depend on each other's execution results, and multi-environment execution is the simultaneous execution of automated scenario tests by different test environment addresses;

[0019] According to the nature of the interface, check the execution mode of the automated use case in the system, choose serial automated execution or parallel automated execution, and cooperate with the system's release requirements, combined with the settings of continued integration, to implement the automatic execution of the smoke automated test strategy after the integration deployment, and to implement the automated execution strategy of regular online inspections. The scenario automated test strategies include: scheduled execution strategy, which automatically runs test cases according to a predetermined schedule, which is suitable for continuous integration and monitoring requirements; triggered execution strategy: when specific events such as code submission and build completion occur, the test execution is automatically triggered to ensure fast feedback; concurrent execution strategy: in order to speed up the testing process, multiple test cases or test suites are run at the same time; phased execution strategy: test cases are divided into different stages of unit testing, integration testing, and system testing, and executed in sequence or conditionally; data-driven execution strategy: use different data sets to execute the same test script multiple times to increase test coverage; failure retry strategy: for tests that fail accidentally, set a retry mechanism to distinguish real problems from temporary failures.

[0020] In step S5, configure triggers to support triggering builds after code submission, including setting build plans, supporting daily build execution, regular build execution, smoke test execution, regression test execution, and adding build steps to execute automated tests;

[0021] By implementing triggers through scripting, when the code is submitted, the trigger script is used to automatically build the relevant interfaces and trigger the execution of the automation strategy. In other words, through the trigger execution strategy, the script execution is automatically triggered by code submission, ensuring fast feedback.

[0022] Furthermore, configuration triggers support triggering a build after code submission, including processing steps to process and parse the results generated by Eolink automated testing, including running test suites to execute scenario automation scripts, dividing automated tests into multiple independent test suites, and executing them in parallel on multiple test environments.

[0023] In step S6, single interface and API comprehensive monitoring are continuously monitored through the API monitoring mechanism, including: single interface monitoring is used to monitor the performance and availability of a single interface, API comprehensive monitoring monitors the response time of script execution and interface operation status in the entire scenario automation process in real time, and directly locates the problem of the failed interface through monitoring, and the error information is output to the log, and the log states the detailed interface information; and the failed interface is retried through the automated strategy of failed retries to distinguish real problems from temporary failures. The results generated by the Eolink test are configured to be processed and parsed in the continuous integration test module. The Eolink test is executed through the automated phased execution strategy, and the next phase of the integration strategy is triggered. If the Eolink test fails, there will be specific execution log information, and an email notification mechanism is set to send a notification after the test is completed.

[0024] Another object of the present invention is to provide a scenario-automated continuous testing system for microservice continuous integration, which implements the scenario-automated continuous testing method for microservice continuous integration, and the system includes:

[0025] API interface management module, which is used to import the project interface documents of the microservice architecture system through Eolink, supports swagger format and YApi format, automatically generates API test cases after importing, and edits normal flow and abnormal flow in the automatically generated test cases;

[0026] The test data preparation management module includes centralized management of test environment parameters and test data, storage and management of parameters of different deployment environments, and storage of global variable values ​​of input parameters used by interface test cases in different environment databases through SQL. It supports version management of the same data object to meet the needs of different versions of test cases and test scripts.

[0027] The scenario automation script management module is used to import the API interface management module into the automatically generated API test cases to combine scenario cases according to the needs of the business system;

[0028] The test strategy management module is used to formulate different automation execution strategies according to the business characteristics and interface ownership of each service in the microservice architecture, and deploy different services to execute different automation test strategies;

[0029] The continuous integration test module is used to configure continuous integration with Jenkins through Eolink's open API and set trigger strategies to trigger the build process to execute scenario automated testing;

[0030] The monitoring and reporting module is used to collect, store and display automated test reports through Eolink's test report configuration, monitor the automated test running process, including the execution pass status and running time of each interface, and automatically notify team members after the test is completed in combination with the notification mechanism of the continuous integration test module.

[0031] Furthermore, in the scenario automation script management module, each use case scenario is composed of multiple interface steps, the interface steps are bound to APIs, the scenario scripts are implemented in the interface steps, the response results of the scenario script interfaces are parameterized as global variables through post-scripts, and the subsequent interfaces obtain the parameterized global variables through pre-scripts to realize interface automation;

[0032] In the continuous integration test module, the build step includes processing steps to process and parse the results generated by Eolink automated testing.

[0033] Combining all the above technical solutions, the beneficial effects of the present invention are as follows: the present invention reduces labor costs, automates use cases, and conducts online scheduled inspections or realizes automated access control. Coding efficiency, readability, and visual reports; microservice implementation quality assurance strategy reduces later integration and maintenance costs.

[0034] The purpose of the present invention is to solve the problem of continuous testing of continuous integration and deployment of microservice architecture system. For the system of microservice SpringCloud architecture, there are many system services. Unlike the traditional integrated architecture, which has serious business coupling and needs whole package deployment to implement the system dimension testing strategy, the microservice architecture can be independently deployed and run by individual services. The code submission and release deployment process adopts continuous integration and continuous deployment, so the interface testing of independent services should also be carried out earlier and more frequently, which requires continuous testing to improve the release efficiency. The traditional integrated system test is to manually execute a large number of system-level test cases after the whole package is deployed to verify whether the release deployment is successful or not. This method has high labor cost and low execution efficiency, and cannot meet the continuous testing of daily continuous integration, nor can it issue an intuitive test report. When the system switches the environment for deployment, it needs to be retested manually, which is labor-intensive. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings herein are incorporated in and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description, serve to explain the principles of the present disclosure;

[0036] Figure 1 It is a schematic diagram of a scenario-automated continuous testing system for microservice continuous integration provided by an embodiment of the present invention;

[0037] Figure 2It is a flow chart of a method for automated continuous testing of microservice continuous integration scenarios provided by an embodiment of the present invention;

[0038] Figure 3 It is a schematic diagram of a method for automated continuous testing of microservice continuous integration scenarios provided by an embodiment of the present invention;

[0039] Figure 4 It is an overall example structure diagram of an exemplary specific implementation practice provided by an embodiment of the present invention;

[0040] In the figure: 1. API interface management module; 2. Test environment parameter management module; 3. Scenario automation script management module; 4. Test strategy management module; 5. Continuous integration test module; 6. Monitoring and reporting module. DETAILED DESCRIPTION

[0041] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention, so the present invention is not limited by the specific implementation disclosed below.

[0042] The innovation of the present invention is that the present invention provides a method for writing interface use cases based on interface documents and realizing continuous automated testing through continuous integration that is applicable to microservice architecture. The method imports swagger interface documents through the Eolink tool to manage API interfaces, maintains different deployment environment addresses and parameters through the environment management module, implements automated scripts for test cases based on API management, and writes business scenarios according to business scenarios to make the business scenarios covered by automated testing more comprehensive, post-scripts and pre-scripts process and transfer interface parameters, assert encapsulates and realizes comparison of interface response content, ensures the quality of automated testing of business scenarios, realizes automated testing execution after each deployment and release through open API and Jenkins continuous integration, completes automated testing access control, completes online scheduled inspections by setting the automated test run time, and automatically exports visual test reports after automated testing is executed according to the report module settings.

[0043] Embodiment 1, as Figure 1As shown, the scenario-automated continuous testing system for continuous integration of microservices provided by an embodiment of the present invention imports the project interface document through the API interface management module to automatically generate API test cases, writes interface automation scripts based on the scenario flow of the business system according to the API test cases, and implements automated testing after each deployment and release according to the test strategies executed in different scenarios and through Jenkins continuous integration. It can also set scheduled execution to realize online inspection and realize the export and viewing of visual test reports after each automated execution.

[0044] The system includes: an API interface management module 1, a test environment parameter management module 2, a scenario automation script management module 3, a test strategy management module 4, a continuous integration test module 5, and a monitoring and reporting module 6.

[0045] API interface management module 1, imports the project interface documents of the microservice architecture system through Eolink, supports swagger format, YApi format, etc., automatically generates API test cases after importing, and can edit normal flow and abnormal flow in the automatically generated test cases;

[0046] Test data preparation management module 2, including centralized management of test environment parameters and test data, storage and management of parameters of different deployment environments, and storage of global variable values ​​of input parameters used by interface test cases in different environment databases queried through SQL, supporting version management of the same data object to meet the needs of different versions of test cases and test scripts;

[0047] Scenario automation script management module 3, imports the API interface management module into the automatically generated API test cases to combine scenario cases according to the needs of the business system. Each use case scenario is composed of multiple interface steps. The interface steps are bound to the API, and the scenario script is implemented in the interface steps. The response result of the interface of the scenario script is parameterized as a global variable through the post-script. The subsequent interface obtains the parameterized global variable through the pre-script to realize interface automation;

[0048] Test strategy management module 4, according to the business characteristics and interface ownership of each service in the microservice architecture, formulates different automation execution strategies, and deploys different services to execute different automation test strategies;

[0049] Continuous integration test module 5, through Eolink's open API and Jenkins continuous integration configuration, set the trigger strategy to trigger the build process to perform scenario automated testing, and include processing steps in the build step to process and parse the results generated by Eolink automated testing;

[0050] The monitoring and reporting module 6 collects, stores and displays automated test reports through Eolink's test report configuration. It can monitor the automated test running process, including the execution pass status and running time of each interface, and automatically notify team members after the test is completed in combination with the notification mechanism of the continuous integration test module.

[0051] Embodiment 2, as Figure 2 As shown, the present invention provides a method for performing scenario automated continuous testing on a continuously integrated microservice architecture system based on an interface document, and the specific steps are as follows:

[0052] S1, API interface management, import the swagger interface documents of each microservice of the airport information system into the API interface management module. The API interface management module automatically generates API test cases by importing interface information, and automatically distinguishes interfaces that display post, put, del, and get attributes;

[0053] The query parameters of the test case can automatically generate test preview data. The interface parameter data can automatically generate preview data in various forms according to the interface requirements. You can manually edit the request parameters and the normal flow and abnormal flow test data of the test case.

[0054] S2, test data preparation management, storage management of parameters of different deployment environments and test data of each environment, including deployment address information and test data global parameter configuration;

[0055] Different airports have different environment addresses, and support the maintenance of protocol environment address parameters such as http protocol address, websocket protocol address, dubbo protocol address, etc. Global parameter configuration can be managed through static storage and database dynamic query. The static storage method supports the storage of variable name and variable value mapping relationship. The database dynamic query method uses the front script sql logical query statement to store the input parameter global variable values ​​used by the interface use cases in different environment databases according to the environment address mapping relationship deployed by different airports. According to the test data usage scenario, the data object address and version in the test data preparation management module are formulated in the interface test case through the test parameter management module, and then the corresponding data is automatically obtained for testing during the test execution process;

[0056] S3, scenario automation script management, imports automatically generated API test cases in the API interface management module, and combines scenario test cases according to the needs of the business system;

[0057] Each use case scenario is composed of multiple interface steps, and the step types can be post, put, get, delete, patch and other interface types. The interface step supports binding APIs or new APIs that are not in the API interface management module. The request parameters of the interface automation script are written according to the parameters in the interface document. The parameter variables in the test environment parameter management module are referenced in the request body. The response results of the interface of the scenario script are parameterized global variables through the post-script, and the subsequent interface obtains the parameterized global variables through the pre-script to achieve interface automation. Specifically, the subsequent interface writes and obtains global variables in the pre-script of the interface, and the obtained global variables are used as the input parameters of this interface to execute this interface and output the interface execution results. Whether the script is executed successfully or not is judged by assertion. The assertion rules support multiple verification rules such as http status code and response body. The status code is matched by the server status code. The response body verification method supports multiple verification methods such as jsonPath matching, xPath matching, json document structure verification, full text matching, regular expression matching, etc. It is suitable for interface result verification of different response body formats. The matching verification of jsonPath, xPath, and json document structure is to match the structure content in the label of the response result through the json script. If the match is passed, the use case is executed successfully.

[0058] S4, test strategy management, formulates different automation execution strategies according to the business characteristics and interface ownership of each service in the microservice architecture;

[0059] According to the nature of the interface, you can check the automated use case execution mode in the system, choose serial automated execution or parallel automated execution, and cooperate with the system's release requirements and the settings for continued integration to realize the automatic execution of smoke automated testing strategies after integration and deployment, and the automated execution strategy of regular online inspections. The scenario use cases written in the scenario automation script management module are added to the test plan in the test strategy management module. Different environment addresses are supported to execute different automated testing strategies, and the environment addresses maintained in the test environment parameter management module are automatically introduced. Test cases are combined according to business scenarios of different deployment environments and microservice architectures. The system automatically supports sharing cookies between use cases, and configures different test environments to execute different automated execution test methods, including serial testing, parallel testing, and multi-environment execution. Serial testing is the execution order restricted by the execution results of different use cases, parallel testing is the low-coupling use cases that do not depend on each other's execution results and can be executed in parallel, and multi-environment execution is the automated scenario testing that can be executed simultaneously by different test environment addresses.

[0060] S5, continuous integration test execution, configure Jenkins and Eolink's open API, set trigger conditions, build steps and test tasks, integrate Eolink's scenario automation scripts into the continuous integration pipeline, and configure triggers to support triggering builds after code submission;

[0061] You can set up build plans, support daily build execution, regular build execution, smoke test execution, regression test execution, etc., add build steps to execute automated tests, and the build steps include processing steps to process and parse the results generated by Eolink automated tests, including running test suites to execute scenario automation scripts, dividing automated tests into multiple independent test suites, and executing them in parallel on multiple test environments to improve execution speed and efficiency;

[0062] S6, monitoring and reporting, collects and analyzes test results by configuring an automated test reporting platform, and continuously monitors single interfaces and API comprehensive monitoring through the API monitoring mechanism;

[0063] Single interface monitoring focuses on the performance and availability of a single interface. API comprehensive monitoring can monitor the response time of script execution and interface operation in the entire scenario automation process in real time, and directly locate problems for failed execution interfaces through monitoring. Error information is entered into the log, and the interface trust information is written in the log. In the continuous integration test module, the results generated by the Eolink test are configured to be processed and parsed. If the Eolink test passes, the next stage of integration strategy is triggered. If the Eolink test fails, there will also be specific execution log information, and a notification mechanism is set to notify relevant team members after the test is completed.

[0064] It can be seen from the above embodiments that the present invention reduces manual input, upgrades the scenario test originally performed manually to an automated scenario test, and greatly saves labor costs. The existing industry does not have a method suitable for microservice architecture to write interface use cases based on interface documents and implement continuous automated testing through continuous integration;

[0065] The existing industry does not have a method suitable for microservice architecture to write interface use cases based on interface documents and implement continuous automated testing through continuous integration;

[0066] The present invention changes the huge workload of interface call coding to realize interface automation. The present invention only needs to pay attention to the configuration correctness of continuous integration related plug-ins such as test tool related plug-ins and API monitoring reports, and write scenario automation scripts in the test tool according to the scenario test plan.

[0067] The present invention solves the problem of continuous testing of microservice architecture system. API interface management is performed by importing swagger interface documents through eolink tool, different deployment environment addresses and parameters are maintained through environment management, test cases are automated scripted based on API management, interface parameter processing and transmission are performed by writing pre- and post-scripts, and interface response content is compared by assertion encapsulation. Automated test execution after each deployment and release is performed through open API and Jenkins continuous integration. A method for scene automation continuous testing of continuously integrated microservice architecture system based on interface documents suitable for microservice architecture system is realized, which opens up new ideas for continuous testing practice.

[0068] The present invention realizes scenario automation testing for microservice architecture systems and intuitively sees the results of test execution, greatly improving test efficiency and reducing test costs. Testers only need to pay attention to the configuration correctness of continuous integration-related plug-ins such as test tool-related plug-ins and API monitoring reports, and write scenario automation scripts in the test tool according to the scenario test plan, without spending a huge amount of work on interface call coding. Through the configuration of continuous integration and according to the configuration of the test strategy, automated test execution can be performed, and the interface execution results can be intuitively seen, and automated access control can be completed. Online scheduled inspections can be completed by setting the automated test running time. According to the report module settings, visual test reports will be automatically exported after the automated test is executed. The present invention significantly improves the executability of scenario automation continuous testing and the intuitive effectiveness of test results, greatly ensuring the continuous testing of the system.

[0069] Embodiment 2, as Figure 3 As shown, as a preferred implementation, the airport information system is developed using the spring-cloud microservice architecture, involving many microservice modules and frequent releases. Each release performs a full smoke test or a designated module smoke test as required. The present invention provides a method for scenario automation testing of microservice continuous integration based on interface documents, including an API interface management module, a test data preparation management module, a scenario automation script management module, a test strategy management module, a continuous integration test module, and a monitoring and reporting module.

[0070] API interface management module 1, in which the swagger interface documents of each microservice of the airport information system are imported, interfaces with attributes such as post, put, del, and get can be distinguished and displayed. The interface management module automatically generates API test cases, and the test case parameters can be manually edited;

[0071] Test data preparation management module 2 can be managed by static storage and database dynamic query. The static storage method supports the storage of variable name and variable value mapping relationship. The database dynamic query method uses the front script sql logical query statement to store the input parameter global variable values ​​used by the interface use cases in different environment databases according to the environment address mapping relationship deployed in different airports. According to the use scenario of the test data, the data object address and version in the test data preparation management module are formulated in the interface test case, and then the corresponding data is automatically obtained for testing during the test execution process;

[0072] Scenario automation script management module 3, based on the use cases generated by the API interface management module, combines scenario use cases according to the needs of the business system. The interface steps support binding APIs or new APIs that are not in the API interface management module. The request parameters of the interface automation script are written according to the parameters in the interface document. The parameter variables in the test environment parameter management module are referenced in the request body. The response results of the scenario script interface are parameterized global variables through the post-script. The subsequent interface obtains the parameterized global variables through the pre-script to achieve interface automation. Figure 4 As shown, the white box test developed can also call the automated script separately to verify the single interface. The success or failure of the script execution is judged by assertion. The assertion rules support multiple verification rules such as http status code and response body. The response body verification method supports multiple verification methods such as jsonPath matching, xPath matching, json document structure verification, full text matching, regular expression matching, etc., which is suitable for interface result verification in different response body formats;

[0073] Test strategy management module 4, according to the business characteristics and interface ownership of each service in the microservice architecture, cooperates to formulate different automation execution strategies, adds the scenario use cases written in the scenario automation script management module to the test plan in the test strategy management module, executes different automation test strategies according to different environment addresses, automatically introduces the environment address maintained in the test environment parameter management module, combines test cases according to different deployment environments and business scenarios of microservice architecture, supports sharing cookies between use cases, and configures different test environments to execute different automation execution test methods, including serial testing, parallel testing, and multi-environment execution;

[0074] Continuous integration test execution module 5, configure Jenkins and Eolink's open API, set trigger conditions, build steps and test tasks, integrate Eolink's scenario automation script into the continuous integration pipeline, configure triggers to support triggering builds after code submission, set build plans, support daily build execution, regular build execution, smoke test execution, regression test execution, etc. Figure 4 As shown, after the test environment is prepared, a build step is added to schedule the execution of automated tests. The build step contains processing steps to process and parse the results generated by the Eolink automated test, including running the test suite to execute the scenario automation script, dividing the automated test into multiple independent test suites, and executing them in parallel on multiple test environments to improve execution speed and efficiency;

[0075] Monitoring and reporting module 6, collects and analyzes test results by configuring the automated test reporting platform, and continuously monitors single interfaces and API comprehensive monitoring through the API monitoring mechanism. Single interface monitoring focuses on the performance and availability of a single interface, and API comprehensive monitoring can monitor the response time of script execution and interface operation in the entire scenario automation process in real time, and directly locate problems for failed execution interfaces through monitoring. In the continuous integration test module, configure the processing and parsing of the results generated by the Eolink test, and set up a notification mechanism to notify relevant team members after the test is completed.

[0076] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0077] Since the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present invention, their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0078] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated in one processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present invention. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment.

[0079] An embodiment of the present invention further provides a computer device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor implements the steps in any of the above-mentioned method embodiments when executing the computer program.

[0080] To further illustrate the effects of the embodiments of the present invention, the following experiment was conducted: In a large-scale microservice architecture system of an airport, the present invention conducted a comparison of the efficiency of continuous test execution. A test scenario was taken out, and the tester analyzed the test scenario to write test cases, manually executed the tests, and recorded the execution results of the test cases. After the test passed, the integrated deployment was performed, and other deployment environments were switched. It was necessary to re-execute the manual test of the above test cases, and record the entire process and execution time. This is a manual process.

[0081] The above-mentioned test scenario is executed through the present invention, and the interface document of the test scenario is imported into the API interface management module of the present invention to automatically generate scenario test cases. The tester combines the cases and writes the pre- and post-scripts through the scenario automation script management module, and automatically executes the scenario automation test. After the execution is completed, the continuous integration deployment is automatically triggered through the triggered execution strategy and the test results are automatically exported. Other deployment environments are switched through the test data preparation module, and the switch is made with one click and the execution is automatically executed. After the execution is completed, the test results are automatically exported. This is the process of the present invention.

[0082] By comparing the execution time and results of the manual process and the process of the present invention, it is obvious that the execution efficiency of the present invention is higher, which can be improved by 80%, and the accuracy of the interface execution results is higher. In the manual process, the test results of different deployment environments are omitted, while in the scenario automation test of the present invention, 100% coverage of the scenario is achieved.

[0083] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any modifications, equivalent substitutions and improvements made by any technician familiar with the technical field within the technical scope disclosed by the present invention and within the spirit and principles of the present invention should be covered within the protection scope of the present invention.

Claims

1. A method for automated continuous testing of microservice continuous integration scenarios, characterized in that: The method includes: S1, API interface management, import the swagger interface documents of each microservice of the airport information system into the API interface management module. The API interface management module automatically generates API test cases by importing interface information, and automatically distinguishes interfaces that display post, put, del, and get attributes; S2, test data preparation management, storage management of parameters of different deployment environments and test data of each environment, including deployment address information and test data global parameter configuration; S3, scenario automation script management, imports automatically generated API test cases in the API interface management module, and combines scenario test cases according to the needs of the business system; S4, test strategy management, formulates different automation execution strategies according to the business characteristics and interface ownership of each service in the microservice architecture; S5, continuous integration test execution, configure Jenkins and Eolink's openAPI, set trigger conditions, build steps and test tasks, integrate Eolink's scenario automation scripts into the continuous integration pipeline, and configure triggers to support triggering builds after code submission; S6, monitoring and reporting, collects and analyzes test results by configuring an automated test reporting platform, and continuously monitors single interfaces and API comprehensive monitoring through the API monitoring mechanism; In step S4, different automated execution strategies are formulated according to the business characteristics and interface ownership of each service in the microservice architecture, including: adding the scenario use cases written in the scenario automation script management module to the test plan in the test strategy management module, supporting different environment addresses to execute different automated test strategies, automatically introducing the environment address maintained in the test environment parameter management module, combining test cases according to different deployment environments and business scenarios of the microservice architecture, the system automatically supports sharing cookies between use cases, and configuring different test environments to execute different automated execution test methods, including serial testing, parallel testing, and multi-environment execution. Serial testing is the sequential execution of execution results constrained by different use cases, parallel testing is the parallel execution of low-coupling use cases that do not depend on each other's execution results, and multi-environment execution is the simultaneous execution of automated scenario tests by different test environment addresses; According to the nature of the interface, check the execution mode of the automated use case in the system, choose serial automated execution or parallel automated execution, and cooperate with the system's release requirements, combined with the settings of continued integration, to implement the automatic execution of the smoke automated test strategy after the integration deployment, and to implement the automated execution strategy of regular online inspections. The scenario automated test strategies include: scheduled execution strategy, which automatically runs test cases according to a predetermined schedule, which is suitable for continuous integration and monitoring requirements; triggered execution strategy: when specific events such as code submission and build completion occur, the test execution is automatically triggered to ensure fast feedback; concurrent execution strategy: in order to speed up the testing process, multiple test cases or test suites are run at the same time; phased execution strategy: test cases are divided into different stages of unit testing, integration testing, and system testing, and executed in sequence or conditionally; data-driven execution strategy: use different data sets to execute the same test script multiple times to increase test coverage; failure retry strategy: for tests that fail accidentally, set a retry mechanism to distinguish real problems from temporary failures.

2. The method for scenario-based automated continuous testing of microservice continuous integration according to claim 1, characterized in that: In step S1, the query parameters of the API test case automatically generate test preview data, the interface parameter data automatically generates preview data selection in various forms according to the interface requirements, and the request parameters and the normal flow and abnormal flow test data of the test case are manually edited.

3. The method for scenario-based automated continuous testing of microservice continuous integration according to claim 1, characterized in that: In step S2, the global parameter configuration is managed by static storage and database dynamic query. The static storage method supports the storage of variable name and variable value mapping relationship. The database dynamic query method uses the front script sql logical query statement to store the global variable values ​​used by the interface use cases in different environment databases according to the environment address mapping relationship deployed in different airports. By comparing the use scenario of the test data, the data object address and version in the test data preparation management module are formulated in the interface test case through the test parameter management module, and then the corresponding data is automatically obtained for testing during the test execution process; In step S3, each scenario use case is composed of multiple interface steps, and the step type is selected from the post, put, get, delete, and patch interface types; The interface step binds an API or a new API that is not in the API interface management module. The request parameters of the interface automation script are written according to the parameters in the interface document. The parameter variables in the test environment parameter management module are referenced in the request body. The response result of the scenario script interface is parameterized as a global variable through the post-script. The subsequent interface obtains the parameterized global variables through the pre-script to achieve interface automation. Specifically, the subsequent interface writes and obtains the global variables in the pre-script of the interface. The obtained global variables are used as the input parameters of this interface to execute this interface and output the interface execution results. The global variables are set in the following ways: var res=eo.json.decode(eo.http.response.get()); eo.globals.set("inid",res[0]).

4. The method for scenario-based automated continuous testing of microservice continuous integration according to claim 3 is characterized in that: Whether the script is executed successfully or not is judged by assertion. The assertion rules support multiple verification rules for http status code and response body. The status code is matched by the server status code. The response body verification method supports multiple verification methods such as jsonPath matching, xPath matching, json document structure verification, full-text matching, and regular expression matching. The matching verification of jsonPath, xPath, and json document structure uses json script to match the structure content in the label of the response result. If the match is successful, the use case is executed successfully.

5. The method for scenario-based automated continuous testing of microservice continuous integration according to claim 1, characterized in that: In step S5, configure triggers to support triggering builds after code submission, including setting build plans, supporting daily build execution, regular build execution, smoke test execution, regression test execution, and adding build steps to execute automated tests; By implementing triggers through scripting, when the code is submitted, the trigger script is used to automatically build the relevant interfaces and trigger the execution of the automation strategy. In other words, through the trigger execution strategy, the script execution is automatically triggered by code submission, ensuring fast feedback.

6. The method for scenario-automated continuous testing of microservice continuous integration according to claim 5 is characterized in that: Configuration triggers support triggering builds after code submission. Processing steps are included to process and parse the results generated by Eolink automated testing, including running test suites to execute scenario automation scripts, dividing automated tests into multiple independent test suites, and executing them in parallel on multiple test environments.

7. The method for scenario-based automated continuous testing of microservice continuous integration according to claim 1, characterized in that: In step S6, single interface and API comprehensive monitoring are continuously monitored through the API monitoring mechanism, including: single interface monitoring is used to monitor the performance and availability of a single interface, API comprehensive monitoring monitors the response time of script execution and interface operation status in the entire scenario automation process in real time, and directly locates the problem of the failed interface through monitoring, and the error information is output to the log, and the log states the detailed interface information; and the failed interface is retried through the automated strategy of failed retries to distinguish real problems from temporary failures. The results generated by the Eolink test are configured to be processed and parsed in the continuous integration test module. The Eolink test is executed through the automated phased execution strategy, and the next phase of the integration strategy is triggered. If the Eolink test fails, there will be specific execution log information, and an email notification mechanism is set to send a notification after the test is completed.

8. A scenario-based automated continuous testing system for microservice continuous integration, characterized in that: The system implements the method for scenario-automated continuous testing of microservice continuous integration as described in any one of claims 1 to 7, and the system includes: API interface management module (1), used to import the project interface document of the microservice architecture system through Eolink, supports swagger format and YApi format, automatically generates API test cases after importing, and edits normal flow and abnormal flow in the automatically generated test cases; The test data preparation management module (2) includes centralized management of test environment parameters and test data, storage management of parameters of different deployment environments, and storage of global variable values ​​of input parameters used by interface test cases in different environment databases queried through SQL, supporting the ability to perform version management on the same data object to meet the needs of different versions of test cases and test scripts; The scenario automation script management module (3) is used to import the API test cases automatically generated by the API interface management module (1) to combine scenario cases according to the needs of the business system; A test strategy management module (4) is used to formulate different automation execution strategies according to the business characteristics and interface affiliation of each service in the microservice architecture, and deploy different services to execute different automation test strategies; Continuous integration test module (5), used to configure continuous integration with Jenkins through Eolink's openAPI, and set trigger strategies to trigger the build process to execute scenario automated testing; The monitoring and reporting module (6) is used to collect, store and display automated test reports through Eolink's test report configuration, monitor the automated test running process, including the execution pass status and running time of each interface, and automatically notify team members after the test is completed in combination with the notification mechanism of the continuous integration test module.

9. The scenario-automated continuous testing system for microservice continuous integration according to claim 8, characterized in that: In the scenario automation script management module (3), each use case scenario is composed of a plurality of interface steps, the interface steps are bound to an API, the scenario script is implemented in the interface step, the response result of the scenario script interface is parameterized as a global variable through a post-script, and the subsequent interface obtains the parameterized global variable through a pre-script to realize interface automation; In the continuous integration testing module (5), the build step includes a processing step to process and parse the results generated by the Eolink automated test.

Images