Cross-platform mobile device automation concurrent testing system and method, device and medium

Abstract

The embodiment of the application discloses a cross-platform mobile device automatic concurrent test system and method, equipment and medium, the method comprises: cross-platform concurrent test based on an abstract layer, the abstract layer is integrated with the Python client driver library of the iOS device, the call depth counter of the decorator function of the Python client driver library for limiting recursive call depth is configured as a thread local counter based on thread local storage; when a plurality of WDA drive threads concurrently operate different iOS devices, each WDA drive thread obtains and maintains an independent call depth count value from the thread local counter, associates the failure time marked in the report with the corresponding video on the time axis, realizes accurate backtracking of the fault node, realizes test execution, process recording, report generation linkage based on an event-driven mechanism, and the test report displays the quality change trend by merging historical data.

Description

Technical Field

[0001] This invention relates to the field of mobile terminal automated testing technology, and in particular to a cross-platform mobile device automated concurrent testing system, method, device and medium. Background Technology

[0002] Currently, mobile automated testing widely relies on toolchains (such as Appium, UIAutomator2, WDA, etc.), video recording tools (such as scrcpy, FFmpeg, etc.), and report management tools (such as Allure). The inventors have discovered the following problems with existing mobile automated testing solutions:

[0003] 1. Insufficient multi-device concurrent interaction capability:

[0004] Mainstream iOS automation frameworks do not natively support thread-safe concurrent operations on multiple devices. When multiple threads operate on different devices simultaneously, automation scripts may fail to execute or become unstable, severely limiting the implementation of multi-device collaborative testing scenarios.

[0005] 2. Incomplete visualization of the testing process:

[0006] Existing solutions lack synchronous, complete, and traceable visual records of the multi-device testing process;

[0007] iOS devices lack an efficient and stable integrated screen recording solution;

[0008] Although Android devices have tools such as scrcpy, they lack unified management and automatic integration with test reports in multi-device and asynchronous scenarios.

[0009] When a test fails, it is not possible to quickly pinpoint the critical failure point in the multi-device interaction process;

[0010] It lacks the ability to record and play back simultaneously across platforms and multiple devices.

[0011] 3. Decentralized management of test results:

[0012] Multidimensional data (reports, videos, logs) is stored in a scattered manner and lacks unified archiving;

[0013] Allure reports are typically generated locally and lack the ability to persist historical data and analyze trends, making it difficult to assess quality changes between version iterations.

[0014] There is a lack of automated result archiving and version management mechanisms. Summary of the Invention

[0015] This invention provides a cross-platform automated concurrent testing system, method, device, and medium for mobile devices. It supports integrated automated testing on both iOS and Android platforms, multiple devices, concurrent interaction, visualization of the testing process, and persistence and visualization of test results. It solves the problems of device heterogeneity, concurrent reliability, and report traceability in mobile testing, and achieves high testing reliability and full-process automation.

[0016] In a first aspect, embodiments of the present invention provide an automated concurrent testing system for cross-platform mobile devices, comprising:

[0017] The test execution module is configured with a cross-platform abstraction layer. This module is configured to convert test instructions written in Python automated test scripts based on the unified API interface provided by the cross-platform abstraction layer into HTTP requests corresponding to the target device type, and send them to the target device's HTTP server. The target device's HTTP server then calls the native framework to execute the test instructions carried in the test requests. During the test, the test execution module publishes events containing test status. The abstraction layer integrates a Python client driver library for iOS devices, and the call depth counter of the decorator function in the Python client driver library used to limit the recursive call depth is configured as a thread-local counter based on thread-local storage `threading.local`. When multiple WDA driver threads concurrently operate on different iOS devices, each WDA driver thread obtains and maintains an independent call depth count value from the thread-local counter.

[0018] The process recording module is configured to listen for test status events based on an event-driven mechanism, respond to test status events carrying recording instructions, control the synchronous recording of the test process through the unified recording interface provided by the cross-platform abstraction layer, and adopt the corresponding recording strategy according to the device type.

[0019] The report generation and management module is configured to listen for test status events based on an event-driven mechanism, respond to test end events, and fuse real-time collected multi-dimensional test data with historical test data to generate test reports that include quality trend analysis.

[0020] The backtracking module is used to record the exact moment of test failure and mark it in the test report with a timestamp. It is then linked to the corresponding recorded video on the timeline to achieve accurate backtracking of the fault node.

[0021] As one embodiment, the process recording module is specifically used to: if the target device is iOS, perform asynchronous screenshots and synthesize a video; wherein, the dynamic frame rate is calculated based on the actual execution time of each test case and the total number of screenshots within the actual execution time;

[0022] If the target device is an Android device, an independent recording process instance is dynamically created and bound based on the Android device under test, and a mapping table between the unique serial number (SN) of the Android device and the process handle is established. In response to the test scheduling command, the target process handle is located through the mapping table, and the target recording process instance is independently managed throughout its lifecycle to achieve parallel acquisition and fault isolation of audio and video streams from multiple devices.

[0023] As one embodiment, the report generation and management module includes:

[0024] The data conversion submodule is used to parse and convert the raw test data generated by the test execution module into input data corresponding to the preset report framework;

[0025] The download submodule is used to automatically download and configure the core framework executable program required to generate the report by calling the backend resource interface in response to the completion of the input data generation.

[0026] The historical trend data acquisition submodule is used to acquire historical archived test data from the previous test period and merge and associate it with the input data of the current test period.

[0027] The report rendering submodule is used to call the core execution program of the framework to generate a visual web report containing real-time test results and historical trend analysis based on the merged data.

[0028] The report archiving and distribution submodule is used to compress and package the visualized web report to generate a portable report data package for subsequent display or storage.

[0029] The upload submodule is used to call the backend upload interface to upload the report data package to the object storage service;

[0030] The data persistence submodule is used to obtain the plan identifier (plan_id) and report identifier (report_id) of the current test task after the report is uploaded, serialize and store them, and construct a report metadata object containing a unique access path and timestamp and write it to the persistent database to establish a historical index record of the test report.

[0031] The trend data merging submodule is used to extract metadata from the report data package and merge it into the historical trend data file to update the time-series change record of the test results;

[0032] The record count maintenance submodule is used to update the number of stored historical records based on a preset historical record count value;

[0033] The historical data backup submodule is used to package and back up the historical data after it has been processed by the record quantity maintenance submodule, and generate a new historical archive data package.

[0034] As one embodiment, the system also includes a service-oriented deployment module, configured to provide automated generation, uploading, querying, and multi-dimensional data retrieval services for test reports based on an encapsulated RESTful API interface, thereby realizing service-oriented delivery of test quality data and cross-system calls.

[0035] As one embodiment, the service-oriented deployment module includes:

[0036] The RESTful API service submodule is configured as the unified access point of the system, used to receive external requests and distribute them according to the request path;

[0037] The static resource service submodule is used to respond to the report access HTTP request containing the retrieval instruction distributed by the RESTful API service submodule, locate and return the corresponding Allure report static web page resource according to the plan identifier and report identifier carried in the request path;

[0038] The Allure Report Web Interface Submodule is used to load Allure report static web page resources to provide a front-end visual interaction carrier, and respond to the operation instructions of the front-end user by initiating data requests to the RESTful API service submodule to obtain report data for front-end rendering and display.

[0039] The historical trend chart submodule, integrated into the Allure report web interface submodule, is used to generate and display trend charts of test indicators over time based on historical test data.

[0040] The version comparison submodule, integrated into the Allure report web interface submodule, is used to respond to user comparison commands and perform differential comparison and display of test report data from different time series or different versions;

[0041] The Quality Change Trend Display Submodule, integrated into the Allure Report Web Interface Submodule, is used to visually display the dynamic change trends of software quality indicators.

[0042] The message notification service submodule, connected to the RESTful API service submodule, is used to generate and distribute notification messages based on the execution results of the test task.

[0043] The instant messaging robot submodule is connected to the message notification service submodule and is used to push the notification message through an instant messaging tool.

[0044] The email notification submodule, connected to the message notification service submodule, is used to send notification messages via email;

[0045] The pipeline integration submodule is connected to the RESTful API service submodule and is used to interface with external continuous integration and continuous delivery pipelines.

[0046] The CI / CD automation submodule, connected to the pipeline integration submodule, is used to trigger test report generation and upload tasks during the automated build and deployment process.

[0047] As one embodiment, the system further includes: a data acquisition module, the data acquisition module comprising:

[0048] A multi-dimensional data collection controller is configured to dynamically generate a collection strategy that includes data source type and collection parameters in response to the start command of an automated test task.

[0049] Multiple heterogeneous data acquisition units are respectively connected to the multidimensional data collection controller, and are used to execute data capture tasks in parallel under the control of the acquisition strategy. The heterogeneous data acquisition units include at least: a mobile terminal log acquisition unit, a vehicle bus acquisition unit, a serial communication acquisition unit, a video recording acquisition unit, and a test process acquisition unit.

[0050] The data aggregation and archiving engine, connected to the multidimensional data collection controller, is configured to receive data streams uploaded by each collection unit in real time during the execution of the test task;

[0051] The multidimensional data collection controller is also configured with a synchronization triggering mechanism, which sends a synchronization flag to the video recording and acquisition unit and each log collection unit when a key node of the automated test task is detected. The data aggregation and archiving engine associates and aligns the video data and log data on the timeline according to the synchronization flag, and packages them to generate standardized archive files.

[0052] As one embodiment, the test execution module further includes:

[0053] The Android device concurrency submodule is configured based on the Android device's unique serial number (SN) to schedule uiautomator2 and scrcpy service to establish independent device sessions, thereby enabling isolated testing and synchronous recording across multiple devices.

[0054] Secondly, embodiments of the present invention provide a cross-platform mobile device automated concurrent testing method, comprising: configuring a cross-platform abstraction layer; converting test instructions written in a Python automated test script based on the unified API interface provided by the cross-platform abstraction layer into HTTP requests corresponding to the target device type; sending the HTTP requests to the target device's HTTP server; and having the target device's HTTP server call the native framework to execute the test instructions carried in the test requests; and publishing events containing test status during the testing process.

[0055] The abstraction layer integrates a Python client driver library for iOS devices. The call depth counter of the decorator function of the Python client driver library used to limit the recursive call depth is configured as a thread-local counter based on thread-local storage threading.local. When multiple WDA driver threads operate concurrently on different iOS devices, each WDA driver thread obtains and maintains an independent call depth count value from the thread-local counter.

[0056] Based on the event-driven mechanism, it listens for test status events and responds to test status events carrying recording instructions. It controls the synchronous recording of the test process through the unified recording interface provided by the cross-platform abstraction layer and adopts the corresponding recording strategy according to the device type.

[0057] Based on an event-driven mechanism, it listens for test status events and responds to test end events. It integrates real-time collected multi-dimensional test data with historical test data to generate a test report that includes quality trend analysis.

[0058] By recording the exact moment of test failure and marking it with a timestamp in the test report, and linking it with the corresponding recorded video on a timeline, accurate backtracking of the fault node can be achieved.

[0059] Thirdly, embodiments of the present invention provide an automated concurrent testing device for cross-platform mobile devices, comprising: a memory and a processor;

[0060] The memory is used to store computer programs; the processor is used to read the computer programs in the memory and, when executing the programs, implement the cross-platform mobile device automated concurrent testing method as described above.

[0061] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the cross-platform mobile device automated concurrent testing method as described above.

[0062] Compared with the prior art, the technical solution provided by the embodiments of the present invention has at least the following positive effects:

[0063] In the technical solution of this invention embodiment, the test execution module is configured with a cross-platform abstraction layer. The test execution module is configured to convert test instructions written in Python automated test scripts based on the unified API interface provided by the cross-platform abstraction layer into HTTP requests corresponding to the target device type, and send them to the target device's HTTP server for the target device's HTTP... The server invokes the native framework to execute test requests carrying test instructions. The abstraction layer integrates a Python client driver library for iOS devices. The call depth counter for the decorator function in the Python client driver library, used to limit the depth of recursive calls, is configured as a thread-local counter based on thread-local storage `threading.local`. When multiple WDA driver threads concurrently operate on different iOS devices, each WDA driver thread obtains and maintains an independent call depth count value from the thread-local counter, avoiding count state pollution between threads and ensuring that the call depth detection logic of each thread is isolated and does not interfere with each other. This achieves stable concurrent driving across multiple iOS devices. The test execution module publishes events containing test status information during the test. The process recording module is configured to listen for test status events based on an event-driven mechanism, responding to test status events carrying recording instructions. It controls the synchronous recording of the test process through a unified recording interface provided by the cross-platform abstraction layer and adopts corresponding recording strategies based on device type. The report generation and management module is configured to listen for test status events based on an event-driven mechanism, responding to test end events. It fuses real-time collected multi-dimensional test data with historical test data to generate a test report including quality trend analysis. Test execution, video recording, and report generation are linked based on an event-driven mechanism, achieving deep coupling across the entire testing process. By recording the exact moment of a test failure and marking it with a timestamp in the test report, and associating it with the corresponding recorded video on a timeline, precise backtracking of the failure point is achieved. Attached Figure Description

[0064] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0065] Figure 1 This is a schematic diagram of the cross-platform mobile device automated concurrent testing system provided in Embodiment 1 of the present invention;

[0066] Figure 2 This is a diagram illustrating the test results and Allure report address data based on embodiments of the present invention;

[0067] Figure 3This is a diagram illustrating an Allure report based on an embodiment of the present invention;

[0068] Figure 4 This is another Allure report illustration based on an embodiment of the present invention;

[0069] Figure 5 This is a flowchart of the cross-platform mobile device automated concurrent testing method provided in Embodiment 2 of the present invention;

[0070] Figure 6 This is a schematic diagram of the hardware architecture of the cross-platform mobile device automated concurrent testing device provided in Embodiment 3 of the present invention. Detailed Implementation

[0071] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0072] The core idea of ​​this invention is to design a unified automated testing system framework for mobile devices. Through a modular and service-oriented architecture, it deeply integrates three core functions: video recording, concurrent testing, and report management, while maintaining relative decoupling between modules. This system framework adheres to the principle of "high cohesion and low coupling," aiming to provide developers with a one-stop solution, enabling them to quickly integrate and execute multi-device concurrent testing with minimal learning and time investment. Specifically, the basic ideas include the following aspects:

[0073] 1. Unified Framework Design: A standardized and scalable testing framework is built, compatible with both Android and iOS platforms. The framework encapsulates platform differences through an abstraction layer, providing a consistent API interface. Developers do not need to concern themselves with the details of the underlying toolchain; they can trigger full-process testing simply through configuration (such as device serial number or port number), significantly reducing integration complexity.

[0074] 2. Balancing deep integration and decoupling:

[0075] Deep integration: Video recording, test execution, and report generation are linked through an event-driven mechanism. For example, when a test fails, the time point is automatically recorded (using the `record_failure_time` method), and keyframes in the video are marked in the report, enabling precise problem localization.

[0076] Relative decoupling: Each module is developed and deployed independently, communicating through standard interfaces. For example, the video recording module can be upgraded independently without affecting the testing logic, and the reporting service module supports plug-in extensions (such as custom Allure plugins). This design ensures the system's flexibility and maintainability.

[0077] 3. Minimize development costs:

[0078] Low-code integration: Provides declarative configuration and templated scripts, allowing developers to adapt to new projects by modifying only a few parameters (such as device list and test case name).

[0079] Automated pipeline: The entire process, from environment preparation and test execution to report delivery, is automated, reducing manual intervention. For example, after the test is completed, allure_upload is automatically called to upload the report, and the results are pushed through a chatbot, improving efficiency.

[0080] 4. Technological innovation drives reliability:

[0081] System stability is ensured by fixing the WDA thread security vulnerability, and resource utilization is optimized by dynamic frame rate calculation and asynchronous screenshot synthesis to avoid device lag or data loss.

[0082] The cross-platform mobile device automated concurrent testing system provided in this embodiment of the invention aims to achieve highly reliable automated concurrent testing of multiple devices across platforms. This embodiment of the cross-platform mobile device automated concurrent testing system includes:

[0083] The test execution module, configured with a cross-platform abstraction layer, transforms test instructions written in Python automated test scripts using the unified API interface provided by the cross-platform abstraction layer into HTTP requests corresponding to the target device type. These requests are then sent to the target device's HTTP server, which in turn invokes the native framework to execute the test instructions carried in the test requests. During the test process, the test execution module publishes events containing test status information.

[0084] For iOS devices, the test execution module's architecture is as follows: It parses Python automated test scripts, performs test commands for iOS devices, and converts these commands into HTTP requests using facebook-wda (a Python client library). These requests are then sent to the WDA Server on the iOS device. The WDA HTTP Server then calls the native framework XCTest to execute the iOS test commands. Specifically, the facebook-wda library communicates directly with the WDA HTTP Server running on the iOS device via the HTTP protocol, with each WDA thread independently maintaining an HTTP connection to the corresponding WDA Server port on the device.

[0085] The abstraction layer integrates a Python client driver library for iOS devices, namely the facebook-wda Python client library. The call depth counter of the decorator function of the Python client driver library used to limit the recursive call depth is configured as a thread-local counter based on thread-local storage threading.local. When multiple WDA driver threads operate concurrently on different iOS devices, each WDA driver thread obtains and maintains an independent call depth count value from the thread-local counter.

[0086] In the existing facebook-wda Python client library, the decorator function used to limit the depth of recursive calls uses a module-level global variable `_depth` as a call depth counter. When multiple threads make concurrent calls, all threads share this global call depth counter, which causes the count value to be accumulated by multiple threads, potentially triggering the depth limit accidentally, or the count value to be reset by other threads, rendering the depth protection ineffective.

[0087] In this embodiment of the invention, the global variable `_depth` is replaced with an attribute of the `threading.local()` object, so that each thread has an independent counter instance, that is, each thread has a private call depth counter. This allows each WDA thread to obtain and maintain an independent call depth count value from the thread local storage, avoiding counting state pollution between multiple threads, ensuring that the call depth detection logic of each thread is isolated from each other and does not interfere with each other, thereby achieving stable concurrent driving of multiple iOS devices.

[0088] The test execution module is also used to schedule uiautomator2 and scrcpy service to establish independent device sessions based on the unique serial number (SN) of the Android device, so as to achieve isolated testing and synchronous recording of multiple devices.

[0089] Therefore, developers do not need to worry about the details of the underlying toolchain. They can trigger full-process testing with simple configuration (such as device SN or port number), which significantly reduces integration complexity.

[0090] The process recording module is configured to listen for test status events based on an event-driven mechanism, respond to test status events carrying recording instructions, control the synchronous recording of the test process through a unified recording interface provided by the cross-platform abstraction layer, and adopt the corresponding recording strategy according to the device type.

[0091] The process recording module is specifically used for: if the target device is iOS, asynchronous screenshots are taken and synthesized into video; the dynamic frame rate is calculated based on the actual execution time of each test case and the total number of screenshots taken within that time. If the target device is Android, an independent recording process instance is dynamically created and bound to the Android device under test, and a mapping table between the Android device's unique serial number (SN) and the process handle is established; in response to test scheduling instructions, the target process handle is located through the mapping table, and independent lifecycle management is performed on the target recording process instance to achieve parallel acquisition and fault isolation of audio and video streams from multiple devices.

[0092] This invention provides a unified recording framework, offering unified interfaces for record_start() and record_stop(), and adaptively selecting recording strategies based on the platform (iOS / Android).

[0093] iOS Smart Recording: Employs an "asynchronous screenshot → video synthesis" method to avoid the performance impact of direct screen recording. It uses a dynamic frame rate algorithm to calculate the optimal frame rate based on the actual execution time of each test case and the number of screenshots. The specific formula is: Dynamic Frame Rate (fps) = Total Screenshots / Actual Recording Time (seconds). The actual execution time of each test case is used as its recording time. Therefore, the ratio of the total number of screenshots taken within the actual execution time to the actual execution time is the dynamic frame rate for that test case. Examples of specific application scenarios for dynamic frame rate are as follows:

[0094] Smoke test scenario: Each test case takes 3-7 minutes to execute, and a corresponding 3-7 minute video is generated;

[0095] Stress testing scenario: Each test case takes about 10 seconds to execute, and a short video of about 10 seconds is generated accordingly.

[0096] Android Precise Recording: Based on scrcpy, it adds process-level management by device serial number, and supports independent and reliable start and stop of multiple devices.

[0097] The data acquisition module includes:

[0098] A multi-dimensional data collection controller is configured to dynamically generate a collection strategy that includes data source type and collection parameters in response to the start command of an automated test task.

[0099] Multiple heterogeneous data acquisition units are connected to a multidimensional data collection controller to execute data capture tasks in parallel under the control of the acquisition strategy. The heterogeneous data acquisition units include at least: a mobile terminal log acquisition unit, a vehicle bus acquisition unit, a serial communication acquisition unit, a video recording acquisition unit, and a test process acquisition unit.

[0100] The data aggregation and archiving engine, connected to the multidimensional data collection controller, is configured to receive data streams uploaded by each acquisition unit in real time during the execution of the test task. The multidimensional data collection controller is also configured with a synchronization trigger mechanism, which sends synchronization markers to the video recording acquisition unit and each log acquisition unit when a key node of the automated test task is detected. The data aggregation and archiving engine associates and aligns the video data and log data on the timeline according to the synchronization markers and packages them to generate standardized archive files.

[0101] The data acquisition module enables multi-dimensional data acquisition and aggregation, and the unified collector automatically collects logs and data from various dimensions, supporting iOS system diagnostic logs, Android SDK logs, CAN bus logs, serial port logs, etc.

[0102] The service-oriented deployment module is configured as a RESTful API interface based on encapsulation, providing automated generation, uploading, querying, and multi-dimensional data retrieval services for test reports, realizing service-oriented delivery of test quality data and cross-system calls.

[0103] The report generation and management module is configured to listen for test status events based on an event-driven mechanism, respond to test end events, and fuse real-time collected multi-dimensional test data with historical test data to generate test reports that include quality trend analysis.

[0104] The backtracking module records the exact moment of a test failure, marking it as a timestamp in the test report and associating it with the corresponding recorded video on a timeline to achieve precise backtracking of the failure point. Specifically, the exact moment of test failure can be recorded using the `record_failure_time()` method.

[0105] The report generation and management module may include:

[0106] The data conversion submodule is used to parse and convert the raw test data generated by the test execution module into input data corresponding to the preset report framework;

[0107] The download submodule is used to automatically download and configure the core framework executable program required to generate the report by calling the backend resource interface in response to the completion of the input data generation.

[0108] The historical trend data acquisition submodule is used to acquire historical archived test data from the previous test period and merge and associate it with the input data of the current test period.

[0109] The report rendering submodule is used to call the core execution program of the framework to generate a visual web report containing real-time test results and historical trend analysis based on the merged data.

[0110] The report archiving and distribution submodule is used to compress and package the visualized web report to generate a portable report data package for subsequent display or storage.

[0111] The upload submodule is used to call the backend upload interface to upload the report data package to the object storage service;

[0112] The data persistence submodule is used to obtain the plan identifier (plan_id) and report identifier (report_id) of the current test task after the report is uploaded, serialize and store them, and construct a report metadata object containing a unique access path and timestamp and write it to the persistent database to establish a historical index record of the test report.

[0113] The trend data merging submodule is used to extract metadata from the report data package and merge it into the historical trend data file to update the time-series change record of the test results;

[0114] The record count maintenance submodule is used to update the number of stored historical records based on a preset historical record count value;

[0115] The historical data backup submodule is used to package and back up the historical data after it has been processed by the record quantity maintenance submodule, and generate a new historical archive data package.

[0116] The service-oriented deployment module may include:

[0117] The RESTful API service submodule is configured as the unified access point of the system, used to receive external requests and distribute them according to the request path;

[0118] The static resource service submodule is used to respond to the report access HTTP request containing the retrieval instruction distributed by the RESTful API service submodule, locate and return the corresponding Allure report static web page resource according to the plan identifier and report identifier carried in the request path;

[0119] The Allure Report Web Interface Submodule is used to load Allure report static web page resources to provide a front-end visual interaction carrier, and respond to the operation instructions of the front-end user by initiating data requests to the RESTful API service submodule to obtain report data for front-end rendering and display.

[0120] The historical trend chart submodule, integrated into the Allure report web interface submodule, is used to generate and display trend charts of test indicators over time based on historical test data.

[0121] The version comparison submodule, integrated into the Allure report web interface submodule, is used to respond to user comparison commands and perform differential comparison and display of test report data from different time series or different versions;

[0122] The Quality Change Trend Display Submodule, integrated into the Allure Report Web Interface Submodule, is used to visually display the dynamic change trends of software quality indicators.

[0123] The message notification service submodule, connected to the RESTful API service submodule, is used to generate and distribute notification messages based on the execution results of the test task.

[0124] The instant messaging robot submodule is connected to the message notification service submodule and is used to push the notification message through an instant messaging tool.

[0125] The email notification submodule, connected to the message notification service submodule, is used to send notification messages via email;

[0126] The pipeline integration submodule is connected to the RESTful API service submodule and is used to interface with external continuous integration and continuous delivery pipelines.

[0127] The CI / CD automation submodule, connected to the pipeline integration submodule, is used to trigger test report generation and upload tasks during the automated build and deployment process.

[0128] The embodiments of the present invention realize a closed loop of the entire process from test execution → process recording → result collection → report generation → history management → service deployment.

[0129] Figure 1 This is a schematic diagram of the cross-platform mobile device automated concurrent testing system provided in an embodiment of the present invention. The following is in conjunction with... Figure 1 The present invention provides a detailed description of the cross-platform mobile device automated concurrent testing system.

[0130] The cross-platform mobile device automated concurrent testing system of this invention can adopt a layered structure, specifically including: a test execution layer, a device control and concurrency layer, a process recording layer, a data collection layer, a report generation and history management layer, and a service-oriented presentation layer.

[0131] The test execution layer and the device control and concurrency layer are used to implement the test execution module.

[0132] The test execution layer may include:

[0133] pytest test scripts: Write test steps, call business logic, and perform result assertions.

[0134] Pytest testing framework: automatically discovers scripts, runs test cases, manages pre- and post-processing resources, and outputs reports.

[0135] Test scheduler: determines execution timing, allocates computing resources, orchestrates task order, and integrates with CI / CD.

[0136] The device control and concurrency layer may include:

[0137] The multi-device concurrency controller is used for multi-device parallel test management. It can simultaneously schedule multiple test processes and threads to operate different mobile terminals, and is responsible for resource allocation and load balancing to make full use of device resources.

[0138] The iOS multi-device driver encapsulates the WebDriverAgent (WDA) communication protocol, providing a unified control interface to the upper layers. WDA calls the iOS native testing framework XCTest to execute unit tests, performance tests, UI tests, etc.

[0139] Thread safety modifications were implemented by using thread-local storage technology to provide a private call depth counter for each WDA thread. The iOS device driver layer uses the facebook-wda Python client library, and the module-level global variable `_depth` used inside the decorator function of this library to limit the recursive call depth is replaced with an attribute of the `threading.local()` object, giving each thread an independent counter instance.

[0140] Android multi-device driver, which encapsulates the uiAutomator2 testing framework and scrcpy, is used to translate upper-level test logic (such as "clicking the login button") into specific Android UI operation commands. scrcpy provides real-time visual feedback, projecting the terminal screen to the test host in real time, facilitating debugging and monitoring.

[0141] By managing by device serial number (SN), each test process or thread is bound to the unique serial number (SN) of the Android device, enabling concurrent test management.

[0142] The process recording layer provides an architecture for recording and replaying automated test processes that is compatible with both iOS and Android platforms.

[0143] The process recording layer may include:

[0144] The recording controller provides a unified entry point for recording logic, shielding it from the differences between underlying systems. It receives instructions from the upper layer (such as "start recording" and "stop recording"), and then distributes the task to the corresponding recording branch based on the device type (iOS or Android).

[0145] iOS device recording (asynchronous screenshot): This method utilizes the facebook-wda client library to call the WDA Server's screenshot interface to achieve high-frequency screen capture. An asynchronous, non-blocking mechanism is employed to ensure that the screenshot task runs in the background, completely decoupling it from the main execution flow of the test script. This guarantees screen continuity without compromising script performance.

[0146] Dynamic frame rate algorithm: Calculates the optimal frame rate based on the actual recording duration and the number of screenshots. The discrete image sequence acquired through asynchronous screenshots is preprocessed, and the dynamic frame rate algorithm is applied.

[0147] Synthesized video: The FFmpeg multimedia processing framework is used to efficiently encode the optimized and marked image sequences, and finally encapsulate them into a standard MP4 format video file, ensuring cross-platform compatibility and playback stability.

[0148] Failure time point marking: When the test script triggers a failure event, the system captures and records the time of the failure in real time through the record_failure_time() method. This time point is marked as a timestamp in the subsequently generated Allure test report and associated with the timeline of the corresponding recorded video. This allows testers to quickly locate the time of failure in the video based on the timestamp in the report, enabling accurate backtracking.

[0149] Android Device Recording (scrcpy Image): Based on the scrcpy core framework, a high-efficiency video stream acquisition channel is established. It interacts directly with the device's underlying layer via the ADB protocol to obtain native H.264 hardware-encoded video streams.

[0150] Multi-device synchronous control is responsible for the overall management of the bandwidth and resource allocation of concurrent video streams. By dynamically adjusting the transmission strategy, it avoids network congestion and host processing bottlenecks when multiple machines are recording at the same time, ensuring the stability and continuity of recording tasks under high concurrency load.

[0151] Timestamp alignment ensures that all captured video frames are marked with a unified global logical timestamp, rather than relying on the device's local time. This guarantees that during cross-platform (Android and iOS) playback analysis, the footage from different devices can be accurately synchronized based on a unified time reference, greatly improving the accuracy of fault reproduction and behavior comparison.

[0152] The data collection layer may include:

[0153] A multidimensional data collector, configured to dynamically generate a collection strategy that includes data source type and collection parameters in response to the start command of an automated test task. The data collection layer includes the following heterogeneous data collection units:

[0154] The iOS system diagnostic log is connected to the multidimensional data collector and is used to collect iOS system diagnostic logs.

[0155] The Android SDK logs are communicated with the multidimensional data collector and are used to collect Android SDK logs.

[0156] The CAN bus log is a communication connection to a multidimensional data collector used to collect CAN bus logs.

[0157] The serial port log is connected to the multidimensional data collector and is used to collect serial port logs.

[0158] Record video files; the communication connection is to a multidimensional data collector for acquiring and recording video files.

[0159] The test execution log is connected to the multidimensional data collector and is used to collect test execution logs.

[0160] Data archiving and aggregation, communication connection to heterogeneous data acquisition units, configured to receive data streams uploaded by each acquisition unit in real time during test task execution.

[0161] The multidimensional data collector is also equipped with a synchronization triggering mechanism, which sends synchronization markers to the video recording and acquisition unit and each acquisition unit when a critical node of the automated test task is detected. The data aggregation and archiving engine associates and aligns the video data and log data on the timeline according to the synchronization markers and packages them to generate standardized archive files.

[0162] Report generation and historical management may include:

[0163] Allure report generation is used to parse and convert the raw test data generated during test execution into input data corresponding to the Allure report framework.

[0164] Call the backend interface GET / allure / history / download in response to the completion of input data generation. This will automatically download and configure the core framework executable program required for generating the report.

[0165] Download history.zip to merge historical trend data. This is used to obtain archived test data from the previous test period and merge and associate it with the input data for the current test period.

[0166] The generated HTML report includes historical trend charts and is used to call the framework's core execution program to generate a visual web report containing real-time test results and historical trend analysis based on the merged data.

[0167] The file is compressed into allure-report.zip, which is used to compress and package the visual web report to generate a portable report data package for subsequent display or storage.

[0168] Call the backend interface POST / allure / upload / to call the backend upload interface and upload the report data packet to the object storage service.

[0169] The Plan_id and report_id are serialized and stored. After the report is uploaded, the plan_id and report_id of the current test task are obtained, serialized and stored, and a report metadata object containing a unique access path and timestamp is constructed and written to the persistent database to establish a historical index record of the test report.

[0170] Merge history-trend.json, which is used to extract metadata from the report data package and merge it into the historical trend data file to update the time-series change records of test results.

[0171] Maintain the 30 most recent records to update the number of stored historical records based on a preset number of historical records. Understandably, the preset number of historical records can be set according to actual needs, and there are no restrictions on its specific value.

[0172] The backup history directory is used to package and back up the historical data corresponding to the updated number of historical records, generating a new historical archive data package.

[0173] The report generation and historical management layers merge historical data (history.zip) into the current test results, enhancing the historical nature of Allure reports. Serialized storage using planId and reportId enables structured archiving. By continuously integrating test data collected in the current period with historical test data, test data demonstrating quality change trends is provided.

[0174] The service-oriented presentation layer may include:

[0175] The RESTful API service communicates with the report generation and history management layer through a standard interface. It is configured as the unified access point of the system to receive external requests and distribute them according to the request path.

[0176] The GET Allure / serve / plan_id / report_id / command is used to respond to a report access HTTP request containing a retrieval instruction from a RESTful API service. Based on the plan identifier and report identifier carried in the request path, it locates and returns the corresponding Allure report static web page resource.

[0177] The Allure Reports Web Interface is used to load static web page resources of Allure reports to provide a visual interactive platform for the front end, and to respond to the operation commands of the front end user by initiating data requests to the RESTful API service to obtain report data for front end rendering and display.

[0178] Historical trend charts, integrated into the Allure report web interface, are used to generate and display trend charts of test metrics over time based on historical test data.

[0179] The version comparison function is integrated into the Allure report web interface. It is used to respond to user comparison commands and display the differences between test report data from different time periods or different versions.

[0180] The quality change trend display is integrated into the Allure report web interface and is used to visually display the dynamic changes in software quality indicators.

[0181] The message notification service, connected to the RESTful API service, is used to generate and distribute notification messages based on the execution results of test tasks.

[0182] Lark / WeChat bots connect to message notification services and are used to push notification messages through instant messaging tools.

[0183] Email notifications, connected to the messaging service, are used to send notification messages via email.

[0184] Pipeline integration connects to RESTful API services and is used to interface with external continuous integration and continuous delivery pipelines.

[0185] CI / CD automation connects to pipeline integration and is used to trigger test report generation and upload tasks in automated build and deployment processes.

[0186] The service-oriented presentation layer provides RESTful API interfaces for report uploading, querying, and management.

[0187] This invention integrates video recording, concurrent testing, and report management, addressing the fragmentation and concurrency deficiencies of existing toolchains. Compared to existing technologies, this invention solves the problem of video association across multiple devices by synchronous recording on both platforms and timestamp alignment, improving backtracking efficiency; it supports stable concurrent testing on iOS devices by fixing WDA thread safety issues, improving test reliability and coverage; it enhances team collaboration and continuous integration capabilities through service-oriented reporting, including historical data and remote access; and it reduces human error and improves testing efficiency through end-to-end automation.

[0188] The embodiments of the present invention have advantages in system architecture integration:

[0189] 1. Closed-loop process: Test execution → Process recording → Result collection → Report generation → Historical management → Service deployment.

[0190] 2. Modular design: high cohesion and low coupling, each module can be upgraded independently.

[0191] 3. Cross-platform compatibility: It supports both iOS and Android platforms and ensures high-reliability concurrency on iOS.

[0192] 4. Enterprise-level applications: Verified in real-world projects (see [link]). Figures 2-4 (As shown in the test results and report presentation), testing efficiency is improved by 30%-50%, and the success rate of concurrent testing is increased from 70% to 100%.

[0193] Embodiment 2 of the present invention provides an automated concurrent testing method for cross-platform mobile devices, such as... Figure 5 As shown, it includes the following steps:

[0194] Step 501: Configure the cross-platform abstraction layer to convert test instructions written in Python automated test scripts based on the unified API interface provided by the cross-platform abstraction layer into HTTP requests corresponding to the target device type, and send them to the target device's HTTP server. The target device's HTTP server can then call the native framework to execute the test instructions carried in the test requests. During the test, publish events containing test status.

[0195] Step 502: The abstraction layer integrates the Python client driver library for iOS devices. The call depth counter of the decorator function in the Python client driver library, which is used to limit the recursive call depth, is configured as a thread-local counter based on thread-local storage threading.local. When multiple WDA driver threads operate on different iOS devices concurrently, each WDA driver thread obtains and maintains an independent call depth count value from the thread-local counter.

[0196] Step 503: Listen for test status events published during the test based on the event-driven mechanism, respond to test status events carrying recording instructions, control the synchronous recording of the test process through the unified recording interface provided by the cross-platform abstraction layer, and adopt the corresponding recording strategy according to the device type.

[0197] Step 504: Based on the event-driven mechanism, listen for test status events, respond to the test end event, and fuse the real-time collected multi-dimensional test data with historical test data to generate a test report that includes quality trend analysis.

[0198] Step 505: By recording the exact moment of test failure and marking it with a timestamp in the test report, and associating it with the corresponding recorded video on the timeline, the fault node can be accurately traced back.

[0199] The cross-platform mobile device automated concurrent testing method of this invention corresponds to the cross-platform mobile device automated concurrent testing system of the foregoing embodiments, and will not be described again here.

[0200] Figure 6 This is a schematic diagram of the architecture of a cross-platform mobile device automated concurrent testing device provided in Embodiment 3 of the present invention. The testing device 60 includes a memory 61 and a processor 62.

[0201] The memory 61 is used to store computer programs; the processor 62 is used to read the computer programs in the memory 61 and, when executing the programs, implement the cross-platform mobile device automated concurrent testing method as described in the foregoing embodiments.

[0202] Embodiment 4 of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a computer processor, is used to perform the technical solution of any method embodiment.

[0203] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or grid device, etc.) to execute the methods described in the various embodiments of the present invention.

[0204] It is worth noting that in the embodiments of the above-mentioned device, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of the present invention.

[0205] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A cross-platform automated concurrent testing system for mobile devices, characterized in that, include: The test execution module is configured with a cross-platform abstraction layer. The test execution module is configured to convert test instructions written in Python automated test scripts based on the unified API interface provided by the cross-platform abstraction layer into HTTP requests corresponding to the target device type, and send them to the HTTP server of the target device, so that the HTTP server of the target device can call the native framework to execute the test instructions carried by the test request. The test execution module publishes events containing test status during the test process; wherein, the abstraction layer integrates a Python client driver library for iOS devices, and configures the call depth counter of the decorator function of the Python client driver library used to limit the recursive call depth as a thread-local counter based on thread-local storage threading.local; when multiple WDA driver threads concurrently operate on different iOS devices, each WDA driver thread obtains and maintains an independent call depth count value from the thread-local counter; The process recording module is configured to listen for test status events based on an event-driven mechanism, respond to test status events carrying recording instructions, control the synchronous recording of the test process through the unified recording interface provided by the cross-platform abstraction layer, and adopt the corresponding recording strategy according to the device type. The report generation and management module is configured to listen for test status events based on an event-driven mechanism, respond to test end events, and fuse real-time collected multi-dimensional test data with historical test data to generate test reports that include quality trend analysis. The backtracking module is used to record the exact moment of test failure and mark it in the test report with a timestamp. It is then linked to the corresponding recorded video on the timeline to achieve accurate backtracking of the fault node.

2. The system according to claim 1, characterized in that, The process recording module is specifically used for: if the target device is iOS, then performing asynchronous screenshots and synthesizing a video; wherein, the dynamic frame rate is calculated based on the actual execution time of each test case and the total number of screenshots within the actual execution time; If the target device is an Android device, an independent recording process instance is dynamically created and bound based on the Android device under test, and a mapping table between the unique serial number (SN) of the Android device and the process handle is established. In response to the test scheduling command, the target process handle is located through the mapping table, and the target recording process instance is independently managed throughout its lifecycle to achieve parallel acquisition and fault isolation of audio and video streams from multiple devices.

3. The system according to claim 1, characterized in that, The report generation and management module includes: The data conversion submodule is used to parse and convert the raw test data generated by the test execution module into input data corresponding to the preset report framework; The download submodule is used to automatically download and configure the core framework executable program required to generate the report by calling the backend resource interface in response to the completion of the input data generation. The historical trend data acquisition submodule is used to acquire historical archived test data from the previous test period and merge and associate it with the input data of the current test period. The report rendering submodule is used to call the core execution program of the framework to generate a visual web report containing real-time test results and historical trend analysis based on the merged data. The report archiving and distribution submodule is used to compress and package the visualized web report to generate a portable report data package for subsequent display or storage. The upload submodule is used to call the backend upload interface to upload the report data package to the object storage service; The data persistence submodule is used to obtain the plan identifier (plan_id) and report identifier (report_id) of the current test task after the report is uploaded, serialize and store them, and construct a report metadata object containing a unique access path and timestamp and write it to the persistent database to establish a historical index record of the test report. The trend data merging submodule is used to extract metadata from the report data package and merge it into the historical trend data file to update the time-series change record of the test results; The record count maintenance submodule is used to update the number of stored historical records based on a preset historical record count value; The historical data backup submodule is used to package and back up the historical data after it has been processed by the record quantity maintenance submodule, and generate a new historical archive data package.

4. The system according to claim 1, characterized in that, The system also includes a service-oriented deployment module, configured as a RESTful API interface based on encapsulation, which provides automated generation, uploading, querying and multi-dimensional data retrieval services for test reports, realizing service-oriented delivery of test quality data and cross-system calls.

5. The system according to claim 4, characterized in that, The service-oriented deployment module includes: The RESTful API service submodule is configured as the unified access point of the system, used to receive external requests and distribute them according to the request path; The static resource service submodule is used to respond to the report access HTTP request containing the retrieval instruction distributed by the RESTful API service submodule, locate and return the corresponding Allure report static web page resource according to the plan identifier and report identifier carried in the request path; The Allure Report Web Interface Submodule is used to load Allure report static web page resources to provide a front-end visual interaction carrier, and respond to the operation instructions of the front-end user by initiating data requests to the RESTful API service submodule to obtain report data for front-end rendering and display. The historical trend chart submodule, integrated into the Allure report web interface submodule, is used to generate and display trend charts of test indicators over time based on historical test data. The version comparison submodule, integrated into the Allure report web interface submodule, is used to respond to user comparison commands and perform differential comparison and display of test report data from different time series or different versions; The Quality Change Trend Display Submodule, integrated into the Allure Report Web Interface Submodule, is used to visually display the dynamic change trends of software quality indicators. The message notification service submodule, connected to the RESTful API service submodule, is used to generate and distribute notification messages based on the execution results of the test task. The instant messaging robot submodule is connected to the message notification service submodule and is used to push the notification message through an instant messaging tool. The email notification submodule, connected to the message notification service submodule, is used to send notification messages via email; The pipeline integration submodule is connected to the RESTful API service submodule and is used to interface with external continuous integration and continuous delivery pipelines. The CI / CD automation submodule, connected to the pipeline integration submodule, is used to trigger test report generation and upload tasks during the automated build and deployment process.

6. The system according to claim 1, characterized in that, The system further includes: a data acquisition module, the data acquisition module comprising: A multi-dimensional data collection controller is configured to dynamically generate a collection strategy that includes data source type and collection parameters in response to the start command of an automated test task. Multiple heterogeneous data acquisition units are respectively connected to the multidimensional data collection controller, and are used to execute data capture tasks in parallel under the control of the acquisition strategy. The heterogeneous data acquisition units include at least: a mobile terminal log acquisition unit, a vehicle bus acquisition unit, a serial communication acquisition unit, a video recording acquisition unit, and a test process acquisition unit. The data aggregation and archiving engine, connected to the multidimensional data collection controller, is configured to receive data streams uploaded by each collection unit in real time during the execution of the test task; The multidimensional data collection controller is also configured with a synchronization triggering mechanism, which sends a synchronization flag to the video recording and acquisition unit and each log collection unit when a key node of the automated test task is detected. The data aggregation and archiving engine associates and aligns the video data and log data on the timeline according to the synchronization flag, and packages them to generate standardized archive files.

7. The system according to claim 1, characterized in that, The test execution module also includes: The Android device concurrency submodule is configured based on the Android device's unique serial number (SN) to schedule uiautomator2 and scrcpy service to establish independent device sessions, thereby enabling isolated testing and synchronous recording across multiple devices.

8. A cross-platform automated concurrent testing method for mobile devices, characterized in that, include: Configure a cross-platform abstraction layer to convert test instructions written in Python automated test scripts based on the unified API interface provided by the cross-platform abstraction layer into HTTP requests corresponding to the target device type, and send them to the HTTP server of the target device, so that the HTTP server of the target device can call the native framework to execute the test instructions carried in the test request; Publish events containing test status during the test; The abstraction layer integrates a Python client driver library for iOS devices. The call depth counter of the decorator function of the Python client driver library used to limit the recursive call depth is configured as a thread-local counter based on thread-local storage threading.local. When multiple WDA driver threads operate concurrently on different iOS devices, each WDA driver thread obtains and maintains an independent call depth count value from the thread-local counter. Based on the event-driven mechanism, it listens for test status events and responds to test status events carrying recording instructions. It controls the synchronous recording of the test process through the unified recording interface provided by the cross-platform abstraction layer and adopts the corresponding recording strategy according to the device type. Based on an event-driven mechanism, it listens for test status events and responds to test end events. It integrates real-time collected multi-dimensional test data with historical test data to generate a test report that includes quality trend analysis. By recording the exact moment of test failure and marking it with a timestamp in the test report, and linking it with the corresponding recorded video on a timeline, accurate backtracking of the fault node can be achieved.

9. A cross-platform automated concurrent testing device for mobile devices, characterized in that, include: Including memory and processor; Memory, used to store computer programs; The processor is used to read the computer program in the memory and, when executing the program, implement the cross-platform mobile device automated concurrent testing method as described in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the cross-platform mobile device automated concurrent testing method as described in claim 8.

Images