Mobile UI Automation Testing with AI Phone Control, No Scripts

Teams doing mobile UI automation usually think of Appium first. Almost every team I have dealt with started there. The framework itself is enough. They look for another approach when the maintenance gets out of hand.

Where the time and the environment go

The environment has to be ready first: phone drivers, the SDK, the server side, the client connection, and the differences between models and OS versions. When the environment is unstable, testers spend most of their time on why a device will not connect. Checking the feature comes after that.

Scripts are the second piece. A locator-based setup means choosing a locator while you write, handling waits and popups while it runs, and going back to fix it after a redesign. One control change can take a batch of cases down together. The more cases you have, the more you have to change. You often end up with a large pile of cases, and few of them still get run.

Dimension	Script-based setup	Conversation plus workflow
Cost to start	Set up the environment and write code	Say the steps clearly and it can run
How a case is written	Code plus assertions	Plain-language description
After a redesign	Locators break and the script has to change	It acts on what is on the screen, so a redesign breaks less
Many device models	A separate environment for each set	Pick devices by group
Where results show up	A test-report framework	One record in execution history

This path does not cover a full test-engineering setup. It is for quick checks and repeat regression. The tool is iEasyRun. It runs on your own computer, supports Android, iOS, and HarmonyOS, and keeps several phones together.

Say the steps in conversation, then save them as a workflow

Install the workstation and the phone-side program from the installation selection page, and confirm the test phone is online on the devices page. An offline device can only be viewed. It cannot run.

Then open a new session on the conversation page, select the online test phone, and walk through the case in plain language. Cover three things:

1. Preconditions: which screen you start from, and whether you log in first or clear data first.
2. Steps: what to tap, what to type, and which screen to wait for.
3. Expected result: which text should appear, and which page it should land on.

The bottom of the conversation page has Consult, Run, and Refine. Pick by how clear the case already is.

Run: you already know the steps. Send the instruction. The AI plans at once and operates on the real phone.

Refine: you know what to test, and the steps are not filled in yet. Talk through the screens, the order, and the boundary conditions over several turns, turn that into steps that can run, then switch to Run.

Consult: you only ask how to write it. The test phone is not controlled.

A description you can copy to start:

Open the app, log in with the test account, go to the Me page, tap the avatar to open the profile, change the nickname to test001, save, go back, and confirm the nickname shows as test001.

What you settle while refining can be saved on the prompts page. The next time you run the same case, pull it back out.

Conversation is for trying a case. Once the same case has run cleanly several times in a row, save it so you do not describe it again each time.

Create one in the workflow library on the workflows page and edit it on the canvas. Common steps include “start the automation environment,” “wait,” “open the app,” and “gesture: swipe.” Put the case in a fixed order.

What the canvas can do	Use in a test
Validate	Check the step links and parameters before it goes live, so a config error does not show up halfway through a run
Arrange	Once there are many steps, tidy the layout so the case structure is readable at a glance
AI workflow help	Have the AI generate or fill in steps, so a long case does not have to be built from nothing
Trial run	Check the template on one test phone, then roll it out to the whole group

Account, nickname, keyword, and anything else that may change each time should stay as parameters. Do not write them into the template. Pass them in when you run it. One “change nickname” template can cover a normal value and a boundary value.

After it is set up, trial-run one test phone. The trial result goes into execution history in the same record format as a formal run, so you can compare them.

How to read execution history, and how to group models

Results are collected on the execution history page. Each record has four fields: where the task came from (a conversation session, a scheduled task, or a workflow trial run), the status (success, failure, or in progress), the target device, and the error message. On a failure, read the log summary in the error.

For regression across models, filter by target device. You can see which machine and which OS version failed.

The words in the error line up with a next step:

• “automation environment”: go back to the install page and check the phone-side settings
• “device offline”: go back to the devices page and check the connection
• “unauthorized / expired”: check the template status in the workflow library
• an image match or recognition failure: add an image template, or check the related settings under capabilities and models

With few models, the differences are still small. Once there are many devices, it is hard to tell which one is which. On the devices page, do four things: scan, add the phone, set an alias, and group it.

Test phones can be grouped two ways.

By OS version, such as “Android 13,” “Android 14,” and “iOS 17,” so you can see where compatibility differs.

By purpose, such as “smoke phones” and “regression phones,” so machines that run on different schedules stay apart.

After the groups exist, pick devices by group when you send a regression. One dispatch covers every online phone in the group. Each phone runs the same case template on its own. When a new test phone arrives, add it and put it in the matching group. Later tasks include it.

Once the flow is stable, put the regression on a fixed time from the schedule page. Set a workflow schedule, pick the template and the target group, set the time rule, and it runs when the time comes. Three conditions, the same as other scheduled tasks: the workstation on the computer stays on, because scheduling is local and there is no cloud side; the target device is online, or it can connect on its own when the time comes; for a USB device, the cable is still connected at that moment.

What to hand it, and what stays in the old framework

It fits smoke checks on the critical path, repeat regression before a release, consistency checks across device models, and whether a UI element or a piece of copy is on the screen. The steps are clear, they have to run again and again, and they do not need a fast response.

Keep the old setup for tests that assert an exact number or an API response, for complex concurrency and performance numbers, and for cases that have to sit inside CI and produce a structured test report. iEasyRun gives you real-phone operation and execution records. It does not include a full test-report framework. The part of regression you tap most often can go here. Assertions and reports stay in the original framework.

Once a case runs from what is on the screen, a redesign means fewer trips back to fix locators. Connect one test phone, pick the case you run most often, run it in conversation, and save it as a workflow. After it runs cleanly, group by model and add a schedule. The software is completely free, with no paywall. It runs on your own computer, and the data stays local. Setup is on the installation selection page.