A method, device, medium, and program product for automated testing

Abstract

The objective of this application is to provide a method for automated testing, which includes: receiving the test task sent by a second device in response to a submission operation performed by a user for a test task, where the test task includes test cases and test parameters; connecting to a highly available service according to the test parameters, performing at least one high-availability switching operation on the primary node and the secondary node of the highly available service, and executing at least one test case while performing the at least one high-availability switching operation; generating test report information corresponding to the test case, and returning the test report information to the second device. This application is compatible with specified highly available services and test metrics in interface testing to complete the automated execution of high-availability tasks, assist in performing periodic routine checks on high availability, and by combining high-availability automation on an automated testing platform, the reliability and effectiveness of highly available cluster services can be more ensured through periodic routine testing.

Description

Technical Field

[0001] This application relates to the field of communications, and in particular, to a technology for automated testing. Background Art

[0002] In the prior art, a high-availability cluster (HA Cluster) is the most basic server cluster technology in an IT infrastructure aimed at reducing service interruption time. By protecting the user's business programs from providing services uninterruptedly externally and minimizing the impact of failures caused by software, hardware, and human factors on the business, it is generally applied to databases, management nodes, load balancing nodes, etc. Summary of the Invention

[0003] An object of this application is to provide a method, device, medium, and program product for automated testing.

[0004] According to one aspect of this application, there is provided a method for automated testing, the method comprising:

[0005] Receiving the test task sent by a second device in response to a submission operation performed by a user for the test task, where the test task includes test cases and test parameters;

[0006] Connecting to a high-availability service according to the test parameters, performing at least one high-availability switching operation on the primary node and the secondary node of the high-availability service, and performing at least one of the test cases while performing the at least one high-availability switching operation;

[0007] Generating test report information corresponding to the test case, and returning the test report information to the second device.

[0008] According to another aspect of this application, there is provided a method for automated testing, the method comprising:

[0009] In response to a submission operation performed by a user for the test task, sending the test task to a first device so that the first device executes the test task, where the test task includes test cases and test parameters, and executing the test task includes connecting to a high-availability service according to the test parameters and performing at least one high-availability switching operation on the primary node and the secondary node of the high-availability service, and performing the test case while performing the high-availability switching operation, and generating test report information corresponding to the test case;

[0010] Receiving and presenting the test report information returned by the first device.

[0011] According to one aspect of this application, there is provided a first device for automated testing, the device comprising:

[0012] A module, configured to receive the test task sent by a second device in response to a submission operation performed by a user for a test task, where the test task includes test cases and test parameters;

[0013] A second module, configured to connect to a highly available service according to the test parameters, perform at least one high-availability switching operation on a primary node and a secondary node of the highly available service, and perform at least one of the test cases while performing the at least one high-availability switching operation;

[0014] A third module, configured to generate test report information corresponding to the test cases, and return the test report information to the second device.

[0015] According to another aspect of the present application, there is provided a second device for automated testing, the device includes:

[0016] A first module, configured to, in response to a submission operation performed by a user for a test task, send the test task to a first device, so that the first device executes the test task, where the test task includes test cases and test parameters, and executing the test task includes connecting to a highly available service according to the test parameters and performing at least one high-availability switching operation on a primary node and a secondary node of the highly available service, and performing the test cases while performing the high-availability switching operation, and generating test report information corresponding to the test cases;

[0017] A second module, configured to receive and present the test report information returned by the first device.

[0018] According to one aspect of the present application, there is provided a computer device for automated testing, including a memory, a processor, and a computer program stored on the memory, where the processor executes the computer program to implement the operations of any of the above methods.

[0019] According to one aspect of the present application, there is provided a computer-readable storage medium, on which a computer program is stored, characterized in that when the computer program is executed by a processor, the operations of any of the above methods are implemented.

[0020] According to one aspect of the present application, there is provided a computer program product, including a computer program, where when the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0021] Compared with the prior art, in the present application, a first device receives a test task sent by a second device in response to a submission operation performed by a user for a test task, where the test task includes test cases and test parameters; according to the test parameters, connect to a highly available service, perform at least one highly available switch operation on the primary node and the secondary node of the highly available service, and execute at least one of the test cases while performing the at least one highly available switch operation; generate test report information corresponding to the test cases, and return the test report information to the second device. The present application is compatible with a specified highly available service and test metrics in interface testing to complete the automated execution of highly available tasks, assist in performing periodic routine checks for high availability, and by combining high availability automation on an automated test platform, the reliability and effectiveness of the highly available cluster service can be more ensured through periodic routine tests. Expanding this function on the automated test platform and utilizing the existing module functions, the technology implementation is more efficient and convenient. High availability automation fully covers soapUI and jmeter test types in all dimensions, with stronger robustness, and the execution metrics are set through custom parameters, making it more flexible and expandable. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Other features, objects, and advantages of the present application will become more apparent by reading the detailed description of the non-limiting embodiments with reference to the following drawings:

[0023] Figure 1 FIG. shows a flowchart of a method for automated testing according to an embodiment of the present application;

[0024] Figure 2 FIG. shows a flowchart of a method for automated testing according to an embodiment of the present application;

[0025] Figure 3 FIG. shows a system flowchart of a method for automated testing according to an embodiment of the present application;

[0026] Figure 4 FIG. shows a structural diagram of a first device for automated testing according to an embodiment of the present application;

[0027] Figure 5 FIG. shows a structural diagram of a second device for automated testing according to an embodiment of the present application;

[0028] Figure 6 FIG. shows a presentation schematic diagram of a method for automated testing according to an embodiment of the present application;

[0029] Figure 7 FIG. shows a presentation schematic diagram of a method for automated testing according to an embodiment of the present application;

[0030] Figure 8Shows a presentation schematic diagram for automated testing according to an embodiment of the present application;

[0031] Figure 9 Shows an exemplary system that can be used to implement the various embodiments described in the present application.

[0032] Identical or similar reference numerals in the drawings represent identical or similar components. Detailed implementation manners

[0033] The present application will be further described in detail below with reference to the accompanying drawings.

[0034] In a typical configuration of the present application, the terminal, the devices of the service network, and the trusted party each include one or more processors (e.g., a Central Processing Unit (CPU)), an input / output interface, a network interface, and a memory.

[0035] The memory may include non-permanent memory in the computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of, for example, read only memory (ROM) or flash memory. The memory is an example of the computer-readable medium.

[0036] Computer-readable media includes both permanent and non-permanent, removable and non-removable media implemented by any method or technology for information storage. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, Phase-Change Memory (PCM), Programmable Random Access Memory (PRAM), Static Random-Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read-Only Memory (ROM), Electrically-Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technologies, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information that can be accessed by a computing device.

[0037] The devices referred to in this application include, but are not limited to, terminals, network devices, or devices formed by integrating a terminal and a network device through a network. The terminal includes, but is not limited to, any mobile electronic product that can perform human-computer interaction with a user (such as through a touchpad), such as a smart phone, a tablet computer, etc. The mobile electronic product can adopt any operating system, such as the Android operating system, the iOS operating system, etc. Among them, the network device includes an electronic device that can automatically perform numerical calculations and information processing according to pre-set or stored instructions. Its hardware includes, but is not limited to, a microprocessor, an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc. The network device includes, but is not limited to, a computer, a network host, a single network server, a set of multiple network servers, or a cloud composed of multiple servers; here, the cloud is composed of a large number of computers or network servers based on cloud computing (Cloud Computing), where cloud computing is a type of distributed computing and consists of a virtual supercomputer formed by a group of loosely coupled computer sets. The network includes, but is not limited to, the Internet, a wide area network, a metropolitan area network, a local area network, a VPN network, a wireless ad hoc network (Ad Hoc network), etc. Preferably, the device can also be a program running on the terminal, the network device, or a device formed by integrating a terminal and a network device, a network device, a touch terminal, or a network device and a touch terminal through a network.

[0038] Of course, those skilled in the art should understand that the above devices are only examples, and other existing or future devices that are applicable to this application should also be included within the protection scope of this application and are hereby incorporated by reference.

[0039] In the description of this application, "a plurality of" means two or more, unless otherwise specifically defined.

[0040] Figure 1A method flow chart for automated testing according to an embodiment of the present application is shown. The method includes step S11, step S12, and step S13. In step S11, a first device receives the test task sent by a second device in response to a submission operation performed by a user for a test task, where the test task includes test cases and test parameters; in step S12, the first device connects to a highly available service according to the test parameters, performs at least one highly available switching operation on the primary node and the secondary node of the highly available service, and executes at least one of the test cases while performing the at least one highly available switching operation; in step S13, the first device generates test report information corresponding to the test case and returns the test report information to the second device.

[0041] In step S11, a first device receives the test task sent by a second device in response to a submission operation performed by a user for a test task, where the test task includes test cases and test parameters. In some embodiments, the first device may be a backend server, which has deployed backend call scripts for interface automation testing, has deployed the testrunner.sh and jmeter.sh programs necessary for starting soapUI and jmeter projects for testing, and has deployed tomcat services and python-http services to store test result files for front-end access. In some embodiments, the second device may be a front-end server, which has deployed an automated testing platform for a jar service based on the springboot framework. In some embodiments, the test task includes, but is not limited to, interface test tasks of the soapUI type and interface test tasks of the jmeter type. In some embodiments, the second device sends the test task to the first device in response to a submission operation performed by a user (i.e., a tester) for a certain test task in the automated testing platform. In some embodiments, the test task includes, but is not limited to, test cases and test parameters. The test cases include, but are not limited to, xml test cases and jmx test cases. The test parameters include, but are not limited to, the type of highly available service specified by the user and the number of execution threads of the jmx test case. The types of highly available services supported by the first device include, but are not limited to, Redis, Eureka, Kafka, Zookeeper, Mongodb, etc. In some embodiments, a highly available service refers to an interface service that employs highly available cluster (HA Cluster) technology.

[0042] In step S12, the first device connects to the high-availability service according to the test parameters, performs at least one high-availability switching operation on the master node and the slave node of the high-availability service, and executes at least one of the test cases while performing the at least one high-availability switching operation. In some embodiments, after receiving the test task, the first device executes the test task based on the backend call script of the deployed interface automation test. The specific process of executing the test task includes connecting to the high-availability service of this type according to the high-availability service type in the test parameters, performing at least one high-availability switch on the master node and the slave node of the high-availability server, and executing at least one test case in the test task while performing the at least one high-availability switch. For all nodes (including the master node and the slave node) of the high-availability server, each execution of the high-availability switch means that after obtaining the current master and slave nodes of the high-availability service, killing the current master node, then querying for the new master node, and then restoring the original master node to complete the process of one high-availability switch. In some embodiments, the execution process of the test case in the interface test task of the soapUI type means executing the xml test case through the testrunner.sh command in the soapUI automation test framework, and the execution process of the test case in the interface test task of the jmeter type means executing the jmx test case through the jmeter.sh command in the jmeter automation test framework. In some embodiments, the high-availability switch and the test case are executed in two different threads respectively.

[0043] In step S13, the first device generates test report information corresponding to the test case and returns the test report information to the second device. In some embodiments, for an interface test task of the soapUI type, the result folder generated after the execution of the xml test case includes an html result page. By reading the execution result data of the test case in this html result page (for example, the number of TestCases test cases or test times, the number of Failures test failures, the number of Errors test errors, the Success rate test success rate, the Time test duration, etc.), after classifying the test cases according to the business modules maintained in the automated test platform, a csv file is created for each module, and the execution result data belonging to this module is written into it. Then, through the method encapsulated in the code library of the automated test platform, the csv file data under all modules included in this test task is written into the final test report. In some embodiments, for an interface test task of the jmeter type, a jtl test result file corresponding to the test case will be generated after the execution of the jmx test case. By reading the test result data in this jtl test result file, after classifying the test cases according to the business modules maintained in the automated test platform in the same way, a csv file is created for each module, and the test result data belonging to this module is written into it. Then, through the method encapsulated in the code library of the automated test platform, the csv file data under all modules included in this test task is written into the final test report. In some embodiments, while returning the test report to the second device for presentation, if the test parameters also include an email sending list, the test report will also be sent to the email recipients in the email sending list in the form of an email. Or, if the first device is already associated with a target publishing platform (such as an enterprise WeChat official account), the test report will also be directly pushed to this target publishing platform. Or, the test report is pushed to one or more accounts on this target publishing platform (such as the WeChat accounts of several recipients configured on the first device). Users can view and track the details of the test report through text messages and links. This application is compatible with specified high-availability services and test metrics in interface testing to complete the automated execution of high-availability tasks, assist in performing periodic routine checks for high availability. By combining high-availability automation on the automated test platform, the reliability and effectiveness of the high-availability cluster service can be more ensured through periodic routine tests. Expanding this function on the automated test platform and utilizing the existing module functions, the technology implementation is more efficient and convenient. The high-availability automation covers the soapUI and jmeter test types in all dimensions, with stronger usability and robustness. The execution metrics are set through custom parameters, which is more flexible and extensible.

[0044] In some embodiments, the test parameters include high-availability service identification information, and the test task further includes a configuration file; wherein, connecting to the high-availability service includes: obtaining cluster host IP information from the configuration file according to the high-availability service identification information, and connecting to the high-availability service according to the cluster host IP information. In some embodiments, the test task further includes a configuration file, in which there is a key-value pair mapping relationship between the high-availability service identification and the cluster host IP. The key is the high-availability service identification, and the value is the cluster host IP. The second device can obtain the cluster host IP mapped by the high-availability service identification from the configuration file according to the high-availability service identification in the test parameters, and then connect to the high-availability service corresponding to the high-availability service type in the test parameters according to the cluster host IP.

[0045] In some embodiments, the test parameters further include the high-availability test duration; wherein, step S12 includes: connecting to the high-availability service according to the test parameters, performing at least one high-availability switching operation on the primary node and the secondary node of the high-availability service within the high-availability test duration, and performing at least one test case while performing the at least one high-availability switching operation. In some embodiments, if the test parameters further include the high-availability test duration, then high-availability switching operations and test case executions are continuously performed within the high-availability test duration. In some embodiments, the two high-availability switching operations can be consecutive, or there can be a predetermined first time interval therebetween. The two test case executions can be consecutive, or there can be a predetermined second time interval therebetween. The first time interval and the second time interval can be the same, or they can be different.

[0046] In some embodiments, the test parameters further include the high-availability service switching times and the test case execution times; wherein, step S12 includes: the first device connecting to the high-availability service according to the test parameters, performing high-availability switching operations for the high-availability service switching times on the primary node and the secondary node of the high-availability service, and performing test cases for the test case execution times while performing the high-availability switching operations. In some embodiments, if the test parameters further include the high-availability service switching times and the test case execution times, then high-availability switching operations for the high-availability service switching times are performed, and test cases for the test case execution times are simultaneously performed while performing the high-availability switching operations.

[0047] In some embodiments, each high-availability switching operation includes step S14 (not shown). In step S14, the first device obtains the current master node and at least one current slave node of the high-availability service, kills the process of the current master node, performs a node query operation on the high-availability service. If a new current master node of the high-availability service is queried, the process of the current master node is restored, and the first predetermined duration is waited, and then step S14 is repeatedly executed. In some embodiments, first, the current master node and at least one current slave node of the high-availability service are obtained, then the process of the current master node is killed, and then a node query operation is performed on the high-availability service. If a new current master node of the high-availability service is queried, the new current master node is different from the original master node, that is, one of the original slave nodes becomes the new current master node, and the original master node becomes the new slave node. In some embodiments, if a new current master node of the high-availability service is queried, the process of the original master node is restored, and then the first predetermined duration is waited, and then step S14 is repeatedly executed until the total execution duration of step S14 reaches the high-availability test duration in the test parameters, or until the number of executions of step S14 reaches the number of high-availability service switches in the test parameters, where the first predetermined duration can be any value greater than or equal to 0. In some embodiments, the methods of killing the master node process and restoring the master node process vary depending on the deployment methods of different services. For example, for a service deployed in a docker container, the docker commands stop / start can be used to kill or restore the master node process, which is not limited herein, and those skilled in the art should be able to understand.

[0048] In some embodiments, step S14 includes: obtaining the current master node and at least one current slave node of the high-availability service, and killing the process of the current master node; performing a node query operation on the high-availability service. If a new current master node of the high-availability service is queried, the process of the current master node is restored; otherwise, continue to perform the node query operation on the high-availability service until a predetermined end query condition is met, and then restore the process of the current master node; wait for the first predetermined duration, and then repeat step S14. In some embodiments, if a new current master node of the high-availability service is queried, the process of the original master node is immediately restored; otherwise, continue to perform the node query operation on the high-availability service several times until a predetermined end query condition is met, stop continuing to perform the node query operation, and restore the process of the original master node. In some embodiments, the end query condition includes but is not limited to that the current number of query times reaches a predetermined number threshold, the current query duration reaches a predetermined duration threshold, or a new current master node of the high-availability service is queried.

[0049] In some embodiments, the continuing to perform the node query operation on the highly available service includes: waiting for a second predetermined duration and then continuing to perform the node query operation on the highly available service. In some embodiments, if a new current master node of the highly available service cannot be queried, first wait for the second predetermined duration, and then continue to perform the node query operation on the highly available service several times, with the interval between each node query operation also being the second predetermined duration, where the second predetermined duration can be any value greater than or equal to 0.

[0050] In some embodiments, the ending query conditions include at least one of the following: the current number of queries has reached a predetermined number threshold; the current query duration has reached a predetermined duration threshold; a new current master node of the highly available service has been queried. In some embodiments, the ending query condition can be that the total number of operations corresponding to the currently executed node query operations (the current number of queries) is greater than or equal to the predetermined number threshold, or it can also be that the total operation duration corresponding to the currently executed node query operations (the current query duration) is greater than or equal to the predetermined duration threshold, or it can also be that a new current master node of the highly available service has been queried during a certain node query operation, in which case the node query operation is no longer continued and the process of the original master node is restored.

[0051] In some embodiments, step S12 includes: the first device, in response to receiving the test task execution request for the test task sent by the second device, connects to the highly available service according to the test parameters, performs at least one high-availability switching operation on the master node and the slave node of the highly available service, and executes at least one of the test cases while performing the at least one high-availability switching operation, where the test task execution request is periodically generated by the second device according to the periodic expression input by the user for the test task. In some embodiments, the second device will periodically generate a test task execution request for the test task according to the periodic expression (cron expression) input by the user for the test task, and send the test task execution request to the first device. The first device will only execute the test task based on the backend call script of the deployed interface automation test after receiving the test task execution request. It can be understood that in this case, after receiving the test task sent by the second device, the first device will not automatically start executing the test task, but will start executing the test task every time it receives the test task execution request for the test task sent by the second device later.

[0052] In some embodiments, the test parameter further includes a cycle expression; wherein, step S12 includes: the first device periodically executes the test task according to the cycle expression, and the periodic execution of the test task includes connecting to the highly available service according to the test parameter, performing at least one highly available switch operation on the primary node and the secondary node of the highly available service, and executing at least one of the test cases while performing the at least one highly available switch operation. In some embodiments, the test parameter further includes a cycle expression (cron expression). After receiving the test task, the first device will periodically execute the test task based on the backend call script of the deployed interface automation test according to the cycle expression, that is, periodically execute the test task.

[0053] Figure 2 The flowchart of a method for automated testing according to an embodiment of the present application is shown. The method includes step S21 and step S22. In step S21, the second device sends the test task to the first device in response to a submission operation performed by the user for the test task, so that the first device executes the test task, where the test task includes test cases and test parameters, and the execution of the test task includes connecting to the highly available service according to the test parameters and performing at least one highly available switch operation on the primary node and the secondary node of the highly available service, and executing the test cases while performing the highly available switch operation, and generating test report information corresponding to the test cases; in step S22, the second device receives and presents the test report information returned by the first device.

[0054] In step S21, the second device responds to the submission operation performed by the user for the test task and sends the test task to the first device so that the first device executes the test task. The test task includes test cases and test parameters. Executing the test task includes connecting to the highly available service according to the test parameters and performing at least one highly available switching operation on the master node and the slave node of the highly available service, and executing the test cases while performing the highly available switching operation and generating test report information corresponding to the test cases. In some embodiments, the first device may be a backend server, which has deployed backend call scripts for interface automation testing, has deployed testrunner.sh and jmeter.sh programs necessary for starting soapUI and jmeter project scripts for testing, has deployed tomcat services and python-http services to store test result files for front-end access. In some embodiments, the second device may be a front-end server, which has deployed an automated testing platform for jar services based on the springboot framework. In some embodiments, the test task includes, but is not limited to, interface test tasks of the soapUI type and interface test tasks of the jmeter type. In some embodiments, the second device responds to the submission operation performed by the user (i.e., the tester) for a certain test task in the automated testing platform and sends the test task to the first device. In some embodiments, the test task includes, but is not limited to, test cases and test parameters. The test cases include, but are not limited to, xml test cases and jmx test cases. The test parameters include, but are not limited to, the type of highly available service specified by the user and the number of execution threads of the jmx test case. The types of highly available services supported by the first device include, but are not limited to, Redis, Eureka, Kafka, Zookeeper, Mongodb, etc. In some embodiments, the highly available service refers to an interface service that adopts the highly available cluster (HA Cluster) technology. In some embodiments, after receiving the test task, the first device will execute the test task based on the deployed backend call scripts for interface automation testing. The specific process of executing the test task includes connecting to the highly available service of this type according to the type of highly available service in the test parameters, and performing at least one highly available switch on the master (master) node and the slave (slave) node of the highly available server, and executing at least one test case in the test task while performing the at least one highly available switch. For all nodes of the highly available server (including the master node and the slave node), each execution of the highly available switch refers to the process of killing the current master node after obtaining the current master-slave nodes of the highly available service, then querying for the new master node, and then restoring the original master node to complete one highly available switch process.In some embodiments, the execution process of test cases in the interface test task of the soapUI type refers to executing xml test cases through the testrunner.sh command in the soapUI automation test framework, and the execution process of test cases in the interface test task of the jmeter type refers to executing jmx test cases through the jmeter.sh command in the jmeter automation test framework. In some embodiments, the high-availability switchover and test cases are executed in two different threads respectively.

[0055] In step S22, the second device receives and presents the test report information returned by the first device. In some embodiments, for the interface test task of the soapUI type on the first device, the result folder generated after the execution of the xml test case includes an html result page. By reading the execution result data of the test case in this html result page (for example, the number of TestCases test cases or test times, the number of Failures test failures, the number of Errors test errors, the Success rate test success rate, the Time test duration, etc.), after classifying the test cases according to the business modules maintained in the automation test platform, create a csv file in units of modules, write the execution result data belonging to this module, and then through the method encapsulated in the code library of the automation test platform, write the data of the csv files under all modules included in this test task into the final test report. In some embodiments, for the interface test task of the jmeter type on the first device, a jtl test result file corresponding to this test case will be generated after the execution of the jmx test case. By reading the test result data in this jtl test result file, after classifying the test cases according to the business modules maintained in the automation test platform in the same way, create a csv file in units of modules, write the test result data belonging to this module, and then through the method encapsulated in the code library of the automation test platform, write the data of the csv files under all modules included in this test task into the final test report. In some embodiments, the first device provides the test report to the second device and presents the test report to the user (tester). In some embodiments, while presenting the test report, if the test parameters also include an email sending list, the second device will also send the test report to the email recipients in the email sending list in the form of an email, or, if the second device is associated with the target publishing platform (for example, the enterprise WeChat official account), it will also directly push the test report to this target publishing platform, or push the test report to one or more accounts on this target publishing platform (for example, the WeChat accounts of several recipients configured on the second device), and the user can view and track the details of the test report through text information and links.

[0056] In some embodiments, the test parameters include high-availability service identification information, and the test task further includes a configuration file, so that the first device obtains cluster host IP information from the configuration file according to the high-availability service identification information, and connects to the high-availability service according to the cluster host IP information. In some embodiments, the user (tester) needs to create the test task first, and can input (fill in or select) the test cases and the test parameters corresponding to the test task when creating it. Alternatively, after creating the test task, the test cases and the test parameters corresponding to the test task can also be set. In some embodiments, the test task further includes a configuration file, and the configuration file stores a key-value pair mapping relationship between the high-availability service identification and the cluster host IP. The key is the high-availability service identification, and the value is the cluster host IP. The second device can obtain the cluster host IP mapped by the high-availability service identification from the configuration file according to the high-availability service identification in the test parameters, and then connect to the high-availability service corresponding to the high-availability service type in the test parameters according to the cluster host IP.

[0057] In some embodiments, the method further includes: in response to a test task creation operation performed by the user on the test project, the second device obtains the test cases and the test parameters input by the user, and creates the test task, where the test project includes the configuration file. In some embodiments, the user (tester) needs to create a test project first, and then create a test task belonging to the test project under the test project. The user needs to input (fill in or select) the test cases and the test parameters corresponding to the test task on the test task creation page to complete the creation of the test task. In some embodiments, each test project corresponds to a configuration file, and all test tasks under the test project use the configuration file. In some embodiments, each test project may correspond to one or more configuration files, and the user needs to select the configuration file used by the test project when creating a test task belonging to the test project. In some embodiments, the user can input the configuration file corresponding to the test project when creating the test project, or, after creating the test project, the configuration file corresponding to the test project can also be set. In some embodiments, the test projects are divided into two categories, namely the soapUI type and the jmeter type. If the test project is of the soapUI type, all test tasks under the test project are soapUI type interface test tasks. If the test project is of the jmeter type, all test tasks under the test project are jmeter type interface test tasks. As an example, such as Figure 6As shown, a user (tester) can create a test project on the test project page of the automated testing platform and input (fill in or select) information such as the project name, project description, and project type of the test project. Then, all the created test projects in the automated testing platform will be presented on the test project page. As an example, as Figure 7 shown, the user (tester) can set the corresponding configuration name for each test project on the test configuration page in the automated testing platform. Among them, each configuration name corresponds to a configuration file that has been uploaded to the automated testing platform. As an example, as Figure 8 shown, the user can create a test task on the interface testing page of the automated testing platform, specify the test project to which the test task belongs and the test cases used by the test task, and can also input the corresponding custom parameters, email list, and cycle expression of the test task. For example, Figure 8 the custom parameter in

[0058] is "--HA redis--HAConfig redis--duration 30m". "--HA" is used to specify the type of the high-availability service corresponding to the test task (such as "redis"), "--HAConfig" is used to specify the identifier of the high-availability service corresponding to the test task (such as "redis"), and "--duration" is used to specify the high-availability test duration corresponding to the test task (such as "30m"). Then, the user can click the "Save" button on the interface testing page to complete the creation of the test task.

[0059] In some embodiments, the test parameter further includes a periodic expression, so that the first device periodically executes the test task according to the periodic expression. In some embodiments, the test parameter further includes a periodic expression (cron expression). After receiving the test task, the first device will, according to the periodic expression, periodically execute the test task based on the backend call script of the deployed interface automation test, that is, periodically execute the test task.

[0060] In some embodiments, the method further includes: the second device obtains the periodic expression input by the user for the test task; according to the periodic expression, periodically generates a test task execution request for the test task and sends it to the first device, so that the first device executes the test task in response to receiving the test task execution request. In some embodiments, the second device will, according to the periodic expression (cron expression) input by the user for the test task, periodically generate a test task execution request for the test task and send the test task execution request to the first device. The first device will execute the test task based on the backend call script of the deployed interface automation test only after receiving the test task execution request. We can understand that in this case, after receiving the test task sent by the second device, the first device will not automatically start executing the test task, but will start executing the test task only after receiving the test task execution request for the test task sent by the second device each time thereafter.

[0061] Figure 3 Shows a flowchart of a system method for automated testing according to an embodiment of the present application.

[0062] As Figure 3 shown, in step S31, the second device sends the test task to the first device in response to the submission operation performed by the user for the test task execution. Among them, the test task includes test cases and test parameters. This step is the same as or similar to the foregoing step S21 and will not be elaborated here; in step S32, the first device receives the test task, connects to the highly available service according to the test parameters, performs at least one highly available switching operation on the primary node and the secondary node of the highly available service, and executes at least one of the test cases while performing the at least one highly available switching operation. This step is the same as or similar to the foregoing steps S11 and S12 and will not be elaborated here; in step S33, the first device generates test report information corresponding to the test case and returns the test report information to the second device. This step is the same as or similar to the foregoing step S13 and will not be elaborated here; in step S33, the second device receives and presents the test report information. This step is the same as or similar to the foregoing step S22 and will not be elaborated here.

[0063] Figure 4 shows a structural diagram of a first device for automated testing according to an embodiment of the present application. The device includes a module 11, a module 12, and a module 13. The module 11 is configured to receive the test task sent by a second device in response to a submission operation performed by a user for a test task. Wherein, the test task includes test cases and test parameters. The module 12 is configured to connect to a highly available service according to the test parameters, perform at least one highly available switching operation on the primary node and the secondary node of the highly available service, and execute at least one of the test cases while performing the at least one highly available switching operation. The module 13 is configured to generate test report information corresponding to the test cases and return the test report information to the second device.

[0064] The module 11 is configured to receive the test task sent by a second device in response to a submission operation performed by a user for a test task. Wherein, the test task includes test cases and test parameters. In some embodiments, the first device may be a backend server, which has deployed backend call scripts for interface automation testing, has deployed the necessary testrunner.sh and jmeter.sh programs for starting soapUI and jmeter projects, and has deployed tomcat services and python-http services to store test result files for front-end access. In some embodiments, the second device may be a front-end server, which has deployed an automated testing platform based on a springboot framework jar service. In some embodiments, the test task includes, but is not limited to, interface test tasks of the soapUI type and interface test tasks of the jmeter type. In some embodiments, the second device sends the test task to the first device in response to a submission operation performed by a user (i.e., a tester) for a certain test task in the automated testing platform. In some embodiments, the test task includes, but is not limited to, test cases and test parameters. The test cases include, but are not limited to, xml test cases and jmx test cases. The test parameters include, but are not limited to, the type of highly available service specified by the user and the number of execution threads of the jmx test case. The types of highly available services supported by the first device include, but are not limited to, Redis, Eureka, Kafka, Zookeeper, Mongodb, etc. In some embodiments, a highly available service refers to an interface service that employs a highly available cluster (HA Cluster) technology.

[0065] A first and second module 12 is configured to connect to a highly available service according to the test parameters, perform at least one high-availability switching operation on the primary node and the secondary node of the highly available service, and execute at least one of the test cases while performing the at least one high-availability switching operation. In some embodiments, after receiving the test task, the first device executes the test task based on the backend call script of the deployed interface automation test. The specific process of executing the test task includes connecting to the highly available service of the corresponding type according to the highly available service type in the test parameters, performing at least one high-availability switch on the primary (master) node and the secondary (slave) node of the highly available server, and executing at least one test case in the test task while performing the at least one high-availability switch. For all nodes (including the primary node and the secondary node) of the highly available server, each execution of the high-availability switch refers to the process of killing the current primary node after obtaining the current primary and secondary nodes of the highly available service, then querying for a new primary node, and then restoring the original primary node to complete one high-availability switch. In some embodiments, the execution process of the test case in the interface test task of the soapUI type refers to executing the xml test case through the testrunner.sh command in the soapUI automation test framework, and the execution process of the test case in the interface test task of the jmeter type refers to executing the jmx test case through the jmeter.sh command in the jmeter automation test framework. In some embodiments, the high-availability switch and the test case are executed in two different threads respectively.

[0066] A test report information generation module 13 is configured to generate test report information corresponding to the test case and return the test report information to the second device. In some embodiments, for an interface test task of the soapUI type, an html result page is included in the result folder generated after the xml test case is executed. By reading the execution result data of the test case in the html result page (e.g., the number of TestCases test cases or test times, the number of Failures test failures, the number of Errors test errors, the Success rate test success rate, the Time test duration, etc.), after classifying the test cases according to the business modules maintained in the automated test platform, a csv file is created for each module, and the execution result data belonging to the module is written into it. Then, through the method encapsulated in the code library of the automated test platform, the csv file data under all modules included in the test task is written into the final test report. In some embodiments, for an interface test task of the jmeter type, a jtl test result file corresponding to the test case is generated after the jmx test case is executed. By reading the test result data in the jtl test result file, after classifying the test cases according to the business modules maintained in the automated test platform in the same way, a csv file is created for each module, and the test result data belonging to the module is written into it. Then, through the method encapsulated in the code library of the automated test platform, the csv file data under all modules included in the test task is written into the final test report. In some embodiments, while returning the test report to the second device for presentation, if the test parameters also include an email sending list, the test report is also sent to the email recipients in the email sending list in the form of an email. Or, if the first device is already associated with a target publishing platform (e.g., an enterprise WeChat official account), the test report will also be directly pushed to the target publishing platform. Or, the test report is pushed to one or more accounts on the target publishing platform (e.g., WeChat accounts of several recipients configured on the first device), and users can view and track the details of the test report through text messages and links. This application is compatible with specified high-availability services and test metrics in interface testing to complete the automated execution of high-availability tasks, assisting in performing periodic routine checks for high availability. By combining high-availability automation on the automated test platform, the reliability and effectiveness of the high-availability cluster service can be more ensured through periodic routine tests. Expanding this function on the automated test platform and leveraging the existing module functions, the technology implementation is more efficient and convenient. High-availability automation comprehensively covers the soapUI and jmeter test types, with stronger usability and robustness. The execution metrics are set through custom parameters, making it more flexible and extensible.

[0067] In some embodiments, the test parameters include high-availability service identification information, and the test task further includes a configuration file; wherein, connecting to the high-availability service includes: obtaining cluster host IP information from the configuration file according to the high-availability service identification information, and connecting to the high-availability service according to the cluster host IP information. Here, the related operations are the same as or similar to those in Figure 1 the embodiments shown, so they will not be elaborated here and are included herein by reference.

[0068] In some embodiments, the test parameters further include the high-availability test duration; wherein, the first and second module 12 is configured to: connect to the high-availability service according to the test parameters, perform at least one high-availability switching operation on the primary node and the secondary node of the high-availability service within the high-availability test duration, and execute at least one of the test cases while performing the at least one high-availability switching operation. Here, the related operations are the same as or similar to those in Figure 1 the embodiments shown, so they will not be elaborated here and are included herein by reference.

[0069] In some embodiments, the test parameters further include the number of high-availability service switches and the number of test case executions; wherein, the first and second module 12 is configured to: connect to the high-availability service according to the test parameters, perform the high-availability switching operation of the number of high-availability service switches on the primary node and the secondary node of the high-availability service, and execute the test cases of the number of test case executions while performing the high-availability switching operation. Here, the related operations are the same as or similar to those in Figure 1 the embodiments shown, so they will not be elaborated here and are included herein by reference.

[0070] In some embodiments, each high-availability switching operation includes a fourteenth module 14 (not shown). The fourteenth module 14 is configured to obtain the current primary node and at least one current secondary node of the high-availability service, kill the process of the current primary node, perform a node query operation on the high-availability service, if a new current primary node of the high-availability service is queried, resume the process of the current primary node, wait for a first predetermined duration, and then repeat the execution of the fourteenth module 14. Here, the related operations are the same as or similar to those in Figure 1 the embodiments shown, so they will not be elaborated here and are included herein by reference.

[0071] In some embodiments, the 1-4 module 14 is configured to: obtain the current master node and at least one current slave node of the highly available service, and kill the process of the current master node; perform a node query operation on the highly available service, and if a new current master node of the highly available service is queried, resume the process of the current master node; otherwise, continue to perform the node query operation on the highly available service until a predetermined end query condition is met, and then resume the process of the current master node; wait for a first predetermined duration, and then repeat the execution of the 1-4 module 14. Here, the related operations are the same as or similar to those in Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0072] In some embodiments, the step of continuing to perform the node query operation on the highly available service includes: waiting for a second predetermined duration and then continuing to perform the node query operation on the highly available service. Here, the related operations are the same as or similar to those in Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0073] In some embodiments, the end query condition includes at least one of the following: the current number of query times reaches a predetermined number threshold; the current query duration reaches a predetermined duration threshold; a new current master node of the highly available service is queried. Here, the related operations are the same as or similar to those in Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0074] In some embodiments, the 1-2 module 12 is configured to: in response to receiving a test task execution request for the test task sent by the second device, connect to the highly available service according to the test parameters, perform at least one high-availability switching operation on the master node and the slave nodes of the highly available service, and execute at least one of the test cases while performing the at least one high-availability switching operation, where the test task execution request is periodically generated by the second device according to a cycle expression input by the user for the test task. Here, the related operations are the same as or similar to those in Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0075] In some embodiments, the test parameters further include a cycle expression; wherein, the 1-2 module 12 is configured to: periodically execute the test task according to the cycle expression, where the periodic execution of the test task includes connecting to the highly available service according to the test parameters, performing at least one high-availability switching operation on the master node and the slave nodes of the highly available service, and executing at least one of the test cases while performing the at least one high-availability switching operation. Here, the related operations are the same as or similar to those in Figure 1The embodiments shown are the same as or similar to those described above, so they will not be elaborated here and are incorporated herein by reference.

[0076] Figure 5 FIG. shows a structural diagram of a second device for automated flow measurement according to an embodiment of the present application. The device includes a module 21 and a module 22. The module 21 is configured to, in response to a submission operation performed by a user for a test task, send the test task to a first device, so that the first device executes the test task. Wherein, the test task includes a test case and test parameters, and the execution of the test task includes connecting to a highly available service according to the test parameters and performing at least one high-availability switching operation on the primary node and the secondary node of the highly available service, and executing the test case while performing the high-availability switching operation, and generating test report information corresponding to the test case; The module 22 is configured to receive and present the test report information returned by the first device.

[0077] A 21-module, which is configured to send the test task to a first device in response to a submission operation performed by a user for the execution of a test task, so that the first device executes the test task. The test task includes test cases and test parameters. The execution of the test task includes connecting to a highly available service according to the test parameters and performing at least one highly available switching operation on the master node and the slave node of the highly available service, and executing the test cases while performing the highly available switching operation, and generating test report information corresponding to the test cases. In some embodiments, the first device may be a backend server, on which backend call scripts for interface automation testing are deployed, testrunner.sh and jmeter.sh programs necessary for starting soapUI and jmeter project scripts are deployed, tomcat service and python-http service are deployed to store test result files for front-end access. In some embodiments, the second device may be a front-end server, on which an automation testing platform based on a springboot framework jar service is deployed. In some embodiments, the test task includes, but is not limited to, interface test tasks of the soapUI type and interface test tasks of the jmeter type. In some embodiments, the second device sends the test task to the first device in response to a submission operation performed by a user (i.e., a tester) for a certain test task in the automation testing platform. In some embodiments, the test task includes, but is not limited to, test cases and test parameters. The test cases include, but are not limited to, xml test cases and jmx test cases. The test parameters include, but are not limited to, the type of highly available service specified by the user and the number of execution threads of the jmx test case. The types of highly available services supported by the first device include, but are not limited to, Redis, Eureka, Kafka, Zookeeper, Mongodb, etc. In some embodiments, the highly available service refers to an interface service that employs a highly available cluster (HA Cluster) technology. In some embodiments, after receiving the test task, the first device executes the test task based on the deployed backend call scripts for interface automation testing. The specific process of executing the test task includes connecting to the highly available service of this type according to the type of highly available service in the test parameters, and performing at least one highly available switch on the master (master) node and the slave (slave) node of the highly available server, and executing at least one test case in the test task while performing the at least one highly available switch. For all nodes (including the master node and the slave node) of the highly available server, each execution of the highly available switch refers to the process of obtaining the current master and slave nodes of the highly available service, killing the current master node, then querying for a new master node, and then restoring the original master node to complete one highly available switch process.In some embodiments, the execution process of test cases in an interface test task of the soapUI type refers to executing xml test cases through the testrunner.sh command in the soapUI automation test framework. The execution process of test cases in an interface test task of the jmeter type refers to executing jmx test cases through the jmeter.sh command in the jmeter automation test framework. In some embodiments, high-availability switching and test cases are executed in two different threads respectively.

[0078] Module 22, for receiving and presenting the test report information returned by the first device. In some embodiments, for an interface test task of the soapUI type on the first device, the result folder generated after the execution of xml test cases includes an html result page. By reading the execution result data of the test case in this html result page (for example, the number of TestCases test cases or test times, the number of Failures test failures, the number of Errors test errors, the Success rate test success rate, the Time test duration, etc.), after classifying the test cases according to the business modules maintained in the automated test platform, create a csv file in units of modules, write the execution result data belonging to this module, and then through the method encapsulated in the code library of the automated test platform, write the data of csv files under all modules included in this test task into the final test report. In some embodiments, for an interface test task of the jmeter type on the first device, a jtl test result file corresponding to this test case will be generated after the execution of jmx test cases. By reading the test result data in this jtl test result file, also classify the test cases according to the business modules maintained in the automated test platform, create a csv file in units of modules, write the test result data belonging to this module, and then through the method encapsulated in the code library of the automated test platform, write the data of csv files under all modules included in this test task into the final test report. In some embodiments, the first device provides the test report to the second device and presents the test report to the user (tester). In some embodiments, while presenting the test report, if the test parameters also include an email sending list, the second device will also send the test report to the email recipients in the email sending list in the form of an email. Or, if the second device is associated with the target publishing platform (for example, the enterprise WeChat official account), it will also directly push the test report to this target publishing platform. Or, push the test report to one or more accounts on this target publishing platform (for example, the WeChat accounts of several recipients configured on the second device). The user can view and track the details of the test report through text information and links.

[0079] In some embodiments, the test parameters include high-availability service identification information, and the test task further includes a configuration file, so that the first device obtains cluster host IP information from the configuration file according to the high-availability service identification information, and connects to the high-availability service according to the cluster host IP information. Here, the related operations are the same as or similar to those of Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0080] In some embodiments, the device is further configured to: in response to a test task creation operation performed by the user on a test item, obtain the test case and the test parameters input by the user, and create the test task, where the test item includes the configuration file. Here, the related operations are the same as or similar to those of Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0081] In some embodiments, the test parameters further include at least one of the following: the number of high-availability service switches; the number of test case executions; the duration of high-availability testing. Here, the related operations are the same as or similar to those of Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0082] In some embodiments, the test parameters further include a cycle expression, so that the first device periodically executes the test task according to the cycle expression. Here, the related operations are the same as or similar to those of Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0083] In some embodiments, the device is further configured to: obtain the cycle expression input by the user for the test task; according to the cycle expression, periodically generate a test task execution request for the test task and send it to the first device, so that the first device executes the test task in response to receiving the test task execution request. Here, the related operations are the same as or similar to those of Figure 1 the embodiments shown, so they will not be elaborated here and are incorporated herein by reference.

[0084] In addition to the methods and devices introduced in the above embodiments, the present application further provides a computer-readable storage medium, where the computer-readable storage medium stores computer code, and when the computer code is executed, the method as described in any one of the previous items is executed.

[0085] The present application further provides a computer program product, and when the computer program product is executed by a computer device, the method as described in any one of the previous items is executed.

[0086] The present application also provides a computer device, which includes:

[0087] One or more processors;

[0088] A memory for storing one or more computer programs;

[0089] When the one or more computer programs are executed by the one or more processors, the one or more processors are caused to implement the method as described in any of the previous items.

[0090] Figure 9 Illustrates an exemplary system that can be used to implement the various embodiments described in the present application;

[0091] As Figure 9 shown in some embodiments, the system 300 can act as any one of the devices in the various embodiments. In some embodiments, the system 300 may include one or more computer-readable media having instructions (e.g., system memory or NVM / storage device 320) and one or more processors (e.g., (one or more) processors 305) coupled to the one or more computer-readable media and configured to execute the instructions to implement modules to perform the actions described in the present application.

[0092] For one embodiment, the system control module 310 may include any suitable interface controller to provide any suitable interface to at least one of the (one or more) processors 305 and / or any suitable device or component communicating with the system control module 310.

[0093] The system control module 310 may include a memory controller module 330 to provide an interface to the system memory 315. The memory controller module 330 may be a hardware module, a software module, and / or a firmware module.

[0094] The system memory 315 may be used to, for example, load and store data and / or instructions for the system 300. For one embodiment, the system memory 315 may include any suitable volatile memory, e.g., suitable DRAM. In some embodiments, the system memory 315 may include double data rate type four synchronous dynamic random access memory (DDR4 SDRAM).

[0095] For one embodiment, the system control module 310 may include one or more input / output (I / O) controllers to provide an interface to the NVM / storage device 320 and the (one or more) communication interfaces 325.

[0096] For example, the NVM / storage device 320 can be used to store data and / or instructions. The NVM / storage device 320 can include any suitable non-volatile memory (e.g., flash memory) and / or can include any suitable (one or more) non-volatile storage devices (e.g., one or more hard disk drives (HDDs), one or more compact discs (CDs) drives, and / or one or more digital versatile discs (DVDs) drives).

[0097] The NVM / storage device 320 can include storage resources that are physically part of the device on which the system 300 is installed, or it can be accessed by the device without being part of the device. For example, the NVM / storage device 320 can be accessed via a network through the (one or more) communication interfaces 325.

[0098] (One or more) communication interfaces 325 can provide an interface for the system 300 to communicate through one or more networks and / or with any other suitable device. The system 300 can communicate wirelessly with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols.

[0099] For one embodiment, at least one of the (one or more) processors 305 can be logically encapsulated with one or more controllers of the system control module 310 (e.g., the memory controller module 330). For one embodiment, at least one of the (one or more) processors 305 can be logically encapsulated with one or more controllers of the system control module 310 to form a system-in-package (SiP). For one embodiment, at least one of the (one or more) processors 305 can be logically integrated with one or more controllers of the system control module 310 on the same die. For one embodiment, at least one of the (one or more) processors 305 can be logically integrated with one or more controllers of the system control module 310 on the same die to form a system-on-chip (SoC).

[0100] In various embodiments, the system 300 can be, but is not limited to: a server, a workstation, a desktop computing device, or a mobile computing device (e.g., a laptop computing device, a handheld computing device, a tablet, a netbook, etc.). In various embodiments, the system 300 can have more or fewer components and / or a different architecture. For example, in some embodiments, the system 300 includes one or more cameras, a keyboard, a liquid crystal display (LCD) screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application specific integrated circuit (ASIC), and speakers.

[0101] It should be noted that the present application can be implemented in software and / or a combination of software and hardware. For example, it can be implemented using an application specific integrated circuit (ASIC), a general purpose computer, or any other similar hardware device. In one embodiment, the software program of the present application can be executed by a processor to implement the steps or functions described above. Similarly, the software program of the present application (including related data structures) can be stored in a computer-readable recording medium, such as a RAM memory, a magnetic or optical drive, or a floppy disk and the like. Additionally, some steps or functions of the present application can be implemented using hardware, for example, as a circuit that cooperates with a processor to execute each step or function.

[0102] In addition, a part of the present application can be applied as a computer program product, such as computer program instructions, which when executed by a computer, through the operation of the computer, can call or provide the methods and / or technical solutions according to the present application. Those skilled in the art should understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to the computer.

[0103] The communication medium includes a medium through which a communication signal containing, for example, computer-readable instructions, data structures, program modules, or other data is transmitted from one system to another system. The communication medium can include a guided transmission medium (such as cables and wires (e.g., optical fibers, coaxial, etc.)) and a wireless (unguided transmission) medium that can propagate energy waves, such as sound, electromagnetic, RF, microwave, and infrared. The computer-readable instructions, data structures, program modules, or other data can be embodied as, for example, a modulated data signal in a wireless medium (such as a carrier wave or a similar mechanism embodied as part of spread spectrum technology). The term "modulated data signal" refers to a signal whose one or more characteristics are changed or set in a manner that encodes information in the signal. The modulation can be analog, digital, or a hybrid modulation technique.

[0104] By way of example and not limitation, a computer-readable storage medium may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. For example, computer-readable storage media includes, but is not limited to, volatile memory such as random access memory (RAM, DRAM, SRAM); and non-volatile memory such as flash memory, various read-only memories (ROM, PROM, EPROM, EEPROM), magnetic and ferromagnetic / ferroelectric memories (MRAM, FeRAM); and magnetic and optical storage devices (hard disks, tapes, CDs, DVDs); or other media now known or later developed that can store computer-readable information / data for use by a computer system.

[0105] Here, an embodiment according to the present application includes a device that includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to run based on the methods and / or technical solutions according to the foregoing multiple embodiments of the present application.

[0106] For those skilled in the art, it is obvious that the present application is not limited to the details of the above exemplary embodiments, and the present application can be implemented in other specific forms without departing from the spirit or basic characteristics of the present application. Therefore, from any point of view, the embodiments should be regarded as exemplary and non-limiting. The scope of the present application is defined by the appended claims rather than the above description. Therefore, all changes falling within the meaning and scope of the equivalent elements of the claims are intended to be included in the present application. Any reference signs in the claims should not be construed as limiting the claims involved. In addition, it is obvious that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. The multiple units or devices stated in the apparatus claims can also be implemented by one unit or device through software or hardware. First, second, etc. are used to denote names and do not denote any particular order.

Claims

1. A method for automated testing, applied to a first device, wherein, The method includes: Receiving the test task sent by a second device in response to a submission operation performed by a user for the test task, where the test task includes test cases and test parameters, the test parameters include the highly available service type specified by the user, and the test task is an interface test task; Connecting to the highly available service according to the test parameters, performing at least one highly available switching operation on the primary node and the secondary node of the highly available service, and performing at least one of the test cases while performing the at least one highly available switching operation, where the highly available service includes an interface service adopting a highly available cluster technology, the highly available service corresponds to the highly available service type, and the highly available switching and the test case are executed in two different threads respectively; Generating test report information corresponding to the test case and returning the test report information to the second device, where the test report information includes test result data of the test case.

2. The method according to claim 1, wherein, The test parameters include highly available service identification information, and the test task further includes a configuration file; Wherein, the connecting to the highly available service includes: Obtaining cluster host IP information from the configuration file according to the highly available service identification information and connecting to the highly available service according to the cluster host IP information.

3. The method according to claim 2, wherein, The test parameters further include a highly available test duration; Wherein, the connecting to the highly available service according to the test parameters, performing at least one highly available switching operation on the primary node and the secondary node of the highly available service, and performing at least one of the test cases while performing the at least one highly available switching operation includes: Connecting to the highly available service according to the test parameters, and within the highly available test duration, performing at least one highly available switching operation on the primary node and the secondary node of the highly available service, and performing at least one of the test cases while performing the at least one highly available switching operation.

4. The method according to claim 2, wherein The test parameters further include the number of highly available service switchings and the number of test case executions; Wherein, the connecting to the highly available service according to the test parameters, performing at least one highly available switching operation on the primary node and the secondary node of the highly available service, and performing at least one of the test cases while performing the at least one highly available switching operation includes: Connecting to the highly available service according to the test parameters, performing the highly available switching operation of the number of highly available service switchings on the primary node and the secondary node of the highly available service, and performing the test case of the number of test case executions while performing the highly available switching operation.

5. The method according to claim 1, wherein, Each highly available switching operation includes: Step r: Obtaining the current primary node and at least one current secondary node of the highly available service, killing the process of the current primary node, performing a node query operation on the highly available service, if a new current primary node of the highly available service is queried, restoring the process of the current primary node, waiting for a first predetermined duration, and then repeating step r.

6. The method according to claim 5, wherein step r includes: Obtain the current master node and at least one current slave node of the highly available service, and kill the process of the current master node; Perform a node query operation on the highly available service. If a new current master node of the highly available service is queried, resume the process of the current master node; otherwise, continue to perform the node query operation on the highly available service until a predetermined end query condition is met, and then resume the process of the current master node; Wait for a first predetermined duration, and then repeat step r.

7. The method according to claim 6, wherein, The continuing to perform the node query operation on the highly available service includes: Wait for a second predetermined duration, and continue to perform the node query operation on the highly available service.

8. The method according to claim 6, wherein, The end query condition includes at least one of the following: The current number of query times has reached a predetermined number threshold; The current query duration has reached a predetermined duration threshold; A new current master node of the highly available service is queried.

9. The method according to claim 1, wherein The connecting to the highly available service according to the test parameters, performing at least one high-availability switching operation on the master node and the slave nodes of the highly available service, and performing at least one of the test cases while performing the at least one high-availability switching operation includes: In response to receiving a test task execution request for the test task sent by the second device, connect to the highly available service according to the test parameters, perform at least one high-availability switching operation on the master node and the slave nodes of the highly available service, and perform at least one of the test cases while performing the at least one high-availability switching operation, where the test task execution request is periodically generated by the second device according to a cycle expression input by the user for the test task.

10. The method according to claim 1, wherein, The test parameters further include a cycle expression; Wherein, the connecting to the highly available service according to the test parameters, performing at least one high-availability switching operation on the master node and the slave nodes of the highly available service, and performing at least one of the test cases while performing the at least one high-availability switching operation includes: Periodically execute the test task according to the cycle expression, where the periodically executing the test task includes connecting to the highly available service according to the test parameters, performing at least one high-availability switching operation on the master node and the slave nodes of the highly available service, and performing at least one of the test cases while performing the at least one high-availability switching operation.

11. A method for automated testing, applied to a second device, wherein, The method includes: In response to a submission operation performed by a user for a test task, send the test task to a first device so that the first device executes the test task, where the test task includes test cases and test parameters, the test parameters include the highly available service type specified by the user, the test task is an interface test task, and where executing the test task includes connecting to the highly available service according to the test parameters and performing at least one highly available switch operation on the primary node and the secondary node of the highly available service, and while performing the highly available switch operation, executing the test cases and generating test report information corresponding to the test cases, where the highly available service includes an interface service adopting a highly available cluster technology, the highly available service corresponds to the highly available service type, the highly available switch and the test cases are executed in two different threads respectively, and the test report information includes test result data of the test cases; Receive and present the test report information returned by the first device.

12. The method according to claim 11, wherein, The test parameters include highly available service identification information, and the test task further includes a configuration file so that the first device obtains cluster host IP information from the configuration file according to the highly available service identification information and connects to the highly available service according to the cluster host IP information.

13. The method according to claim 12, wherein, The method further includes: In response to a test task creation operation performed by the user for a test project, obtain the test cases and the test parameters input by the user and create the test task, where the test project includes the configuration file.

14. The method according to claim 11, wherein The test parameters further include at least one of the following: Number of highly available service switches; Number of test case executions; Highly available test duration.

15. The method according to claim 11, wherein, The test parameters further include a periodic expression so that the first device periodically executes the test task according to the periodic expression.

16. The method according to claim 11, wherein, The method further includes: Obtain the periodic expression input by the user for the test task; According to the periodic expression, periodically generate a test task execution request for the test task and send it to the first device so that the first device executes the test task in response to receiving the test task execution request.

17. A method for automated testing, wherein, The method includes: In response to a submission operation performed by a user for a test task, a second device sends the test task to a first device, where the test task includes test cases and test parameters, the test parameters include the highly available service type specified by the user, and the test task is an interface test task; The first device receives the test task, connects to the highly available service according to the test parameters, performs at least one highly available switch operation on the primary node and the secondary node of the highly available service, and while performing the at least one highly available switch operation, executes the test cases at least once, where the highly available service includes an interface service adopting a highly available cluster technology, the highly available service corresponds to the highly available service type, and the highly available switch and the test cases are executed in two different threads respectively; The first device generates test report information corresponding to the test case and returns the test report information to the second device, where the test report information includes test result data corresponding to the test case; The second device receives and presents the test report information.

18. A computer device for automated testing, comprising a memory, a processor, and a computer program stored on the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 17.

19. A computer-readable storage medium having computer programs / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, the steps of the method according to any one of claims 1 to 17 are implemented.

20. A computer program product comprising a computer program, characterized in that, When the computer program is executed by the processor, the steps of the method according to any one of claims 1 to 17 are implemented.

Images