An Android graphical interface automatic testing method based on a multi-machine parallel architecture

Abstract

This invention discloses an automated testing method for Android graphical user interfaces based on a multi-machine parallel architecture, comprising: determining parallel scheduling nodes and test nodes based on node capability tag bidding; the parallel scheduling node maintaining a global test task queue and exploration frontier, prioritizing and deduplicating test subtasks according to indicators such as application entry point, page novelty, coverage benefits, and historical execution feedback; the test node completing a closed loop of page state reading, click / input strategy execution, and log and crash stack collection within a local Android test container; after the execution trajectory and exception information are returned, the parallel scheduling node uniformly performs result merging, sample management, and report generation, and provides a standardized interface to the external security vulnerability mining task management / scheduling subsystem. This invention solves the problems of low efficiency, repetitive exploration, and single point of failure in single-machine testing.

Description

Technical Field

[0001] This invention relates to the field of graphical user interface testing, and more specifically to an automated testing method for Android graphical user interfaces based on a multi-machine parallel architecture. Background Technology

[0002] Current automated testing of Android applications' graphical user interfaces (GUIs) faces challenges in single-device exploration mode, including slow coverage improvement, severe path duplication, and difficulties in adapting to complex applications. As application size and interaction complexity rapidly increase (multiple entry points, deep page navigation, dynamic components, and cross-process interactions), single-instance testing tools tend to repeatedly linger on popular pages, failing to effectively reach less popular branches. Simultaneously, behaviors such as login, personalized recommendations, and dynamic loading cause page structures to change over time and with varying user states. Single-device or loosely parallel exploration struggles to maintain a globally consistent test view, limiting testing efficiency and defect detection rates.

[0003] Existing technologies mainly include single-machine exploration tools such as random click tools, model-driven tools, and evolutionary / reinforcement learning-driven tools, as well as cloud-based parallel execution platforms oriented towards the resource layer. Random / heuristic tools (such as the early DroidBot) have low implementation costs but limited insight into complex interface behaviors; model-driven tools (such as solutions centered on interface transition graphs, Stoat, etc.) guide exploration by constructing finite-state models, but most still rely on single-instance execution; evolutionary / reinforcement learning solutions (such as explorers based on multi-objective optimization or human behavior simulation) can achieve certain gains on single machines, but lack a unified mechanism for large-scale collaboration and deduplication. On the other hand, while cloud real machine / simulator platforms provide parallel device resources, they focus more on the ability to "run simultaneously," lacking cross-device global state sharing, unified scheduling, and result aggregation, making it difficult to avoid redundancy at the algorithmic level.

[0004] The aforementioned existing technologies share the following common defects: First, the lack of a globally consistent Interface Transition Graph (UTG) and exploration frontier maintenance prevents the deduplication and incremental merging of test states across devices / processes, resulting in significant noise and duplicate execution. Second, the lack of multi-node task prioritization and benefit evaluation mechanisms hinders the concentration of limited resources on high-value paths. Third, the scheduling plane commonly suffers from single points of failure and manual intervention; control node anomalies interrupt tasks, making it difficult to meet the engineering requirements for long-term stable operation. These issues directly lead to sluggish growth in test case output and code coverage, scattered crash and exception samples, and incomplete reproduction scripts and location information.

[0005] At the engineering implementation level, existing tools lack sufficient support for heterogeneous operating environments and enterprise-level integration. Most solutions lack unified adaptation and offline automated deployment for x86 / ARM, different Android SDK versions, and virtualization environments such as reDroid; test results are mostly raw logs and scattered screenshots, lacking standardized sample management, crash stack traces, vulnerability trigger sequence diagrams, risk analysis, and remediation suggestions—structured outputs geared towards the R&D closed loop; at the same time, the interfaces with enterprise-side security vulnerability mining task management / scheduling systems are not unified, making it difficult to achieve integrated parallel task orchestration, result display, and report generation.

[0006] Therefore, there is an urgent need for an automated testing technology for Android GUI that supports multi-machine parallel processing. This technology should achieve incremental consistency of the global UTG and deduplication for exploring cutting-edge technologies at the algorithm level, provide self-healing high-availability scheduling and offline automated deployment at the system level, and output structured test results that can be directly used for engineering repair loops. Only by simultaneously addressing the issues of parallel collaboration, environment adaptation, and result engineering can we achieve a balance between large-scale test case output, improved coverage, and rapid defect localization in complex application scenarios (such as Meituan and Douyin). Summary of the Invention

[0007] The purpose of this invention is to provide an automated testing method for Android graphical interfaces based on a multi-machine parallel architecture, in order to solve the problems that single-machine GUI exploration is prone to state duplication and redundant paths, making it difficult to balance coverage and efficiency in complex applications; at the same time, heterogeneous environments (x86 / ARM, different SDK versions) pose higher requirements for deployment and stability.

[0008] To achieve the above objectives, the present invention employs the following technical solution: An automated testing method for Android graphical user interfaces based on a multi-machine parallel architecture includes: Node deployment and role election phase: The environment initialization and agent deployment are completed on each node through offline installation scripts. After the node starts up, it reports its capability tags and elects a parallel scheduling node based on heartbeat keep-alive and voting mechanisms. The remaining nodes become test nodes. Task access and segmentation phase: Input the application to be tested and the test strategy into the parallel scheduling node, preprocess the application to be tested, and segment the test task into multiple sub-tasks that can be executed in parallel; During the test task distribution phase, the parallel scheduling node maintains a globally unified interface transition graph, state summary set, or exploration frontier set as the basis for subtask distribution. Before subtask distribution, the subtasks are first deduplicated and sorted based on the global state. Then, the subtasks are matched and distributed in combination with the capability tags of the test node, and a timeout reassignment mechanism is set for the subtasks. Test execution and status acquisition phase: The test node starts the application under test locally and enters the event execution loop; each round determines the next test action based on the status information of the current interface and a preset strategy; the test node collects the running information during the action execution process and records the event sequence and snapshot when risky behavior is detected; In the result feedback and report generation phase, the test node sends the test results generated when the application under test is executed locally back to the parallel scheduling node; the parallel scheduling node performs global merging and extraction of the backed test results, and finally generates a structured test report. High availability and self-healing phase; through periodic heartbeat monitoring between parallel scheduling nodes and test nodes, failed nodes are detected and their unfinished subtasks are reclaimed, leases are reset and redistributed; when a parallel scheduling node crashes, role reselection is triggered, and a new parallel scheduling node recovers its state from shared storage; at the same time, the unique identifiers and idempotent checks of test tasks and results are used to avoid duplicate processing.

[0009] Furthermore, the capability tag is used to describe the testing capabilities and resource availability of the node; the capability tag is encoded into a structured data object and sent to the cluster registry center; All nodes that have been deployed and successfully registered are initially designated as candidate nodes. Through a role election protocol based on heartbeat keep-alive and voting mechanisms, a parallel scheduling node is automatically selected from the candidate nodes to be responsible for maintaining the global task queue, deduplication status, and result aggregation. The remaining nodes are identified as test nodes and are responsible for actually executing test tasks. The voting mechanism can be implemented using priority comparison, node lease, distributed consensus protocol, or primary / secondary election mechanism; multi-master conflicts are avoided through majority voting, timeout retries, and term number comparison; if the current parallelism node loses connection, crashes, or actively withdraws, the remaining test nodes will automatically initiate a re-election.

[0010] Furthermore, in the task access and segmentation stage, for gray-box mode, static analysis results, interface jump prior information, code instrumentation results, function coverage information or component call graph information are received to assist in subsequent task priority sorting. The preprocessing process of the parallel nodes for the application under test includes verifying the integrity of the APK, parsing the Manifest file, extracting the entry Activity, identifying permission declarations, identifying exportable components, creating an initial startup script, configuring installation parameters, and generating a unique task identifier for each application under test. Based on the test objectives, the test task is constructed into multiple sub-tasks according to the application entry point, page function area, known components, exploration depth, time slice budget, or behavior strategy type.

[0011] Furthermore, the interface transition graph is used to record the jump relationships between page states; the state summary set is used to represent visited pages, executed event combinations, observed anomaly samples and their corresponding contexts; the exploration frontier set is used to maintain page states or action candidates that have not yet been fully explored but have high expected returns. The deduplication criteria used by the parallel scheduling nodes before distributing tasks include page hierarchy tree hash value, control attribute summary, screenshot-aware fingerprint, Activity name and control set combination identifier, event sequence prefix summary, or a combination of multiple features. Subsequently, the parallel nodes select and sort the tasks based on a preset priority rule. The priority rule comprehensively considers factors such as page novelty, historical coverage benefits, target control scarcity, path depth, crash proximity, node adaptability, and retry history. When subtasks are distributed, the parallel scheduling node matches the capability tags reported by the test nodes, prioritizing the allocation of high-load subtasks to test nodes with sufficient resources, allocating subtasks that depend on specific SDK versions to compatible test nodes, and allocating ARM or x86-specific image subtasks to test nodes of the corresponding architecture; the distribution method is either push or pull. Set a lease time, execution confirmation status, and failure retry flag for each subtask; if no response is received after a timeout, re-queue the subtask and wait for reassignment.

[0012] Furthermore, the test node performs actual GUI automated tests in a local Android runtime container; the preset strategies include a random strategy, a heuristic strategy based on control visibility, a path expansion strategy based on the interface model, and a priority exploration strategy based on historical gains; the test node is allowed to maintain a node-level cache locally; After the test action is completed, if a risky behavior is detected, the event sequence before and after the trigger, the interface state snapshot and the log context are recorded and saved as an anomaly sample; a timestamp, page summary and execution result label are attached to each test action to form a complete test trajectory chain.

[0013] Furthermore, the test nodes transmit the test results generated by local execution back using structured result objects; after receiving the test results, the parallel scheduling nodes perform a global result merging operation, including but not limited to: writing newly discovered page states into the global interface transformation graph, adding executed paths to the explored set, clustering abnormal samples according to crash signatures, call stack summaries, or trigger contexts, folding duplicate alerts, and calculating the actual benefit value of each subtask; for crash samples, extracting key stack frames, exception types, the sequence of events in the last few steps before triggering, and the corresponding page states to form a directly reproducible defect summary; for suspicious risk behaviors, generating a vulnerability triggering sequence diagram to visually display the chain path relationship of "starting page - key action - intermediate jump - abnormal trigger point".

[0014] Furthermore, the parallel scheduling node and the test node maintain periodic heartbeat communication. The scheduling node is used to sense whether each test node is online, whether the load is normal, and whether the container is healthy. The test node is used to sense whether the scheduling node is continuously reachable. If a test node fails to report a heartbeat within a preset time window, the scheduling node can mark it as a failed node and perform recycling, lease reset, and redistribution of its occupied but unfinished subtasks. When a parallel scheduling node fails, the test node re-elects a new parallel scheduling node according to the preset election rules. The newly elected parallel scheduling node restores the global task queue, page state summary, and result index information from shared storage, persistent database, or the most recent state snapshot. It sets a unique identifier for the test task and result object and uses an idempotent verification mechanism to prevent the same result from being merged multiple times.

[0015] An automated testing system for Android graphical user interfaces based on a multi-machine parallel architecture includes: The node deployment and role election module is used to complete the environment initialization and agent deployment on each node through offline installation scripts. After the node starts, it reports the capability tags and elects a parallel scheduling node based on the heartbeat keep-alive and voting mechanism, while the remaining nodes become test nodes. The task access and segmentation module is used to input the application under test and the test strategy into the parallel scheduling node, preprocess the application under test, and segment the test task into multiple sub-tasks that can be executed in parallel. The test task distribution module is used to schedule nodes in parallel. It maintains a globally unified interface transition graph, state summary set, or exploration frontier set as the basis for subtask distribution. Before subtask distribution, it first performs deduplication and sorting of subtasks based on the global state. Then, it matches and distributes subtasks based on the capability tags of the test nodes and sets a timeout reassignment mechanism for subtasks. The test execution and status acquisition module is used by the test node to start the application under test locally and enter the event execution loop. In each round, based on the status information of the current interface, the next test action is determined based on the preset strategy. The test node collects the running information during the action execution process and records the event sequence and snapshot when risky behavior is detected. The result feedback and report generation module is used by the test node to send back the test results generated when the application under test is executed locally to the parallel scheduling node; the parallel scheduling node performs global merging and extraction of the returned test results, and finally generates a structured test report. The high availability and self-healing module is used to detect failed nodes and reclaim their unfinished subtasks, reset leases and redistribute them through periodic heartbeat monitoring between parallel scheduling nodes and test nodes; when a parallel scheduling node crashes, it triggers role reselection, and the new parallel scheduling node recovers its state from shared storage; at the same time, it avoids duplicate processing by using unique identifiers and idempotent checks for test tasks and results.

[0016] A terminal device includes a processor, a memory, and a computer program stored in the memory; when the processor executes the computer program, it implements the Android graphical interface automated testing method based on a multi-machine parallel architecture.

[0017] A computer-readable storage medium storing a computer program; when executed by a processor, the computer program implements the automated testing method for Android graphical interfaces based on a multi-machine parallel architecture.

[0018] Compared with the prior art, the present invention has the following technical features: This invention significantly improves test case output, coverage efficiency, and defect localization capabilities while reducing redundancy and noise through globally unified task scheduling, frontier deduplication distribution, and high-availability node collaboration. In comparison with existing model-driven tools (such as Stoat), this invention increases the number of valid test cases generated by approximately 1200% under the same time budget, reduces redundant events and duplicate paths by approximately 86%, and improves overall code coverage by approximately 30%. Relying on crash sample clustering and call stack backtracking, this invention significantly reduces the human cost of defect localization, completing the localization and reproduction script generation for a single defect in an average of approximately 10 minutes. This invention runs stably in both ARMUbuntu+reDroid and x86 environments and has been adapted and verified in complex domestic GUI application scenarios such as Meituan and Douyin, demonstrating good robustness to diverse interface structures and dynamic components. Meanwhile, the results provided by this invention are more comprehensive: it can intuitively present key information such as static analysis results of the target application, vulnerability trigger sequence diagram, crash call stack, risk analysis and remediation suggestions, trigger time and number of triggers, etc., supporting closed-loop testing and rapid remediation in R&D, and comprehensively demonstrating its significant advantages over existing technologies in terms of parallel efficiency, coverage quality and engineering feasibility. Attached Figure Description

[0019] Figure 1 This is a system framework diagram of the method of the present invention; Figure 2 This is a schematic diagram of the module interaction of the system of the present invention. Detailed Implementation

[0020] This invention provides an automated testing method for Android graphical user interfaces based on a multi-machine parallel architecture. Through global task scheduling and exploration of cutting-edge deduplication distribution mechanisms, it achieves efficient generation of test cases through multi-node collaboration and significantly improves code coverage and defect location efficiency. At the same time, it designs a unified execution and result display framework that can be adapted to complex GUI applications, supporting automated output of static analysis, vulnerability triggering sequence tracing, crash call stack parsing, and risk remediation suggestions.

[0021] This invention provides a system applicable to automated graphical interface testing scenarios for Android applications (APKs), particularly suitable for applications with deep page hierarchies, complex interaction paths, frequent dynamic component loading, reliance on login or user state switching, and where single-machine testing is insufficient to complete thorough exploration within a reasonable timeframe. The application can be a native Android application running on a smartphone, tablet, cloud device, or virtualized Android container, or a hybrid application containing WebView, dynamic components, or cross-process interaction logic. In a typical embodiment, the testing target is a large-scale domestic mobile application, and the testing objectives include, but are not limited to: automatically generating test event sequences, improving interface state coverage, discovering crashes and abnormal behaviors, forming reproducible defect triggering paths, and outputting structured analysis results for use by R&D or security teams.

[0022] This invention achieves efficient generation of test cases and drives defect analysis through unified task access, deduplication distribution, and result feedback across multiple nodes. The overall approach is as follows: Parallel scheduling nodes maintain a global test task queue and exploration frontier, prioritizing and deduplicating test subtasks based on indicators such as application entry point, page novelty, coverage benefits, and historical execution feedback; test nodes complete a closed loop within their local Android test container, encompassing page state reading, click / input strategy execution, and log and crash stack collection; after execution traces and exception information are fed back, the parallel scheduling nodes uniformly merge results, manage samples, and generate reports, providing a standardized interface to the external security vulnerability mining task management / scheduling subsystem.

[0023] Before executing the entire testing process of this invention, the test environment needs to be prepared first. This preparation includes at least: the application under test (APK), configuration files related to the testing strategy, the basic runtime environment for each node, an Android runtime container or emulator image, inter-node network communication configuration, and result storage directory or database connection information. A node refers to a computing device connected to the system of this invention and undertaking scheduling or execution functions; it can be a physical server, a virtual machine, or a container host. The Android runtime container can be reDroid, AndroidEmulator, Genymotion, or other virtualization components that can provide an Android runtime environment. The basic runtime environment can be a Linux system environment, preferably Ubuntu, but can be replaced with other operating system platforms that support container orchestration, automated script installation, and Android virtualization execution, depending on deployment requirements. Each node is pre-installed with Python, Java, Android SDK, ADB toolchain, container runtime, log collection module, and node communication components to ensure that subsequent task scheduling, test execution, and result feedback can be completed automatically. For heterogeneous nodes, this invention allows simultaneous access to x86 architecture nodes and ARM architecture nodes, and manages compatibility through a unified image description file, architecture identifier, and capability tag.

[0024] After completing the above preparations, the design process of the system of the present invention can be further refined into the following six stages. Each stage can be executed sequentially or partially in parallel if the prerequisites are satisfied.

[0025] 1. Node deployment and role election phase: The environment initialization and agent deployment are completed on each node through offline installation scripts. After the node starts, it reports its capability tags and elects a parallel scheduling node based on the heartbeat keep-alive and voting mechanism. The remaining nodes become test nodes.

[0026] In this phase, an offline installation script is first used to complete environment initialization, dependency installation, image retrieval, test agent deployment, and system registration on the nodes to be connected. The offline installation script is preferably an automated installer composed of a Shell script, a Python script, or a combination of both, and its execution environment is preferably a Linux server terminal environment. The offline installation script pre-packages an Android test image, dependency installation packages, configuration templates, and startup commands, enabling batch deployment in environments without external network access or with restricted network access, thus adapting to the deployment needs of enterprise intranets, laboratory clusters, or secure isolation environments. After installation, each node starts a local node agent process, which is responsible for collecting and reporting the capability tags of that node.

[0027] The capability tags are used to describe the testing capabilities and resource availability of a node, and include at least one or more of the following information: CPU architecture type, memory capacity, disk space, Android SDK version, supported Android container types, number of test instances that can be launched concurrently, current load status, node network address, device identifier, historical failure rate, and node health status. Preferably, this invention encodes the above capability tags into structured data objects and sends them to the cluster registry center for subsequent role election and task allocation.

[0028] In one implementation, all deployed and successfully registered nodes are initially in a candidate state. The system automatically selects a parallel scheduling node from the candidate nodes using a role election protocol based on heartbeat keep-alive and voting mechanisms. This node is responsible for maintaining the global task queue, deduplication status, and result aggregation. The remaining nodes are identified as test nodes and are responsible for actually executing test tasks. The voting mechanism can be implemented using priority comparison, node leases, distributed consensus protocols, or a master-slave election mechanism. For example, nodes with higher computing resources, more stable networks, and more reliable historical operation can be prioritized as parallel scheduling nodes; multi-master conflicts can also be avoided through majority voting, timeout retries, and term number comparison. If the current parallel scheduling node becomes disconnected, crashes, or voluntarily withdraws, the remaining test nodes can automatically initiate a re-election according to the same election rules to form a new scheduling node, thereby avoiding the interruption of the entire test process due to a single point of failure. The above role division method is not unique. In alternative implementations, scheduling roles can also be determined by pre-designating a master node, manually configuring master and slave nodes, or using external coordination services to elect a master.

[0029] Through this stage, the present invention realizes the automatic access, capability awareness and scheduling role self-organization of multi-node test clusters, providing a unified basic operating platform for subsequent multi-machine parallel testing.

[0030] 2. Task access and segmentation stage: Input the application to be tested and the test strategy into the parallel scheduling node, preprocess the application to be tested, and segment the test task into multiple sub-tasks that can be executed in parallel.

[0031] In this phase, the parallel scheduling node receives the application under test and the test strategy input, and transforms them into test subtasks that can be executed in parallel. The application under test includes the target APK file, application package name, and information about launchable Activities. The test strategy includes, but is not limited to, test time budget, step budget, blacklist and whitelist page configuration, whether to enable login state, whether to enable gray-box auxiliary information, whether to preserve the crash scene, and result output format requirements. For gray-box mode, it can further receive static analysis results, interface jump prior information, code instrumentation results, function coverage information, or component call graph information to assist in subsequent task priority ranking. The various parameters in the test strategy are used in the stages of task splitting, task distribution, test execution, and result reporting.

[0032] Upon receiving the aforementioned input, the parallel scheduling node first preprocesses the application under test. In one implementation, preprocessing includes: verifying APK integrity, parsing the Manifest file, extracting the entry Activity, identifying permission declarations, identifying exportable components, creating an initial startup script, configuring installation parameters, and generating a unique task identifier for each application under test. Subsequently, the system divides the overall test task according to the test objective. This division is not a simple average distribution, but rather constructs multiple sub-tasks based on the application entry point, page functional areas, known components, exploration depth, time slice budget, or behavioral strategy type. For example, "shallow exploration starting from the homepage entry point," "deep exploration starting from the personal center after login," and "targeted exploration around a specific Activity" can be divided into different tasks. Alternatively, it can be divided according to different strategy instances, such as random strategy sub-tasks, model-driven strategy sub-tasks, and historical uncovered area compensation sub-tasks.

[0033] In a preferred embodiment, each test subtask includes at least the following fields: target application identifier, initial page or entry context, event budget, strategy parameters, node architecture constraints, execution priority, maximum number of retries, associated historical state summary, and expected result feedback identifier. Through task segmentation, this invention decomposes the overall testing problem of a complex application into multiple subtasks that can be executed in parallel, have independently quantifiable benefits, and be dynamically recycled and redistributed according to state, providing a foundation for efficient multi-node collaboration in the future. Alternatively, this stage can also avoid explicitly segmenting into fixed-size subtasks, instead maintaining a unified exploration frontier, with test nodes "pulling" the next state to be explored as needed; both fall within the scope of this invention.

[0034] 3. Test task distribution phase; Parallel scheduling nodes maintain a globally unified interface transition graph, state summary set, or exploration frontier set as the basis for subtask distribution; Before subtask distribution, subtasks are first deduplicated and sorted based on the global state; Then, matching and distribution are performed in conjunction with the capability tags of the test nodes, and a timeout reassignment mechanism is set for subtasks.

[0035] In this phase, parallel scheduling nodes deduplicate, sort, and distribute subtasks based on the global state. Unlike existing technologies that simply distribute tasks by polling idle nodes, this invention preferably maintains a globally unified interface transition graph, state summary set, or exploration frontier set as the core basis for subtask distribution. The interface transition graph records the jump relationships between page states; the state summary set represents visited pages, executed event combinations, observed anomaly samples, and their corresponding contexts; the exploration frontier set maintains page states or action candidates that have not yet been fully explored but are expected to yield high returns.

[0036] Before distributing tasks, the parallel scheduling nodes first perform deduplication based on the task description and global state to avoid multiple test nodes repeatedly exploring the same page state, the same event prefix, or obviously equivalent action paths within the same time window. The deduplication criteria can be page hierarchy tree hash value, control attribute summary, screenshot-aware fingerprint, Activity name and control set combination identifier, event sequence prefix summary, or a combination of these features. Subsequently, the parallel nodes select and sort tasks based on preset priority rules. These priority rules can comprehensively consider factors such as page novelty, historical coverage benefits, target control scarcity, path depth, crash proximity, node adaptability, and retry history. For example, this invention can assign higher scheduling priority to newly appearing pages, less frequently accessed states after deep jumps, and pages that have recently triggered boundary anomalies multiple times; for states that have been repeatedly traversed by multiple nodes and have low benefits, their distribution priority is reduced.

[0037] When subtasks are actually distributed, the parallel scheduling node matches them with the capability tags reported by the test nodes, prioritizing the allocation of high-load subtasks to nodes with sufficient resources, subtasks dependent on specific SDK versions to compatible nodes, and subtasks with ARM or x86-specific images to nodes corresponding to their architectures, thereby improving resource utilization and execution success rate. The distribution method can be push-based, where the parallel scheduling node actively distributes subtasks; or pull-based, where test nodes actively request tasks when idle. To prevent subtask loss, this invention can also set a lease time, execution confirmation status, and failure retry flag for each subtask; if no response is received after timeout, the subtask is re-queued for re-allocation. Through this stage, this invention achieves dynamic, deduplicated, and reward-oriented task scheduling for multi-node collaborative environments.

[0038] 4. Test Execution and Status Acquisition Phase: The test node starts the application under test locally and enters the event execution loop; each round determines the next test action based on the status information of the current interface and the preset strategy; the test node collects the running information during the action execution process and records the event sequence and snapshot when a risky behavior is detected.

[0039] In this phase, test nodes execute actual GUI automated tests within a local Android runtime container. Upon receiving a subtask, the test node first starts or reuses the corresponding Android test container based on the task parameters, completing APK installation, application startup, initial page loading, and necessary test state injection. If the task requires the use of a predefined account, simulated permission authorization, preset network state, or a specific user state, the test node will construct the corresponding environment before performing the exploration to ensure that subsequent events can fall into the target functional path.

[0040] Subsequently, the test node enters the event execution loop. In each loop, the test node first reads the current interface's state information, which may include at least: the current Activity name, interface hierarchy tree, control coordinates, text content, clickable attributes, input box attributes, scroll area information, pop-up information, and screenshots. Then, the test node selects the next test action from the candidate action set according to a preset strategy. The candidate actions may include click, long press, swipe, text input, back, menu trigger, system event simulation, multi-point operation, or a combination thereof. The preset strategy may be a random strategy, a heuristic strategy based on control visibility, a path expansion strategy based on the interface model, a priority exploration strategy based on historical gains, or other strategies and methods that can drive automated interaction of the Android GUI. To improve the strategy's effectiveness, this invention allows for local maintenance of node-level caches, such as recording recently visited state summaries, failed control coordinates, and suspected invalid pages, to reduce local invalid exploration.

[0041] After the test action is executed, the test node continuously collects runtime information during the execution process, including but not limited to: interface change results, system logs, application logs, exception stacks, ANR information, crash signals, resource usage, function call stacks, or instrumentation events. If application crashes, page freezes, abnormal jumps, black screens, permission abnormalities, or other unexpected risk behaviors are detected, the event sequence before and after the trigger, interface state snapshots, and log context are immediately recorded and saved as exception samples. To facilitate subsequent reproduction, this invention preferably adds a timestamp, page summary, and execution result tag to each test action, thereby forming a complete test trajectory chain. As an alternative, the execution subject in this stage can be not only a virtualized Android container, but also a physical device, a cloud device, or other device environments that support ADB control and interface capture.

[0042] Through this stage, the present invention can continuously obtain fine-grained page evolution information and anomaly evidence while multiple nodes are executed in parallel, providing a complete data foundation for global deduplication, crash clustering and report generation.

[0043] 5. Result feedback and report generation stage: The test node sends the test results generated when the application under test is executed locally back to the parallel scheduling node; the parallel scheduling node performs global merging and extraction of the backed test results, and finally generates a structured test report.

[0044] During this phase, the test nodes transmit the test trajectory, interface state summary, anomaly samples, log files, and statistical metrics generated during local execution back to the parallel scheduling node. To adapt to large-scale parallel operation environments, this invention preferably uses structured result objects for transmission. These result objects may include fields such as task identifier, node identifier, start state, execution event sequence, termination state, summary of newly discovered pages, crash type, anomaly log, screenshot path, replay script, and execution time. For large files, such as screenshots, videos, and complete logs, this invention can also use object storage path upload and message index transmission to reduce communication load.

[0045] After receiving the test results, the parallel scheduling node first performs a global result merging operation. This merging operation includes, but is not limited to: writing newly discovered page states into the global interface transition graph, adding executed paths to the explored set, clustering abnormal samples by crash signature, call stack digest, or trigger context, folding duplicate alerts, and calculating the actual benefit value of each subtask. For crash samples (samples saved due to the abnormal behavior of application crash), this invention preferably automatically extracts key stack frames, exception types, the sequence of events in the last few steps before triggering, and the corresponding page states to form a directly reproducible defect summary; for suspicious risky behaviors, a vulnerability triggering sequence diagram can be further generated to visually display the chain-like path relationship of "starting page—key action—intermediate jump—abnormal trigger point".

[0046] Regarding report generation, this invention preferably outputs a structured test report. The report content may include: basic information of the target application, test environment information, node resource usage, number of covered pages, number of novel states discovered, typical path diagrams, statistics of crashes and anomalies, trigger time and number of triggers for each anomaly, call stack analysis results, risk level assessment, suspected cause analysis, and remediation suggestions. If the system integrates a static analysis module, auxiliary content such as component exposure information, suspicious call chains, and summaries of relevant code locations can also be presented in the report. The report can be output in webpage, JSON, or database record format, or displayed in PDF, HTML, or a visual panel format. Through this stage, this invention unifies and transforms execution evidence originally scattered across multiple test nodes into an engineering output usable in the R&D closed loop, significantly reducing the cost of manual compilation and defect localization.

[0047] 6. High Availability and Self-Healing Phase: Through periodic heartbeat monitoring between parallel scheduling nodes and test nodes, failed nodes are detected and their unfinished subtasks are reclaimed, leases are reset and redistributed; when a parallel scheduling node crashes, role reselection is triggered, and a new parallel scheduling node recovers its state from shared storage; at the same time, the unique identifiers and idempotent checks of test tasks and results are used to avoid duplicate processing. In this phase, the present invention ensures strong fault tolerance of the system during long-term operation through mechanisms such as heartbeat monitoring, role reselection, task leases, and idempotent retries. Specifically, the parallel scheduling node and the test node maintain periodic heartbeat communication. The scheduling node is used to sense whether each test node is online, whether the load is normal, and whether the container is healthy; the test node is used to sense whether the scheduling node is continuously reachable. If a test node fails to report a heartbeat within a preset time window, the scheduling node can mark it as a failed node and perform recycling, lease reset, and redistribution of its occupied but unfinished subtasks to avoid permanent task loss. If an Android test container exits abnormally, the test node can automatically restart the container and resume execution or re-request the task based on the local cache state.

[0048] When a parallel scheduling node fails, its test nodes re-elect a new parallel scheduling node according to preset election rules. The newly elected parallel scheduling node can restore the global task queue, page state summary, and result index information from shared storage, persistent database, or the most recent state snapshot to minimize context loss caused by the failure. To prevent test tasks from being repeatedly counted due to retries, this invention sets unique identifiers for test tasks and result objects and uses an idempotent verification mechanism to prevent the same result from being merged multiple times. In other words, even in the event of node failure, network interruption, or container anomaly, the system can continue to execute unfinished tests through task recycling and state recovery mechanisms, thereby meeting the needs of enterprise-level long-term operation and continuous batch task mining.

[0049] Through the above-mentioned high availability and self-healing design, this invention breaks through the single-point control and manual recovery mode common in existing Android GUI testing tools, enabling the system to not only "run simultaneously" in a multi-machine parallel environment, but also to maintain the continuity of the global testing process, consistency of results, and traceability of tasks when nodes are abnormal.

[0050] In summary, through the coordinated efforts of the six stages described above, this invention achieves multi-machine parallel execution, global deduplication scheduling, heterogeneous environment adaptation, unified aggregation of abnormal samples, and high-availability self-healing operation for automated testing tasks of Android application graphical interfaces, without relying on a single node to remain continuously online. Compared to existing single-machine exploration solutions or cloud-based execution solutions that only provide resource concurrency but lack a global coordination mechanism, this invention can more effectively utilize distributed testing resources, reduce redundant path exploration, improve page state coverage and defect discovery efficiency, and output structured test results that can directly support vulnerability analysis, defect reproduction, and R&D remediation.

[0051] See Figure 1 and Figure 2 To implement the above-mentioned automated testing method, this invention provides an automated testing system for Android graphical user interface based on a multi-machine parallel architecture, including a node deployment and role election module, a task access and splitting module, a test task distribution module, a test execution and status acquisition module, a result feedback and report generation module, and a high availability and self-healing module; the specific implementation process of each module corresponds to the six stages in the method section above, and will not be elaborated here.

[0052] In this system, nodes are installed and deployed offline via automated scripts and added to the cluster. They then vote to be assigned as either parallel scheduling nodes (control nodes) or test nodes. When a parallel scheduling node goes offline, a test node automatically initiates an election to take over the role, ensuring that a single node failure does not affect continuous global testing. Android test containers can be launched in batches in virtualization environments such as reDroid, and run consistently across architectures.

[0053] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for Android graphical interface automation testing based on multi-machine parallel architecture, characterized in that, include: Node deployment and role election phase; The environment initialization and agent deployment are completed on each node through an offline installation script. After the node starts up, it reports its capability tags and elects a parallel scheduling node based on a heartbeat keep-alive and voting mechanism. The remaining nodes become test nodes. Task access and segmentation phase: Input the application to be tested and the test strategy into the parallel scheduling node, preprocess the application to be tested, and segment the test task into multiple sub-tasks that can be executed in parallel; Test task distribution phase; Parallel scheduling nodes maintain a globally unified interface transition graph, state summary set, or exploration frontier set as the basis for subtask distribution; before subtask distribution, subtasks are first deduplicated and sorted based on the global state; then, matching and distribution are performed in conjunction with the capability tags of the test nodes, and a timeout reassignment mechanism is set for subtasks. Test execution and status acquisition phase: The test node starts the application under test locally and enters the event execution loop; each round determines the next test action based on the status information of the current interface and a preset strategy. The test node collects runtime information during the execution of actions and records event sequences and snapshots when risky behaviors are detected. The results feedback and report generation stage; The test node sends the test results generated when the application under test is executed locally back to the parallel scheduling node; The parallel scheduling nodes perform global merging and extraction of the returned test results, and finally generate a structured test report; High availability and self-healing phase; through periodic heartbeat monitoring between parallel scheduling nodes and test nodes, failed nodes are detected and their unfinished subtasks are reclaimed, leases are reset and redistributed; when a parallel scheduling node crashes, role reselection is triggered, and a new parallel scheduling node recovers its state from shared storage; at the same time, the unique identifiers and idempotent checks of test tasks and results are used to avoid duplicate processing. 2.The Android graphical user interface automation testing method based on a multi-machine parallel architecture according to claim 1, wherein, The capability tags are used to describe the testing capabilities and resource availability of a node; the capability tags are encoded into structured data objects and sent to the cluster registry center; All nodes that have been deployed and successfully registered are initially selected as candidate nodes. Through a role election protocol based on heartbeat keep-alive and voting mechanisms, a parallel scheduling node is automatically selected from the candidate nodes to be responsible for maintaining the global task queue, deduplication status, and result aggregation. The remaining nodes are designated as test nodes and are responsible for actually executing the test tasks; The voting mechanism can be implemented using priority comparison, node lease, distributed consensus protocol, or primary / secondary election mechanism; multi-master conflicts are avoided through majority voting, timeout retries, and term number comparison; if the current parallelism node loses connection, crashes, or actively withdraws, the remaining test nodes will automatically initiate a re-election. 3.The Android graphical user interface automation testing method based on multi-machine parallel architecture according to claim 1, wherein, During the task access and segmentation phase, for gray-box mode, further static analysis results, interface jump prior information, code instrumentation results, function coverage information or component call graph information are received to assist in subsequent task priority sorting. The preprocessing process of the parallel nodes for the application under test includes verifying the integrity of the APK, parsing the Manifest file, extracting the entry Activity, identifying permission declarations, identifying exportable components, creating an initial startup script, configuring installation parameters, and generating a unique task identifier for each application under test. Based on the test objectives, the test task is constructed into multiple sub-tasks according to the application entry point, page function area, known components, exploration depth, time slice budget, or behavior strategy type. 4.The method of claim 1, wherein, The interface transition graph is used to record the jump relationships between page states; the state summary set is used to represent visited pages, executed event combinations, observed anomaly samples and their corresponding contexts; the exploration frontier set is used to maintain page states or action candidates that have not yet been fully explored but have high expected returns. The deduplication criteria used by the parallel scheduling nodes before distributing tasks include page hierarchy tree hash value, control attribute summary, screenshot-aware fingerprint, Activity name and control set combination identifier, event sequence prefix summary, or a combination of multiple features. Subsequently, the parallel nodes select and sort the tasks based on a preset priority rule. The priority rule comprehensively considers factors such as page novelty, historical coverage benefits, target control scarcity, path depth, crash proximity, node adaptability, and retry history. When subtasks are issued, the parallel scheduling node matches the capability tags reported by the test nodes, prioritizing the allocation of high-load subtasks to test nodes with sufficient resources, allocating subtasks that depend on specific SDK versions to compatible test nodes, and allocating ARM or x86-specific image subtasks to test nodes of the corresponding architecture. The distribution method can be either push or pull. Set a lease time, execution confirmation status, and failure retry flag for each subtask; if no response is received after a timeout, re-queue the subtask and wait for reassignment. 5.The Android graphical user interface automation testing method based on the multi-machine parallel architecture according to claim 1, wherein, The test node executes actual GUI automated tests in a local Android runtime container; the preset strategies include a random strategy, a heuristic strategy based on control visibility, a path expansion strategy based on the interface model, and a priority exploration strategy based on historical gains. Test nodes are allowed to maintain node-level caches locally; After the test action is completed, if a risky behavior is detected, the event sequence before and after the trigger, the interface state snapshot and the log context are recorded and saved as an anomaly sample; a timestamp, page summary and execution result label are attached to each test action to form a complete test trajectory chain.

6. The automated testing method for Android graphical user interface based on a multi-machine parallel architecture according to claim 1, characterized in that, The test node will send back the test results generated by the local execution in the form of a structured result object; After receiving the test results, the parallel scheduling node performs a global result merging operation, including but not limited to: writing newly discovered page states into the global interface transformation graph, adding executed paths to the explored set, clustering abnormal samples by crash signature, call stack digest, or trigger context, folding duplicate alarms, and calculating the actual benefit value of each subtask; for crash samples, extracting key stack frames, exception types, the last few event sequences before triggering, and corresponding page states to form a directly reproducible defect summary; for suspicious risk behaviors, generating a vulnerability triggering sequence graph to visually display the chain path relationship of "starting page - key action - intermediate jump - abnormal trigger point".

7. The automated testing method for Android graphical user interface based on a multi-machine parallel architecture according to claim 1, characterized in that, The parallel scheduling node and the test node maintain periodic heartbeat communication. The scheduling node is used to sense whether each test node is online, whether the load is normal, and whether the container is healthy; the test node is used to sense whether the scheduling node is continuously reachable. If a test node fails to report a heartbeat within a preset time window, the scheduling node can mark it as a failed node and reclaim, reset the lease, and redistribute the subtasks it holds but has not yet completed. When a parallel scheduling node fails, the test node re-elects a new parallel scheduling node according to the preset election rules; the newly elected parallel scheduling node restores the global task queue, page state summary and result index information from shared storage, persistent database or the most recent state snapshot; Set unique identifiers for test tasks and result objects, and use an idempotent verification mechanism to prevent the same result from being merged multiple times.

8. An automated testing system for Android graphical user interfaces based on a multi-machine parallel architecture, characterized in that, include: The node deployment and role election module is used to complete the environment initialization and agent deployment on each node through offline installation scripts. After the node starts, it reports the capability tags and elects a parallel scheduling node based on the heartbeat keep-alive and voting mechanism, while the remaining nodes become test nodes. The task access and segmentation module is used to input the application under test and the test strategy into the parallel scheduling node, preprocess the application under test, and segment the test task into multiple sub-tasks that can be executed in parallel. The test task distribution module is used to schedule nodes in parallel. It maintains a globally unified interface transition graph, state summary set, or exploration frontier set as the basis for subtask distribution. Before subtask distribution, it first performs deduplication and sorting of subtasks based on the global state. Then, it matches and distributes subtasks based on the capability tags of the test nodes and sets a timeout reassignment mechanism for subtasks. The test execution and status acquisition module is used by the test node to start the application under test locally and enter the event execution loop; in each round, based on the status information of the current interface, the next test action is determined based on the preset strategy. The test node collects runtime information during the execution of actions and records event sequences and snapshots when risky behaviors are detected. The result feedback and report generation module is used by the test node to send back the test results generated when the application under test is executed locally to the parallel scheduling node. The parallel scheduling nodes perform global merging and extraction of the returned test results, and finally generate a structured test report; The high availability and self-healing module is used to detect failed nodes and reclaim their unfinished subtasks, reset leases and redistribute them through periodic heartbeat monitoring between parallel scheduling nodes and test nodes; when a parallel scheduling node crashes, it triggers role reselection, and the new parallel scheduling node recovers its state from shared storage; at the same time, it avoids duplicate processing by using unique identifiers and idempotent checks for test tasks and results.

9. A terminal device, comprising a processor, a memory, and a computer program stored in the memory; characterized in that, When the processor executes a computer program, it implements the Android graphical interface automated testing method based on a multi-machine parallel architecture as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program; characterized in that, When the computer program is executed by the processor, it implements the Android graphical interface automated testing method based on a multi-machine parallel architecture as described in any one of claims 1-7.

Images