Why UI Automation Stalls and How to Revive It: A Frontend Testing Playbook

Framework selection

Desktop: AutoIt, Selenium, Puppeteer, Mocha, Pywinauto, Sikuli

Mobile: UIAutomator, Instrumentation, WDA, Appium, XCTest

Internal platforms: QTA (large‑scale automation platform), Zhiyan, Testone (DWT & Rua frameworks), Wetest (device management)

Other solutions: AirTest, custom SDKs

Initial implementation

The early automation combined Selenium with the internal QTA platform. Custom screenshot handling replaced ImageGrab.grab with driver.get_screenshot_as_file, and test execution was run in headless mode to improve speed.

Key problems

Massive test matrix across Windows, macOS, iOS, Android and Web caused frequent merge conflicts that broke large portions of the suite.

High manual effort at every stage: test‑case understanding, authoring, environment validation, debugging and issue triage.

Flaky UI locators (e.g., attribute errors, changing XPaths) and lack of quantitative coverage data.

Solution overview

5.1 Process planning & result optimisation

Adopted a horizontal‑and‑vertical code‑reuse strategy:

Horizontal unification : All business teams share a common base library for driver initialisation, login, and common utilities.

Vertical unification : A single test case can run on Web, Windows and macOS by abstracting platform‑specific details into a base class.

Example of platform‑specific base class selection:

platform_type = config.Platform_Type
if platform_type == PLATFORM_WEB:
    from wedoctest.wedocapp.web_test_case import WeDocBaseTestCase
elif platform_type == PLATFORM_WIN:
    from wedoctest.wedocapp.win_test_case import WeDocBaseTestCase
elif platform_type == PLATFORM_MAC:
    from wedoctest.wedocapp.mac_test_case import WeDocBaseTestCase

class LaunchWord(WeDocBaseTestCase):
    """Word document automation base class compatible with mac, Windows and web"""

Key practices introduced:

Template‑based UI element location using XPath, image matching (AirTest) and OCR for stable identification.

Injecting JavaScript in Web tests to retrieve element attributes directly from the application, reducing reliance on fragile locators.

Using ADB broadcasts for Android actions, e.g.:

adb shell am broadcast -a com.tencent.xxx --es action "click_accept"

5.2 Task closure & reporting

Automation tasks are linked to change tickets. A subscription system notifies stakeholders of missed runs, low success rates or critical failures. Reports are unified across desktop and mobile, containing step‑by‑step actions, screenshots and automatically classified error types. One‑click bug filing captures case details, logs, environment information and attaches relevant videos.

5.3 Team collaboration & case sharing

All teams co‑define automation goals, share reusable test cases and involve developers in debugging. The repository now hosts more than 33 code bases with over 6,000 test cases on the main branch, executed >150 times daily.

Metrics & stage results

Core business coverage exceeds 70 % .

Automation success rate for daily releases is above 93 % .

Daily execution count >150 runs, with >6,000 cases in the main branch.

Bug detection: >140 bugs, including >60 critical issues in one month.

Test‑suite stability >95 % in unchanged environments.

Future outlook

Planned enhancements include leveraging large language models for automated test‑case generation, deeper performance testing (timing, memory, CPU) and extending the framework to new product areas. Continuous metric collection, framework hygiene and cross‑team ownership are essential for sustainable automation.