Cloud mobile phone test system and method based on ARM native architecture and intelligent environment arrangement

Abstract

The invention discloses a cloud mobile phone testing system and method based on an ARM native architecture and intelligent environment arrangement, and relates to the technical field of automatic testing, and the method comprises the steps: obtaining an operation node based on a dynamic scheduling plan, matching an Android container mirror image from an Android container mirror image warehouse according to a multi-dimensional parameter in a Kubernetes framework, pulling the Android container mirror image to the operation node, and carrying out the cloud mobile phone testing according to the operation node. The method comprises the following steps: acquiring an Android container instance by instantiating an Android container mirror image, mounting an application installation package, an automatic test script and a data acquisition agent, constructing a cloud mobile phone test environment, running the automatic test script in the cloud mobile phone test environment, controlling a cloud mobile phone to simulate a real user behavior, and acquiring multi-modal test data and storing the multi-modal test data as an original test data set; the automation degree, the efficiency and the resource utilization rate of cloud mobile phone testing are improved, and the requirements under different hardware and software environments are met.

Description

Technical Field

[0001] This invention relates to the field of automated testing technology, and in particular to a cloud phone testing system and method based on ARM native architecture and intelligent environment orchestration. Background Technology

[0002] With the widespread use of mobile devices, especially smartphones, the demand for smartphone performance testing and automated testing is increasing daily. To improve the efficiency and coverage of smartphone testing, cloud computing and virtualization technologies have been widely adopted in recent years. Cloud phone technology, in particular, utilizes cloud resources to simulate different models and versions of mobile phones, greatly reducing the need for physical devices and enabling rapid scheduling of test tasks in the cloud. Existing cloud phone testing platforms typically abstract physical hardware resources into virtual resources through virtualization technology, providing multiple instances of Android device environments in the cloud for automated test scripts to run.

[0003] While existing cloud phone testing platforms offer some virtualization support, they have limitations in resource management and scheduling, especially when testing cloud phones using different hardware architectures. Existing resource scheduling mechanisms fail to fully consider the characteristics of ARM SoC architecture, easily leading to inefficient system performance utilization. Existing systems often rely on static hardware configurations and fixed resource scheduling strategies, failing to flexibly adjust resource allocation based on test task requirements, the actual state of device resources, and task priorities. This results in low efficiency and wasted hardware resources in cloud phone testing. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a cloud phone testing method based on ARM native architecture and intelligent environment orchestration to solve the problems of low resource utilization and difficulty in handling large-scale concurrent testing.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a cloud phone testing method based on ARM native architecture and intelligent environment orchestration, which includes deploying an ARM SoC server cluster, building a Kubernetes framework and image repository on the ARM SoC server cluster, pushing images covering different Android versions and manufacturer UIs to the image repository, and building an Android container image repository. It receives test requests, collects resource status information of each ARM SoC node, and generates a dynamic scheduling plan through a dynamic priority evaluation algorithm. Based on a dynamic scheduling plan, a running node is obtained. In the Kubernetes framework, an Android container image is matched from the Android container image repository according to multi-dimensional parameters, pulled onto the running node, and an Android container instance is obtained by instantiating the Android container image. The application installation package, automated test scripts and data collection agent are then mounted to build a cloud phone test environment. Run automated test scripts in the cloud phone testing environment to control the cloud phone to simulate real user behavior and collect multimodal test data as the raw test dataset; Perform intelligent test diagnostic analysis on the original test dataset to generate a cloud phone test report.

[0007] As a preferred embodiment of the cloud phone testing method based on ARM native architecture and intelligent environment orchestration described in this invention, the specific steps for building the Android container image repository are as follows: Deploy an ARM SoC server cluster, select one ARM SoC node as the master node, and add other ARM SoC nodes to the Kubernetes cluster to build the Kubernetes framework; An image repository is built using Docker Registry, which pushes multiple images covering different Android versions and manufacturer UIs to the repository, thus creating an Android container image repository.

[0008] As a preferred embodiment of the cloud phone testing method based on ARM native architecture and intelligent environment orchestration described in this invention, the specific steps for receiving test requests and simultaneously collecting resource status information of each ARM SoC node are as follows: The test request is generated by receiving test tasks, waiting time, test priority labels and multi-dimensional parameters through the task queue to be scheduled. By running monitoring tools on each ARM SoC node, resource status information is collected in real time.

[0009] As a preferred embodiment of the cloud phone testing method based on ARM native architecture and intelligent environment orchestration described in this invention, the step of generating a dynamic scheduling plan through a dynamic priority evaluation algorithm includes the following specific steps. Based on resource status information and resource parameters in multi-dimensional parameters, a list of feasible nodes is selected for each test task. Resource requirements are calculated based on resource parameters in the multidimensional parameters. Based on the list of feasible nodes, resource requirements, test priority labels and waiting time are comprehensively evaluated to obtain a dynamic score. The test tasks are sorted from high to low according to their dynamic scores. An ARMSoC node is selected as the running node and bound to the test task based on the minimum load priority strategy, and the binding relationship is used as a dynamic scheduling plan.

[0010] As a preferred embodiment of the cloud phone testing method based on ARM native architecture and intelligent environment orchestration described in this invention, the following steps are taken: Based on a dynamic scheduling plan, a running node is obtained; within the Kubernetes framework, an Android container image is matched from the Android container image repository according to multi-dimensional parameters, pulled onto the running node, and an Android container instance is obtained by instantiating the Android container image. Read the binding relationship between test tasks and running nodes in the dynamic scheduling plan, and obtain the running nodes; In the Kubernetes framework, the image parameters in the multidimensional parameters are matched with the image parameters in the multidimensional parameters of each Android container image in the Android container image repository; When a match is found, the Android container image is pulled from the Pod resource and stored on the running node; On the running node, the Android container image is instantiated using the Kubernetes framework to obtain an Android container instance.

[0011] As a preferred embodiment of the cloud phone testing method based on ARM native architecture and intelligent environment orchestration described in this invention, the specific steps for mounting the application installation package, automated test scripts, and data acquisition agent to construct the cloud phone testing environment are as follows. By using the ConfigMap feature of the Kubernetes framework, the application installation package is mounted to a specified directory of the Android container instance, and automated test scripts are also mounted at the same time. By configuring a volume using the Kubernetes framework, a data acquisition agent is mounted onto an Android container instance, thus creating a cloud phone testing environment.

[0012] As a preferred embodiment of the cloud phone testing method based on ARM native architecture and intelligent environment orchestration described in this invention, the steps of running automated test scripts in the cloud phone testing environment, controlling the cloud phone to simulate real user behavior, and collecting multimodal test data as the original test dataset are as follows. The Kubernetes framework executes automated test scripts through entrypoints, calls the underlying framework's APIs, and sends event commands to Android container instances to simulate real user behavior. Multimodal test data is collected in real time through a data acquisition agent. Structured data records are generated through field mapping and encapsulation, and then stored in batches as the original test dataset.

[0013] As a preferred embodiment of the cloud phone testing method based on ARM native architecture and intelligent environment orchestration described in this invention, the specific steps for performing intelligent test diagnostic analysis on the original test dataset and generating a cloud phone test report are as follows: Data preprocessing and feature extraction are performed on the original test dataset to obtain key fault features, and fault classification and location results are obtained through intelligent diagnostic analysis. The fault classification and location results are aggregated with indicators and qualitatively evaluated to generate a cloud phone test report.

[0014] As a preferred embodiment of the cloud phone testing method based on ARM native architecture and intelligent environment orchestration described in this invention, the specific steps for preprocessing and feature extraction of the original test dataset to obtain key fault features are as follows: The original test dataset is cleaned, normalized, and format-converted to obtain standardized test data; Key fault characteristics are extracted from standardized test data through natural language processing and time series analysis.

[0015] Secondly, the present invention provides a cloud phone testing system based on ARM native architecture and intelligent environment orchestration, including a resource deployment module for deploying an ARM SoC server cluster, building a Kubernetes framework and image repository on the ARM SoC server cluster, and pushing images covering different Android versions and manufacturer UIs to the image repository to build an Android container image repository. The scheduling evaluation module is used to receive test requests, collect resource status information of each ARM SoC node, and generate a dynamic scheduling plan through a dynamic priority evaluation algorithm. The environment building module is used to obtain running nodes based on a dynamic scheduling plan, match Android container images from the Android container image repository in the Kubernetes framework according to multi-dimensional parameters, pull them onto the running nodes, obtain Android container instances by instantiating Android container images, and mount application installation packages, automated test scripts and data collection agents to build a cloud phone test environment. The test execution module is used to run automated test scripts in the cloud phone test environment, control the cloud phone to simulate real user behavior, and collect multimodal test data as raw test datasets. The diagnostic analysis module is used to perform intelligent test diagnostic analysis on the original test dataset and generate cloud phone test reports.

[0016] The beneficial effects of this invention are as follows: By generating a dynamic scheduling plan through a dynamic priority evaluation algorithm, the scheduling of test tasks among ARM SoC nodes is optimized, ensuring efficient resource utilization and improved testing efficiency; at the same time, the automated cloud phone testing environment built on the Kubernetes framework can automatically match and pull the required resources according to task requirements, reducing manual intervention and configuration errors, and improving the flexibility of environment configuration and system scalability; it improves the automation level, efficiency, and resource utilization of cloud phone testing, and adapts to the needs of different hardware and software environments. Attached Figure Description

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

[0018] Figure 1 This is a flowchart of a cloud phone testing method based on the native ARM architecture and intelligent environment orchestration.

[0019] Figure 2 This is a schematic diagram of a cloud phone testing system based on the native ARM architecture and intelligent environment orchestration.

[0020] Figure 3 A flowchart for building an Android container image repository.

[0021] Figure 4 A flowchart for generating a dynamic scheduling plan. Detailed Implementation

[0022] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0023] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0024] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0025] Reference Figures 1-4 This is one embodiment of the present invention, which provides a cloud phone testing method based on ARM native architecture and intelligent environment orchestration, including the following steps: S1. Deploy an ARM SoC server cluster, build a Kubernetes framework and image repository on the ARM SoC server cluster, and push images covering different Android versions and manufacturer UIs to the image repository to build an Android container image repository.

[0026] S1.1 Deploy an ARM SoC server cluster, select an ARM SoC node as the master node, add other ARM SoC nodes to the Kubernetes cluster, and build the Kubernetes framework.

[0027] Furthermore, install the same version of Linux on all ARM SoC servers, configure static IP addresses and hostname resolution, and disable the firewall and swap partition. Install Docker, kubeadm, kubelet, and kubectl toolsets on all ARM SoC nodes. Select one ARM SoC node as the master node, initialize it using the `kubeadm init` command, configure the master node's API server address and network plugins, and generate the `kubeadm join` command. Join the Kubernetes cluster on the other ARM SoC nodes using the `kubeadm join` command, register worker nodes to the master node, and confirm that all ARM SoC nodes are in a Ready state, thus establishing the Kubernetes framework. It's worth noting that Docker is an open-source containerization platform used to create, manage, and distribute container images, supporting the packaging of applications and their dependencies into lightweight containers; Kubernetes is an open-source container orchestration platform used to automate the deployment, scaling, management, and operation of containerized applications; Linux is an open-source UNIX-like operating system kernel widely used in servers, embedded devices, and other fields, supporting multi-user, multi-tasking processing; kubeadm is a tool for quickly initializing Kubernetes clusters; kubelet is a proxy service running on each node of the cluster, responsible for managing the container lifecycle and communicating with the cluster control plane; kubectl is a command-line client tool for Kubernetes, used for interacting with the cluster and manipulating resources; and ARM SoC is a system-on-a-chip based on the ARM architecture.

[0028] S1.2 Build an image repository using Docker Registry, push multiple images covering different Android versions and manufacturer UIs to the image repository, and build an Android container image repository.

[0029] Furthermore, the Registry image is obtained by executing the command `docker pull registry:2`, generating TLS certificates and basic authentication files. The Registry image is instantiated by `docker run`, and the Docker Registry is configured and started by setting port mapping, data volume mounting, and security environment variables to build the image repository. Android container images containing different Android versions and manufacturer UIs are pushed to the image repository using the `docker push` command to build the Android container image repository. It should be noted that Docker Registry is an open-source image repository service provided by Docker, used to store, distribute, and manage Docker container images.

[0030] S2. Receive test requests, collect resource status information of each ARM SoC node, and generate a dynamic scheduling plan through a dynamic priority evaluation algorithm.

[0031] S2.1 Receive test tasks, waiting time, test priority labels and multi-dimensional parameters through the task queue to be scheduled, and form a test request.

[0032] Furthermore, deploy a queue service that supports persistent and structured messages, create a dedicated queue based on the queue service as a queue of tasks to be scheduled, receive test requests from the queue of tasks to be scheduled, and obtain test task content, waiting time, test priority label and multi-dimensional parameter data from the test requests.

[0033] S2.2. By running monitoring tools on each ARM SoC node, resource status information is collected in real time.

[0034] Furthermore, a monitoring component is deployed on all ARM SoC nodes and configured to collect system-level resource metrics. By modifying the monitoring component's configuration file, the metric collection interval is set to 5 seconds, and necessary collectors are enabled to ensure real-time performance. The monitoring component service process is started, and the monitoring component service process is verified to successfully expose monitoring data on the specified port to ensure that resource status information is continuously collected.

[0035] S2.3. Based on resource status information and resource parameters in multi-dimensional parameters, select a list of feasible nodes for each test task.

[0036] Furthermore, the resource status information of each ARM SoC node is compared item by item with the resource parameters in the multi-dimensional parameters. Only when the number of available CPU cores of the ARM SoC node is greater than or equal to the number of CPU cores required by the task, the available memory is greater than or equal to the memory required by the task, the remaining disk space is greater than or equal to the storage space required by the task, and the network bandwidth meets the minimum requirements of the task, can it be included in the list of feasible nodes. The ARM SoC nodes that meet all the conditions are selected to form the list of feasible nodes for the current test task to be scheduled.

[0037] Furthermore, the number of CPU cores, memory size, and storage space required for the test task are obtained from the resource parameters. The resource requirements are obtained by summing the products of the number of CPU cores, memory size, and storage space required for the test task with the corresponding CPU resource weight coefficient, memory resource weight coefficient, and storage resource weight coefficient, respectively. It should be noted that the weight coefficients of CPU, memory, and storage resources are preset based on the resource consumption data of historical test tasks, and are used to reflect the relative importance of different resource types in the overall resource requirements. For example, by analyzing the resource consumption data of 1000 historical test tasks, the average number of CPU cores is 2, the average memory size is 4, and the average storage space is 1. Then, the CPU resource weight coefficient = 2 / (2+4+1) = 0.286, the memory resource weight coefficient = 4 / 7 = 0.571, and the storage resource weight coefficient = 1 / 7 = 0.143.

[0038] S2.4 Calculate the resource requirement based on the resource parameters in the multi-dimensional parameters. Based on the list of feasible nodes, comprehensively evaluate the resource requirement, test priority label, and waiting time to obtain a dynamic score.

[0039] Furthermore, the number of CPU cores, memory size, and storage space required for the test task are obtained from the resource parameters. The resource requirement is obtained by summing the products of the number of CPU cores, memory size, and storage space required for the test task with the corresponding CPU resource weight coefficient, memory resource weight coefficient, and storage resource weight coefficient, respectively. The test priority label of the test task is converted into a test priority numerical score (e.g., high priority = 3, medium priority = 2, low priority = 1). The dynamic score is obtained by accumulating the test priority numerical score controlled by w1 and the waiting time controlled by w2, and then subtracting the resource requirement controlled by w3. The relative influence of these three factors on the final scheduling can be changed by adjusting the three configurable weight coefficients (all positive numbers) of w1, w2, and w3.

[0040] It should be noted that the weight coefficients of CPU, memory, and storage resources are preset based on the resource consumption data of historical test tasks, and are used to reflect the relative importance of different resource types in the overall resource requirements. For example, by analyzing the resource consumption data of 1000 historical test tasks, the average number of CPU cores is 2, the average memory size is 4, and the average storage space is 1. Then, the CPU resource weight coefficient = 2 / (2+4+1) = 0.286, the memory resource weight coefficient = 4 / 7 = 0.571, and the storage resource weight coefficient = 1 / 7 = 0.143.

[0041] S2.5 Sort the test tasks from high to low according to the dynamic score, select an ARM SoC node as the running node and bind it to the test task based on the minimum load priority strategy, and use the binding relationship as a dynamic scheduling plan.

[0042] Furthermore, all test tasks are sorted from high to low according to their dynamic scores to ensure that test tasks with high dynamic scores are preferentially assigned to the running nodes. For each sorted test task, the ARM SoC node with the lowest current comprehensive load value is selected from the list of feasible nodes. The test task is bound to the selected ARM SoC node, and the binding relationship is stored as a dynamic scheduling plan using a hash table as the storage structure. It should be noted that the minimum load priority strategy means: quantifying the overall load value by weighting the resource status information of each ARM SoC node; when allocating running nodes for each test task, prioritizing the ARM SoC node with the lowest current overall load value in the feasible node list.

[0043] S3. Based on the dynamic scheduling plan, obtain the running node, match the Android container image from the Android container image repository in the Kubernetes framework according to multi-dimensional parameters, pull it to the running node, obtain the Android container instance by instantiating the Android container image, and mount the application installation package, automated test script and data collection agent to build the cloud phone test environment.

[0044] S3.1 Read the binding relationship between test tasks and running nodes in the dynamic scheduling plan, and obtain the running nodes.

[0045] Furthermore, the system searches the storage structure of the dynamic scheduling plan using the unique identifier of the test task as the key to retrieve the binding record of the specified test task, extract the corresponding run node identifier, and obtain the run node. The run node identifier is then passed to the Kubernetes framework for subsequent deployment of the test environment on the run node.

[0046] S3.2 In the Kubernetes framework, match the image parameters in the multidimensional parameters with the image parameters in the multidimensional parameters of each Android container image in the Android container image repository.

[0047] Furthermore, image parameters are extracted from multi-dimensional parameters, including Android version, manufacturer UI, display resolution, and irregular screen shape; the image parameters of multi-dimensional parameters are precisely compared with the image parameters of each Android container image in the Android container image repository, and the results that match perfectly are selected as the only candidates for subsequent retrieval.

[0048] S3.3 When a match is found, the Android container image is pulled through the Pod resource and stored on the running node.

[0049] Furthermore, based on the matching image parameters, the complete image address is concatenated and filled into the Pod template, and the affinity rules of the running node are written to generate a temporary Pod configuration file containing the image address. The temporary Pod configuration file is deployed in the Kubernetes cluster using the kubectl apply command, and the Kubernetes framework is triggered to pull the Android container image from the Android container image repository to the running node. By monitoring the Pod pull status, it is confirmed that the Android container image is successfully stored in the container runtime local cache of the running node.

[0050] S3.4 On the running node, instantiate the Android container image using the Kubernetes framework to obtain an Android container instance.

[0051] Furthermore, based on the matched image parameters, the complete image address is concatenated and filled into the Pod template. Affinity rules for the running node are written, and the container name, ConfigMap mount path, Volume mount configuration, and entrypoint startup command are added to generate the official Pod configuration file. The official Pod configuration file is deployed to the Kubernetes cluster using the command `kubectl apply -f android-pod.yaml`, triggering the instantiation process of the Android container image. The Pod status is verified using the command `kubectl get pods`, confirming that the Android container instance has been successfully created on the specified running node and is in a running state.

[0052] S3.5. Using the ConfigMap feature of the Kubernetes framework, mount the application installation package to the specified directory of the Android container instance, and simultaneously mount the automated test scripts.

[0053] Furthermore, a ConfigMap object containing the application installation package and automated test scripts is created, and these two files are stored as key-value pairs in the ConfigMap. In the Pod configuration file of the Android container instance, mount points are defined through volumeMounts to mount the application installation package to a specified directory, while the automated test scripts are mounted to another specified directory.

[0054] S3.6. Using the Kubernetes framework, the data acquisition agent is mounted to the Android container instance via a volume, thus building a cloud phone testing environment.

[0055] Furthermore, create a Volume resource of type emptyDir and store the data collection agent file as Volume data in the Kubernetes cluster; in the Pod configuration file of the Android container instance, specify the mount path through the volumeMounts field to mount the Volume to the specified directory inside the container; deploy the Pod configuration using kubectl apply, and verify that the data collection agent file is successfully mounted under the / data / collector path inside the container using the kubectl exec command.

[0056] S4. Run automated test scripts in the cloud phone testing environment to control the cloud phone to simulate real user behavior and collect multimodal test data as the raw test dataset.

[0057] S4.1 The Kubernetes framework executes automated test scripts through entrypoints to call the underlying framework's APIs and send event commands to Android container instances to simulate real user behavior.

[0058] Furthermore, in the Pod configuration file of the Android container instance, the full path of the automated test script is specified through the entrypoint parameter to ensure that the script is automatically executed when the container starts. The automated test script calls the API of the Android underlying framework to generate and send user event instructions to the Android container instance. The user event instructions are processed in real time by the Android underlying framework to simulate real user operation behavior and drive the execution of the automated test process.

[0059] S4.2. Collect multimodal test data in real time through the data acquisition agent, generate structured data records through field mapping and encapsulation, and store them in batches as the original test dataset.

[0060] Furthermore, a data acquisition agent is launched in the Android container instance to capture multimodal test data in real time; the raw data is converted into structured fields and encapsulated into JSON format records by applying preset field mapping rules; the structured data records are then written to the database in batches to form a complete raw test dataset. It should be noted that the field mapping rules are set by defining the correspondence between various raw fields and structured fields in the multimodal test data. For example, the system timestamp is mapped to "timestamp", the touch event type is mapped to "event_type", and the performance value is mapped to "data_value". The field mapping rules also specify the data type, unit, and value range of each field to ensure that the raw data from different sources maintains semantic consistency and format uniformity after conversion.

[0061] S5. Perform intelligent test diagnostic analysis on the original test dataset and generate a cloud phone test report.

[0062] S5.1 Clean, normalize, and convert the format of the original test dataset to obtain standardized test data.

[0063] Furthermore, data cleaning is performed to address missing values, duplicate records, and inconsistent formats in the original test dataset; the numerical test data is scaled using the Min-Max normalization algorithm to ensure that all feature values ​​fall within the [0,1] range; and the processed data is converted into a standardized CSV structured format through a format conversion operation to generate a complete standardized test dataset.

[0064] S5.2 Extract key fault characteristics from standardized test data through natural language processing and time series analysis.

[0065] Furthermore, for the fault text logs in the standardized test data, the TF-IDF algorithm is used for word segmentation, stop word removal, and feature weighting to extract key text feature vectors; for the system performance time series in the standardized test data, sliding window statistics and anomaly detection algorithms are used to extract key time series feature points (including anomaly occurrence timestamp, anomaly magnitude, anomaly duration, and anomaly frequency); the key text feature vectors and key time series feature points are fused to generate a key fault feature set containing fault type, occurrence time, severity, and impact range.

[0066] It should be noted that the anomaly detection algorithm is based on the probability density estimation of Gaussian distribution. It detects anomalies by calculating the degree of deviation of data points from the normal data distribution and is used to extract key time-series feature points from the system performance time series.

[0067] S5.3. By performing intelligent diagnostic analysis on key fault characteristics, fault classification and location results are obtained.

[0068] Furthermore, a pre-trained random forest model is used to classify the key fault feature set and output the fault type; based on the system component identification and time series data in the key fault feature set, a fault location algorithm is used to accurately determine the specific module or service node where the fault occurred as the location result. It should be noted that the training process of the random forest model is as follows: Standardized test data accumulated from historical cloud phone tests is used as input, and a set of key fault features generated by natural language processing and time series analysis is extracted from it as feature vectors, with automatically verified fault types used as supervision labels; multiple decision trees are constructed through Bootstrap sampling, and each tree randomly selects a subset from all features and chooses the optimal splitting feature when splitting at a node, and finally integrates the voting results of all trees to form a classification prediction; continuous iterative training is carried out until the classification accuracy of fault types on the independent validation set reaches the preset requirement (e.g., an accuracy of over 92%), thereby obtaining a random forest fault classification model that can perform high-precision and robust classification of key fault feature sets in new test tasks; It should also be noted that when using a pre-trained random forest model to classify the set of key fault features, the set of key fault features is fed into the random forest model as an input feature vector. The random forest model consists of multiple decision trees. Each decision tree independently makes path judgments on the input features and outputs a fault type voting result (such as UI crash, performance abnormality, or network timeout). The voting results of all decision trees are aggregated, and the fault type with the most votes is selected as the final classification output.

[0069] S5.4. Aggregate indicators and conduct qualitative quality assessments on the fault classification and location results to generate a cloud phone test report.

[0070] Furthermore, key quantitative indicators (such as the number of faults, severity distribution, and scope of impact) are extracted from the fault classification and localization results, statistically aggregated, and aggregated indicators are generated. Based on preset quality assessment rules, the aggregated indicators are analyzed, and the test quality level (such as excellent / good / needs improvement) and improvement suggestions are output as the quality assessment conclusion. The aggregated indicators, quality assessment conclusions, and fault classification and localization results are integrated into a structured cloud phone test report, which includes a fault overview, root cause analysis, scope of impact, and optimization suggestions. It should be noted that the quality assessment rules quantify and assign values ​​to the distribution of fault severity in the aggregated indicators, assigning 3 points to crashes, 2 points to freezes, and 1 point to warnings. The total severity of faults is calculated and then divided by the product of the total number of faults and the maximum severity coefficient of 3 to obtain the percentage of fault severity. The comprehensive quality score is calculated as (1 - percentage of fault severity) × 100. The test quality level is determined based on the comprehensive quality score: when the comprehensive quality score is ≥ 90, it is output as excellent; when the comprehensive quality score is ≤ 70 and < 90, it is output as good; and when the comprehensive quality score is < 70, it is output as needing improvement. It also associates with the preset improvement suggestion template, where the "excellent" level is associated with "no optimization required, can enter the release process", the "good" level is associated with "it is recommended to fix low-to-medium risk issues before release", and the "needs improvement" level is associated with "high-risk faults exist, must be fixed and retested".

[0071] This embodiment also provides a cloud phone testing system based on ARM native architecture and intelligent environment orchestration, including: a resource deployment module for deploying an ARM SoC server cluster, building a Kubernetes framework and image repository on the ARM SoC server cluster, and pushing images covering different Android versions and manufacturer UIs to the image repository to build an Android container image repository; The scheduling evaluation module is used to receive test requests, collect resource status information of each ARM SoC node, and generate a dynamic scheduling plan through a dynamic priority evaluation algorithm. The environment building module is used to obtain running nodes based on a dynamic scheduling plan, match Android container images from the Android container image repository in the Kubernetes framework according to multi-dimensional parameters, pull them onto the running nodes, obtain Android container instances by instantiating Android container images, and mount application installation packages, automated test scripts and data collection agents to build a cloud phone test environment. The test execution module is used to run automated test scripts in the cloud phone test environment, control the cloud phone to simulate real user behavior, and collect multimodal test data as raw test datasets. The diagnostic analysis module is used to perform intelligent test diagnostic analysis on the original test dataset and generate cloud phone test reports.

[0072] In summary, this invention optimizes test task scheduling among ARM SoC nodes by generating a dynamic scheduling plan through a dynamic priority evaluation algorithm, ensuring efficient resource utilization and improved testing efficiency. Simultaneously, the automated cloud phone testing environment built on the Kubernetes framework can automatically match and retrieve the required resources according to task requirements, reducing manual intervention and configuration errors, and improving the flexibility of environment configuration and system scalability. This enhances the automation, efficiency, and resource utilization of cloud phone testing, adapting to the needs of different hardware and software environments.

[0073] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cloud phone testing method based on an ARM native architecture and intelligent environment orchestration, characterized in that: include, Deploy an ARM SoC server cluster, build a Kubernetes framework and image repository on the ARM SoC server cluster, and push images covering different Android versions and manufacturer UIs to the image repository to build an Android container image repository; It receives test requests, collects resource status information of each ARM SoC node, and generates a dynamic scheduling plan through a dynamic priority evaluation algorithm. Based on a dynamic scheduling plan, a running node is obtained. In the Kubernetes framework, an Android container image is matched from the Android container image repository according to multi-dimensional parameters, pulled onto the running node, and an Android container instance is obtained by instantiating the Android container image. The application installation package, automated test scripts and data collection agent are then mounted to build a cloud phone test environment. Run automated test scripts in the cloud phone testing environment to control the cloud phone to simulate real user behavior and collect multimodal test data as the raw test dataset; Perform intelligent test diagnostic analysis on the original test dataset to generate a cloud phone test report.

2. The cloud mobile test method based on ARM native architecture and intelligent environment arrangement according to claim 1, characterized in that: The specific steps for building the Android container image repository are as follows. Deploy an ARM SoC server cluster, select one ARM SoC node as the master node, and add other ARM SoC nodes to the Kubernetes cluster to build the Kubernetes framework; By building an image repository using Docker Registry, multiple images covering different Android versions and manufacturer UIs can be pushed to the image repository to create an Android container image repository.

3. The cloud mobile test method based on ARM native architecture and intelligent environment arrangement according to claim 2, characterized in that: The process of receiving test requests and simultaneously collecting resource status information from each ARM SoC node is detailed below. The test request is generated by receiving test tasks, waiting time, test priority labels and multi-dimensional parameters through the task queue to be scheduled. By running monitoring tools on each ARM SoC node, resource status information is collected in real time.

4. The cloud mobile test method based on ARM native architecture and intelligent environment arrangement according to claim 3, characterized in that: The dynamic scheduling plan is generated using a dynamic priority evaluation algorithm, and the specific steps are as follows. Based on resource status information and resource parameters in multi-dimensional parameters, a list of feasible nodes is selected for each test task. Resource requirements are calculated based on resource parameters in the multidimensional parameters. Based on the list of feasible nodes, resource requirements, test priority labels and waiting time are comprehensively evaluated to obtain a dynamic score. The test tasks are sorted from high to low according to their dynamic scores. An ARM SoC node is selected as the running node and bound to the test task based on the minimum load priority strategy, and the binding relationship is used as a dynamic scheduling plan.

5. The cloud mobile test method based on ARM native architecture and intelligent environment arrangement according to claim 4, characterized in that: The process involves obtaining a running node based on a dynamic scheduling plan, matching an Android container image from the Android container image repository within the Kubernetes framework according to multi-dimensional parameters, pulling the image onto the running node, and then instantiating the Android container image to obtain an Android container instance. The specific steps are as follows. Read the binding relationship between test tasks and running nodes in the dynamic scheduling plan, and obtain the running nodes; In the Kubernetes framework, the image parameters in the multidimensional parameters are matched with the image parameters in the multidimensional parameters of each Android container image in the Android container image repository; When a match is found, the Android container image is pulled from the Pod resource and stored on the running node; On the running node, the Android container image is instantiated using the Kubernetes framework to obtain an Android container instance.

6. The cloud phone testing method based on ARM native architecture and intelligent environment orchestration as described in claim 1, characterized in that: The process of mounting the application installation package, automated test scripts, and data acquisition agent to build a cloud phone testing environment involves the following steps: By using the ConfigMap feature of the Kubernetes framework, the application installation package is mounted to a specified directory of the Android container instance, and automated test scripts are also mounted at the same time. By configuring a volume using the Kubernetes framework, a data acquisition agent is mounted onto an Android container instance, thus creating a cloud phone testing environment.

7. The cloud phone testing method based on ARM native architecture and intelligent environment orchestration as described in claim 6, characterized in that: The steps for running automated test scripts in the cloud phone testing environment, controlling the cloud phone to simulate real user behavior, and collecting multimodal test data as the raw test dataset are as follows. The Kubernetes framework executes automated test scripts through entrypoints, calls the underlying framework's APIs, and sends event commands to Android container instances to simulate real user behavior. Multimodal test data is collected in real time during the simulation process. Structured data records are generated through field mapping and encapsulation, and then stored in batches as the original test dataset.

8. The cloud phone testing method based on ARM native architecture and intelligent environment orchestration as described in claim 7, characterized in that: The specific steps for performing intelligent test diagnostic analysis on the original test dataset and generating a cloud phone test report are as follows. Data preprocessing and feature extraction are performed on the original test dataset to obtain key fault features, and fault classification and location results are obtained through intelligent diagnostic analysis. The fault classification and location results are aggregated with indicators and qualitatively evaluated to generate a cloud phone test report.

9. The cloud phone testing method based on ARM native architecture and intelligent environment orchestration as described in claim 8, characterized in that: The specific steps for preprocessing and feature extraction of the original test dataset to obtain key fault features are as follows. The original test dataset is cleaned, normalized, and format-converted to obtain standardized test data; Key fault characteristics are extracted from standardized test data through natural language processing and time series analysis.

10. A cloud phone testing system based on ARM native architecture and intelligent environment orchestration, based on the cloud phone testing method based on ARM native architecture and intelligent environment orchestration as described in any one of claims 1 to 9, characterized in that: include, The resource deployment module is used to deploy ARM SoC server clusters, build Kubernetes framework and image repository on ARM SoC server clusters, and push images covering different Android versions and manufacturer UIs to the image repository to build an Android container image repository. The scheduling evaluation module is used to receive test requests, collect resource status information of each ARM SoC node, and generate a dynamic scheduling plan through a dynamic priority evaluation algorithm. The environment building module is used to obtain running nodes based on a dynamic scheduling plan, match Android container images from the Android container image repository in the Kubernetes framework according to multi-dimensional parameters, pull them onto the running nodes, obtain Android container instances by instantiating Android container images, and mount application installation packages, automated test scripts and data collection agents to build a cloud phone test environment. The test execution module is used to run automated test scripts in the cloud phone test environment, control the cloud phone to simulate real user behavior, and collect multimodal test data as raw test datasets. The diagnostic analysis module is used to perform intelligent test diagnostic analysis on the original test dataset and generate cloud phone test reports.

Images