Distributed automated testing device, method, equipment and medium based on microservice architecture

Abstract

The present invention provides a distributed automated testing device, method, equipment and medium based on a microservice architecture, firstly obtaining a management POD and an execution POD; then deploying the management POD in a virtual machine or server, and distributing multiple execution PODs in a test environment through the management POD; and using the management POD to call the interface service provided by each execution POD, and initiating a request or instruction to the corresponding execution POD based on the interface service; and then obtaining and displaying the automated testing results after each execution POD executes the corresponding request or instruction. The present invention adopts a microservice approach, first deploying a management POD in a virtual machine or server, and then using the management POD to distribute and deploy multiple execution PODs in one or more test environments, so that the present application has a distributed feature. The present invention can solve the problem in the prior art that the automated testing framework is independently operated, highly centralized, and has a high cost of customized transformation by distributing multiple execution PODs.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a distributed automated testing device, method, computer equipment and computer-readable medium based on a microservice architecture. Background Art

[0002] Currently, all kinds of automated testing frameworks or devices (hereinafter referred to as automated frameworks) run on independent servers or virtual machines to provide external services. However, this approach has the following defects:

[0003] 1. When performing automated testing on large-scale, distributed microservices, various microservices can be elastically scaled according to the actual load to achieve high resource utilization; however, since the automation framework is not elastic, the framework must be deployed in advance according to the maximum specifications, or the framework operation scale needs to be manually adjusted before each test, resulting in low hardware resource utilization and excessively high labor costs.

[0004] 2. Since the automation framework runs on an independent server, it is physically isolated from the server cluster where the microservices are located. It is affected by the network card transmission speed, switch throughput, and the fact that the microservice server clusters are located in different provinces and cities. As a result, performance testing cannot be carried out well, resulting in network jitter, which greatly affects the test accuracy and causes a decrease in test accuracy.

[0005] 3. Limited automated testing methods. Since microservices run in a Kubernetes cluster, the automation framework cannot directly enter a specific POD (POD is the smallest unit created or deployed by Kubernetes) for testing. For example, it cannot directly execute commands in the POD and call certain services in the POD. As a result, it can only enter the POD through indirect means, such as connecting to the POD through the SSH protocol on a certain port. However, indirect entry methods are prone to container security issues.

[0006] 4. Nowadays, various software or products based on microservice architecture usually have multiple iterations in production and test environments at the same time, and different versions require different framework functions or even conflict. The centralized automation framework obviously cannot support multiple iterations well, and can only rely entirely on writing corresponding automation scripts to achieve simultaneous testing of different iterations. Once the centralized basic framework is upgraded, or the version of the dependency package is too high or too low, resulting in script mismatch, or all threads in the thread pool are hung due to a crash or network congestion on a server, all automated test tasks will fail. That is, due to the specific centralized attributes of the automation framework, the traditional automation framework cannot perform multiple copies, elastic scaling, service fuses, version control, service rollback and other functions, and is not easy to modify and lacks flexibility: modifications to the automation framework and the addition of new functions usually affect the entire system.

[0007] Therefore, since the automated testing framework in the existing technology runs independently and is highly centralized, its customization and transformation costs are high, and it cannot be elastically scaled, it is physically or logically isolated from each microservice, and thus cannot achieve good results in performance testing, interface testing, microservice invasive testing, etc. Summary of the invention

[0008] In view of the shortcomings of the prior art described above, an object of the present invention is to provide a distributed automated testing device, method, equipment and medium based on a microservice architecture, so as to solve the problems existing in automated testing under a microservice architecture in the prior art.

[0009] To achieve the above-mentioned object and other related objects, the present invention provides a distributed automated testing device based on a microservice architecture, comprising: a first container combination and a second container combination;

[0010] The first container combination is deployed in a virtual machine or a server, and the first container combination is used to distribute and deploy multiple second container combinations in a test environment, and call the interface service of the second container combination, initiate a request or instruction to each second container combination, and display the automated test result after each second container combination executes the request or instruction;

[0011] The second container combination is used to provide an interface service, receive and execute a request or instruction initiated by the first container combination, and generate a corresponding automated test result.

[0012] Optionally, the first container assembly comprises:

[0013] A deployment module, used to deploy the multiple second container combinations in a distributed manner in a test environment, perform heartbeat keep-alive on each second container combination, and monitor the running status of each second container combination in real time;

[0014] An instruction module, used to call the interface service provided by each second container combination, and initiate a request or instruction to the corresponding second container combination based on the interface service;

[0015] A collection module, used to collect the test report, operation log and health status of each second container combination, and display the automated test result after each second container combination executes the request or instruction;

[0016] The first storage module is connected to the deployment module, the instruction module, and the collection module respectively, and is used to store data in the deployment module, the instruction module, and the collection module.

[0017] Optionally, after the deployment module deploys a second container combination in a distributed manner in the test environment, the deployment module further includes:

[0018] determining a fault state of the certain second container combination according to the operation log of the certain second container combination stored in the first storage module;

[0019] If a fault occurs in the second container combination, a copy of the second container combination is obtained, and the copy of the second container combination is distributedly deployed in the test environment.

[0020] Optionally, after the instruction module initiates a request or instruction to a second container combination based on the interface service, the method further includes:

[0021] determining a fault state of the certain second container combination according to the operation log of the certain second container combination stored in the first storage module;

[0022] If a fault occurs in the certain second container combination, stop initiating a request or instruction to the certain second container combination;

[0023] If the certain second container combination does not have a fault, based on the interface service of the certain second container combination, continuously initiate a request or instruction to the certain second container combination.

[0024] Optionally, if there are multiple test environments, the process of the deployment module distributing the second container combination in the multiple test environments includes:

[0025] Selecting a test environment from the multiple test environments, and determining whether the selected test environment has a target test;

[0026] If there is a target test, obtain the pre-input policy type, and schedule all idle clusters in the remaining test environments according to the policy type, and deploy one or more second container combinations in all idle clusters, and use all the second container combinations after the deployment to perform the target test;

[0027] If the target test does not exist, selecting another test environment from the multiple test environments to perform target test determination;

[0028] Among them, the target test includes at least one of the following: demand growth business test, performance test, popular time period test; the pre-input strategy types include at least one of the following: timed high-efficiency strategy, timed zero occupancy strategy, indicator high-efficiency strategy, indicator zero occupancy strategy, high-efficiency strategy that mixes timing and indicators, and zero occupancy strategy that mixes timing and indicators.

[0029] Optionally, the device further comprises: a service rollback module, the service rollback module being used to receive a rollback instruction or rollback request input externally, and rollback the second container combination under the current version to a specified version according to the rollback instruction or rollback request.

[0030] Optionally, the second container assembly comprises:

[0031] An interface service module, used for providing an interface service and receiving a request or instruction initiated by the first container combination after calling the interface service;

[0032] An operation module, configured to load a pre-installed automation framework and execute the received request or instruction based on the loaded automation framework;

[0033] A reporting module, used to integrate the data when the operation module executes the request or instruction, and generate corresponding automated test results;

[0034] A log module, used to generate operation logs of the interface service module, operation module and report module;

[0035] The second storage module is connected to the interface service module, the operation module, the report module and the log module respectively, and is used to store data in the interface service module, the operation module, the report module and the log module.

[0036] Optionally, the first container group is a management POD, and the second container group is an execution POD.

[0037] Optionally, the device further comprises: a version control module, the version control module being used to select a plurality of second container combinations deployed in the test environment, the selected plurality of second container combinations comprising second container combinations of different versions.

[0038] The present invention also provides a distributed automated testing method based on a microservice architecture, the method comprising the following steps:

[0039] Get a first container combination and a second container combination;

[0040] Deploy the first container combination in a virtual machine or a server, and perform distributed deployment of multiple second container combinations in a test environment through the first container combination;

[0041] Using the first container combination to call the interface service provided by each second container combination, and initiating a request or instruction to the corresponding second container combination based on the interface service;

[0042] The automated test result after each second container combination executes the corresponding request or instruction is obtained and displayed.

[0043] Optionally, after distributing and deploying a second container combination in a test environment through the first container combination, the method further includes:

[0044] Obtaining a test report of the certain second container combination, and determining a fault state of the certain second container combination according to the test report of the certain second container combination;

[0045] If a fault occurs in the certain second container combination, a copy of the certain second container combination is obtained, and the copy of the certain second container combination is distributedly deployed in the test environment;

[0046] If there is no fault in the second container combination, the second container combination is deployed in a distributed manner in the test environment.

[0047] Optionally, after initiating a request or instruction to the corresponding second container combination based on the interface service, the method further includes:

[0048] Obtaining a test report of the certain second container combination, and determining a fault state of the certain second container combination according to the test report of the certain second container combination;

[0049] If a fault occurs in the certain second container combination, stop initiating a request or instruction to the certain second container combination;

[0050] If the certain second container combination does not have a fault, based on the interface service of the certain second container combination, continuously initiate a request or instruction to the certain second container combination.

[0051] The present invention also provides a computer device, comprising:

[0052] Processor; and

[0053] A computer-readable medium storing instructions, when the processor executes the instructions, causes the device to perform any of the methods described above.

[0054] The present invention also provides a computer-readable medium on which instructions are stored. The instructions are loaded by a processor and executed by any of the methods described above.

[0055] As described above, the present invention provides a distributed automated testing device, method, equipment and medium based on a microservice architecture, which has the following beneficial effects:

[0056] The present invention first obtains a first container combination and a second container combination; then deploys the first container combination in a virtual machine or a server, and distributes multiple second container combinations in a test environment through the first container combination; and uses the first container combination to call the interface service provided by each second container combination, and initiates a request or instruction to the corresponding second container combination based on the interface service; and then obtains and displays the automated test results after each second container combination executes the corresponding request or instruction. Among them, the first container combination can be a management POD, and the second container combination can be an execution POD. The present invention adopts a microservice method, first deploys a management POD in a virtual machine or a server, and then uses this management POD to distribute and deploy multiple execution PODs in one or more test environments, so that the present application has a distributed feature. Even if the number of test environments increases, the execution POD only consumes a very small part of the performance of the test environment, which is not only easy to maintain, but also has high stability, and can make full use of idle test environments. Therefore, the present invention can solve the problem that the automated test framework in the prior art is independent operation, high degree of centralization, and high customization and transformation cost by distributing multiple execution PODs. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 A schematic diagram of the architecture of a distributed automated testing device based on a microservice architecture provided by an embodiment;

[0058] Figure 2 A schematic diagram of the architecture of a first container assembly provided by an embodiment;

[0059] Figure 3 A schematic diagram of the architecture of a second container assembly provided by an embodiment;

[0060] Figure 4 A schematic diagram of deploying multiple versions of a second container combination provided by an embodiment;

[0061] Figure 5 A schematic diagram of deploying a replica of a second container combination provided by an embodiment;

[0062] Figure 6 A schematic diagram of deploying multiple versions of a second container combination provided in another embodiment;

[0063] Figure 7 A schematic diagram of deploying a second container combination when performing a target test provided by an embodiment;

[0064] Figure 8 A schematic diagram of a second container assembly for deploying a customized version provided by an embodiment;

[0065] Fig. 9A schematic diagram of a distributed automated testing method based on a microservice architecture provided by an embodiment;

[0066] Fig.10 A schematic diagram of the hardware structure of a computer device provided in an embodiment. DETAILED DESCRIPTION

[0067] The following describes the embodiments of the present invention by specific examples, and those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0068] It should be noted that the illustrations provided in this embodiment are only used to illustrate the basic concept of the present invention in a schematic manner. Therefore, the drawings only show components related to the present invention rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0069] This embodiment provides a distributed automated testing device based on a microservice architecture, the device comprising: a first container combination and a second container combination; the first container combination is deployed in a virtual machine or a server, and the first container combination is used to distribute and deploy multiple second container combinations in a test environment, and call the interface service of the second container combination, initiate a request or instruction to each second container combination, and display the automated testing results after each second container combination executes the request or instruction. The second container combination is used to provide an interface service, receive and execute the request or instruction initiated by the first container combination, and generate the corresponding automated testing results. In this embodiment, the first container combination can be a management POD, and the second container combination can be an execution POD. Specifically, as Figure 1As shown, the management POD is only used as a management node, consumes less resources, and can be directly deployed in a low-configuration virtual machine or server. The execution POD is deployed by the management POD to the kubernetes cluster (k8s cluster for short) of each tested environment. It can be seen that this embodiment adopts a microservice approach, first deploying a management POD in a virtual machine or server, and then using this management POD to distribute and deploy multiple execution PODs in one or more test environments, so that this application has a distributed feature. Even if the number of test environments increases, the execution POD only consumes a very small part of the performance of the test environment, which is not only easy to maintain and has high stability, but also can make full use of idle test environments. Therefore, this embodiment can solve the problem that the automated testing framework in the prior art is independent operation, high degree of centralization, and high cost of customized transformation by distributing multiple execution PODs.

[0070] In an exemplary embodiment, the first container combination or management POD includes: a deployment module, an instruction module, a collection module and a first storage module; wherein the deployment module is used to deploy multiple second container combinations in a distributed manner in a test environment, and to perform heartbeat keep-alive for each second container combination, and to monitor the operating status of each second container combination in real time. The instruction module is used to call the interface service provided by each second container combination, and to initiate a request or instruction to the corresponding second container combination based on the interface service. The collection module is used to collect the test report, operation log and container combination health status within each second container combination, and to display the automated test results after each second container combination executes the request or instruction. The first storage module is respectively connected to the deployment module, the instruction module and the collection module, and is used to store data in the deployment module, the instruction module and the collection module. The first storage module in this embodiment is composed of MYSQL storage. Specifically, as Figure 2 As shown in the figure, the function of the deployment module is to deploy the execution POD in the tested environment, keep the execution POD alive with heartbeat, and monitor the running status in real time. The function of the instruction module is to send interface requests or instructions to the OPENAPI service in the execution POD. The function of the collection module is to regularly collect test reports, operation logs, POD health status and other indicators in the execution POD, and show the results of this automated test to the user. MYSQL is used as the first storage module to store all data in the deployment module, instruction module and collection module, including running process data and running result data.

[0071] In an exemplary embodiment, the second container combination or execution POD includes: an interface service module, an operation module, a report module, a log module and a second storage module. Among them, the interface service module is used to provide interface services and receive requests or instructions initiated after the first container combination calls the interface service. The operation module is used to load the pre-installed automation framework and execute the received request or instruction based on the loaded automation framework. The report module is used to integrate the data when the operation module executes the request or instruction to generate the corresponding automation test results. The log module is used to generate the operation log of the interface service module, the operation module and the report module. The second storage module is connected to the interface service module, the operation module, the report module and the log module respectively, and is used to store the data in the interface service module, the operation module, the report module and the log module. The second storage module in this embodiment is composed of SQLITE data storage. Specifically, as shown in 3, the function of the OPENAPI service module is to provide interface services to the outside, and the management POD or the user can directly call the interface service to initiate a request or issue an instruction to the execution POD. After receiving the corresponding request or instruction, the OPENAPI service module will call the operation module, and the operation module will load the pre-installed automation framework and run the corresponding script or instruction in the request at the same time. The function of the report module is to integrate the data of the running module and generate the corresponding automated test results, such as the integrated script running status, running results, time consumption, etc. The function of the log module is to collect all logs generated during the operation of other modules in the execution POD for analysis and use by managers or users. Among them, the pre-installed automation frameworks include but are not limited to: pytest, unitest, JUnit, etc. It can be seen that this embodiment can flexibly respond to the automated test frameworks corresponding to different development languages ​​in the business POD through the distributed execution of POD, and each execution POD can be customized as needed and load different automation frameworks, such as Junit corresponding to Java, pytest corresponding to Python, etc. At the same time, the OPENAPI service of the execution POD has the ability to be open to the outside world, and users can fully customize the access to their own automated testing platform to manage, schedule or develop new functions for the execution POD. At the same time, you can access your own or a third-party monitoring platform to maintain the running status of the execution POD.

[0072] According to the above record, in an exemplary embodiment, after the deployment module in the first container combination deploys a second container combination in a distributed manner in a test environment, it also includes: judging the fault state of the second container combination according to the operation log of the second container combination stored in the first storage module; if the second container combination has a fault, obtaining a copy of the second container combination and deploying the copy of the second container combination in a distributed manner in the test environment. Specifically, Figure 4 and Figure 5As shown, after the management POD deploys the execution POD in the tested cluster A of the tested environment, and deploys the execution POD in the tested cluster B of the tested environment, the deployment module is used to perform heartbeat keep-alive on the execution PODs in the tested clusters A and B, and the running status is monitored in real time; if the deployment module fails to keep the heartbeat of POD1 in the tested cluster B, it is determined whether there is a fault according to the running log of POD1 in the tested cluster B collected by the collection module; if a fault occurs, the copy of POD1, POD1.1, is used as a replacement version of POD1 and deployed in the original tested cluster B. Among them, the execution POD deployed to the tested cluster A can be the execution POD of version A, and the execution POD deployed to the tested cluster B can be the execution POD of version B. It can be seen that this embodiment provides the use of a copy of the execution POD to replace the original execution POD, and determines that after an execution POD in the tested environment fails, the corresponding business will not be interrupted.

[0073] According to the above record, in an exemplary embodiment, after the instruction module in the first container combination initiates a request or instruction to a second container combination based on the interface service, it also includes: judging the fault state of the second container combination according to the operation log of the second container combination stored in the first storage module; if the second container combination has a fault, stop initiating requests or instructions to the second container combination; if the second container combination has no fault, continue to initiate requests or instructions to the second container combination based on the interface service of the second container combination. Specifically, Figure 6As shown, the automation tester or manager manages the POD through WEB operations, then calls the interface service of the execution POD, issues instructions to the execution POD, deploys the A version of the execution POD in two test environments, and deploys the B version of the execution POD in one test environment. After the deployment is completed, the deployment module in the management POD is used to perform heartbeat keep-alive on the deployed A version of the execution POD and the B version of the execution POD, and the running status is monitored in real time; the heartbeat keep-alive is performed on the execution PODs in the tested clusters A and B, and the running status is monitored in real time; if the deployment module in the management POD fails to keep the heartbeat alive for the B version of the execution POD in the third test environment, the running log of the B version of the execution POD in the third test environment collected by the collection module is used to determine whether it has a fault; if a fault occurs, the management POD will stop initiating requests or instructions to the execution POD, thereby helping to achieve service fuse. It can be seen that this embodiment uses service fusing to ensure that during performance or high-traffic testing, when the business system is impacted and hangs, the execution POD will not cause service avalanche or unlimited growth of resource consumption due to thread blocking, causing the tested environment to crash, and reversely affect the management POD, causing the management POD to hang, thereby making it impossible to carry out testing normally in all tested environments.

[0074] In an exemplary embodiment, if there are multiple test environments when the management POD deploys the execution POD to the test environment, the process of the deployment module in the management POD distributing the second container combination in multiple test environments includes: selecting a test environment from multiple test environments, and judging whether the selected test environment has a target test; if there is a target test, obtaining the pre-entered policy type, and scheduling all idle clusters in the remaining test environments according to the policy type, and deploying one or more second container combinations in all idle clusters, and using all second container combinations after the deployment is completed to perform the target test; if there is no target test, selecting another test environment from multiple test environments to perform the target test judgment. Among them, the target test includes at least one of the following: demand growth business test, performance test, and hot time period test; the pre-entered policy type includes at least one of the following: timed high-efficiency policy, timed zero-occupancy policy, indicator high-efficiency policy, indicator zero-occupancy policy, timed and indicator mixed high-efficiency policy, timed and indicator mixed zero-occupancy policy. This is equivalent to a test environment or a test cluster that is conducting a demand growth business test, performance test, or hot time period test. The management POD will schedule the execution POD in the idle k8s cluster according to the pre-entered elastic strategy, and then determine whether there is an execution POD in the idle k8s cluster. If not, the execution POD will be deployed in the idle k8s cluster. After the execution POD is deployed, the execution POD in the idle k8s cluster will be used to conduct the corresponding demand growth business test, performance test, or hot time period test at the same time, so that the execution POD can be elastically scaled. Specifically, Figure 7 As shown, when the A version execution POD in the tested cluster A is performing performance testing, the management POD will determine whether there is an execution POD in the idle k8s cluster B and the idle k8s cluster C. If not, the execution POD will be deployed; if yes, the corresponding execution POD will be added to the performance test at the same time. It can be seen that the execution POD in this embodiment can be elastically scaled. When performing demand growth business testing, performance testing, or a hot time period test, the idle execution POD in other tested environments can be used according to the elastic strategy, and after the test is completed, it can be decided whether to clean up the idle execution POD according to the elastic strategy. Among them, the elastic strategy can be divided into a timing strategy, an indicator strategy, and a hybrid strategy, and each strategy corresponds to two states: high efficiency and zero occupancy. High efficiency means that after the test is completed, the management POD does not clean up the scheduled execution POD, and the execution POD at this time is in a low resource consumption state and remains available at any time. Zero occupancy means that the execution POD will be cleaned up by the management POD, and at the beginning of a new test, the management POD will redeploy the execution POD in the idle tested environment.

[0075] In an exemplary embodiment, the device also includes: a service rollback module, the service rollback module is used to receive an externally input rollback instruction or rollback request, and roll back the second container combination under the current version to a specified version according to the rollback instruction or rollback request. Specifically, service rollback means that after the user customizes a dedicated execution POD, if there is a problem or other reasons, the execution POD can be quickly rolled back to the specified version directly through the management POD, so as not to affect the testing process of the business system. By setting a service rollback module, this embodiment allows automated testers or users to input rollback instructions or rollback requests, thereby helping automated testers or users to roll back the execution POD to a specified version.

[0076] In an exemplary embodiment, the apparatus further comprises: a version control module, the version control module being used to select a plurality of second container combinations deployed in the test environment, the selected plurality of second container combinations comprising second container combinations of different versions. Figure 8 As shown, the automation tester can customize and deploy a certain version of the execution POD according to user needs through the version control module, so as to test different iteration versions. This is equivalent to using the version control module, so that users can use different customized versions of the execution POD according to the iteration version of the business system in the tested environment. For example, the automation framework version 1.0.0 in the execution POD can be mapped to the business version 2.0.0, and the automation framework version 1.0.1 in the execution POD can be mapped to the business version 2.0.1.

[0077] In summary, the present invention provides a distributed automated testing device based on a microservice architecture, the device includes a management POD and an execution POD, wherein the management POD is deployed in a virtual machine or a server, and the management POD is used to deploy multiple execution PODs in a distributed manner in a test environment, and call the interface service of the execution POD, initiate a request or instruction to each execution POD, and display the automated test results after each execution POD executes the request or instruction. The execution POD is used to provide an interface service, receive and execute the request or instruction initiated by the management POD, and generate the corresponding automated test results. It is equivalent to the device adopting a microservice mode, first deploying a management POD in a virtual machine or a server, and then using this management POD to deploy multiple execution PODs in a distributed manner in one or more test environments, so that the present application has a distributed feature. Even if the test environment increases, the execution POD only consumes a very small part of the performance of the test environment, which is not only easy to maintain, but also has high stability, and can make full use of the idle test environment. Therefore, the device can solve the problem that the automated testing framework in the prior art is independent operation, high degree of centralization, and high cost of customized transformation by distributing multiple execution PODs. At the same time, this device can flexibly respond to the automated testing frameworks corresponding to different development languages ​​in the business POD through the distributed execution POD method, and each execution POD can be customized and loaded with different automation frameworks as needed, such as Junit for Java, pytest for Python, etc. In addition, the OPENAPI service of the execution POD has the ability to be open to the outside world. Users can completely customize and access their own automated testing platform to manage, schedule or develop new functions for the execution POD. It can also access its own or a third-party monitoring platform to maintain the running status of the execution POD. In addition, the execution POD in this device has the characteristics of multiple copies, elastic scaling, service fuses, version control, service rollback, etc., and the management POD can realize unified scheduling of the above characteristics.

[0078] like Fig. 9 As shown, the present invention also provides a distributed automated testing method based on a microservice architecture, the method comprising the following steps:

[0079] S100, obtaining a first container combination and a second container combination;

[0080] S200, deploying the first container combination in a virtual machine or a server, and performing distributed deployment of multiple second container combinations in a test environment through the first container combination;

[0081] S300, using the first container combination to call an interface service provided by each second container combination, and initiating a request or instruction to the corresponding second container combination based on the interface service;

[0082] S400, obtaining and displaying the automated test result after each second container combination executes the corresponding request or instruction.

[0083] Among them, the first container combination in this embodiment can be a management POD, and the second container combination can be an execution POD. Specifically, the management POD is only used as a management node, consumes less resources, and can be directly deployed in a low-configuration virtual machine or server. The execution POD is deployed by the management POD to the k8s cluster of each tested environment. It can be seen that this embodiment adopts a microservice approach, first deploys a management POD in a virtual machine or server, and then uses this management POD to distribute and deploy multiple execution PODs in one or more test environments, so that this application has a distributed feature. Even if the number of test environments increases, the execution POD only consumes a very small part of the performance of the test environment, which is not only easy to maintain and has high stability, but also can make full use of idle test environments. Therefore, this embodiment can solve the problem that the automated testing framework in the prior art is independent operation, high degree of centralization, and high customization and transformation costs by distributing multiple execution PODs.

[0084] In an exemplary embodiment, after a second container combination is distributedly deployed in a test environment through a first container combination, it also includes: obtaining a test report of a second container combination, and judging the fault state of a second container combination according to the test report of a second container combination; if a second container combination has a fault, obtaining a copy of a second container combination, and distributing a copy of a second container combination in the test environment. As an example, specifically, after the management POD deploys the execution POD in the tested cluster A of the tested environment, and deploys the execution POD in the tested cluster B of the tested environment, the deployment module is used to perform heartbeat keep-alive on the execution PODs in the tested cluster A and the tested cluster B, and the running status is monitored in real time; if the deployment module fails to keep the heartbeat alive for POD1 in the tested cluster B, it is judged whether it has a fault according to the running log of POD1 in the tested cluster B collected by the collection module; if a fault occurs, the copy POD1.1 of POD1 is used as a replacement version of POD1 and deployed in the original tested cluster B. The execution POD deployed to the tested cluster A may be the execution POD of version A, and the execution POD deployed to the tested cluster B may be the execution POD of version B. It can be seen that this embodiment provides a method of replacing the original execution POD with a copy of the execution POD, and ensures that after an execution POD in the tested environment fails, the corresponding business will not be interrupted.

[0085] In an exemplary embodiment, after the first container combination initiates a request or instruction to the corresponding second container combination based on the interface service, it also includes: obtaining a test report of a second container combination, and judging the fault status of a second container combination according to the test report of a second container combination; if a second container combination has a fault, stop initiating a request or instruction to a second container combination; if a second container combination does not have a fault, continue to initiate a request or instruction to a second container combination based on the interface service of a second container combination. As an example, specifically, the automation tester or manager manages the POD through WEB operations, and then calls the interface service of the execution POD, issues instructions to the execution POD, and deploys the execution POD of version A in two test environments respectively, and the execution POD of version B in one test environment. After the deployment is completed, the deployment module in the management POD is used to perform heartbeat keep-alive on the deployed version A execution POD and version B execution POD, and the running status is monitored in real time; the heartbeat keep-alive is performed on the execution PODs in the tested cluster A and the tested cluster B, and the running status is monitored in real time; if the deployment module in the management POD fails to perform heartbeat keep-alive on the version B execution POD in the third test environment, then the running log of the version B execution POD in the third test environment collected by the collection module is used to determine whether there is a fault; if a fault occurs, the management POD will stop initiating requests or instructions to the execution POD, thereby helping to achieve service fusing. It can be seen that this embodiment uses service fusing to ensure that in performance or high-traffic testing, after the business system is impacted and hangs, the execution POD will not cause service avalanche or unlimited growth of resource consumption due to thread blocking, causing the tested environment to crash, and reversely affect the management POD, causing the management POD to hang, so that all tested environments cannot be tested normally.

[0086] In an exemplary embodiment, if there are multiple test environments when the management POD deploys the execution POD to the test environment, the process of the deployment module in the management POD distributing the second container combination in multiple test environments includes: selecting a test environment from multiple test environments, and judging whether the selected test environment has a target test; if there is a target test, obtaining the pre-entered policy type, and scheduling all idle clusters in the remaining test environments according to the policy type, and deploying one or more second container combinations in all idle clusters, and using all second container combinations after the deployment is completed to perform the target test; if there is no target test, selecting another test environment from multiple test environments to perform the target test judgment. Among them, the target test includes at least one of the following: demand growth business test, performance test, and hot time period test; the pre-entered policy type includes at least one of the following: timed high-efficiency policy, timed zero-occupancy policy, indicator high-efficiency policy, indicator zero-occupancy policy, timed and indicator mixed high-efficiency policy, timed and indicator mixed zero-occupancy policy. This is equivalent to a test environment or a test cluster that is conducting a demand growth business test, performance test, or hot time period test. The management POD will schedule the execution POD in the idle k8s cluster according to the pre-entered elastic strategy, and then determine whether there is an execution POD in the idle k8s cluster. If not, the execution POD will be deployed in the idle k8s cluster. After the execution POD is deployed, the execution POD in the idle k8s cluster will be used to conduct the corresponding demand growth business test, performance test, or hot time period test at the same time, so that the execution POD can be elastically scaled. Specifically, Figure 7 As shown, when the A version execution POD in the tested cluster A is performing performance testing, the management POD will determine whether there is an execution POD in the idle k8s cluster B and the idle k8s cluster C. If not, the execution POD will be deployed; if yes, the corresponding execution POD will be added to the performance test at the same time. It can be seen that the execution POD in this embodiment can be elastically scaled. When performing demand growth business testing, performance testing, or a hot time period test, the idle execution POD in other tested environments can be used according to the elastic strategy, and after the test is completed, it can be decided whether to clean up the idle execution POD according to the elastic strategy. Among them, the elastic strategy can be divided into a timing strategy, an indicator strategy, and a hybrid strategy, and each strategy corresponds to two states: high efficiency and zero occupancy. High efficiency means that after the test is completed, the management POD does not clean up the scheduled execution POD, and the execution POD at this time is in a low resource consumption state and remains available at any time. Zero occupancy means that the execution POD will be cleaned up by the management POD, and at the beginning of a new test, the management POD will redeploy the execution POD in the idle tested environment.

[0087] In an exemplary embodiment, after the user customizes the dedicated execution POD, if there is a problem or other problems, the method further includes: inputting a rollback instruction or rollback request, and directly rolling back the execution POD to the specified version through the management POD, so as not to affect the test process of the business system. In addition, the method can also use different customized versions of the execution POD according to the iterative version of the business system in the tested environment, for example, the automation framework version 1.0.0 in the execution POD can be matched to the business version 2.0.0, and the automation framework version 1.0.1 in the execution POD can be matched to the business version 2.0.1.

[0088] In summary, the present invention provides a distributed automated testing method based on a microservice architecture, first obtaining a management POD and an execution POD; then deploying the management POD in a virtual machine or server, and distributing multiple execution PODs in a test environment through the management POD; and using the management POD to call the interface service provided by each execution POD, and initiating a request or instruction to the corresponding execution POD based on the interface service; and then obtaining and displaying the automated testing results after each execution POD executes the corresponding request or instruction. This is equivalent to the method using a microservice approach, first deploying a management POD in a virtual machine or server, and then using this management POD to distribute and deploy multiple execution PODs in one or more test environments, so that the present application has a distributed feature. Even if the number of test environments increases, the execution POD only consumes a very small part of the performance of the test environment, which is not only easy to maintain, but also highly stable, and can make full use of idle test environments. Therefore, the method can solve the problem that the automated testing framework in the prior art is independent operation, high degree of centralization, and high cost of customized transformation by distributing multiple execution PODs. At the same time, this method can flexibly respond to the automated testing frameworks corresponding to different development languages ​​in the business POD, such as Junit for Java, pytest for Python, etc., through the distributed execution of POD, and each execution POD can be customized and loaded with different automation frameworks as needed. In addition, the OPENAPI service of the execution POD has the ability to be open to the outside world, and users can completely customize the access to their own automated testing platform to manage, schedule or develop new functions for the execution POD. It can also access its own or a third-party monitoring platform to maintain the running status of the execution POD. In addition, the execution POD in this method has the characteristics of multiple copies, elastic scaling, service fuses, version control, service rollback, etc., and the management POD can realize unified scheduling of the above characteristics.

[0089] The present application also provides a computer device, which may include: one or more processors; and one or more machine-readable media having instructions stored thereon, which, when executed by the one or more processors, enable the device to execute Fig. 9The method described. Fig.10 FIG. 1 is a schematic diagram showing a structure of a computer device 1000. Fig.10 As shown, the computer device 1000 includes: a processor 1010 , a memory 1020 , a power supply 1030 , a display unit 1040 , and an input unit 1060 .

[0090] The processor 1010 is the control center of the computer device 1000. It uses various interfaces and lines to connect various components, and executes various functions of the computer device 1000 by running or executing software programs and / or data stored in the memory 1020, thereby monitoring the computer device 1000 as a whole. In the embodiment of the present application, when the processor 1010 calls the computer program stored in the memory 1020, the following is executed: Fig. 9 The method described. Optionally, the processor 1010 may include one or more processing units; preferably, the processor 1010 may integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a user interface, and applications, etc., and the modem processor mainly processes wireless communications. In some embodiments, the processor and the memory may be implemented on a single chip, and in some embodiments, they may also be implemented separately on separate chips.

[0091] The memory 1020 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, various applications, etc.; the data storage area may store data created according to the use of the computer device 1000, etc. In addition, the memory 1020 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices, etc.

[0092] The computer device 1000 also includes a power source 1030 (such as a battery) for supplying power to various components. The power source can be logically connected to the processor 1010 through a power management system, so that the power management system can manage functions such as charging, discharging, and power consumption.

[0093] The display unit 1040 may be used to display information input by the user or information provided to the user and various menus of the computer device 1000, and in the embodiment of the present invention, is mainly used to display the display interface of each application in the computer device 1000 and objects such as text and pictures displayed in the display interface. The display unit 1040 may include a display panel 1050. The display panel 1050 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc.

[0094] The input unit 1060 may be used to receive information such as numbers or characters input by the user. The input unit 1060 may include a touch panel 1070 and other input devices 1080. The touch panel 1070, also known as a touch screen, may collect touch operations of the user on or near it (such as operations of the user using a finger, a stylus, or any other suitable object or accessory on or near the touch panel 1070).

[0095] Specifically, the touch panel 1070 can detect the user's touch operation, detect the signal brought by the touch operation, convert these signals into touch point coordinates, send them to the processor 1010, and receive and execute the command sent by the processor 1010. In addition, the touch panel 1070 can be implemented in various types such as resistive, capacitive, infrared and surface acoustic wave. Other input devices 1080 can include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, power on / off keys, etc.), a trackball, a mouse, a joystick, etc.

[0096] Of course, the touch panel 1070 can cover the display panel 1050. When the touch panel 1070 detects a touch operation on or near it, it is transmitted to the processor 1010 to determine the type of touch event, and then the processor 1010 provides a corresponding visual output on the display panel 1050 according to the type of touch event. Fig.10 In the embodiment, the touch panel 1070 and the display panel 1050 are two independent components to implement the input and output functions of the computer device 1000, but in some embodiments, the touch panel 1070 and the display panel 1050 can be integrated to implement the input and output functions of the computer device 1000.

[0097] The computer device 1000 may further include one or more sensors, such as a pressure sensor, a gravity acceleration sensor, a proximity light sensor, etc. Of course, according to the needs of specific applications, the computer device 1000 may also include other components such as a camera.

[0098] The embodiment of the present application also provides a computer-readable storage medium, in which instructions are stored. When one or more processors execute the instructions, the above-mentioned device can perform the above-mentioned Fig. 9 The method described.

[0099] It can be understood by those skilled in the art that Fig.10This is only an example of a computer device and does not constitute a limitation on the device. The device may include more or fewer components than shown in the figure, or combine certain components, or different components. For the convenience of description, the above parts are divided into modules (or units) according to their functions and described separately. Of course, when implementing this application, the functions of each module (or unit) can be implemented in the same or multiple software or hardware.

[0100] Those skilled in the art should understand that the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be applied to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the functions in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0101] It should be understood that, although the terms first, second, third, etc. may be used to describe preset ranges, etc. in the embodiments of the present invention, these preset ranges should not be limited to these terms. These terms are only used to distinguish preset ranges from each other. For example, without departing from the scope of the embodiments of the present invention, the first preset range may also be referred to as the second preset range, and similarly, the second preset range may also be referred to as the first preset range.

[0102] Therefore, the present invention effectively overcomes various shortcomings in the prior art and has a high industrial utilization value. The above embodiments are only illustrative of the principles and effects of the present invention, and are not intended to limit the present invention. Anyone familiar with the technology can modify or change the above embodiments without violating the spirit and scope of the present invention. Therefore, all equivalent modifications or changes made by those with ordinary knowledge in the technical field without departing from the spirit and technical ideas disclosed by the present invention should still be covered by the claims of the present invention.

Claims

1. A distributed automated testing device based on a microservice architecture, characterized in that: The device comprises: a first container combination and a second container combination; The first container combination is deployed in a virtual machine or a server, and the first container combination is used to distribute and deploy multiple second container combinations in a test environment, and call the interface service of the second container combination, initiate a request or instruction to each second container combination, and display the automated test result after each second container combination executes the request or instruction; The second container combination is used to provide an interface service, receive and execute a request or instruction initiated by the first container combination, and generate a corresponding automated test result; Among them, the first container combination includes: a deployment module, an instruction module, a collection module and a first storage module, the deployment module is used to distribute the multiple second container combinations in the test environment, and perform heartbeat keep-alive on each second container combination, and monitor the running status of each second container combination in real time; the instruction module is used to call the interface service provided by each second container combination, and initiate a request or instruction to the corresponding second container combination based on the interface service; the collection module is used to collect the test report, operation log and container combination health status inside each second container combination, and display the automated test results after each second container combination executes the request or instruction; the first storage module is connected to the deployment module, instruction module, and collection module respectively, and is used to store data in the deployment module, instruction module, and collection module; If there are multiple test environments, the process of the deployment module distributing the second container combination in multiple test environments includes: selecting a test environment from the multiple test environments, and determining whether the selected test environment has a target test; if there is a target test, obtaining a pre-entered policy type, and scheduling all idle clusters in the remaining test environments according to the policy type, and deploying one or more second container combinations in all idle clusters, and performing target testing using all second container combinations after the deployment is completed; if there is no target test, selecting another test environment from the multiple test environments for target test judgment; wherein the target test includes at least one of the following: demand growth business test, performance test, and hot time period test; the pre-entered policy types include at least one of the following: timed high-efficiency strategy, timed zero occupancy strategy, indicator high-efficiency strategy, indicator zero occupancy strategy, a high-efficiency strategy that mixes timing and indicators, and a zero occupancy strategy that mixes timing and indicators.

2. The distributed automated testing device based on microservice architecture according to claim 1, characterized in that: After the deployment module deploys a second container combination in a distributed manner in the test environment, the deployment module further includes: determining a fault state of the certain second container combination according to the operation log of the certain second container combination stored in the first storage module; If a fault occurs in the second container combination, a copy of the second container combination is obtained, and the copy of the second container combination is distributedly deployed in the test environment.

3. The distributed automated testing device based on microservice architecture according to claim 1, characterized in that: After the instruction module initiates a request or instruction to a second container combination based on the interface service, the method further includes: determining a fault state of the certain second container combination according to the operation log of the certain second container combination stored in the first storage module; If a fault occurs in the certain second container combination, stop initiating a request or instruction to the certain second container combination; If the certain second container combination does not have a fault, based on the interface service of the certain second container combination, continuously initiate a request or instruction to the certain second container combination.

4. The distributed automated testing device based on microservice architecture according to claim 2 or 3, characterized in that: The device also includes: a service rollback module, which is used to receive a rollback instruction or a rollback request input from the outside, and roll back the second container combination under the current version to a specified version according to the rollback instruction or the rollback request.

5. The distributed automated testing device based on microservice architecture according to any one of claims 1 to 3, characterized in that: The second container assembly comprises: An interface service module, used for providing an interface service and receiving a request or instruction initiated by the first container combination after calling the interface service; An operation module, configured to load a pre-installed automation framework and execute the received request or instruction based on the loaded automation framework; A reporting module, used to integrate the data when the operation module executes the request or instruction, and generate corresponding automated test results; A log module, used to generate operation logs of the interface service module, operation module and report module; The second storage module is connected to the interface service module, the operation module, the report module and the log module respectively, and is used to store data in the interface service module, the operation module, the report module and the log module.

6. A distributed automated testing method based on microservice architecture, characterized in that: The method comprises the following steps: Get a first container combination and a second container combination; Deploy the first container combination in a virtual machine or a server, and perform distributed deployment of multiple second container combinations in a test environment through the first container combination; Using the first container combination to call the interface service provided by each second container combination, and initiating a request or instruction to the corresponding second container combination based on the interface service; Obtain and display the automated test results after each second container combination executes the corresponding request or instruction; Among them, the first container combination includes: a deployment module, an instruction module, a collection module and a first storage module, the deployment module is used to distribute the multiple second container combinations in the test environment, and perform heartbeat keep-alive on each second container combination, and monitor the running status of each second container combination in real time; the instruction module is used to call the interface service provided by each second container combination, and initiate a request or instruction to the corresponding second container combination based on the interface service; the collection module is used to collect the test report, operation log and container combination health status inside each second container combination, and display the automated test results after each second container combination executes the request or instruction; the first storage module is connected to the deployment module, instruction module, and collection module respectively, and is used to store data in the deployment module, instruction module, and collection module; If there are multiple test environments, the process of the deployment module distributing the second container combination in multiple test environments includes: selecting a test environment from the multiple test environments, and determining whether the selected test environment has a target test; if there is a target test, obtaining a pre-entered policy type, and scheduling all idle clusters in the remaining test environments according to the policy type, and deploying one or more second container combinations in all idle clusters, and performing target testing using all second container combinations after the deployment is completed; if there is no target test, selecting another test environment from the multiple test environments for target test judgment; wherein the target test includes at least one of the following: demand growth business test, performance test, and hot time period test; the pre-entered policy types include at least one of the following: timed high-efficiency strategy, timed zero occupancy strategy, indicator high-efficiency strategy, indicator zero occupancy strategy, a high-efficiency strategy that mixes timing and indicators, and a zero occupancy strategy that mixes timing and indicators.

7. A computer device, characterized in that: include: processor; and A computer readable medium storing instructions, when the processor executes the instructions, causes the device to perform the method as claimed in claim 6.

8. A computer-readable medium, characterized in that Instructions are stored thereon, and the instructions are loaded by a processor to execute the method according to claim 6.

Images