A method and system for scheduling test cases for multi-terminal interaction

Abstract

The application provides a multi-terminal interaction test case scheduling method and system, and relates to the field of automatic testing, and comprises the following steps: setting a corresponding priority weight for a plurality of parsed test cases in sequence and adding the test cases to a to-be-executed queue; arranging the test cases in the to-be-executed queue in descending order according to the priority weight; after the arrangement is completed, the test cases are popped out from the head of the to-be-executed queue in sequence and a matching agent machine is queried, the test cases are executed in the selected agent after the test cases are matched with the agent machine that can undertake the test cases according to the dependent terminal, and the test cases in the to-be-executed queue are executed completely; and the execution efficiency of the agent machine when scheduling the test cases in the multi-terminal mode can be improved.

Description

Technical Field

[0001] This invention relates to the field of automated testing, and more specifically to a method and system for scheduling test cases involving multi-terminal interaction. Background Technology

[0002] The live streaming industry is booming, with scenarios like live online classes involving multi-terminal interaction. Achieving multi-terminal interaction typically requires automated testing across multiple roles and terminal types. Automated testing usually involves various terminal devices, such as browsers, iOS devices, Android devices, and clients. These devices play different roles in completing one or more test cases. If the agent machine used to execute the test cases can simultaneously support four types of terminals, then the agent machine needs to be connected to multiple corresponding external devices. However, not all test cases involve four different terminal types, and not all agent machines are equipped with the complete set of equipment to support all terminals. Therefore, based on the device dependencies of the test cases, selecting the most suitable agent machine to execute the test cases and an efficient scheduling scheme is particularly important.

[0003] Therefore, this invention proposes a method and system for scheduling test cases involving multi-terminal interaction. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention proposes a scheduling method and system for test cases involving multi-terminal interaction, which can improve the execution efficiency of agent machines when scheduling test cases in multi-terminal formats.

[0005] The technical solution of this invention is implemented as follows:

[0006] A method for scheduling test cases involving multi-terminal interaction includes the following steps:

[0007] Multiple test cases that require terminal support after parsing are added to the execution queue in sequence, and corresponding priority weights are set. The priority weights are configured to decrease when there is no suitable agent during round-robin matching. When a test case is added to the queue, the test cases in the execution queue are sorted in descending order according to their priority weights.

[0008] After the test cases are arranged, they are popped out sequentially from the head of the queue to be executed and a matching agent machine is queried. After matching the agent machine that can handle the test cases according to their dependent terminals, the test cases are executed in the selected agent. The agent machine can be expanded and registered. The queue to be executed is used to enqueue test cases and is in a polling state.

[0009] The test cases are popped sequentially from the head of the queue to be executed and the matching agent machines are queried, further including:

[0010] The first test case pops up and queries the state of the registered agent machine. If no idle agent machine is found, the priority weight of the corresponding test case is reduced, and the test case is re-entered into the execution queue and arranged in descending order. If an idle agent machine is found, the current test case needs to be further searched according to its dependent end to find an agent machine that can carry out the execution.

[0011] After the query, if all idle agent machines do not have the ability to undertake the current test case, the priority weight of the corresponding test case is reduced, and the test case is re-entered into the execution queue and arranged in descending order. If there is an idle agent machine that has the ability to undertake the current test case, the agent machine that meets the condition is arranged in ascending order according to its carrying capacity. The test case will select the first agent machine after the arrangement to undertake and start execution. The selected agent machine is set to the occupied state, i.e., no idle state.

[0012] After the execution of the test case, the agent machine that undertakes it is released and set to the idle state, waiting for the next query matching.

[0013] Preferably, the test case file is obtained from the gitlab code repository and parsed, and the key information corresponding to the test case is entered into the database scheduling system.

[0014] Preferably, the key information includes test case file name, description, author, and test case dependent end.

[0015] Preferably, the agent machine is registered in the scheduling system before execution and registers the carrying capacity. The carrying capacity of the agent machine includes web end, android end, iOS end, and client end.

[0016] The application further provides a test case scheduling system for multi-terminal interaction, comprising a suite management module, an agent machine management module, a task queue module, an environment module and an execution record module, wherein the suite management module is used to obtain and parse multiple test cases from a gitlab code library; the agent machine management module is used to register agent machines and record their carrying capacity; the task queue module is used to set corresponding priority weights for all the test cases parsed from the suite management module in sequence and add them to a to-be-executed queue for arrangement, and is also used to execute the test cases in selected agent machines after the test cases are queried and matched with the agent machines; the environment module is used to manage the execution environment of the agent machines; and the execution record module is used to record the log of the execution process of the test cases in the task queue module and the report of the completed execution.

[0017] Compared with the prior art, the application has the following advantages:

[0018] By using the scheme, when scheduling the test cases for multi-terminal interaction, the carrying relationship between the test cases and the execution machines does not need to be matched in advance, each test case is matched again when executed, that is, the optimal agent machine that meets the condition at present is selected according to the actual carrying condition of the agent machine, so that the uneven distribution of the number of task matching in multiple queues caused by early distribution, the inability to maximize the utilization of resources and the improvement of the execution efficiency of the agent machine when scheduling the test cases in the form of multi-terminal are avoided. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only represent some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor.

[0020] Figure 1 A flowchart of the test case scheduling method for multi-terminal interaction of the present application;

[0021] Figure 2 A system block diagram of the test case scheduling system for multi-terminal interaction of the present application. DETAILED DESCRIPTION

[0022] The technical solutions in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments only represent some embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the protection scope of the present application.

[0023] In the description of the present application, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, which are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation of the present application. In addition, the terms "first", "second", "third", "fourth" and the like are only for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0024] In the description of the present application, it should be noted that unless otherwise explicitly specified and limited, the terms "mounting", "connecting", "connecting" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium; it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0025] Embodiment 1

[0026] The embodiment provides a scheduling method for test cases of multi-terminal interaction, as shown in Figure 1 The method comprises the following steps:

[0027] A plurality of test cases required to be dependent on terminals after analysis are sequentially added to a to-be-executed queue, and a corresponding priority weight is set, the priority weight being a configuration that can be decreased when a polling matching adapter is not adapted; when a test case is enqueued, the test cases in the to-be-executed queue are arranged in descending order according to the priority weight;

[0028] After the arrangement is completed, the test cases are sequentially popped from the head of the to-be-executed queue and queried for matching adapter machines, and after the dependent terminals are matched with the adapter machines that can be accepted, the test cases are executed in the selected adapters, the adapter machines can be expanded and registered at any time, and are distributed for execution; the to-be-executed queue is always available for test cases to be enqueued and is in a polling state at any time; the test cases and the execution machines do not need to be matched in advance, and whether there is a concurrent relationship between the embodiments does not need to be considered;

[0029] The test cases are sequentially popped from the head of the to-be-executed queue and queried for matching adapter machines, and further comprise:

[0030] The first test case in the queue is popped out and the state of the registered agent machine is queried. If no idle agent machine is found, the priority weight of the corresponding test case is reduced, the test case after the weight reduction is re-entered into the execution queue and arranged in descending order in the execution queue. If an idle agent machine is found, the current test case needs to be further searched according to its dependent end to find an agent machine capable of carrying out the execution.

[0031] After the query, if all idle agent machines do not have the ability to undertake the current test case, the priority weight of the corresponding test case is reduced, and the test case after the weight reduction is re-entered into the execution queue and arranged in descending order in the execution queue. If there is an idle agent machine that has the ability to undertake the current test case, the agent machines that meet the condition are arranged in ascending order according to their carrying capacity. The test case will select the first agent machine after the arrangement to undertake and start execution. The selected agent machine is set to the occupied state, i.e., the idle state.

[0032] After the execution of the test case is completed, the agent machine that undertakes it is released and set to the idle state, waiting for the next query matching.

[0033] In the embodiment, the agent machine needs to be registered in the scheduling system before execution and register the undertaking capacity. The undertaking capacity of the agent machine includes the web end, the android end, the iOS end and the client end.

[0034] The embodiment also provides a scheduling system for test cases of multi-terminal interaction, which comprises a suite management module, an agent machine management module, a task queue module, an environment module and an execution record module. The suite management module is used to obtain and parse a plurality of test cases from a gitlab code library.

[0035] The agent machine management module is used to register the agent machine and register the undertaking capacity thereof.

[0036] The task queue module is used to set the corresponding priority weight of all test cases parsed from the suite management module in sequence and add the test cases to the execution queue for arrangement, and is also used for test case query and agent machine matching and execution in the selected agent machine.

[0037] The environment module is used to manage the execution environment of the agent machine.

[0038] The execution record module is used to record the log of the execution process of the test case in the task queue module and the report of the completed execution.

[0039] Embodiment 2

[0040] This embodiment simultaneously adds three typical use cases of interactive classroom to execution, and the scheduling process is as follows

[0041] 1. Use case scenario

[0042]

[0043]

[0044] 2. Agent list

[0045]

[0046]

[0047] The background is as above, and the scheduling process is as follows:

[0048] 1. Three use cases are clicked to execute and added to the execution queue, and according to the digital weight, the priority order is: classroom answering, classroom signing, and classroom countdown;

[0049] 2. The use case of classroom answering at the head of the queue is popped out of the queue, and the agent machines are found, and the idle agents are found to be agent1, agent2, and agent3;

[0050] 3. According to the dependence terminal of the classroom answering use case, which is web / Android / iOS and the agent supporting capability, the agent machines that can support execution are filtered to be agent1 and agent2;

[0051] 4. After sorting the machines filtered in step 3 in ascending order according to the capability, the order is agent1 and agent2;

[0052] 5. The classroom answering use case is given to agent1 for execution, and the state of agent1 is set to occupied;

[0053] 6. Repeat step 2, and the use case at the head of the queue is classroom signing, and the dependence terminal is web / Android / iOS, and the idle devices are agent2 and agent3;

[0054] 7. After capability matching, the devices that can support execution are agent2, the use case is given to agent2 for execution, and the state of agent2 is set to occupied;

[0055] 8. Repeat step 2, and the use case at the head of the queue is classroom countdown, and the dependence terminal is client, and the idle device is agent3;

[0056] 9. According to the ability matching, if there is no agent machine that can undertake, the classroom countdown weight is-10, and the use case is re-joined in the queue, and the weight is sorted, if there is other use case in the process, the above steps are repeated, the first use case is popped out to find a machine, if there is no other use case, the classroom countdown use case will be polled to agent2 (only agent2 can undertake the client end) to execute the current task to release the idle state, and the agent executes the use case until all the use cases in the queue are executed.

[0057] That is, when there are many single UI automation test cases involving an uncertain number of multi-terminals, in the case of dynamically scalable services with different execution capabilities, the scheduling method of the test case with multi-terminal interaction improves the execution efficiency of the agent in the test case.

[0058] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for scheduling test cases involving multi-terminal interaction, characterized in that: Includes the following steps: Multiple test cases that require the terminal to be parsed are added to the execution queue in sequence, and corresponding priority weights are set. The priority weights are configured to decrease when there is no suitable agent during round-robin matching. When a test case is added to the queue, the test cases in the execution queue are sorted in descending order according to their priority weights. After the test cases are arranged, they are popped out sequentially from the head of the queue to be executed and a matching agent machine is queried. After matching the agent machine that can handle the test cases according to their dependent terminals, the test cases are executed in the selected agent. The agent machine can be expanded and registered. The queue to be executed is used to enqueue test cases and is in a polling state. There is no need to pre-match the connection between test cases and agent machines, and there is no need to consider whether there is a concurrency relationship between test cases; The test cases are popped sequentially from the head of the queue to be executed and the matching agent machines are queried, further including: After the test case at the head of the queue pops up, the status of the registered agent machines is queried. If no idle agent machine is found, the priority weight of the corresponding test case is reduced, and the reduced test case is re-entered into the execution queue and sorted in descending order in the execution queue. If an idle agent machine is found, the current test case needs to be further evaluated based on its dependent terminal to find an agent machine that can take over the execution. Upon investigation, if all available agent machines are unable to handle the current test case, the priority weight of the corresponding test case is reduced, and the reduced test cases are added back to the execution queue and sorted in descending order. If there are available agent machines capable of handling the current test case, the agent machines that meet the conditions are sorted in ascending order according to their handling capacity. The test case will be selected to be handled by the first agent machine in the sorted list and will begin execution. The selected agent machines are set to occupied status, i.e., no available machines. After the test case is executed, the agent machine that took over it is released and set to an idle state, waiting for the next query to match; The agent machine registers with the scheduling system before execution and registers its service capabilities, which include web, Android, iOS, and client-side applications.

2. The method for scheduling test cases for multi-terminal interaction according to claim 1, characterized in that... : After the test case files are retrieved and parsed from the GitLab code repository, the key information corresponding to the test cases is entered into the database scheduling system.

3. The method for scheduling test cases for multi-terminal interaction according to claim 2, characterized in that... The key information includes the test case file name, description, author, and the terminal that the test case depends on.

4. A scheduling system that applies the scheduling method for test cases involving multi-terminal interaction as described in any one of claims 1-3, characterized in that... It includes a suite management module, an agent machine management module, a task queue module, an environment module, and an execution record module. The suite management module is used to obtain and parse multiple test cases from the GitLab code repository. The agent machine management module is used to register agent machines and record their processing capabilities; The task queue module is used to set numerical priority weights for all test cases parsed from the suite management module, arrange them, and add them to the execution queue. It is also used to query and match test cases with agent machines and then execute them on the selected agent machine. The environment module is used to manage the execution environment of the agent machine; The execution log module is used to record the execution process of test cases in the task queue module and the execution completion report.

Images