CN112306887A

CN112306887A - Program test distribution method and corresponding device, equipment and medium

Info

Publication number: CN112306887A
Application number: CN202011259195.3A
Authority: CN
Inventors: 熊盛; 翁国川; 陈俊宇
Original assignee: Guangzhou Cubesili Information Technology Co Ltd
Current assignee: Guangzhou Cubesili Information Technology Co Ltd
Priority date: 2020-11-12
Filing date: 2020-11-12
Publication date: 2021-02-02

Abstract

The application discloses a program test distribution method and a corresponding device, equipment and medium thereof, wherein the method comprises the following steps: monitoring the update of a target program pointed by a preset address pool, and synchronizing the latest installation package to the local; determining a plurality of tested devices suitable for testing the target program according to the test task load information reported by a plurality of online terminal devices in the device pool; distributing the installation package of the target program synchronized to the local to the tested equipment, installing the installation package into the tested equipment, and starting running; and calling a test script in the script pool, which is adapted to the target program, to start the test of the target program in the tested equipment. The method and the device can realize the full-flow automatic test of the application program, and greatly improve the implementation efficiency of software engineering.

Description

Program test distribution method and corresponding device, equipment and medium

Technical Field

The present application relates to the field of computer software testing, and in particular, to a method and an apparatus for distributing program testing, and an electronic device and a non-volatile storage medium corresponding to the method and apparatus.

Background

The developed application program (APP) of the terminal device needs to be released after testing to test various performances of the APP in the running process of the terminal device, and to find potential various running problems in time, such as whether a popup window is normal, whether a business logic is correct, whether a human-computer interaction function is smooth, whether an abnormality occurs, and the like.

Due to the fact that environmental factors such as touch interaction and screen size difference exist in the testing requirements of the application program on the terminal equipment side, interaction experience of the application program is more important, and therefore the testing requirements are different from software testing on traditional desktop computer equipment, and touch response testing in the aspect of man-machine interaction is more important. Another problem with applications on the terminal device side is that the versions are changed frequently, sometimes a new version is released a week or several days, and the code involved in the new version is modified in some ways, and these modifications are sometimes also made in a whole body, so that the program testing team is often faced with a lot of testing work. Program testing is usually done manually, taking into account the randomness of human-computer interaction itself. Although manual testing may maximize user usage habits and perform some touch interaction testing, the efficiency of manual testing is conceivable. Therefore, when a new version is released, factors such as timeliness and low manual efficiency are considered, release is often promoted without comprehensive testing, new problems are often caused, and use experience is influenced.

In addition, in practice, program testing work is more specialized, a development team may use a large number of terminal devices dedicated to program testing to test the specific performance of an application program in different terminal devices, and the development team may be responsible for the division development of multiple application programs.

In the prior art, various platforms and tools for assisting in implementing software operation test exist, and the tools generally only pay attention to individual links or aspects of a test project, are difficult to organically integrate, and cannot provide a unified framework for efficiently testing an application program, so that the application program test requirements under a large number of frequent development conditions are difficult to meet.

In view of the above problems generally faced by the industry, it is imperative to provide some effective solutions.

Disclosure of Invention

The present application is directed to solving at least one of the above problems and providing a program test distribution method and a corresponding device, electronic device, and nonvolatile storage medium, so as to implement an automated distribution test for an application program.

In order to meet various purposes of the application, the following technical scheme is adopted in the application:

a program test distribution method provided in accordance with one of the objects of the present application, comprising the steps of:

monitoring the update of a target program pointed by a preset address pool, and synchronizing the latest installation package to the local;

determining a plurality of tested devices suitable for testing the target program according to the test task load information reported by a plurality of online terminal devices in the device pool;

distributing the installation package of the target program synchronized to the local to the tested equipment, installing the installation package into the tested equipment, and starting running;

and calling a test script in the script pool, which is adapted to the target program, to start the test of the target program in the tested equipment.

In a further embodiment, the method further comprises the following steps:

and receiving the test task load information reported by the online terminal equipment at regular time, wherein the test task load information comprises the number of test tasks being executed in the terminal equipment and/or the residual time for completing the execution of the test tasks.

In a more specific embodiment, in the step of determining a plurality of devices to be tested suitable for testing the target program according to test task load information reported by a plurality of online terminal devices in a device pool, according to the number of test tasks currently executed by the terminal devices and/or the remaining time of the test tasks executed by the terminal devices in the test task load information, the terminal devices with the optimal parameters are selected and determined as the devices to be tested.

In some embodiments, the step of invoking a test script in the script pool, which is adapted to the target program, to start testing the target program in the device under test includes the following steps:

acquiring a test script preset for the target program, and distributing the test script to the tested equipment;

sending a starting instruction to the tested equipment to start the analysis and execution of the test script so as to simulate operation events acting on the running interface of the target program in series to realize the test of the target program;

and receiving result data returned in the test process of the tested equipment.

acquiring a test script preset for the target program, and analyzing and executing an execution statement in the test script to start the test;

converting the mapping function expression in the execution statement into a corresponding native function expression in the target program to construct a corresponding calling instruction;

sending the call instruction to the tested equipment specified by the execution statement so that the tested equipment calls a native function of a target program according to the call instruction to implement the test;

and receiving result data returned in the test process of the tested equipment.

In a preferred embodiment, the method further comprises the steps of:

and automatically generating report output by the result data returned in the process of testing the target program by the tested equipment.

In some embodiments, the local device is configured with an Appium service, and the terminal devices each run a background process that communicates with the Appium service to cooperate with the implementation of the test.

A program test distribution apparatus provided in accordance with an object of the present application includes:

the program synchronization module is used for monitoring the update of a target program pointed by a preset address pool and synchronizing the latest installation package to the local;

the device optimization module is used for determining a plurality of tested devices suitable for testing the target program according to the test task load information reported by the plurality of online terminal devices in the device pool;

the program distribution module is used for distributing the installation package of the target program synchronized to the local to the tested equipment, so that the installation package is installed into the tested equipment and starts to run;

and the test execution module is used for calling the test script matched with the target program in the script pool to start the test of the target program in the tested equipment.

An electronic device adapted to one of the objects of the present application includes a central processing unit and a memory, the central processing unit is used for calling and running a computer program stored in the memory to execute the steps of the program test distribution method described in the present application.

A non-volatile storage medium, which is provided in a form of computer readable instructions, stores a computer program implemented according to the program test distribution method, which when called by a computer, performs the steps included in the method.

Compared with the prior art, the application has the following advantages:

firstly, the updating of the installation package of the synchronous target program is monitored, part of the terminal equipment is preferably selected as the tested equipment by utilizing the load information of the test tasks reported by the terminal equipment, the updated installation package is transmitted to the tested equipment, the test of the tested equipment is started by utilizing the test script, the whole process can be realized by computer control, the automatic acquisition of the installation package, the intelligent automatic selection of the tested equipment and the control and operation of the test script are realized, the issuing and the test process of the application program are automated, and the whole process does not need to depend on manual participation.

Secondly, the application realizes an automatic testing framework based on abstract factory principle, updates of target programs to be tested are managed by an address pool, all terminal devices participating in testing are managed by an equipment pool, testing scripts for describing a testing process are managed by a script pool, all parts are combined with each other to form automatic services, standardized interfaces can be accessed after the interfaces are standardized on the basis, and the expansibility is strong.

In addition, this application can obviously promote software test engineering operating efficiency through constructing automatic test flow, especially to how big type project, many terminal equipment operational environment's centralized test, the developer only needs to upload appointed network address with its installation package of accomplishing, alright throw into its installation package into the whole automatic test of many operational environment by this application is automatic, the developer only need wait relevant test result can, no extra engineering consumption in the period, can save development tester's time cost by a wide margin.

Drawings

The foregoing and/or additional aspects and advantages of the present application will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:

FIG. 1 is a schematic diagram of a typical deployment architecture associated with implementing the subject technology;

FIG. 2 is a schematic flow chart diagram of an exemplary embodiment of a program test distribution method of the present application;

fig. 3 is a schematic flowchart illustrating a step S14 of the program test distribution method according to another embodiment of the present application, which is embodied on the basis of the exemplary embodiment;

fig. 4 is a schematic flowchart illustrating a step S14 of the program test distribution method according to another embodiment of the present application, which is embodied on the basis of the exemplary embodiment;

FIG. 5 is a flowchart illustrating a process for generating a mapping table in the embodiment shown in FIG. 4;

FIG. 6 is a flowchart illustrating a procedure of sending a call instruction called in step S143' in the embodiment shown in FIG. 4;

fig. 7 is a functional block diagram of an exemplary embodiment of a program test distribution method of the present application.

Detailed Description

Reference will now be made in detail to embodiments of the present application, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are exemplary only for the purpose of explaining the present application and are not to be construed as limiting the present application.

As used herein, the singular forms "a", "an", "the" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that when an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or intervening elements may also be present. Further, "connected" or "coupled" as used herein may include wirelessly connected or wirelessly coupled. As used herein, the term "and/or" includes all or any element and all combinations of one or more of the associated listed items.

It will be understood by those within the art that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the prior art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

As will be appreciated by those skilled in the art, "client," "terminal," and "terminal device" as used herein include both devices that are wireless signal receivers, which are devices having only wireless signal receivers without transmit capability, and devices that are receive and transmit hardware, which have receive and transmit hardware capable of two-way communication over a two-way communication link. Such a device may include: cellular or other communication devices such as personal computers, tablets, etc. having single or multi-line displays or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service), which may combine voice, data processing, facsimile and/or data communication capabilities; a PDA (Personal Digital Assistant), which may include a radio frequency receiver, a pager, internet/intranet access, a web browser, a notepad, a calendar and/or a GPS (Global Positioning System) receiver; a conventional laptop and/or palmtop computer or other device having and/or including a radio frequency receiver. As used herein, a "client," "terminal device" can be portable, transportable, installed in a vehicle (aeronautical, maritime, and/or land-based), or situated and/or configured to operate locally and/or in a distributed fashion at any other location(s) on earth and/or in space. The "client", "terminal Device" used herein may also be a communication terminal, a web terminal, a music/video playing terminal, such as a PDA, an MID (Mobile Internet Device) and/or a Mobile phone with music/video playing function, and may also be a smart tv, a set-top box, and the like.

The hardware referred to by the names "server", "client", "service node", etc. is essentially an electronic device with the performance of a personal computer, and is a hardware device having necessary components disclosed by the von neumann principle such as a central processing unit (including an arithmetic unit and a controller), a memory, an input device, an output device, etc., a computer program is stored in the memory, and the central processing unit calls a program stored in an external memory into the internal memory to run, executes instructions in the program, and interacts with the input and output devices, thereby completing a specific function.

It should be noted that the concept of "server" as referred to in this application can be extended to the case of a server cluster. According to the network deployment principle understood by those skilled in the art, the servers should be logically divided, and in physical space, the servers may be independent from each other but can be called through an interface, or may be integrated into one physical computer or a set of computer clusters. Those skilled in the art will appreciate this variation and should not be so limited as to restrict the implementation of the network deployment of the present application.

Referring to fig. 1, the hardware basis required for implementing the related art embodiments of the present application can be deployed according to the architecture shown in the figure, and the functions and functions of the components are disclosed as follows:

the remote server 80 referred to in this application can be used as a front-end application server, and is responsible for further connecting with related data servers, so as to form a logically related server cluster, so as to provide services for related terminal devices, such as the

smart phones

81 and 82 and the personal computer shown in the figure. Both the

smart phones

81, 82 and the personal computer may establish a data communication link with the remote server 80 via a known network access method.

The remote server 80 of the present application is adapted to provide internet services such as webcast, instant messaging, etc., and provide corresponding internet services to corresponding terminal devices by operating the services, so that different users can exchange communication data between users by using the services of the remote server 80 through their respective terminal devices. For example, one user may obtain a video stream, information, instructions, etc. of another user via the remote server 80.

The terminal device of the present application is equipped with a related operating system, such as an IOS, an HMS (grand mend), an Android, and other operating systems providing equivalent functions, under the support of such an operating system, the remote server 80 and the terminal device may perform data communication through a communication link agreed with each other, and application programs developed for the operating systems adaptively may also normally run in the terminal device, and by the operation of the application programs, the terminal device may implement human-computer interaction, remote interaction, and various indirect interactions with other terminals through the remote server.

The main control server 88, which is referred to herein as an independent device, is mainly used to implement the program test distribution method of the present application, so as to control the devices under

test

81 and 82 of the present application to perform testing. The

devices

81 and 82 to be tested are the terminal devices, and are mainly responsible for implementing the background process in the present application, which is matched with the main control server, so as to test the target program in the devices to be tested in cooperation with the program test distribution method executed by the main control server. The main control Server 88 and the terminal equipment work in a Server/Client mode, the main control Server 88 is used as a Server end to implement control, the tested

equipment

81 and 82 acts as a Client end to receive test, a communication link can be established between the tested equipment 81 and the tested equipment 82 by adopting physical wired connection or wireless connection, and even under the premise of being supported by an operating system, the communication mechanism can be established by a third-party Server on a public network. According to the principle of the application, the master control server 88 controls the plurality of devices under

test

81 and 82 to perform testing, and each device under

test

81 and 82 performs communication data exchange through the remote server under the control of the master control server 88, so that the testing of the interactive service flow of the plurality of devices under

test

81 and 82 can be realized.

It should be noted that, in order to support the formation of the C/S architecture between the main control Server 88 and the

devices

81 and 82 to be tested, the main control Server 88 implements a corresponding application program according to the program test distribution method of the present application so that the method can be implemented after the main control Server 88 runs to form a Server side, and the

devices

81 and 82 to be tested are also embedded with a background program which is used for communicating with the Server side and is responsible for executing instructions of the Server side, and this background program is implemented in a manner of implementing a test by cooperating with the program test distribution method of the present application, and receives various instructions of the Server side when the background program runs to execute corresponding functions, so that the

devices

81 and 82 to be tested send out the role of the Client side.

The application program referred to in this application is generally referred to as an application program that runs on an electronic device such as a server or a terminal device, and the application program implements the related technical solution of this application in a programming manner, and a program code of the application program may be stored in a nonvolatile storage medium that can be identified by a computer in the form of a computer executable instruction, and called into a memory by a central processing unit to run, and the related apparatus of this application is constructed by running the application program on the computer. The target program is an application program to be tested, which is to be run in the devices under

test

81 and 82, and interacts with the remote server through its running, and uses a service opened by the remote server.

Different devices under

test

81 and 82 may run on different operating systems, such as IOS, Android, etc., and therefore the target programs installed therein may also be developed in different native languages of the operating systems, but since the same target program is usually developed according to certain functional logic regardless of its running environment, and only the languages used are different, this situation does not affect the implementation of the present application. Similarly, the application program related to the present application in the main 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, and the implementation of the present application is not affected.

The test script is written in a high-level computer language, and is generally a language that can be supported by the application program responsible for implementing the present application in the main control server 88, such as Python, JavaScript, and the like, and may logically form a plurality of branch flows by using turn statements such as if, case, and the like, and may be executed by executing the statements from the aspect of actions, for example, triggering an operation event or calling a method function by executing the statements. As a basic function, the main task of the execution statements is to simulate a series of operation events acting on the running interface of the target program according to the requirement of the test flow, or initiate a series of call instructions for calling the native functions of the target program, trigger the operation events by sending the test script to the devices under

test

81 and 82 for parsing, or control the target program to execute the native functions according to the requirement by sending the call instructions to each corresponding device under

test

81 and 82 so as to cooperate with the test. It can be understood that the test script converts complicated manual operation into an automatically executed operation command, thereby greatly reducing the repetitive operation of testers and improving the test efficiency.

The person skilled in the art will know this: although the various methods of the present application are described based on the same concept so as to be common to each other, they may be independently performed unless otherwise specified. In the same way, for each embodiment disclosed in the present application, it is proposed based on the same inventive concept, and therefore, concepts of the same expression and concepts of which expressions are different but are appropriately changed only for convenience should be equally understood.

Referring to fig. 2, a program testing and distributing method of the present application is implemented by an application program on a master server side, and in an exemplary embodiment, the method includes the following steps:

step S11, monitoring the update of the target program pointed by the preset address pool, and synchronizing the latest installation package to the local:

the main control server is responsible for maintaining a preset address pool and is used for storing the installation package storage addresses of the to-be-tested application programs corresponding to all test items, and operation and maintenance personnel can take the application programs needing to be tracked and tested as the target programs, and add the default storage addresses of the application programs into the address pool through a background page for monitoring in the step. Therefore, different development teams can access the same address pool, corresponding storage addresses of the target programs of the different development teams are added into the address pool, centralized management is implemented by the method, and the development teams only need to store the installation packages of the target programs according to normal operation habits theoretically.

In this step, the positions pointed by the storage addresses in the address pool are monitored, when the corresponding storage addresses are found to have the installation packages of the target programs which are newly added or replaced, the installation packages can be compared with the installation packages of the target programs which are synchronized previously in the main control server, and when the change is confirmed, the newly added or replaced installation packages are synchronized to the local, so that the test of the installation packages is carried out subsequently. In order to improve the comparison efficiency of the installation package, at the stage of comparing the installation packages, the installation package pointed by the storage address may be obtained and compared with the digital signature of the installation package stored locally.

For the historical installation package of the target program stored locally, the master control server can perform regular cleaning, delete the historical installation package in time or wait for manual cleaning.

The file format of the installation package is determined according to the terminal device operating system to which the installation package is adapted, for example, an APK suffix file in an Android operating system, and an IPA suffix file in an IOS operating system. The master control server can create a special storage folder locally for storing the installation packages synchronized from the different storage addresses, and can implement more efficient organization and management on the installation packages through a file index technology when necessary. In this regard, those skilled in the art will appreciate.

Step S12, determining, according to test task load information reported by a plurality of online terminal devices in the device pool, a plurality of devices to be tested suitable for testing the target program:

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.) of the terminal device participating in the application program test and the relevant operating environment information (such as operating system type), so that when the main control server implements the method, the specific designation of the terminal device can be implemented according to the unique characteristic information, and the terminal device suitable for operating the installation package can be selected by using the operating environment information. A tester can pre-configure a plurality of terminal devices for program testing, install background programs which are implemented by matching with the program testing distribution method in the application in the terminal devices, and add the unique characteristic information and the running environment information of the terminal devices into the device pool through a background management page.

The device pool is further configured to store test task load information reported by each terminal device, and specifically, the terminal device may monitor, in real time, a task execution state in which the terminal device performs a program test as a device to be tested through the operation of the background program, and continuously report, in the current task execution state, load information related to a test task which is used to indicate that the terminal device is executing the test task, to the main control server, so that the main control server can timely and dynamically grasp the task execution state of each terminal device through the test task load information, and thus, the terminal device which is used to optimize more efficiency is used as the device to be tested.

Therefore, in an embodiment of the application, which enriches technical means, besides the application of the technical means of allowing manual reporting of test task load information of each terminal device, a concurrent step for automatically collecting the test task load information is also added, and in the step, the master control server receives the test task load information reported by each terminal device, stores the test task load information in the device pool, and stores the test task load information in association with corresponding unique feature information.

The test task load information is determined according to the requirements of the application, the representation form of the test task load information can be flexible, and the test task load information mainly comprises two types of data in function, wherein one type of data is the number of test tasks being executed in the terminal equipment to which the test task load information belongs, and the other type of data is the residual time for the test tasks to be executed. The parameter of the number of executing test tasks is mainly considered that the terminal device dedicated to program test may need to queue up to process tests of a plurality of different target programs, so that the larger the parameter is, the more busy the terminal device is, and the more idle the terminal device is. Obviously, when the terminal device is scheduled to be used as the tested device of a certain target program solely according to the parameter, the terminal device with the lowest parameter should be selected preferentially. The parameter of the remaining time for the execution of the currently executed test task is mainly considered that the terminal device can only vacate time and space to process the newly added test task after the currently executed test task is completed, and therefore, similarly, it can be understood that when the terminal device is solely scheduled by the parameter, the terminal device with the lowest parameter should be preferentially selected to be used as the device under test.

In practice, how many parameters and which parameters in specific form constitute the test task load information is essentially about the formulation of a scheduling policy of the terminal device, and such scheduling policy itself is flexibly implemented by those skilled in the art. For example, in the exemplary embodiment recommended by the present application, when the master control server prefers the terminal device for testing the target program, the terminal device that is the smallest in the number of the test tasks being executed and the smallest in the remaining time of the test tasks being executed is selected by considering the above two parameters at the same time, and such terminal device is preferably the device to be tested for the target program. Therefore, regarding the scheduling strategy of the terminal device, only the selection effect of the tested device is influenced, and the implementation of the technical scheme of the application is not influenced.

Of course, as an additional means understood by those skilled in the art, when the master server selects the terminal device, the operating environment information recorded by the terminal device in the device pool should also be considered, for example, for an installation package with an APK suffix, it should be preferred that the terminal device running the Android operating system in the operating environment information should be indicated as the device under test, and the terminal running the IOS operating system should not be selected as the device under test.

In addition, the method does not exclude the situation that operation and maintenance personnel appoint the terminal equipment for testing a certain target program in a self-defining mode through the background management page, when the preset steps are included, the steps can be replaced equally, and the terminal equipment defined by the operation and maintenance personnel is directly called in an adaptive mode to be used as the tested equipment of the target program.

Step S13, distributing the installation package of the target program synchronized to the local to the device under test, installing the installation package into the device under test, and starting to run:

after the main control server completes the synchronization of the installation package of the target program and optimizes the corresponding tested equipment for the target program, the installation package can be transmitted to the tested equipment through a system debugging tool provided by an operating system of each terminal equipment by using an equipment debugging instruction defined by the system debugging tool, and the installation package is controlled to be installed and started in the tested equipment.

The system debugging tools are provided by an operating system operated by the tested equipment, and the equipment debugging instructions provided by the system debugging tools can be called in the main control server to establish a communication link between the main control server and the tested equipment so as to realize the control of the tested equipment in the main control server. Different system debugging tools provided by different terminal equipment operating systems are different, for example, for an Android operating system, the Android operating system provides an adb debugging tool for a master control server to establish debugging control of the master control server on a tested device; for the IOS operating system, the similar principle is that the ideviceinstar tool is provided for the master server to realize the equivalent function.

adb (Android Debug bridge) is a general command line tool that allows a computer acting as a master server to communicate with simulator instances or connected Android devices, and can facilitate management and operation of these Android devices, such as installing and debugging applications on a device under test. The specific operation manner of communicating with the Android device by using the device debug command of the adb belongs to the technical content well known to those skilled in the art, and therefore, it will not be described herein any further.

Similarly, ideviceinstar is a command line tool that runs primarily on a computer acting as a master server for managing the installation and uninstallation of applications on iOS devices. Since the tool is an open tool equipped by an operating system, those skilled in the art are aware of its application, and therefore detailed description thereof is omitted here.

In addition, other different operating systems typically provide similar command line tools to provide a means for a computer acting as a master server to manipulate the terminal device running the operating system.

In communication media, the main control server and the tested device are usually directly connected by data lines such as USB, and these system debugging tools can theoretically also function under the condition that wireless connection is established between the main control server and the terminal device or remote connection is established based on a public network.

Specifically, for the case that the tested device and the master control server interact with each other through the public network, the two devices may perform subsequent interaction through the data message. In the case that the interaction between the device under test and the master server is performed without a public network, since the communication based on the adb of the device under test usually works at the first port, for example, data is read from and written into the 9000 port, and the master server opens the second port, for example, the 9092 port, for reading from and writing into data, in this case, after the target program of the device under test is opened, the redirection of the port between the device under test and the master server can be realized by using a device debugging instruction for relocation of a debugging tool such as the adb, and a communication channel for a subsequent test procedure between the device under test and the master server is established.

The method is suitable for the situation that the tested equipment adopts different operating systems, a corresponding debugging tool can be adopted in the step, a communication link is started, and the installation package of the target program is transmitted to the tested equipment through the communication link. The distribution of the installation packages is realized by respectively transmitting the installation packages of the target programs to the selected multiple tested devices.

After confirming that the installation package is successfully received by the device under test, the system debugging tool can further call an installation command to drive the device under test to execute the installation of the installation package on the local machine of the device under test.

After the target program of the application is installed on the device under test, the master control server can control the device under test to start the target program. For example, for the case that the device under test runs the Android operating system, the target program may be started through the Start of adb, which is a device debug instruction. In order to ensure the smooth implementation of the present application, for each device under test accessing the master control server, the device under test may be controlled one by one to start the target program. Step S14, invoking a test script in the script pool adapted to the target program to start testing the target program in the device under test:

the main control server also maintains a script pool for storing test scripts of various target programs, the test scripts can be written based on different test procedures, the same target program can also store a plurality of test scripts based on different test procedures, testers can construct the script pool through technical means such as a database and a file index architecture, and when the test of the target program is implemented, the corresponding test scripts are called to implement the test, so that the test scripts are multiplexed.

Taking the example of constructing the script pool by using a database, in order to store and manage a plurality of test scripts of a plurality of target programs, a database can be established, the database is used for maintaining the mapping relation between the uniqueness characteristic of the target program and the reference address of the test script, and the reference address of one test script and the uniqueness characteristic information of the corresponding target program form a data record of the database together, so that the uniqueness characteristic of an application program to be tested can be utilized subsequently, and one or more test scripts related to the application program can be inquired and obtained from the database for testing the application program subsequently. Generally, the package name of the application program is the unique characteristic thereof, and the unique characteristic information can be used as the unique characteristic information to be stored in association with the reference address of the test script. The database can be stored locally in the main control server or in other equipment which can be accessed by the main control server in a touch mode, and can also be stored in other servers deployed at the cloud end, so long as the database can be called by the main control server. Therefore, the method and the device for testing the software project not only help to realize automatic testing of the application programs, but also are suitable for improving the management capacity of the software project, and for a development team or organization responsible for developing a large number of application programs, the script pool manages the test scripts, so that the capacity of the whole organization for meeting the test requirements of a large number of software products under the flag can be greatly improved, and the technical development cost of the whole organization is further greatly saved.

Based on the above-mentioned implementation scheme of the script pool, this step may be adapted to the target program to be tested, and by using the unique features such as its package name, the reference address of the corresponding test script is determined from the database, and the corresponding test script is obtained, and the analysis and operation of the test script are used to start and implement the test on the target program in each device under test.

The above discloses typical embodiments of the program test distribution method of the present application, and further, in consideration of different situations of the call operation mechanism of the test script, the present application adaptively provides other embodiments for perfecting the subsequent steps:

referring to fig. 3, in another embodiment of the present application, the test script is sent by the master server to each device under test for parsing and execution, and is mainly implemented by the aid of the application technical architecture known to those skilled in the art.

The Appium is an open source test automation framework that can be used for native, hybrid, and mobile Web application testing, using the WebDriver protocol to drive iOS, Android, and Windows applications. The apple can simultaneously support Android and iOS in a cross-platform mode, and supports multiple languages: java, python, php, Ruby, etc. The apple provides a Server component at the Server side and a Clients component (WebDriverAgent in IOS and UiAutomator in Android) at the client side, so that the apple is suitable for running corresponding processes at the main control Server and the tested device respectively so that the main control Server and the tested device can be matched to carry out program test.

Adapted to the present embodiment, on the basis of the foregoing exemplary embodiment of the present application, the step S14 is implemented by the following specific steps:

step S141, obtaining a test script preset for the target program, and distributing the test script to the device to be tested:

as described above, in this step, the master control server may obtain corresponding test scripts after querying from the script pool by using the package name of the target program, and then send the test scripts to each device to be tested.

Step S142, sending a start instruction to the device under test to start parsing and executing the test script, so as to simulate a series of operation events acting on the operation interface of the target program to implement testing of the target program:

the test framework of the Appium is realized based on a click operation event simulating an operation interface of a program to be tested, so that a test script can only be analyzed and executed in a tested device end, and after the main control server confirms that the tested script is transmitted to a certain tested device, a starting instruction can be sent to the tested device by means of a system debugging tool, so that a background process of the tested device starts to analyze and execute the test script in response to the starting instruction.

In this case, the execution statement inside the test script is used for describing the test flow to be followed by the test script, and the execution statement acting on the target program is mainly a description statement for simulating the operation event of the target program running interface of the device under test. Moreover, due to the requirement that the test flow needs to include a series of operations, a series of the operation events needs to be simulated by a plurality of execution statements 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 response to the corresponding operation events and the target program can run according to the test flow. It can be understood that the test script converts the complicated human interface operation into the automatically executed operation command, thereby greatly reducing the repetitive operation of the tester and improving the test efficiency.

The operation event can be simulated in the execution statement of the test script in various ways, and one implementation way is that an event message is broadcasted to the system, for example, a message related to a touch event is broadcasted in an Android system, which causes the operation event to be recognized by a corresponding target program process and triggers the execution of a corresponding code in the process; in another mode, since when some operation event needs to be simulated, a method (function) responding to the operation event is actually executed, it is sufficient to directly call the method (function) responding to the operation event when some operation event needs to be simulated by directly monitoring the operation of the process of the target program under test by means of Hook technology (Hook). Different operating systems and development tools may allow different technical means to be used for implementing the simulation means, and even not limited to the two manners given above, and those skilled in the art can flexibly adapt the technical means provided by the operating systems or the development tools according to the disclosure herein to achieve the purpose of simulation.

After a background process in the tested device starts analysis of the test script, each execution statement is analyzed and executed, a series of multiple operation events are simulated according to a test flow described by the test script, the operation events act on an operation interface of the target program, the target program is switched from one operation interface to another operation interface, and therefore the test of the target program is implemented.

Other tested devices synchronously receiving the test are tested in the same mode, related test effects can be observed by testers, and meanwhile, result data returned after execution statements submitted to the main control server are executed can be written into the test script, or other actively reported buried point data and the like can be written into the test script. The various types of data can be regarded as result data, and are submitted to the master control server by a background process of the tested device, or are submitted to other network addresses which can be accessed and acquired by the master control server.

Step S143, receiving result data returned in the test execution process of the device under test:

in the process of analyzing and executing the test script by each tested device, the main control server obtains the result data returned by each tested device in a backlog manner, and the result data can be presented in the interface thereof, or a corresponding test report is generated according to a preset rule and output to a preset network address, or sent to a corresponding communication interface for further analysis by a tester.

According to the above disclosure of the present embodiment, for the scheme of implementing the test by using the simulation operation event, the automatic test process implemented by the present application can be implemented in parallel and stably in a plurality of devices to be tested, the operation of a human touch interface can be omitted in the whole process, and the devices to be tested can be matched to perform the test of the target program without being attended to.

Referring to fig. 4, in another embodiment of the present application, the test script is automatically parsed by the main control server, and then is converted into a call instruction sent to each corresponding device to be tested to control each device to be tested to perform a test of the target program in cooperation with the device to be tested.

Please refer to fig. 1, which is adapted to the requirement of this embodiment that a plurality of devices to be tested need to be controlled to cooperate with each other to test the service interaction logic in the target program, and in the process of performing the test flow by analyzing and executing the test script, a call instruction needs to be sent to the plurality of devices to be tested, so as to control the target program of each device to be tested to operate in cooperation with the test.

The test flow is described and organized mainly by execution statements related to conditions in the test script, such as if, case, etc., and when these conditional statements are parsed and executed, different branch flows are executed correspondingly according to different condition judgment results. Just through the steering action of various conditional execution statements, a tester can investigate whether the service interaction logic designed by the target program meets the test requirements or not according to the running condition of the target program in the tested equipment. Because the conditional execution statement can call the corresponding branch flow according to the specific situation, the test script can be compatible with various test requirements through the programming thinking of the preset design, and the fault tolerance of the test flow can be improved, so that slight differences among different tested target program versions cannot influence the normal operation of the whole test flow.

The execution statement of the test script also comprises a statement for generating a subsequent call instruction, and the execution statement is written by a developer of the test script according to a native function of a target program.

As described above, the test flow includes a plurality of branch flows for each device under test, and the same device under test may be controlled by a plurality of similar branch flows suitable for the same device under test to send call instructions. Therefore, one tested device corresponds to a plurality of branch flows in the test script, a plurality of branch flows acting on the same tested device form an independent branch flow, and the same branch flow in the whole test flow acts on the same tested device. Thus, for a first device under test 81, there may be multiple branches of the test script written in the test script that act on the first device under test 81, and all of these branches of the test script that act on the first device under test constitute a first type of branch of the test script that acts on the first device under test 81, and the execution statements in the test script will ultimately act on the first device under test 81. The same applies to the second device under test 82, which may be controlled by a second type of branching process.

Therefore, regarding the execution sequence of the test flow, in order to achieve the effect that the target programs of at least two devices under test exchange communication data with each other through the remote server, the implementation of this embodiment will generally show the following interaction process:

in one aspect, according to a plurality of execution statements in a first type of branch flow preset in the test flow to adapt to the first device under test 81, a plurality of call instructions of primitive functions in the target program of the first device under test 81 are transmitted to the first device under test 81, so that the target program of the first device under test 81 uploads communication data in a streaming media format to a remote server with a first user identity. For example, according to a first branch flow in the first type of branch flows in the test flow, after the target program of the first device under test 81 is logged in by the user a by the call instruction sent by the main control server 88, the user a enters a live broadcast state as a broadcast user under the action of the second branch flow, and starts to upload a live broadcast stream thereof as the communication data for exchange to the remote server 80 (mainly a media server in a live broadcast service), where the live broadcast stream is in a streaming media format. Of course, in practical applications, there may be more interaction details, for example, required for multiple interactions with the remote server 80, and these interaction details may also be required to be completed under the action of the call instruction, and for this case, they may also be pre-programmed in the test script as the execution statements that the corresponding branch flow needs to be pre-programmed.

On the other hand, according to a plurality of execution statements in a second type of branch flow preset in the test flow to adapt to the second device under test 82, a plurality of call instructions of primitive functions in the target program of the second device under test 82 are transmitted to the second device under test 82, so that the target program of the second device under test 82 downloads the communication data in the streaming media format from the remote server with the second user identity: the difference from the previous aspect is that the target program in the second device under test 82 is logged in by the user B as the viewer user, and the user B downloads the communication data in the streaming media format uploaded by the user a to the remote server under the action of the second type of branch flow, that is, the live stream of the user a is played and displayed in the graphical user interface. Similarly, the second device under test 82 generally needs to cooperate with a plurality of specific branch processes in the second type of branch process to perform the above functions.

As can be understood from the above disclosure of an exemplary embodiment of a specific execution sequence of a test flow, the entire test flow is defined by an execution statement in a test script, and various execution sequences of the test flow need to be flexibly arranged by adapting to a specific service interaction logic of a target program, but in summary, a main control server generally needs to implement a test of an interaction service logic between the devices to be tested by interactively executing a plurality of branch flows corresponding to the devices to be tested, and as for a sequence in an interaction process, the sequence can be flexibly customized according to the inherent service interaction logic of the target program. Therefore, the specific execution sequence of the test flow does not adversely affect the spirit of the present invention. However, the exemplary embodiment disclosed herein is a representative embodiment in which the test script describes a test flow, and in this way, the control of the interaction of the target programs in the multiple devices under test with the actual test on the business interaction logic can be realized.

Therefore, in the present embodiment, based on the exemplary embodiments disclosed above, the step S14 is executed according to the following specific steps:

step S141' acquires a test script preset for the target program, and analyzes and executes an execution statement therein to start and implement the test:

after the target program in each tested device is started, the master control server can call a pre-written test script in the script pool, and starts the analysis of the test script to execute the execution statement therein, so as to implement the test flow described therein.

Step S142', converting the mapping function expression in the execution statement into a corresponding native function expression in the target program to construct a corresponding call instruction:

the mapping function described by the mapping function expression is generated by converting the native function in the source code of the target program in advance, and the inverse process of the conversion process is implemented in the step, so that the mapping function expression is reversely converted into the native function expression of the source code of the target program, and the subsequent control terminal equipment can call the corresponding native function.

The mapping data between the mapping function and the native function is stored in a mapping table in advance, and in order to provide the mapping table so as to determine the unique corresponding native function according to the mapping function query in the test script execution statement, referring to fig. 5, the mapping table is constructed as follows:

step S21, extracting annotation information in the source code of the target program, where the annotation information includes function description information of the native function:

during the development process of the target program, a developer can add annotation information to the source code of the target program, wherein the annotation information comprises function description information of a native function which is possibly called and executed by the master control server indirectly through a call instruction in the future, and the function description information generally comprises function description information such as a method name, a parameter name list, a parameter type list, a return value type and the like corresponding to the native function. The annotation information can be independently used as an explanatory document for externally exposing the API in the source code, so that the annotation information in the explanatory document can be directly extracted from the explanatory document.

Step S22, performing syntax analysis on the annotation information, and generating a syntax tree corresponding to a native function according to the function description information of the native function:

on the basis of extracting the annotation information, the step can analyze the annotation information based on a syntax analysis compiling principle, firstly generate a corresponding analysis tree, and then optimize the analysis tree into a syntax tree, so as to analyze function description information such as a method name, a parameter name list, a parameter type list, a return value type and the like corresponding to the native function.

Step S23, correspondingly converting the native function into a mapping function suitable for referring to the native function in the execution statement of the test script according to the syntax tree:

a developer may preset a protocol data structure and, subject to the constraint of complying with the specifications of such a protocol data structure, convert the native function into a corresponding mapping function. Thus, each native function may obtain a mapping function that generates its respective. Since the mapping function points substantially to its corresponding native function, the mapping function is subsequently referenced in the execution statement of the test script, which is essentially an indirect call to its corresponding native function.

Step S24, storing the mapping relationship data between the native function and the mapping function in a mapping table for determining the corresponding native function according to the mapping function in the execution statement:

the mapping relation data between the formed native function and the mapping function thereof can be stored in a mapping table, and can be provided for the test script to be referred when the test script runs, and the mapping table can be queried by using the mapping function referred by the execution statement in the test script, so that the corresponding native function can be uniquely determined.

The mapping table can be used for executing the program test distribution method of the application and also can serve the development process of the test script, and a test (development) person can open the mapping function name stored in the mapping table to a test person for inquiry in the process of writing the test script, so that the test person can quickly display the mapping function name and the reference method corresponding to the index characters according to the index characters by inputting individual index characters, and the programming efficiency of the mapping table is improved.

As mentioned above, the test flow described by the test script includes a plurality of branch flows, and these branch flows are internally composed of a plurality of execution statements, and when the test script is executed, the branch flows are read line by line and parsed for execution. In the execution statement, there is a type of execution statement for representing description information of a native function calling a target program of a certain device under test, but in the description information, the native function is not expressed in a native function text form in the target program, but in a text form of a mapping function recognizable by the master control server. In addition, since parameter values are typically passed as they relate to function calls, these parameter values are typically included in the description information. Therefore, after the main control server reads an execution statement preset in the test script for the device under test, the mapping function and the parameter value thereof need to be parsed first, so as to convert the mapping function into the native function of the target program in the device under test.

The mapping relation data between the native functions and the mapping functions is stored in the mapping table stored in advance, and the native functions corresponding to the uniqueness of the native functions can be inquired according to one mapping function by inquiring the mapping table. The mapping table enables the corresponding native function to be corresponded through the mapping function no matter whether the native function in the tested device accords with the specification of the development language used by the test script or not, as long as the development language used by the mapping function is consistent with the development language used by the test, and the corresponding native function is indirectly called in the main control server.

It can be understood that, after the main control server determines, through a preset mapping table, a native function uniquely corresponding to the mapping function specified by the execution statement parsed by the main control server, the native function can be used to carry the parameter value given in the execution statement, and the native function and the parameter value together form the call instruction.

Step S143', sending the call instruction to the device under test specified by the execution statement, so that the device under test invokes the native function of the target program according to the call instruction to perform the test:

after the master control server constructs the call instruction for sending to the tested device, the call instruction needs to be sent to the corresponding tested device.

In order to improve the security of transmitting the call instruction in the test process, in an embodiment that can be flexibly adopted, referring to fig. 6, the following specific steps may be adopted to transmit the call instruction to the corresponding device under test:

step S31, converting the call instruction into a character string:

the call instruction can be converted into a JSON string format, which is commonly referred to as "JavaScript Object notification," a JavaScript Object Notation, which is a text-based, language-independent lightweight data exchange format. In theory, the XML data exchange format may also be used, and the former is recommended in this embodiment. Although XML can be used as a cross-platform data exchange format, processing XML in JS (short for JavaScript) is very inconvenient, XML tags are more than data, the traffic generated by exchange is increased, JSON has no additional tags and can be used as an object to process in JS, and mobile terminal equipment which supports Android operating systems and is friendly to JavaScript is more common at present, so that JSON is more prone to be selected to exchange data. In any format, the data exchange format between the master control server and the tested device is agreed in advance.

Step S32, serializing the character string to form a corresponding byte stream:

serializing the string of characters can convert the object represented by the string of characters into an ordered stream of bytes for transmission over a network. The serialized byte stream holds the state of the Java object and associated description information. After the subsequent tested equipment obtains the serialized object byte stream, the object can be reconstructed through deserialization according to the object state and the description information stored in the byte stream. Essentially, serialization is the writing of the state of an entity object into an ordered byte stream according to a certain format, and deserialization is the reconstruction of the object from the ordered byte stream to restore the state of the object. The core role of the serialization mechanism is the storage and reconstruction of the object state.

Step S33, transmitting the byte stream to the device under test to implement transmission of the call instruction:

after the calling instruction is converted into a byte stream form, the main control server can write the byte stream into a corresponding port and transmit the byte stream to the tested equipment through a communication channel between the main control server and the tested equipment, so that a control effect is generated on the tested equipment.

Through the implementation of the above-described embodiment regarding transmitting a call instruction to a device under test, after a certain call instruction is sent to a corresponding device under test, a background process of the device under test is driven by the call instruction to control the running of a target program therein. Specifically, the device under test performs reverse operation on the received byte stream, deserializes the byte stream into a character string, constructs a corresponding function object, namely the native function and a parameter value thereof, and calls the corresponding native function in the process of the target program by reflection call or mapping call to make the native function refer to the parameter value for operation, thereby finally obtaining relevant operation result data. Since the target programs of multiple devices under test usually interact under the action of the same service interaction logic during the test process, the running of the native functions therein may also upload or download corresponding communication data, including streaming media data, instruction data, information data, etc., to the remote server, as will be understood by those skilled in the art.

Step S144', receiving result data returned in the test execution process of the device under test:

in some cases, after the device under test executes the native function of the target program according to the call instruction sent by the main control server, it needs to check the result data returned correspondingly by using some conditional turn statements such as if and case, so as to determine which branch process to execute subsequently. The branch flow for executing the steering may be a branch flow required for acting on another device under test in turn with the test flow, may also be a branch flow preset in the test script and responsible for performing exception handling, and may even result in directly ending the operation of the test script, depending on the design of the test script for the whole test flow.

As can be seen from the foregoing disclosure, in the present embodiment, a call instruction formed by one execution statement in a test script is sent to a device under test specified by the execution statement, and the device under test is controlled to execute the call instruction, so as to finally obtain corresponding execution result data.

As can be understood from the above disclosure of the specific implementation manners of various situations of this embodiment, under the effect of the test flow specified by the test script, the main control server may successively or alternately control the target programs of the multiple devices under test to cooperate with each other to test the service interaction logic designed in the target program, and the whole test process is automatically implemented by parsing and executing the test script, so as to greatly improve the test efficiency. Specifically, the present embodiment includes the following relative advantages:

firstly, the embodiment is suitable for implementation according to a Client/Server, after the method is applied, under the action of a test flow compiled by a test script, a main control Server can respectively transmit call instructions of native functions of a target program in a plurality of tested devices matched with the test, and the execution of the corresponding native functions of the target program is controlled by the response of the call instructions in the tested devices, so that the service logic of the target program is controlled by the cooperation test of the plurality of tested devices, and the multi-user interaction process of the target program is tested and verified.

Secondly, in the embodiment, the Server (the main control Server) sends the call instruction to the Client (the device to be tested) and translates the call instruction into the native function instruction corresponding to the target program, so that the device to be tested can reflect or map the call to execute the native function conveniently, thereby simulating the influence of the user behavior on the stability, maintainability, convenience and the like of the development middesk SDK in a complex interaction scene, and indicating the direction for the development of the quality of the development middesk SDK.

In addition, the embodiment allows a tester to write a test flow into the test script and express the native function call instruction used in the test flow as the execution statement therein, so that the tester can grasp the whole test flow by compiling the test script, the regression test is facilitated, the complicated test can be performed quickly and efficiently, the test which is difficult or can not be performed by hands is replaced, the result consistency and repeatability are achieved, the development midstation SDK has higher trust level, and the test can be executed in a multi-operating system environment.

In addition to the above embodiments, to enrich the technical solutions of the present application, in an embodiment of utilizing result data returned in the test process of each device under test, the program test distribution method of the present application further includes the following post-steps: and automatically generating report output by the result data returned in the process of testing the target program by the tested equipment. Therefore, when the master control server controls the device to be tested according to the test script, the master control server can store the result data into a local file or a remote file after the device to be tested continuously returns the result data to the master control server in the process of carrying out the test of the target program under control, so that a tester can find a problem by examining the result data in the file at a later time, and can even further form a related report to be sent to a user of a preset mailbox or an instant communication tool.

Further, a program test distribution apparatus of the present application can be constructed by functionalizing the steps in the methods disclosed in the above embodiments, and according to this idea, please refer to fig. 7, wherein in an exemplary embodiment, the apparatus includes:

the program synchronization module 81 is configured to monitor update of a target program pointed by a preset address pool, and synchronize the latest installation package to the local;

the device optimization module 82 is configured to determine, according to test task load information reported by a plurality of online terminal devices in the device pool, a plurality of devices to be tested that are suitable for testing the target program;

a program distribution module 83, configured to distribute, to the device under test, an installation package of the target program that has been synchronized to the local, so that the installation package is installed in the device under test and starts to run;

and the test execution module 84 is used for calling a test script in the script pool, which is adapted to the target program, to start the test of the target program in the device under test.

Further, to facilitate the implementation of the present application, the present application provides an electronic device, including a central processing unit and a memory, where the central processing unit is configured to invoke and run a computer program stored in the memory to perform the steps of the program test distribution method in the foregoing embodiments.

It can be seen that the memory is suitable for adopting a nonvolatile storage medium, the aforementioned method is implemented as a computer program and installed in an electronic device such as a mobile phone or a computer, the related program code and data are stored in the nonvolatile storage medium of the electronic device, and further the program is executed by a central processing unit of the electronic device and is called from the nonvolatile storage medium to a memory for execution, so as to achieve the desired purpose of the present application. Therefore, it is understood that in an embodiment of the present application, a non-volatile storage medium may be further provided, in which a computer program implemented according to various embodiments of the program test distribution method is stored, and when the computer program is called by a computer, the computer program executes the steps included in the method.

In conclusion, the application program full-flow automatic test can be realized, and the implementation efficiency of the software engineering is greatly improved.

As will be appreciated by one skilled in the art, the present application includes apparatus that are directed to performing one or more of the operations, methods described herein. These devices may be specially designed and manufactured for the required purposes, or they may comprise known devices in general-purpose computers. These devices have computer programs stored in their memories that are selectively activated or reconfigured. Such a computer program may be stored in a device (e.g., computer) readable medium, including, but not limited to, any type of disk including floppy disks, hard disks, optical disks, CD-ROMs, and magnetic-optical disks, ROMs (Read-Only memories), RAMs (Random Access memories), EPROMs (Erasable Programmable Read-Only memories), EEPROMs (Electrically Erasable Programmable Read-Only memories), flash memories, magnetic cards, or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a bus. That is, a readable medium includes any medium that stores or transmits information in a form readable by a device (e.g., a computer).

It will be understood by those within the art that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions. Those skilled in the art will appreciate that the computer program instructions may be implemented by a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, implement the aspects specified in the block or blocks of the block diagrams and/or flowchart illustrations disclosed herein.

Those of skill in the art will appreciate that the various operations, methods, steps in the processes, acts, or solutions discussed in this application can be interchanged, modified, combined, or eliminated. Further, other steps, measures, or schemes in various operations, methods, or flows that have been discussed in this application can be alternated, altered, rearranged, broken down, combined, or deleted. Further, steps, measures, schemes in the prior art having various operations, methods, procedures disclosed in the present application may also be alternated, modified, rearranged, decomposed, combined, or deleted.

The foregoing is only a partial embodiment of the present application, and it should be noted that, for those skilled in the art, several modifications and decorations can be made without departing from the principle of the present application, and these modifications and decorations should also be regarded as the protection scope of the present application.

Claims

1. A program test distribution method, comprising the steps of:

2. The method of claim 1, further comprising the steps of:

3. The method according to claim 1, wherein in the step of determining a plurality of devices to be tested suitable for testing the target program according to the test task load information reported by the plurality of online terminal devices in the device pool, the terminal device with the optimal parameters is selected to be determined as the device to be tested according to the number of test tasks currently executed by the terminal device and/or the remaining time for completing the execution of the test tasks, which are represented in the test task load information.

4. The method according to claim 1, wherein the step of invoking the test script in the script pool adapted to the target program to initiate the test of the target program in the device under test comprises the steps of:

and receiving result data returned in the test process of the tested equipment.

5. The method according to claim 1, wherein the step of invoking the test script in the script pool adapted to the target program to initiate the test of the target program in the device under test comprises the steps of:

and receiving result data returned in the test process of the tested equipment.

6. The method of claim 1, further comprising the steps of:

7. The method of claim 1, wherein local devices are configured with an Appium service, and wherein the terminal devices each run a background process that communicates with the Appium service to perform the testing.

8. A program test distribution apparatus, characterized by comprising:

9. An electronic device comprising a central processor and a memory, wherein the central processor is configured to invoke execution of a computer program stored in the memory to perform the steps of the method according to any one of claims 1 to 7.

10. A non-volatile storage medium, characterized in that it stores, in the form of computer-readable instructions, a computer program implemented according to the method of any one of claims 1 to 7, which, when invoked by a computer, performs the steps comprised by the corresponding method.