Program multi-system testing method and its corresponding devices, equipment and media

Abstract

The present application discloses a method for multi-system testing of a program and its corresponding apparatus, equipment, and medium, the method comprising the following steps: adding the test tasks of different operating system versions of the target program to different test queues configured for different operating systems; in response to the dequeue event of the test task in any of the test queues, obtaining the installation package and test script of the target program of the corresponding operating system version, and sending them to the tested device installed with the corresponding operating system; starting the automatic testing process of the target program on the tested device, so that the target program applies the test script during the running process of the tested device after installation and collects the buried data and submits it to the data server; pulling the buried data from the data server, and sending the formatted results to the preset communication interface. The present application can meet the needs of testing multiple operating system versions of the program, and provide fully automated and efficient testing services according to different operating systems.

Description

Technical Field

[0001] The present application relates to the field of network live broadcast testing, and in particular to a program multi-system testing method, device and corresponding electronic equipment and non-volatile storage medium. Background Art

[0002] After the development is completed, the application (APP) for the terminal device needs to be tested before it can be released, so as to test the various performances of the application during its operation in the terminal device and promptly discover various potential operating problems, such as whether the pop-up window is normal, whether the business logic is correct, whether the human-computer interaction function is smooth, whether any abnormalities occur, etc.

[0003] The testing requirements of applications on the terminal device side, on the one hand, hope to realize touch response testing in multiple operating systems and multiple complex models through automation, on the other hand, consider the timeliness and require the ability to complete the test quickly, and on the other hand, hope to achieve centralized testing of unified business logic as much as possible. In order to meet these needs, the industry has proposed some automated solutions. For example, in the patent application No. CN112306887A published on February 2, 2021, it proposed a solution that can realize the automated implementation of application testing on terminal devices.

[0004] Despite this, there is still room for improvement in program testing efficiency. This is reflected in the fact that a program automation testing system is a system that centrally handles the testing of a large number of applications. It continuously implements tests on different applications based on test tasks, and needs to grasp the test results of each application in a timely manner. In this case, the task response mechanism of the automation testing system is likely to constitute a bottleneck in the efficiency of the system. Therefore, how to optimize the existing automation testing system to improve its automation testing efficiency has become a space for further improvement of the automation testing system. Summary of the invention

[0005] The purpose of the present application is to solve at least one of the above problems and to provide a program multi-system testing method and its corresponding device, computer equipment, and non-volatile storage medium, so as to implement automated distribution testing on application programs.

[0006] In order to meet the various objectives of this application, this application adopts the following technical solutions:

[0007] A program multi-system testing method provided for one of the purposes of this application comprises the following steps:

[0008] Add the test tasks of different operating system versions of the target program to different test queues configured for different operating systems;

[0009] In response to a dequeue event of a test task in any of the test queues, an installation package and a test script of the target program of the corresponding operating system version are obtained, and sent to a tested device installed with the corresponding operating system;

[0010] Initiate an automatic test process for the target program on the device under test, so that the target program applies the test script during the operation of the device under test after installation, collects the buried data and submits it to the data server;

[0011] Pull the buried point data from the data server and send the formatted result to the preset communication interface.

[0012] In a specific embodiment, adding the test tasks of different operating system versions of the target program to different test queues configured for different operating systems includes the following steps:

[0013] In response to a test task start event of the target program, a first test task and a second test task corresponding to the first operating system and the second operating system are generated;

[0014] Add the first test task to a first test queue, and add the second test task to a second test queue;

[0015] Start monitoring of dequeue events of the first test queue and the second test queue.

[0016] In a specific embodiment, in response to a dequeue event of a test task in any of the test queues, obtaining an installation package and a test script of the target program of the corresponding operating system version and sending them to a tested device installed with the corresponding operating system, comprises the following steps:

[0017] Accept the communication connection between the tested device and the local machine, and mark the operating system installed on each tested device;

[0018] In response to a dequeue event of a test task in any of the test queues, obtaining an installation package of the target program from an installation package server according to the operating system pre-associated with the test queue, and sending the installation package to a tested device installed with the corresponding operating system to complete its installation on the tested device;

[0019] The test script of the target program is obtained from a local database according to the operating system pre-associated with the test queue, and the test script is sent to the tested device on which the target program has been installed.

[0020] In a specific embodiment, after starting the automatic testing process of the target program on the device under test, the device under test executes the following steps:

[0021] Parse and execute the test script received in advance to simulate a series of operation events acting on the running interface of the target program to implement the test of the target program, and collect the tracking data according to the tracking instructions of the test script and submit it to the data server;

[0022] According to the instruction control of the test script, when it is detected that the target program is in a pop-up window blocking state, a control containing any one of multiple specific texts in the pop-up window is detected, and a click event of the control is triggered to eliminate the pop-up window.

[0023] In a preferred embodiment, the step of parsing and executing the pre-received test script includes:

[0024] According to the original identifier of the control specified in the instruction of the test script, the object mapping table attached to the installation package is queried to determine the encrypted identifier corresponding to the original identifier of the control, and the instruction is executed by replacing the original identifier with the encrypted identifier.

[0025] In a specific embodiment, the method of pulling the buried point data from the data server and sending the formatted result to a preset communication interface includes the following steps:

[0026] Pull the tracking data from the data server;

[0027] Performing statistical analysis on the buried point data to obtain analysis results;

[0028] Formatting the analysis result to obtain a formatted result;

[0029] The formatted result is sent to a preset communication interface.

[0030] In an extended embodiment, the multi-system testing method of the present application program further includes the following steps:

[0031] A notification indicating that the test is completed is received from the device under test, and a cleanup instruction is sent to the device under test to clean up the installation package and the test script of the target program previously sent to the device under test and uninstall the target program.

[0032] A program multi-system testing device is provided to meet one of the purposes of the present application, which includes a task diversion module, a task preparation module, a task execution module, and a task reporting module, wherein: the task diversion module is used to add the test tasks of different operating system versions of the target program to different test queues configured for different operating systems; the task preparation module is used to respond to the dequeue event of the test task in any one of the test queues, obtain the installation package and test script of the target program of the corresponding operating system version, and send them to the tested device installed with the corresponding operating system; the task execution module is used to start the automatic testing process of the target program on the tested device, so that the target program applies the test script during the operation of the tested device after installation and collects the buried data and submits it to the data server; the task reporting module is used to pull the buried data from the data server and send the formatted result to the preset communication interface.

[0033] In a specific embodiment, the task diversion module includes a task creation submodule, which is used to respond to the test task start event of the target program to generate the first test task and the second test task corresponding to the first operating system and the second operating system; a task enqueue submodule, which is used to add the first test task to the first test queue and the second test task to the second test queue; and a task monitoring submodule, which is used to start monitoring the dequeue events of the first test queue and the second test queue.

[0034] In a specific embodiment, the task preparation submodule includes: a device access submodule, which is used to accept the communication connection between the tested device and the local machine, and mark the operating system installed on each tested device; a dequeue installation submodule, which is used to respond to the dequeue event of the test task in any one of the test queues, obtain the installation package of the target program from the installation package server according to the operating system pre-associated with the test queue, and send the installation package to the tested device with the corresponding operating system installed to complete its installation on the tested device; a use case transmission submodule, which is used to obtain the test script of the target program from the local database according to the operating system pre-associated with the test queue, and send the test script to the tested device with the target program installed.

[0035] In a specific embodiment, the device under test is configured to include: parsing and executing a pre-received test script to simulate a series of operating events acting on the running interface of the target program to implement testing of the target program, and collecting tracking data according to the tracking instructions of the test script and submitting it to a data server; according to the instruction control of the test script, when it is monitored that the target program is in a pop-up window blocking state, detecting a control containing any one of multiple specific texts in the pop-up window, and triggering a click event of the control to eliminate the pop-up window.

[0036] In a preferred embodiment, the device under test is configured to include: querying the object mapping table attached to the installation package according to the original identifier of the control specified in the instruction of the test script, determining the encrypted identifier corresponding to the original identifier of the control, and executing the instruction with the encrypted identifier instead of the original identifier.

[0037] In a specific embodiment, the task reporting module includes: a data pulling submodule, used to pull the buried point data from a data server; a statistical analysis submodule, used to perform statistical analysis on the buried point data to obtain analysis results; a result processing submodule, used to format the analysis results to obtain formatted results; and a result notification submodule, used to send the formatted results to a preset communication interface.

[0038] In an extended embodiment, the multi-system testing device of the application program also includes a post-cleaning module, which is used to receive a notification returned by the tested device indicating that the test is completed, and send a cleanup instruction to the tested device to clean up the installation package and test script of the target program previously sent to the tested device and uninstall the target program.

[0039] A computer device provided to meet one of the purposes of the present application includes a central processing unit and a memory, wherein the central processing unit is used to call and run a computer program stored in the memory to execute the steps of the program multi-system testing method described in the present application.

[0040] A non-volatile storage medium is provided to meet another purpose of the present application, which stores a computer program implemented according to the program multi-system testing method in the form of computer-readable instructions. When the computer program is called and executed by a computer, the steps included in the method are executed.

[0041] Compared with the prior art, the advantages of this application are as follows:

[0042] The present application is adapted to the testing requirements of implementing tests on the same target program on tested devices with different operating systems. By constructing test queues for the tested devices with different operating systems one by one, each test queue is used to orderly handle the queuing and scheduling tests of different target programs of the same operating system. For the orderly queued target program test tasks, the corresponding test scripts can be applied to perform timely and efficient testing, thereby improving the ability of the automated testing system to serve the centralized testing of massive target programs, making the centralized testing of a large number of target programs with different operating system versions more orderly and efficient, and enabling the automated testing system to have the ability to be deployed on a platform and provide unified interface services, thereby greatly improving the implementation efficiency of software testing projects. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:

[0044] Figure 1 A schematic diagram of a typical deployment architecture related to implementing the technical solution of this application;

[0045] Figure 2 A flowchart of a typical embodiment of the program multi-system testing method of the present application;

[0046] Figure 3 A flowchart of a program multi-system testing method of the present application using two test queues to implement parallel testing;

[0047] Figure 4 A flowchart of a process of configuring a device under test for a test task in a program multi-system testing method of the present application;

[0048] Figure 5 A flowchart of the process of starting an automatic test process for the device under test of the present application;

[0049] Figure 6 A flowchart of the process of processing buried point data by the program multi-system testing method of this application;

[0050] Figure 7 A flowchart of another embodiment of the program multi-system testing method of the present application;

[0051] Figure 8 A schematic block diagram of a typical embodiment of a multi-system test device for the program of the present application;

[0052] Fig. 9 A schematic diagram of the structure of a computer device used in this application. DETAILED DESCRIPTION

[0053] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be interpreted as limiting the present application.

[0054] It will be understood by those skilled in the art that, unless expressly stated, the singular forms "one", "said", and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present application refers to the presence of the features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. It should be understood that when we refer to an element as being "connected" or "coupled" to another element, it may be directly connected or coupled to the other element, or there may be an intermediate element. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein includes all or any unit and all combinations of one or more associated listed items.

[0055] It will be understood by those skilled in the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as those generally understood by those skilled in the art to which this application belongs. It should also be understood that terms such as those defined in general dictionaries should be understood to have meanings consistent with those in the context of the prior art, and will not be interpreted with idealized or overly formal meanings unless specifically defined as here.

[0056] It will be understood by those skilled in the art that the "client", "terminal" and "terminal device" used herein include both devices with wireless signal receivers, which are devices with only wireless signal receivers without transmission capabilities, and devices with receiving and transmitting hardware, which are devices with receiving and transmitting hardware capable of two-way communication on a two-way communication link. Such devices may include: cellular or other communication devices such as personal computers, tablet computers, which have single-line displays or multi-line displays or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service, personal communication system), which can combine voice, data processing, fax and / or data communication capabilities; PDA (Personal Digital Assistant, personal digital assistant), which may include a radio frequency receiver, pager, Internet / intranet access, web browser, notepad, calendar and / or GPS (Global Positioning System, global positioning system) receiver; conventional laptop and / or palmtop computers or other devices, which have and / or include a conventional laptop and / or palmtop computer or other device with and / or including a radio frequency receiver. The "client", "terminal" and "terminal device" used herein may be portable, transportable, installed in a vehicle (air, sea and / or land), or suitable for and / or configured to run locally, and / or in a distributed form, at any other location on the earth and / or in space. The "client", "terminal" and "terminal device" used herein may also be a communication terminal, an Internet terminal, a music / video playing terminal, for example, a PDA, a MID (Mobile Internet Device) and / or a mobile phone with a music / video playing function, or a smart TV, a set-top box and other devices.

[0057] The hardware referred to by the names such as "server", "client", and "service node" in this application is essentially an electronic device with the equivalent capabilities of a personal computer. It is a hardware device with the necessary components revealed by the von Neumann principle, such as a central processing unit (including an arithmetic unit and a controller), a memory, an input device, and an output device. The computer program is stored in its memory, and the central processing unit calls the program stored in the external memory into the internal memory for execution, executes the instructions in the program, and interacts with the input and output devices to complete specific functions.

[0058] It should be pointed out that the concept of "server" referred to in this application can also be extended to the case of server clusters. According to the network deployment principle understood by those skilled in the art, the servers should be logically divided. In physical space, these servers can be independent of each other but can be called through interfaces, or integrated into a physical computer or a set of computer clusters. Those skilled in the art should understand this flexibility, and should not use it to restrict the implementation of the network deployment method of this application.

[0059] See also Figure 1 The hardware foundation required for the implementation of the relevant technical solutions of this application can be deployed according to the architecture shown in the figure, and the roles and functions of its various parts are revealed as follows:

[0060] The remote server 80 referred to in this application can be used as a front-end application server, which is responsible for further connecting to related data servers to form a logically related service cluster to provide services for related terminal devices such as smart phones 81, 82 and personal computers shown in the figure. The smart phones 81, 82 and personal computers can establish a data communication link with the remote server 80 through a well-known network access method.

[0061] The remote server 80 of the present application is suitable for providing Internet services such as live webcasting and instant messaging, and provides corresponding Internet services to corresponding terminal devices by running services, so that different users can use the services of the remote server 80 through their respective terminal devices to achieve the exchange of communication data between users. For example, one user can obtain another user's video stream, information, instructions, etc. through the remote server 80.

[0062] The terminal device of the present application is equipped with relevant operating systems, such as IOS, HMS (Hongmeng), Android and other operating systems that provide equivalent functions. With the support of such operating systems, the remote server 80 and the terminal device can communicate data through a communication link agreed upon by each other, and the application programs adaptively developed for these operating systems can also run normally in the terminal device. It is with the help of the operation of these application programs that the terminal device can realize human-computer interaction, remote interaction and various indirect interactions with other terminals through remote servers.

[0063] The master control server 88 referred to in this application is an independent device, which is mainly used to implement the program multi-system testing method of this application, so as to control the tested devices 81 and 82 of this application for testing. The tested devices 81 and 82 referred to in this application are the terminal devices, which are mainly responsible for implementing the background process that cooperates with the master control server in this application, so as to cooperate with the program multi-system testing method executed by the master control server to test the target program in the tested device. The master control server 88 and the terminal device work in the Server / Client mode, the master control server 88 implements control as the server end, and the tested devices 81 and 82 are tested as the client end. A physical wired connection or a wireless connection can be used to establish a communication link between the two, and even under the premise of the support of the operating system, this communication mechanism can be established through a third-party server on the public network. According to the principle of the present application, the main control server 88 implements the test by controlling multiple tested devices 81, 82. Each tested device 81, 82 exchanges communication data through the remote server under the control of the main control server 88, thereby realizing the testing of the interactive business processes of multiple tested devices 81, 82.

[0064] It should be pointed out that in order to support the formation of a C / S architecture between the main control server 88 and the devices under test 81, 82, the main control server 88 will implement the corresponding application program in accordance with the program multi-system testing method of the present application so that the method can be implemented after it is running to form the server side, and the devices under test 81, 82 will also be implanted with a background program for communicating with the server side and responsible for executing the instructions of the server side. This background program is implemented in accordance with the method of implementing the test in coordination with the program multi-system testing method of the present application. When the background program is running, it receives various instructions from the server side and executes corresponding functions, thereby enabling the devices under test 81, 82 to play the role of the client side.

[0065] The application referred to in this application generally refers to an application running on an electronic device such as a server or terminal device. These applications implement the relevant technical solutions of this application in a programming manner, and their program codes can be stored in a non-volatile storage medium that can be recognized by the computer in the form of computer executable instructions, and are loaded into the memory by the central processing unit for execution. The relevant device of this application is constructed by the operation of the application on the computer. Among them, the target program referred to in this application is the application under test, which will run in the tested devices 81 and 82, interact with the remote server through its operation, and use the services opened by the remote server.

[0066] Different tested devices 81 and 82 may run on different operating systems, such as IOS, Android, etc., so the target programs installed therein may also be developed in different native languages ​​of the operating systems. However, since the same target program is usually developed in accordance with certain functional logic regardless of its operating environment, it is just that the languages ​​used are different. Therefore, this situation does not affect the implementation of the present application. Similarly, the application program related to the present application in the master control server 88 and the target program related to the present application in the tested devices 81 and 82 may also be developed in different native languages, which does not affect the implementation of the present application.

[0067] The test script referred to in this application is used to describe a test process suitable for testing the target program. It is written in a high-level computer language, which is generally a language supported by the application program in the main control server 88 and responsible for implementing this application, such as Python, JavaScript, etc. It can logically form multiple branch processes with the help of if, case and other turn statements, and can be executed through execution statements, such as triggering an operation event or calling a method function through execution statements. As its basic function, the main task of these execution statements is to simulate a series of operation events acting on the running interface of the target program according to the needs of the test process, or to initiate a series of call instructions for calling the native function of the target program, and to trigger these operation events by sending the test script to the tested devices 81 and 82 for parsing, or to control the target program therein to execute the native function on demand to cooperate with the test through these call instructions sent to each corresponding tested device 81 and 82. It can be understood that the test script converts complicated manual operations into automatically executed operation commands, greatly reducing the repetitive operations of testers and improving test efficiency.

[0068] Those skilled in the art should be aware that, although the various methods of the present application are described based on the same concept and thus present commonality to each other, unless otherwise specified, these methods can be independently executed. Similarly, for each embodiment disclosed in the present application, they are all proposed based on the same inventive concept, therefore, concepts with the same expression, and concepts that are appropriately changed for convenience despite different expressions, should be understood as equivalent.

[0069] Unless the mutually exclusive relationship between the embodiments to be disclosed in this application is explicitly stated, the relevant technical features involved in each embodiment can be cross-combined to flexibly construct a new embodiment, as long as such combination does not deviate from the creative spirit of this application and can meet the needs of the prior art or solve certain deficiencies in the prior art. Those skilled in the art should be aware of this flexibility.

[0070] See also Figure 2 The present application discloses a program multi-system testing method, which is implemented by an application program on the master control server side. In a typical embodiment, it includes the following steps:

[0071] Step S11: Add the test tasks of different operating system versions of the target program to different test queues configured for different operating systems respectively.

[0072] For the same target program, the development team usually prepares installation packages adapted to different operating systems so that the target program can be run in terminal devices with different operating systems. The installation package can be uploaded to the master control server or remotely obtained by the master control server for calling during testing. The file format of the installation package depends on the terminal device operating system it is adapted to, such as files with the APK suffix in the Android operating system and files with the IPA suffix in the IOS operating system. Of course, corresponding installation packages for other operating systems can also be included.

[0073] In order to support the centralized and unified testing of applications, the master server pre-builds multiple test queues based on the different operating systems adapted by different installation packages. Each test queue is accessed based on the first-in-first-out principle, and each test queue is used to store test tasks adapted to the operating system associated with the test queue. For example, the first test queue is dedicated to the Android operating system, the second test queue is dedicated to the IOS operating system, the third test queue is dedicated to the HMS (Hongmeng) operating system... and so on. Correspondingly, the first test queue is used to store the test tasks of the Android version of the installation package of the target program, the second test queue is used to store the test tasks of the IOS version of the installation package of the target program, and the third test queue is used to store the test tasks of the HMS version of the installation package of the target program.

[0074] The test task can be a scheduled task triggered by a scheduled task system, or a manually pre-added task, which is used to trigger an automatic test process for a target program. When a test task is dequeued from the corresponding test queue, the automatic test process can be triggered.

[0075] When the target program needs to be tested, the developer can create a test task for it. The application will automatically adapt to the test task, detect whether there is an installation package version that is suitable for multiple operating systems, and adapt to each installation package version to derive a corresponding test task, that is, the first test task corresponding to the first operating system, the second test task corresponding to the second operating system, and so on. Then, the test task and the test queue are adapted to correspond to each other based on the same operating system, and the first test task is added to the first test queue and the second test task is added to the second test queue. Since both test queues are scheduled based on the first-in-first-out principle, the test task that enters the test queue first will be prioritized out of the queue.

[0076] Step S12: in response to a dequeue event of a test task in any of the test queues, obtain an installation package and a test script of the target program of the corresponding operating system version, and send them to a tested device installed with the corresponding operating system:

[0077] The multiple test queues dequeue the test tasks therein according to the first-in-first-out principle, and each dequeue operation triggers a dequeue event. Therefore, when the first test queue serving the Android operating system schedules a test task, it will lead to the relevant preparations for the automatic test of the tested device installed with the Android operating system. Similarly, when the second test queue serving the IOS operating system schedules a test task, it will lead to the relevant preparations for the automatic test of the tested device installed with the IOS operating system.

[0078] Therefore, in response to a dequeue event of a test task in any of the test queues, the operating system associated with the test task can be identified, and thus the corresponding version of the target program can be obtained according to the associated operating system.

[0079] The target program is usually developed with different installation package versions to adapt to different operating systems. Different types of installation packages can be stored in the same installation package server and can be distinguished by the same file name plus different suffixes. When you need to obtain installation packages for different operating systems of a target program, you can download all the suffix files under the file name corresponding to the target program from the installation package server to obtain the installation packages of each corresponding operating system version.

[0080] Similarly, in the storage unit of the local computer, the test script pre-customized for the target program is stored, and the corresponding test script can be queried according to the file name of the target program by querying a preset script mapping table. The test script can also be attached with a corresponding identifier according to the operating system to which it is applicable, so as to identify the test script adapted to different operating systems.

[0081] After the main control server completes acquiring the installation package and the test script of the target program, the installation package and the test script of the target program may be sent to the tested device installed with the operating system associated with the test task.

[0082] The device under test is pre-connected to the main control server, and can utilize the device debugging instructions defined by the system debugging tool compatible with the operating system of the device under test to transmit the installation package and test script to the device under test and control their application in the device under test.

[0083] The system debugging tools are provided by the operating system running on the device under test. The device debugging instructions provided by these system debugging tools can be called in the master server to establish a communication link between the master server and the device under test, so as to control the device under test in the master server. Different terminal device operating systems provide different system debugging tools. For example, for the Android operating system, the master server is provided with an adb debugging tool to establish the master server's debugging control over the device under test; for the IOS operating system, the master server is provided with an ideviceinstaller tool to achieve the same function.

[0084] adb (Android Debug Bridge) is a general command line tool that allows a computer acting as a master server to communicate with an emulator instance or a connected Android device, and facilitates the management and operation of these Android devices, such as installing and debugging applications on the tested device. The specific operation method of using the device debugging command of adb to communicate with an Android device is a technical content well known to those skilled in the art, so it will not be repeated here.

[0085] Similarly, ideviceinstaller is a command line tool that is mainly run on a computer that acts as a master server and is used to manage the installation and uninstallation of applications on iOS devices. Since this tool is an open tool equipped by the operating system, those skilled in the art are already familiar with its application, so it will not be described in detail.

[0086] In addition, other different operating systems generally provide similar command line tools to provide a computer acting as a master server with a means to control terminal devices running the operating system.

[0087] In terms of communication media, currently, the main control server and the device under test are directly connected by a data cable such as USB. In theory, these system debugging tools can also play a role in establishing a wireless connection between the main control server and the terminal device or a remote connection based on a public network. In any case, the main control server and the device under test can form a communication link through a port structure agreed upon by each other, and combine port relocation means when necessary to facilitate data communication between the main control server and the terminal device.

[0088] Specifically, in the case where the tested device and the main control server interact through a public network, the two can interact with each other through data messages. In the case where the tested device and the main control server do not interact through a public network, since the tested device's adb-based communication usually works on the first port, such as reading and writing data to port 9000, and the main control server opens a second port such as port 9092 for reading and writing data, in this case, after opening the target program of the tested device, the device debugging instructions for relocation of debugging tools such as adb can be used to achieve port redirection between the tested device and the main control server, and establish a communication channel between the tested device and the main control server for subsequent test processes.

[0089] To adapt to the situation where the tested device uses different operating systems, in this step, a corresponding debugging tool can be used to enable a communication link, and the installation package of the target program can be transmitted to the tested device through the communication link. By transmitting the installation package of the target program to the selected multiple tested devices respectively, the distribution of the installation package is achieved.

[0090] After confirming that the installation package has been successfully received by the device under test, the installation command can be further called with the help of a system debugging tool to drive the device under test to execute the installation of the installation package on its local machine.

[0091] On the basis that the target program of the present application has been installed on the tested device, the master control server can control the tested device to start the target program. For example, in the case where the tested device runs the Android operating system, the target program can be started through the device debugging command Start of adb. In order to ensure the smooth implementation of the present application, for each tested device connected to the master control server, these tested devices can be controlled one by one to start the target program.

[0092] The master control server maintains a script pool to store test scripts for various target programs. These test scripts can be written based on different test processes. The same target program may also store multiple test scripts based on different test processes. Testers can construct the script pool through technical means such as databases and file index architectures, and call the corresponding test scripts to test the target program when implementing the test, so as to achieve reuse of the test scripts.

[0093] Taking the example of constructing the script pool by borrowing a database (such as the aforementioned mapping relationship table), in order to store and manage multiple test scripts of multiple target programs, a database can be established to maintain the mapping relationship between the unique characteristics of the target program (such as the aforementioned file name) and its test script reference address. The reference address of a test script and its corresponding target program unique feature information together form a data record of the database, so that the unique characteristics of a certain application to be tested can be used to query and obtain one or more test scripts associated with the application from the database for subsequent testing of the application. Generally speaking, the package name of the application is its unique feature, which can be used as the unique feature information for storage associated with the reference address of the test script. The database can be stored locally on the master server or in other devices that the master server can reach and access, or it can be stored in other servers deployed in the cloud, as long as it can be called by the master server of this application. It can be seen that this application not only helps to realize automated testing of applications, but also is suitable for improving the management capabilities of software engineering. For development teams or organizations responsible for developing a large number of applications, managing test scripts through the script pool of this application can greatly enhance the ability of the entire organization to cope with the testing needs of a large number of its software products, and further greatly save its technology development costs.

[0094] Based on the implementation scheme of the script pool disclosed above, this step can adapt to the target program to be tested. By utilizing its unique features such as the package name, the reference address of the corresponding test script can be determined from the database, and the corresponding test script can be obtained and sent to the corresponding device under test. The test script can be parsed and run on the device under test to start and implement the test of the target program in each device under test.

[0095] The main control server is responsible for maintaining a device pool for storing the unique characteristic information (device UID or network address plus port, etc.) and related operating environment information (such as operating system type) of the terminal devices participating in the application test, so that when the main control server implements this method, it can implement specific designation of the terminal device based on the unique characteristic information and select the terminal device suitable for running the installation package using the operating environment information. Testers can pre-configure multiple terminal devices dedicated to program testing, install matching background programs in the terminal devices, and add the unique characteristic information and operating environment information of these terminal devices to the device pool through the background management page.

[0096] The device pool is also used to store the test task load information reported by each terminal device. Specifically, the terminal device can monitor in real time the task execution status of the terminal device as the device under test to implement the program test through the operation of the background program, and continuously report the load information related to the test task being executed by the local device under the current task execution status to the main control server. The main control server can then use the test task load information to timely and dynamically grasp the task execution status of each terminal device, thereby optimizing more efficient terminal devices for use as the device under test.

[0097] To this end, in an embodiment of the present application that enriches the technical means, in addition to allowing the application of technical means such as manual reporting of the test task load information of each terminal device, a concurrent step for automatically collecting the test task load information is also added. In this step, the main control server receives the test task load information reported by each terminal device, and then stores it in the device pool, and stores it in association with the corresponding unique characteristic information.

[0098] The test task load information described above can be expressed in a flexible form according to the needs of this application. In terms of function, it mainly includes two types of data, one is the number of test tasks being executed in the terminal device to which it belongs, and the other is the remaining time for the test task to be completed. Regarding the parameter of the number of test tasks being executed, it is mainly considered that the terminal device dedicated to program testing may need to queue up to process the tests of multiple different target programs. Therefore, the larger the parameter, the busier the terminal device is, otherwise it is relatively idle. Obviously, when scheduling a terminal device as a test device for a target program based on this parameter alone, the terminal device with the lowest parameter should be given priority. Regarding the parameter of the remaining time for the execution of the test task being executed, it is mainly considered that the terminal device can only free up time and space to process the newly added test task after completing the currently executing test task. Therefore, it can be understood by the same token that when scheduling a terminal device based on this parameter alone, the terminal device with the lowest parameter should also be given priority as the test device.

[0099] In practice, the number of parameters and the specific forms of the parameters that make up the test task load information are essentially about the formulation of a scheduling strategy for the terminal device, and this scheduling strategy itself can be flexibly implemented by those skilled in the art. For example, in a typical embodiment recommended for implementation by the present application, when the master control server is preferred to use a terminal device for testing a target program, the above two parameters will be considered at the same time, and the terminal device with the least number of test tasks being executed and the shortest remaining time for the test tasks being executed will be selected, and such a terminal device will be preferred as the device under test for the target program. It can be seen that the scheduling strategy for the terminal device only affects the selection effect of the device under test, and does not affect the implementation of the technical solution of the present application.

[0100] Step S13: Start the automatic test process of the target program on the tested device, so that the target program applies the test script during the running process of the tested device after installation to collect the buried data and submit it to the data server:

[0101] The test script is sent by the master server to each device under test for parsing and execution, mainly with the help of the Appium technical architecture known to those skilled in the art. Appium is an open source test automation framework that can be used for native, hybrid and mobile Web application testing. It uses the WebDriver protocol to drive iOS, Android and Windows applications. Appium can support Android and iOS across platforms at the same time, and supports multiple languages: java, python, php, Ruby, etc. Appium provides a Server component on the server side and a Clients component on the client side (WebDriverAgent in IOS and UiAutomator in Android). Therefore, it is suitable for running corresponding processes at the master server and the device under test respectively so that the two can cooperate to implement program testing.

[0102] Since the Appium testing framework is implemented based on simulating click operation events on the running interface of the tested program, the test script can only be parsed and executed on the tested device. After the main control server confirms that the tested script has been transmitted to a tested device, it can use the system debugging tool to send a startup instruction to the tested device, so that the background process of the tested device responds to the startup instruction and starts parsing and executing the test script.

[0103] In this case, the execution statements within the test script, in addition to being used to describe the test process that the test script must follow, the execution statements that have an effect on the target program are mainly descriptive statements for simulating the operation events of the target program running interface of the device under test. In addition, since the test process needs to include a series of operations, it is usually necessary to use multiple execution statements to simulate a series of the operation events to cooperate with the test. Obviously, the device under test should be able to recognize these operation events, so that the process of the target program can make further responses to the corresponding operation events and enable the target program to run according to the test process. It can be understood that the test script converts complicated human interface operations into automatically executed operation commands, which greatly reduces the repetitive operations of testers and improves test efficiency.

[0104] A variety of methods can be adopted to implement simulation of the operation event in the execution statement of the test script. One implementation method is to broadcast an event message to the system, such as broadcasting a message related to a touch event in the Android system, which will cause it to be recognized by the corresponding target program process and trigger the execution of the corresponding code in the process; in another way, since when a certain operation event needs to be simulated, it is actually necessary to execute a method (function) in response to the operation event, therefore, the operation of the process of the target program under test can be directly monitored by means of a hook technology (Hook), and when a certain operation event needs to be simulated, the method (function) in response to the operation event can be directly called. Different operating systems and development tools may allow different technical means to be used to implement this simulation means, and may not even be limited to the two methods given above. Those skilled in the art can flexibly apply the technical means provided by the operating system or operating tool according to the disclosure herein to achieve the purpose of simulation.

[0105] After the background process in the device under test starts parsing the test script, it parses and executes each execution statement, simulates a series of multiple operation events according to the test flow described in the test script, acts on the running interface of the target program, and switches the target program from one running interface to another, thereby implementing the test of the target program.

[0106] Other devices under test are tested in the same way, and the relevant test results can be observed by the tester. At the same time, the test script can usually write the result data returned after the execution statement is executed by submitting it to the data server, or write other actively reported tracking data, etc. These various types of data can be regarded as result data and submitted to the data server by the background process of the device under test.

[0107] Step S14: Pull the buried point data from the data server and send the formatted result to the preset communication interface:

[0108] As mentioned above, during the implementation of automated testing, the device under test will submit the collected tracking data to the data server according to the tracking instructions within the test script. Therefore, the main control server of the present application can obtain the tracking data corresponding to the target program from the data server. It can be understood that these tracking data are also stored in association with different operating systems. Therefore, relevant result data can be formatted according to different operating systems, and the result data can be sent to a preset communication interface. These communication interfaces can be preset email addresses, mobile phone text message sending interfaces, instant messaging interfaces or other similar means.

[0109] See also Figure 3 In a specific embodiment, the step S11 includes the following steps:

[0110] Step S111, responding to the test task start event of the target program, generating the first test task and the second test task corresponding to the first operating system and the second operating system:

[0111] The backend management user can trigger a test task start event, which contains the specified information of the target program, and accordingly, generates the first test task and the second test task for the two operating systems of the example, wherein the operating system corresponding to the first test task is Android, and the operating system corresponding to the second test task is IOS.

[0112] Step S112: Add the first test task to the first test queue, and add the second test task to the second test queue.

[0113] The first test task is added to the first test queue preset for the Android operating system, and similarly, the second test task is added to the second test queue preset for the IOS. The two test queues have their own tasks, and multiple test tasks in their queues are dequeued according to their own inherent queuing logic.

[0114] Step S113: Start monitoring of the dequeue events of the first test queue and the second test queue:

[0115] After the task is added, the dequeue event of the test task in any test queue can be monitored, so as to adapt to the dequeue event of the test task in any test queue and trigger the automatic test process accordingly.

[0116] This embodiment mainly provides a deployment scheme of test queues for two commonly used operating systems. By using two test queues to queue the test tasks of the two operating systems, the computer task processing logic can be made clearer, thereby achieving efficient execution efficiency. As mentioned above, the information of the tested device itself can be pre-stored in the device pool, so by using the test queue for queuing, combined with the information of the tested device itself, the relevant tested device can be more accurately adapted for each test task.

[0117] See also Figure 4 In a specific embodiment, the step S12 includes the following steps:

[0118] Step S121: accept the communication connection between the tested device and the local computer, and mark the operating system installed on each tested device:

[0119] As mentioned above, USB or other methods can be used to establish physical connections between multiple devices under test and the local machine, i.e., the master server. On this basis, a communication connection between the devices under test and the local machine is established based on tools compatible with the operating system. Then, the device information reported by the devices under test is stored in the device pool, so that the master server can know the operating system installed on the devices under test. Thus, the operating system installed on the devices under test is marked through the device information. Subsequently, the devices under test with the operating system corresponding to the test task installed can be selected to participate in the test by querying the device information. It can be understood that a test queue is thus associated with a batch of devices under test with corresponding operating systems.

[0120] Step S122: in response to a dequeue event of a test task in any of the test queues, obtain the installation package of the target program from the installation package server according to the operating system pre-associated with the test queue, and send the installation package to the device under test installed with the corresponding operating system to complete its installation on the device under test:

[0121] When a test task in any of the test queues is dequeued, the dequeue event is triggered. In response to the dequeue event, the acquisition of the installation package of the target program is initiated, and then the installation package is transmitted to the tested device compatible with the operating system for installation according to the process disclosed in the previous embodiment.

[0122] Step S123: Obtain the test script of the target program from the local database according to the operating system pre-associated with the test queue, and send the test script to the device under test on which the target program has been installed:

[0123] Similarly, in response to the dequeue event, a corresponding test script will be obtained from the script pool described in the previous embodiment. The test script is developed for the corresponding operating system version of the target program. Therefore, it is suitable for being sent to the device under test on which the target program has been installed in the previous step so as to be parsed and executed by the device under test.

[0124] This embodiment standardizes the dequeue event response process. According to this process, it can be determined in an orderly manner that a dequeue event is correctly responded to, ensuring that the centralized and unified automated testing process can operate efficiently and orderly under multi-target programs, multi-operating systems, and multi-test tasks, thereby maximizing the computer operating resource efficiency of the master server.

[0125] See also Figure 5 In a specific embodiment, after starting the automatic test process of the target program on the device under test, the device under test performs the following steps:

[0126] Step S21, parse and execute the pre-received test script to simulate a series of operation events acting on the running interface of the target program to implement the test of the target program, and collect the tracking data according to the tracking instructions of the test script and submit it to the data server:

[0127] As described in the previous typical embodiments, the test script contains various instructions that can be parsed and executed. When they are parsed and executed, they are suitable for simulating a series of operating events acting on the running interface of the target program, thereby realizing the test of the target program. Then, under the action of the tracking instructions of the test script, relevant tracking data is collected and submitted to the data server.

[0128] Step S22: According to the instruction control of the test script, when it is detected that the target program is in a pop-up window blocking state, a control containing any one of a plurality of specific texts in the pop-up window is detected, and a click event of the control is triggered to eliminate the pop-up window:

[0129] In order to avoid pop-up windows blocking the test process of the target program, the test script is implemented during programming to detect the pop-up window blocking status of the target program. When pop-up window blocking is detected, it is further detected whether the current pop-up window contains one of multiple specific texts, such as whether it contains texts such as "Agree" and "OK". When these texts exist, a touch event for the control where these texts are located is further simulated so that the pop-up window is responded to and eliminated, thereby ensuring that the automatic test process of the target program can proceed normally.

[0130] This embodiment further ensures the intelligent automation of the test process by taking into account the pop-up window processing logic, which is particularly important for batch multi-test tasks. By eliminating pop-up windows in a timely manner to ensure the continuity of the test process, unmanned intervention can be achieved throughout the process.

[0131] In a further embodiment, the step S21 includes: according to the original identifier of the control specified in the instruction of the test script, querying the object mapping table attached to the installation package, determining the encrypted identifier corresponding to the original identifier of the control, and executing the instruction with the encrypted identifier instead of the original identifier:

[0132] Android installation packages are usually hardened. Therefore, when obtaining the installation package, it is often necessary to also obtain the object mapping table therein and send it to the side of the tested device for the test script to call, so that when subsequent test cases are parsed and executed, each object and its interface can be smoothly called according to the object mapping table.

[0133] The object mapping table contains the mapping relationship data between the original identifier of each control in the source code of the installation package and the encrypted identifier formed after the source code is reinforced and obfuscated. When the target program is run, it is necessary to use the encrypted identifier to access the control or object instance therein. Therefore, when the test script is parsed and executed, the object mapping table can be looked up first to determine the encrypted identifier corresponding to the original identifier of the control to be called, and the encrypted identifier is used instead of the original identifier to refer to the object instance to realize the call of the control.

[0134] This embodiment further adapts to the situation where the Android system performs reinforcement processing on the installation package and is compatible, so that potential obstacles to the test process of the target program of the Android version are further eliminated, further ensuring the smooth execution of the automated test process.

[0135] See also Figure 6 In a specific embodiment, the step S14 comprises the following steps:

[0136] Step S141: Pull the buried point data from the data server:

[0137] As mentioned above, after the test script is executed by the device under test, the collected tracking data can be uploaded to a pre-specified data server for storage for management convenience. Therefore, the master control server of the present application can pull the tracking data corresponding to a target program from the data server.

[0138] Step S142: Perform statistical analysis on the buried point data to obtain analysis results:

[0139] For the same target program, after multi-system testing, there will be tracking data corresponding to multiple operating systems. In order to help developers understand the test results efficiently, the tracking data collected by each operating system version of the target program can be statistically analyzed according to the operating system or tracking type, so as to obtain more intuitive analysis results.

[0140] Step S143, formatting the analysis result to obtain a formatted result: In order to further improve readability, the analysis result may be formatted.

[0141] Step S144, sending the formatting result to a preset communication interface: generally, the formatting result is sent to a preset mailbox and some instant communication interface, so as to remind the developer in time.

[0142] See also Figure 7 In an extended embodiment, the multi-system testing method of the present application program further includes the following steps:

[0143] Step S15: receiving a notification returned by the device under test indicating that the test is completed, and sending a cleanup instruction to the device under test to clean up the installation package and test script of the target program previously sent to the device under test and uninstall the target program:

[0144] Considering that the device under test continuously serves the testing of multiple target programs for a long time, and the storage space of the device under test is limited, an automatic cleanup step is added to ensure that a highly intelligent automated testing system is obtained by utilizing the deployment of the present application.

[0145] Specifically, after completing the execution of the test script, the device under test is required to send a notification indicating the completion of the test to the main control server, or the main control server automatically detects that a device under test has completed a test task. Based on the notification indicating the completion of the test, the main control server of the present application can send a cleanup instruction to the device under test that provides the notification, and the device under test responds to the cleanup instruction and executes the uninstallation of the installation package and the test script of the target program that has just completed the test, thereby completing the cleanup.

[0146] Furthermore, the device under test may stop responding to new test tasks before completing the cleanup of a target program. Of course, the cleanup and the response to new test tasks may also be processed in parallel.

[0147] This embodiment takes into account the problem of limited storage space of the device under test, realizes the circular reuse of the storage space of the device under test, and further improves the automated testing process by enriching the cleaning methods. Thereby, it is fully ensured that the program automatic testing system deployed and implemented by this application can efficiently and continuously serve the automated testing of the application program, and can even be opened as a public service platform.

[0148] Furthermore, by functionalizing each step in the method disclosed in the above embodiments, a program multi-system testing device of the present application can be constructed. According to this idea, please refer to Figure 8In a typical embodiment, the device includes a task diversion module 11, a task preparation module 12, a task execution module 13, and a task reporting module 14, wherein: the task diversion module 11 is used to add the test tasks of different operating system versions of the target program to different test queues configured for different operating systems; the task preparation module 12 is used to respond to the dequeue event of the test task in any of the test queues, obtain the installation package and test script of the target program of the corresponding operating system version, and send them to the tested device installed with the corresponding operating system; the task execution module 13 is used to start the automatic testing process of the target program on the tested device, so that the target program applies the test script during the operation of the tested device after installation and collects the buried data and submits it to the data server; the task reporting module 14 is used to pull the buried data from the data server and send the formatted result to the preset communication interface.

[0149] In a specific embodiment, the task diversion module 11 includes a task creation submodule, which is used to respond to the test task start event of the target program to generate the first test task and the second test task corresponding to the first operating system and the second operating system; a task enqueue submodule, which is used to add the first test task to the first test queue and the second test task to the second test queue; and a task monitoring submodule, which is used to start monitoring the dequeue events of the first test queue and the second test queue.

[0150] In a specific embodiment, the task preparation submodule 12 includes: a device access submodule, which is used to accept the communication connection between the tested device and the local machine, and mark the operating system installed on each tested device; a dequeue installation submodule, which is used to respond to the dequeue event of the test task in any one of the test queues, obtain the installation package of the target program from the installation package server according to the operating system pre-associated with the test queue, and send the installation package to the tested device with the corresponding operating system installed to complete its installation on the tested device; a use case transmission submodule, which is used to obtain the test script of the target program from the local database according to the operating system pre-associated with the test queue, and send the test script to the tested device with the target program installed.

[0151] In a specific embodiment, the device under test is configured to include: parsing and executing a pre-received test script to simulate a series of operating events acting on the running interface of the target program to implement testing of the target program, and collecting tracking data according to the tracking instructions of the test script and submitting it to a data server; according to the instruction control of the test script, when it is monitored that the target program is in a pop-up window blocking state, detecting a control containing any one of multiple specific texts in the pop-up window, and triggering a click event of the control to eliminate the pop-up window.

[0152] In a preferred embodiment, the device under test is configured to include: querying the object mapping table attached to the installation package according to the original identifier of the control specified in the instruction of the test script, determining the encrypted identifier corresponding to the original identifier of the control, and executing the instruction with the encrypted identifier instead of the original identifier.

[0153] In a specific embodiment, the task reporting module 14 includes: a data pulling submodule, used to pull the buried point data from the data server; a statistical analysis submodule, used to perform statistical analysis on the buried point data to obtain analysis results; a result processing submodule, used to format the analysis results to obtain formatted results; a result notification submodule, used to send the formatted results to a preset communication interface.

[0154] In an extended embodiment, the multi-system testing device of the application program also includes a post-cleaning module, which is used to receive a notification returned by the tested device indicating that the test is completed, and send a cleanup instruction to the tested device to clean up the installation package and test script of the target program previously sent to the tested device and uninstall the target program.

[0155] In order to solve the above technical problems, the present application also provides a computer device. Fig. 9 As shown, a schematic diagram of the internal structure of a computer device. The computer device includes a processor, a non-volatile storage medium, a memory, and a network interface connected via a system bus. Among them, the non-volatile storage medium of the computer device stores an operating system, a database, and computer-readable instructions. The database may store a control information sequence. When the computer-readable instructions are executed by the processor, the processor can implement a program multi-system testing method. The processor of the computer device is used to provide computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor can execute the program multi-system testing method of the present application. The network interface of the computer device is used to connect and communicate with a terminal. Those skilled in the art can understand that Fig. 9 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0156] In this embodiment, the processor is used to execute Figure 8The memory stores the program code and various data required to execute the above modules or submodules. The network interface is used to transmit data between user terminals or servers. The memory in this embodiment stores the program code and data required to execute all modules / submodules in the program multi-system test device of this application, and the server can call the program code and data of the server to execute the functions of all submodules.

[0157] The present application also provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the program multi-system testing method of any embodiment of the present application.

[0158] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments of the present application can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the aforementioned storage medium can be a non-volatile storage medium such as a disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0159] In summary, the present application can meet the needs of testing multiple operating system versions of an application program, and provide fully automated and efficient testing services according to different operating systems.

[0160] Those skilled in the art will appreciate that the various operations, methods, steps, measures, and schemes in the processes discussed in this application may be alternated, altered, combined, or deleted. Further, other steps, measures, and schemes in the various operations, methods, and processes discussed in this application may also be alternated, altered, rearranged, decomposed, combined, or deleted. Further, the steps, measures, and schemes in the prior art that are similar to those disclosed in this application may also be alternated, altered, rearranged, decomposed, combined, or deleted.

[0161] The above description is only a partial implementation method of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A program multi-system testing method, characterized in that: The steps include: Add the test tasks of different operating system versions of the target program to different test queues configured for different operating systems; In response to a dequeue event of a test task in any of the test queues, an installation package and a test script of the target program of the corresponding operating system version are obtained, and sent to a tested device installed with the corresponding operating system, wherein when the operating system is Android, an object mapping table is obtained along with the installation package and sent to the corresponding tested device, wherein the object mapping table contains mapping relationship data between the original identifier of each control in the source code of the installation package and the encrypted identifier formed after the source code is reinforced and obfuscated; Initiate an automatic test process for the target program on the device under test, so that the target program applies the test script during the operation of the device under test after installation and collects the buried data and submits it to the data server; Pull the buried point data from the data server and send the formatted result to the preset communication interface; After starting the automatic test process of the target program on the device under test, the device under test performs the following steps: Parse and execute the test script received in advance, query the object mapping table attached to the installation package according to the original identifier of the control specified in the instruction of the test script, determine the encrypted identifier corresponding to the original identifier of the control, replace the original identifier with the encrypted identifier and execute the instruction to simulate a series of operation events acting on the running interface of the target program to implement the test of the target program, and collect the tracking data according to the tracking instructions of the test script and submit it to the data server; According to the instruction control of the test script, when it is detected that the target program is in a pop-up window blocking state, a control containing any one of multiple specific texts in the pop-up window is detected, and a click event of the control is triggered to eliminate the pop-up window.

2. The method according to claim 1, characterized in that Adding the test tasks of different operating system versions of the target program to different test queues configured for different operating systems includes the following steps: In response to a test task start event of the target program, a first test task and a second test task corresponding to the first operating system and the second operating system are generated; Add the first test task to a first test queue, and add the second test task to a second test queue; Start monitoring of dequeue events of the first test queue and the second test queue.

3. The method according to claim 1, characterized in that In response to a dequeue event of a test task in any of the test queues, obtaining an installation package and a test script of the target program of the corresponding operating system version and sending them to a tested device installed with the corresponding operating system, comprising the following steps: Accept the communication connection between the tested device and the local machine, and mark the operating system installed on each tested device; In response to a dequeue event of a test task in any of the test queues, obtaining an installation package of the target program from an installation package server according to the operating system pre-associated with the test queue, and sending the installation package to a tested device installed with the corresponding operating system to complete its installation on the tested device; The test script of the target program is obtained from a local database according to the operating system pre-associated with the test queue, and the test script is sent to the tested device on which the target program has been installed.

4. The method according to claim 1, characterized in that: Pulling the buried point data from the data server and sending the formatted result to the preset communication interface includes the following steps: Pull the tracking data from the data server; Performing statistical analysis on the buried point data to obtain analysis results; Formatting the analysis result to obtain a formatted result; The formatted result is sent to a preset communication interface.

5. The method according to claim 1, characterized in that: The method also includes the following steps: A notification indicating that the test is completed is received from the device under test, and a cleanup instruction is sent to the device under test to clean up the installation package and the test script of the target program previously sent to the device under test and uninstall the target program.

6. A program multi-system testing device, characterized in that: It includes: A task distribution module is used to add the test tasks of different operating system versions of the target program to different test queues configured for different operating systems; A task preparation module, for responding to a dequeue event of a test task in any of the test queues, obtaining the installation package and test script of the target program of the corresponding operating system version, and sending them to a tested device installed with the corresponding operating system, wherein, when the operating system is Android, the object mapping table thereof is obtained along with the installation package and sent to the corresponding tested device, wherein the object mapping table contains mapping relationship data between the original identifier of each control in the source code of the installation package and the encrypted identifier formed after the source code is reinforced and obfuscated; A task execution module is used to start the automatic testing process of the target program on the tested device, so that the target program applies the test script during the running process of the tested device after installation and collects the buried data and submits it to the data server; The task reporting module is used to pull the buried point data from the data server and send the formatted result to the preset communication interface; The device under test is configured to include: parsing and executing a pre-received test script, querying the object mapping table attached to the installation package according to the original identifier of the control specified in the instruction of the test script, determining the encrypted identifier corresponding to the original identifier of the control, executing the instruction with the encrypted identifier instead of the original identifier, so as to simulate a series of operating events acting on the running interface of the target program to realize the test of the target program, collecting and submitting the tracking data to the data server according to the tracking instructions of the test script; according to the instruction control of the test script, when it is monitored that the target program is in a pop-up window blocking state, detecting a control containing any one of multiple specific texts in the pop-up window, triggering a click event of the control to eliminate the pop-up window.

7. A computer device comprising a central processing unit and a memory, characterized in that: The central processing unit is used to call and run the computer program stored in the memory to execute the steps of the program multi-system testing method as claimed in any one of claims 1 to 5.

8. A non-volatile storage medium, characterized in that: It stores a computer program implemented according to the method described in any one of claims 1 to 5 in the form of computer-readable instructions, and when the computer program is called and executed by a computer, the steps included in the method for multi-system testing of the corresponding program are executed.

Images