Remote Device Scheduling for Mobile App Automated Testing

Author: Zhang Zhiyang

Preface:

"Cloud testing" has become a buzzword in recent years; commercial cloud testing platforms are proliferating, and major companies have been building their own solutions, as seen in conferences like MTSC, NCTS, and Alibaba Cloud Expo. Research shows that cloud testing platforms generally provide two core capabilities: remote real devices and automated testing.

Today we focus on a crucial step in ZhuangZhuang's app automation workflow – remote device scheduling.

Process Setup:

Mobile cloud testing consists of two components: remote devices and automation workflows.

Where are the remote devices?

Remote devices are the backbone of any cloud testing platform; without them, a platform cannot be called "cloud testing".

All ZhuangZhuang QA devices are centrally managed by the cloud device platform (MCP). Team members request and operate remote devices through MCP, making efficient use of device resources.

These devices are connected to dedicated MCP management servers, each running an Agent service that continuously monitors device status and synchronizes information back to MCP.

Therefore, remote device scheduling requires MCP support.

How should remote devices be scheduled?

MCP provides common operations such as device initialization, reboot, app installation, and file upload. When a user triggers these actions in MCP, MCP sends the corresponding command to the Agent, which executes the operation and reports the result back to MCP. This forms a complete remote‑device operation flow that can be referenced by automation tests.

Automation tasks have many custom configurations managed on a separate test platform, so interaction with MCP occurs via APIs.

The envisioned workflow is as follows:

Configure an automation task on the automation platform and trigger an MCP API call, specifying the device, test plan, and parameters.

MCP receives the request, parses the parameters, and selects the appropriate device.

MCP sends the automation command and parameters to the Agent on the device’s server.

The Agent receives the command, downloads required files, assembles the automation command, and executes it.

After discussions with the MCP and Agent teams, several missing details were identified and added:

Automation status should be displayed on the front‑end for easy device filtering and management.

Support simultaneous Android and iOS device allocations.

Automation commands must be extensible; a generic args field is reserved for dynamic information.

When multiple devices share a server, their automation files must be isolated to avoid interference.

After execution, devices must be returned to MCP via a release interface.

For performance tests that run repeatedly, the execution interface should allow reuse of devices currently in an automation state.

An interrupt interface is needed to abort tasks instantly and release devices when necessary.

Task Assignment:

Automation Test Platform:

Document all data required for automation execution based on test types, strategies, and framework commands.

Add MCP device information synchronization and display, distinguishing remote from local devices.

Implement calls to MCP execution APIs for test plans.

Add an interface to check whether all tasks on a device have finished and to release the device.

Provide a function to interrupt running test tasks.

Deploy the automation execution environment on all MCP servers.

MCP:

Provide an API to retrieve device information.

Provide an execution API that accepts a generic args parameter passed directly to the Agent.

Provide an API to interrupt automation tasks.

Provide a callback API for device release.

Add management logic for devices occupied by automation.

Agent:

Add a service interface for automation types, accepting a generic args that is appended to the automation command.

Implement status monitoring to report success, failure, or timeout.

Add a service interface to interrupt automation processes.

With the collaborative effort of all teams, the remote device scheduling workflow for automation has been successfully built.

Final Workflow:

The green line shows the complete remote‑device automation flow; the red line indicates the path when execution fails or is interrupted. This process has been stable for nearly a year and fully meets the remote‑device automation needs. When new automation task types appear, only the automation framework’s execution parameters need to be extended and passed through MCP’s execution API—no changes to MCP or Agent are required.

Device Scheduling Strategies:

After establishing a robust remote‑device scheduling process, three practical allocation strategies are in use:

Manual selection of devices for a test plan (supports multiple platforms and devices).

Scheduled tasks that automatically run test plans.

By default, use the previously selected devices.

Parameters can specify devices for the scheduled task.

If the chosen devices are unavailable, the system first tries to allocate devices that have been pre‑configured for the same task (shown in the green table) and notifies the executor via email.

If no pre‑configured devices are available, random allocation from the pool of supported devices occurs, with email notification.

If the automation device pool lacks sufficient free devices, other idle devices are allocated, and the executor is warned that results may be abnormal.

Direct invocation of the execution API to run a specific test plan or automation type, supporting the same device‑allocation rules as scheduled tasks.

Future Plans:

The current scheduling process assumes devices are in a default state (no special agents or configurations). In practice, testers often need to run tests with custom device setups or special preparations. To accommodate these scenarios, the scheduling workflow and strategies will be refined accordingly, adding support for more advanced automation requirements.

Past Highlights:

iOS Remote Real‑Device Control Practice

Java Bytecode Enhancement Techniques

New Ideas for RPC Service Testing

MQ Message Construction – Decomposing Problems

A Brief Talk on IM and Related Testing Methods

CodeDiff Implementation Overview

Using Wireshark for Packet Capture

Mobile H5 Performance Testing Platform (Part 1)

Happy Delivery Mini‑Program Automation Exploration

One‑Minute Overview of ZhuangZhuang Mini‑Program Testing System

ZhuangZhuang Test Environment Platform Solution

Performance Boost Journey – ZhuangZhuang Beetle Platform 100‑Day Chronicle

Xmind To Cases Tool

ZhuangZhuang Transaction Full‑Link Interface Testing Development and Expansion