An Automated Test Scheduling Method and System for Cloud Real Machine Clusters Based on Edge Computing

Abstract

This invention provides an automated testing scheduling method and system for cloud real machine clusters based on edge computing, relating to the field of edge computing technology. The method includes: deploying an edge scheduling engine on each edge node of the cloud real machine cluster; collecting full-dimensional information of cloud real machine devices within the jurisdiction through the edge scheduling engine, constructing a multi-dimensional profile of the devices, and then constructing an elastic dynamic resource pool; receiving high-concurrency automated testing tasks and completing structured parsing, generating standardized task data and distributing it to the corresponding edge nodes, and constructing a task waiting queue based on task priority; performing queue management and resource locking based on the task waiting queue; obtaining the corresponding optimal adaptation scheduling through a multi-constraint weighted intelligent matching algorithm and forming scheduling instructions; monitoring the operating status and task execution status of the cloud real machine devices in real time, triggering a fault self-healing mechanism after identifying anomalies, automatically removing faulty devices, and achieving task breakpoint continuation testing and seamless switching to backup cloud real machine devices.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, specifically to an automated testing scheduling method and system for cloud real machine clusters based on edge computing. Background Technology

[0002] With the continuous iteration and improvement of the mobile application ecosystem, various mobile terminal device models are becoming increasingly diverse, and the frequency of application iterations is accelerating. Automated testing for compatibility and stability across multiple models and system versions has become an important guarantee for the compliant launch and stable operation of applications.

[0003] Traditional centralized cloud scheduling is limited by network transmission latency and cloud computing power bottlenecks. When facing high concurrency and large batch of test tasks, it lacks standardized task queue management and reasonable task diversion mechanism. When multiple tasks run concurrently, resource contention, task queuing and blocking, and disordered scheduling are likely to occur. The overall scheduling stability and adaptability are poor, and it cannot meet the current needs of high concurrency, differentiation and high stability cloud real machine cluster automated testing applications.

[0004] Therefore, we now provide an automated testing scheduling method and system for cloud real machine clusters based on edge computing. Summary of the Invention

[0005] To address the aforementioned technical problems, the present invention aims to provide an automated testing scheduling method and system for cloud real machine clusters based on edge computing.

[0006] To achieve the above objectives, the present invention provides the following technical solution: an automated test scheduling method for cloud real machine clusters based on edge computing, the method comprising: Deploy edge scheduling engines on each edge node of the cloud real machine cluster to push scheduling computing power down to the edge side; By collecting full-dimensional information on cloud real device devices within the jurisdiction through the edge scheduling engine, a multi-dimensional profile of the devices is constructed, and then an elastic dynamic resource pool of cloud real device devices is dynamically constructed and updated in real time. The cloud-based management system receives high-concurrency automated test tasks and performs structured parsing, generates standardized task data, and distributes it to the corresponding edge nodes. The edge nodes construct task waiting queues based on task priorities and perform queue management and resource locking based on the task waiting queues. The edge scheduling engine uses a multi-constraint weighted intelligent matching algorithm, combined with the device status of the corresponding elastic dynamic resource pool, to obtain the optimal matching and scheduling of high-concurrency automated test tasks and cloud real machine devices after traffic splitting, and generates scheduling instructions to realize automated test scheduling of cloud real machine clusters within the jurisdiction. Edge nodes monitor the real-time operating status and task execution status of cloud real devices. Upon identifying anomalies, they trigger a fault self-healing mechanism, automatically removing faulty devices and enabling task breakpoint continuation testing as well as seamless switching to backup cloud real devices.

[0007] Furthermore, the process of building and updating the elastic dynamic resource pool is as follows: The edge scheduling engine performs a full scan of all connected cloud real device devices within its jurisdiction to obtain multi-dimensional parameters of the cloud real device devices and build a multi-dimensional profile of the devices. Based on multi-dimensional device profiles, cloud-based real-device devices are categorized and aggregated into multiple resource groups, thereby constructing an elastic and dynamic resource pool. Edge nodes poll the status of all devices at a preset polling period, update the status tags of cloud real devices in the elastic dynamic resource pool in real time, and automatically remove failed cloud real devices or add newly connected cloud real devices.

[0008] Furthermore, the structured parsing process of the high-concurrency automated testing task is as follows: Receive high-concurrency automated test tasks, perform structured parsing of the high-concurrency automated test tasks, including extracting hardware constraints, task attribute constraints, and execution constraints; Based on the hardware constraints, task attribute constraints, and execution constraints, standardized task data is generated and distributed to the corresponding edge nodes. The corresponding edge nodes then construct task waiting queues based on task priorities.

[0009] Furthermore, the process of streamlining and resource locking based on the task waiting queue is as follows: The test tasks in the task waiting queue are managed in a hierarchical and partitioned manner, and long-term test tasks, short-term lightweight tasks, and retry failed tasks are isolated in the queue. At the same time, queue throttling control is performed based on the edge node computing power threshold and device load status. The edge scheduling engine scans the idle resource status and concurrent load of the elastic dynamic resource pool in real time, and retrieves tasks to be executed in an orderly manner from the head of the task waiting queue based on the carrying capacity of the cloud real device. When a task is successfully matched and ready to be executed, a distributed resource lock is applied to the target cloud real device, marking the target cloud real device as occupied, and restricting the target cloud real device from being preempted by other test tasks in the same task waiting queue or test tasks in other task waiting queues during task execution; Real-time monitoring of the current task backlog at edge nodes and the overall load of cloud real device equipment. When an abnormality occurs in the queue, the system automatically performs intelligent diversion of the tasks waiting at the tail of the task waiting queue, and distributes the excess test tasks evenly to other edge nodes in the cloud real device cluster that are under low load and in idle state, thereby dynamically adjusting the dequeueing rhythm of the task waiting queue.

[0010] Furthermore, the process of applying distributed resource locking to the target cloud physical device is as follows: A distributed lock mechanism is introduced to lock the state of cloud real machine resources that have been allocated test tasks, preventing multiple test tasks from competing for the same device resources; The edge scheduling engine first selects a set of idle candidate cloud real machine devices from the elastic dynamic resource pool, and prioritizes initiating distributed lock preemption operations on the candidate cloud real machine devices in batches; the unique device ID of the cloud real machine device is used as the lock, and the global transaction number of the currently assigned test task is used as the lock ownership identifier, and the pre-locking preemption is implemented based on the edge node distributed memory mechanism; if the cloud real machine device is successfully locked, the cloud real machine device is temporarily locked and marked as pending scheduling and occupied, and the device that successfully preempted the lock is included in the set of matchable resources; For cloud-based real device devices that have been successfully locked, the optimal adaptation and matching between the test task and the locked cloud-based real device is achieved through a multi-constraint weighted intelligent matching algorithm. If a cloud-based physical device fails to preempt the lock, it will be removed from the candidate list and will no longer participate in the multi-constraint weighted intelligent matching algorithm matching in this round.

[0011] Furthermore, the execution process of the multi-constraint weighted intelligent matching algorithm is as follows: The edge scheduling engine retrieves data of idle cloud real devices and parameters of test tasks to be scheduled from the elastic dynamic resource pool, sets weighting factors and calculates the device task matching degree, thereby obtaining the optimal adaptive scheduling. The optimally adapted and scheduled cloud-based physical devices are used as the optimal execution carriers for tasks, thereby achieving optimal adaptation and scheduling operations. For test tasks that are not matched with cloud real devices, they are kept in the task waiting queue and will be matched again after resources are released.

[0012] Furthermore, the processing procedure of the fault self-healing mechanism is as follows: Edge nodes leverage their proximity to collect data to monitor the operational status and task execution status of cloud-based real-world devices in real time. If a device malfunction is detected, it is temporarily removed from the elastic dynamic resource pool, marked as faulty and awaiting repair, and new task assignment is prohibited. If a test task is abnormally interrupted, the current execution breakpoint, test logs, and runtime data are automatically saved. The appropriate cloud-based real-world devices within the elastic dynamic resource pool are retrieved to seamlessly migrate the task and resume testing from the breakpoint, eliminating the need to retry the task from the beginning.

[0013] A second aspect of the present invention also provides an automated testing scheduling system for cloud real machine clusters based on edge computing, comprising: The cloud-based global management module is used to receive high-concurrency automated testing tasks, perform structured parsing, generate standardized task data, and distribute it to the corresponding edge nodes. The edge intelligent scheduling module is used to deploy edge scheduling engines on each edge node of the cloud real machine cluster, pushing scheduling computing power down to the edge side; it collects full-dimensional information of cloud real machine devices within its jurisdiction through the edge scheduling engine, constructs multi-dimensional profiles of the devices, and then dynamically builds and updates the elastic dynamic resource pool of the cloud real machine devices in real time; the edge nodes construct task waiting queues based on task priorities, and perform queue management and resource locking diversion processing according to the task waiting queues; the edge scheduling engine obtains the optimal matching and scheduling of high-concurrency automated test tasks and cloud real machine devices after diversion processing through a multi-constraint weighted intelligent matching algorithm, combined with the device status of the corresponding elastic dynamic resource pool, and forms scheduling instructions; The device status monitoring module is used to monitor the operating status and task execution status of cloud real device in real time, and trigger the fault self-healing mechanism after identifying anomalies, automatically remove faulty devices, and realize task breakpoint resume testing and seamless switching of backup cloud real device devices. The task execution module is used to execute scheduling instructions to achieve automated test scheduling of cloud real machine clusters within the jurisdiction.

[0014] Compared with existing technologies, the beneficial effects of this invention are: by building a layered and collaborative cloud-edge scheduling architecture, core scheduling capabilities are pushed down to the edge side, and the advantages of edge computing are leveraged to break through many limitations of traditional cloud-based centralized scheduling. Through the coordinated efforts of dynamic and refined management of heterogeneous real machine resources, intelligent and orderly scheduling of high-concurrency tasks, pre-lock anti-preemption adaptation mechanism, and full-process fault self-healing system, the invention effectively solves the technical problems of traditional cloud real machine testing scheduling, such as extensive resource management, disordered scheduling, frequent resource conflicts, and weak anomaly handling capabilities. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0016] Figure 1 This is a schematic diagram of an automated test scheduling method for cloud real machine clusters based on edge computing.

[0017] Figure 2 The flowchart for executing queue control and resource locking.

[0018] Figure 3 A flowchart for applying distributed resource locking to a target cloud physical device.

[0019] Figure 4 This is a module diagram of an automated testing and scheduling system for cloud-based real machine clusters based on edge computing. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0021] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] It should be noted that the cloud-based real device device described in this invention is a virtual testing device deployed within a cloud data center, constructed using virtualization technology, and possessing a complete operating system, hardware simulation capabilities, and a real application runtime environment. It is not a physical mobile phone. It can be dynamically generated, destroyed, expanded, and scaled down in the cloud, providing large-scale, high-concurrency, and multi-device compatible virtual device cluster support for automated mobile application testing. This embodiment is based on a typical architecture of a mainstream domestic cloud testing platform, using a typical application scenario of a single cluster with 12 edge nodes, each node deploying 120 cloud-based real devices, totaling 1440 virtual testing devices, to elaborate on the complete implementation process of this invention.

[0023] Example 1: like Figure 1 As shown, an automated test scheduling method for cloud real machine clusters based on edge computing is described, the method comprising: Step S1: Deploy the edge scheduling engine on each edge node of the cloud real machine cluster to push the scheduling computing power down to the edge side; In this embodiment, the cloud real device cluster adopts a cloud-edge collaborative distributed architecture. The entire cluster is divided into 12 edge nodes, each deployed on an independent physical server. The edge scheduling engine is deployed in a containerized manner. Each edge node deploys one master scheduling container and three slave scheduling containers. The master container is responsible for receiving tasks from the cloud, global resource scheduling and status aggregation, while the slave containers are responsible for local device management, task distribution, load balancing and fault detection.

[0024] To elaborate further, the purpose of offloading scheduling computing power is to reduce network latency in centralized cloud scheduling, alleviate cloud computing power bottlenecks, and improve the real-time performance and stability of task scheduling.

[0025] In the traditional cloud-based centralized scheduling model, all task requests, device status, and scheduling decisions need to travel to and from the cloud. Network latency is typically 20–50ms, and in high-concurrency scenarios, cloud computing power utilization can reach over 95%, which can easily lead to problems such as task queuing, scheduling lag, and resource contention conflicts.

[0026] In this embodiment, core capabilities such as scheduling logic, matching algorithms, resource locking, and fault self-healing are decentralized to edge nodes. The cloud is only responsible for task reception, task parsing, global task distribution, edge node status aggregation, and global policy configuration. Edge nodes directly connect to local cloud real devices. Task scheduling latency is reduced to 3–8ms, cloud computing power utilization is controlled within 30%, and edge node computing power utilization is increased to over 85%, adapting to the scheduling needs of tens of thousands of concurrent test tasks. In a real-world application scenario, when a short video application version was iterated, 5,000 automated compatibility test tasks were issued at once. Under the traditional cloud scheduling mode, the average task waiting time was 120 seconds, and the scheduling failure rate was 3.2%. After adopting the edge scheduling scheme of this invention, the average task waiting time was reduced to 15 seconds, the scheduling failure rate was reduced to 0.1%, the scheduling efficiency was improved by 87.5%, and the stability was significantly enhanced.

[0027] Step S2: Collect full-dimensional information of cloud real device devices in the jurisdiction through the edge scheduling engine, build a multi-dimensional profile of the devices, and then dynamically build and update the elastic dynamic resource pool of cloud real device devices in real time. Step S3: The cloud management system receives high-concurrency automated test tasks and completes structured parsing, generates standardized task data and sends it to the corresponding edge nodes. The edge nodes build task waiting queues based on task priorities and perform queue management and resource locking diversion processing according to the task waiting queues. Step S4: The edge scheduling engine uses a multi-constraint weighted intelligent matching algorithm and combines the device status of the corresponding elastic dynamic resource pool to obtain the optimal matching and scheduling of high-concurrency automated test tasks and cloud real machine devices after traffic splitting, and forms scheduling instructions to realize automated test scheduling of cloud real machine clusters within the jurisdiction. Step S5: Edge nodes monitor the operating status and task execution status of cloud real device devices in real time. After identifying anomalies, they trigger the fault self-healing mechanism, automatically remove faulty devices, and realize task breakpoint continuation testing and seamless switching of backup cloud real device devices.

[0028] It should be further explained that, in the specific implementation process, the construction and updating of the elastic dynamic resource pool is as follows: The edge scheduling engine performs a full scan of all connected cloud physical devices within its jurisdiction, obtaining multi-dimensional parameters of the cloud physical devices, including but not limited to device model, system version, hardware performance, operating load, network status, historical test success rate, and device health. Among these parameters, device model includes but is not limited to virtual device model, screen resolution, screen size, screen density, CPU architecture, number of virtual CPU cores, virtual memory size, and virtual storage capacity. In this embodiment, 120 devices were collected, including 18 virtual machine models, 7 resolutions, 5 screen sizes, and 3 CPU architectures. System versions include, but are not limited to, operating system type, system version number, system patch version, pre-installed application list, system permission configuration, and virtualization driver version. In this embodiment, Android virtual devices cover 6 system versions, and iOS virtual devices cover 4 system versions. The system version distribution is as follows: Android 12 30%, Android 13 25%, Android 14 20%, Android 11 15%, Android 10 and below 10%, iOS 16 40%, iOS 17 35%, iOS 15 20%, and iOS 14 5%. Custom adaptation to mainstream mobile application versions is possible. Hardware performance includes, but is not limited to, virtual CPU frequency, CPU utilization, memory utilization, disk I / O read / write speed, disk utilization, GPU rendering performance, and battery virtual parameters. In this embodiment, high-performance virtual devices account for 20%, mid-performance virtual devices account for 50%, and entry-level virtual devices account for 30%, which can meet different performance requirements such as performance testing, stability testing, and compatibility testing. The operational load includes, but is not limited to, the number of currently running test tasks, the number of concurrent tasks, task CPU utilization, task memory utilization, network bandwidth utilization, device idle time, device continuous running time, the time of the last task completion, and the time of the last restart. In this embodiment, under normal load on the edge node, the number of concurrent tasks per device does not exceed 3, CPU utilization does not exceed 70%, memory utilization does not exceed 80%, and network bandwidth utilization does not exceed 50Mbps. When the load is too high, a rate limiting mechanism is automatically triggered. Network status includes, but is not limited to, network type, network bandwidth, network latency, packet loss rate, network stability score, and network operator simulation. In this embodiment, the default configuration is 50Mbps bandwidth, 20ms latency, and 0.1% packet loss rate. Network parameters can be dynamically adjusted according to the test task requirements to adapt to special needs such as weak network testing and high bandwidth scenario testing. Historical test success rate includes the total number of test tasks in the past 7 days, the number of successes, the number of failures, the success rate, the distribution of failure reasons, the commonly used test types, the average execution time of historical tasks, and the average pass rate of historical tasks. In this embodiment, the success rate of high-quality equipment is not less than 99%, the success rate of ordinary equipment is between 95% and 99%, and the success rate of low-quality equipment is less than 95%. Equipment with a success rate of less than 95% is automatically marked as pending maintenance and new task assignments are restricted.Device health includes device runtime, number of restarts, number of failures, number of alarms, virtualization process liveness status, driver running status, resource leakage, number of abnormal log entries, and comprehensive health score. In this embodiment, a health score of 90 or above is considered a healthy device, 70 to 89 is considered a sub-healthy device, and below 70 is considered a faulty device. Sub-healthy devices are restricted from high-load task allocation, and faulty devices are directly removed from the resource pool.

[0029] Based on the collected multi-dimensional parameters, the edge scheduling engine uses a multi-dimensional weighted profiling model to construct a multi-dimensional profile of the device, generating a unique profile ID for each device. The profile data is stored in the local Redis cache on the edge node and a global MySQL database. The Redis cache validity period is set to 5 minutes for fast reading of device profile data, and the MySQL database is used to permanently store the profile data to ensure consistency between the cloud and the edge node device profile data.

[0030] In the process of constructing the profile, the data of each dimension is first standardized and normalized to eliminate the difference in units. Then, weights are assigned to each dimension. After weighted calculation, a comprehensive profile score of the device is generated. The score ranges from 0 to 100 points. The higher the score, the better the device's adaptability and stability.

[0031] After completing the device profiling, the edge scheduling engine categorizes and aggregates cloud-based real-device devices based on multi-dimensional device profiles, dividing them into multiple resource groups, including compatibility testing resource groups, performance testing resource groups, stability testing resource groups, and niche device-specific testing resource groups. The compatibility testing resource group includes 60 devices across all models and system versions; the performance testing resource group includes 25 high-performance devices; the stability testing resource group includes 25 devices with high success rates and high health; and the niche device-specific testing resource group includes 10 devices with less common models and older system versions. This process then constructs elastic dynamic resources. The Elastic Dynamic Resource Pool maintains real-time device status tags, including idle, occupied, faulty, offline, and under maintenance. Edge nodes poll the device status every 30 seconds, updating tags in real time and automatically removing failed cloud physical devices or adding newly connected cloud physical devices. Specifically, devices are marked as idle when no tasks are running and resource utilization is below 50%; marked as occupied when executing test tasks; marked as faulty when device health is below 70% or processes are abnormal; marked as offline when virtualization instances are destroyed or the network is disconnected; and marked as under maintenance when devices are undergoing upgrades or repairs. The Elastic Dynamic Resource Pool has elastic scaling capabilities. When the number of idle devices is less than 10 and the task queuing time exceeds 30 seconds, scaling is automatically triggered, quickly creating new cloud physical device instances through the virtualization layer, with a scaling speed of up to 20 instances per minute. When the number of idle devices exceeds 50 and there are no new tasks for 10 consecutive minutes, scaling is automatically triggered, destroying idle instances, releasing resources, and reducing operating costs. In this embodiment, the initial capacity of the elastic dynamic resource pool is 120 units, which is expanded to 180 units during peak periods and reduced to 80 units during off-peak periods. The resource utilization rate is always maintained above 80%, effectively avoiding resource waste and resource shortage problems.

[0032] In a real-world application scenario, an e-commerce platform launched 3,000 stability test tasks at once before a major promotion. The resource pool was automatically expanded to 200 machines, and all tasks were allocated within 10 minutes. There were no resource shortages or scheduling delays during task execution, and the average task execution time was reduced by 40%, fully meeting the needs of high concurrency and large-scale automated testing.

[0033] It should be further explained that, in the specific implementation process, the structured parsing of the high-concurrency automated testing task is as follows: It should be noted that high-concurrency automated testing tasks can be submitted in various scenarios. Typical scenarios include full compatibility testing for mobile application version iterations, application performance stress testing, long-term stability testing, regression testing, special testing, and batch device adaptation testing. Among these, the number of tasks for full compatibility testing for mobile application version iterations is typically 5,000 to 10,000; the number of tasks for application performance stress testing is 2,000 to 5,000; the number of tasks for long-term stability testing is 1,000 to 3,000 and lasts for 7 to 30 days; the number of tasks for regression testing is 3,000 to 8,000; the number of tasks for special testing is 500 to 2,000; and the number of tasks for batch device adaptation testing is 1,000 to 4,000.

[0034] In this embodiment, a full-scale compatibility test task for version V8.2 of a social application is used as a typical application scenario. The task reception and structured parsing process is described in detail. This batch of tasks consists of 8,000 tasks, including 6,000 Android test tasks and 2,000 iOS test tasks, covering 25 virtual machine types and 10 system versions. The task types include UI compatibility testing, functional compatibility testing, installation and uninstallation testing, startup speed testing, page rendering testing, and multi-resolution adaptation testing. The task priorities are divided into three levels: high, medium, and low. There are 2,000 high-priority tasks, 5,000 medium-priority tasks, and 1,000 low-priority tasks. The estimated total execution time is 12 hours, the concurrency limit is 1,000 tasks per minute, the timeout threshold is 30 minutes, the number of retries for failure is 2, and the resource switching strategy is automatic switching to backup devices.

[0035] The cloud receives 8,000 high-concurrency automated test tasks (no invalid or malicious tasks). First, it performs a task validity check, which includes the completeness of task parameters, the correctness of parameter format, the validity of machine type and system version, the validity of priority, the reasonableness of concurrency limit, the reasonableness of timeout threshold, the validity of retry count, user permission verification, task quota verification, and security verification. Tasks that fail the verification are directly returned with error information and discarded. The high-concurrency automated test tasks that pass the verification are then subjected to structured parsing, including the extraction of hardware constraints, task attribute constraints, and execution constraints. The hardware constraint parsing includes, but is not limited to, compatible device models, system versions, screen resolutions, hardware performance thresholds, network types, network bandwidth, screen sizes, and CPU architectures; the task attribute constraint parsing includes, but is not limited to, task priority, estimated execution time, maximum concurrency, timeout threshold, task type, task tag, task grouping, task creation time, task deadline, user ID, project ID, and unique task identifier; the execution constraint parsing includes, but is not limited to, test case paths, test framework types, breakpoint saving rules, number of retry attempts, resource switching strategies, test report output formats, log collection levels, device handling after task completion, and abnormal alarm reception methods. After structured parsing is completed, the cloud integrates hardware constraints, task attribute constraints, and execution constraints into standardized task data. The standardized data format is JSON, which includes six top-level fields: unique task ID, hardware constraints, task attributes, execution constraints, timestamp, and checksum. The size of a single task data entry is approximately 2KB, and the total data volume of 8,000 tasks is approximately 16MB, facilitating rapid transmission, storage, and parsing.

[0036] It should be noted that after the standardized task data is generated, the cloud uses a weighted round-robin load balancing strategy to distribute the tasks to the corresponding edge nodes. The weighting factors include the number of idle devices on the edge nodes, node load rate, network latency, historical task success rate, and geographical distance. Priority is given to distributing tasks to edge nodes with more idle devices, lower load rate, lower latency, higher success rate, and closer distance, so as to avoid node overload caused by concentrated task distribution.

[0037] In this embodiment, 8,000 tasks are distributed to 12 edge nodes according to the edge node load balancing strategy. 800 tasks are allocated to each of the 4 edge nodes with more idle devices, 700 tasks are allocated to each of the 6 edge nodes with medium load, and 400 tasks are allocated to each of the 2 edge nodes with high load. The task distribution process adopts breakpoint resumption, AES-256 encrypted transmission, and MD5 data verification to ensure data integrity, security, and accuracy. The total distribution time does not exceed 5 minutes, with no data loss and no transmission errors.

[0038] After receiving standardized task data from the cloud, the edge node first performs data verification and format conversion. The verification includes data integrity, verification code correctness, and format legality. After the verification is successful, the JSON format data is converted into an internal data format that the edge scheduling engine can directly call. A task waiting queue is built based on task priority. The queue adopts a hierarchical partitioned priority queue architecture, which is divided into three layers: high, medium, and low. Within each layer, tasks are sorted according to their submission time. High-priority queues are scheduled, allocated resources, and executed first, followed by medium-priority queues, and low-priority queues are scheduled last, ensuring that urgent tasks are executed first and are not blocked.

[0039] In this embodiment, each edge node constructs three independent queues: a high-priority queue, a medium-priority queue, and a low-priority queue. 8,000 tasks are stored in the corresponding queues, with 2,000 tasks in the high-priority queue, 5,000 tasks in the medium-priority queue, and 1,000 tasks in the low-priority queue. The queues are implemented using Redis sorted sets, supporting millisecond-level enqueue, dequeue, sorting, and search operations. The queue capacity is unlimited, supports dynamic expansion, and queue data is persistently stored. The queue state is automatically restored after the edge node restarts to avoid task loss.

[0040] like Figure 2 As shown, it should be further explained that, in the specific implementation process, the specific process of performing queue management and resource locking based on the task waiting queue is as follows: The test tasks in the task waiting queue are managed in a hierarchical and partitioned manner, and long-term test tasks, short-term lightweight tasks, and retry failed tasks are isolated in the queue. At the same time, queue throttling control is performed based on the computing power threshold of edge nodes and the device load status.

[0041] In this embodiment, during queue isolation, tasks are categorized into three types based on their estimated execution time and execution status: long-duration test tasks, short-duration lightweight tasks, and retry-failure tasks. Long-duration test tasks are those with an estimated execution time exceeding 15 minutes, such as stability testing tasks and stress testing tasks. Short-duration lightweight tasks are those with an estimated execution time of no more than 15 minutes, such as compatibility testing tasks and functional testing tasks. Retry-failure tasks are those that fail and are resubmitted for retry. These three types of tasks are stored in independent sub-queues, ensuring they do not interfere with each other and are scheduled independently. This prevents long-duration tasks from consuming resources and causing short-duration tasks to queue for extended periods, and prevents retry-failure tasks from repeatedly consuming device resources and affecting the execution of new tasks. In this embodiment, all 8000 tasks are short-duration lightweight tasks and are stored in the short-duration task sub-queue. The long-duration task sub-queue and the retry-failure task sub-queue are temporarily empty.

[0042] In this embodiment, during queue throttling control, the edge scheduling engine monitors the edge node computing power threshold, device load status, and queue backlog in real time. The computing power threshold is set to ensure that the total CPU utilization of the edge node does not exceed 80%, the total memory utilization does not exceed 85%, and the total network bandwidth utilization does not exceed 80%. The device load status monitoring shows that the CPU utilization of a single device does not exceed 70%, the memory utilization does not exceed 80%, and the number of concurrent tasks does not exceed 3. The queue backlog threshold is set when the number of queued tasks exceeds twice the number of idle devices on the edge node and the average waiting time of tasks exceeds 30 seconds. When any throttling condition is triggered, the edge scheduling engine automatically throttles low-priority tasks at the tail of the queue, suspends dequeueing, delays scheduling, and prioritizes the execution of high-priority and urgent tasks. Normal scheduling resumes after the node load decreases, resources are released, and the queue backlog is relieved. In this embodiment, during peak task periods, the edge node's CPU utilization reaches a maximum of 75%, memory utilization reaches a maximum of 80%, and the queue backlog is up to 1.5 times the number of idle devices. The throttling threshold is not triggered, and normal scheduling occurs throughout. If the number of tasks surges later, for example, if the number of tasks in a single node's queue reaches 300 and there are only 100 idle devices, the backlog threshold is triggered, and low-priority tasks at the tail are automatically throttled to ensure that high-priority tasks are executed first.

[0043] In this embodiment, the edge scheduling engine scans the idle resource status and concurrent load of the elastic dynamic resource pool in real time, and retrieves tasks to be executed in an orderly manner from the head of the task waiting queue based on the carrying capacity of the cloud real device.

[0044] In this embodiment, during dequeueing, the edge scheduling engine obtains real-time data on the number of idle devices in the elastic dynamic resource pool, device concurrent load, device health, and device task suitability. Following the principles of high priority, submission time, and suitability, tasks are sequentially retrieved from the head of the task waiting queue. The dequeueing process employs multi-threaded parallel processing technology, with a single edge node supporting 50 tasks per second, and a total dequeueing capacity of 600 tasks per second for 12 edge nodes, fully meeting the concurrent limit of 1000 tasks per minute. In this embodiment, 8000 tasks are dequeued in order of priority: 2000 high-priority tasks are dequeued first, followed by 5000 medium-priority tasks, and finally 1000 low-priority tasks. The total dequeueing time does not exceed 2 minutes, with no out-of-order processing, no queue jumping, and no omissions.

[0045] like Figure 3 As shown, it is necessary to further explain that the specific process of applying distributed resource locking to the target cloud physical device during implementation is as follows: In this embodiment, when a task is successfully matched and ready for execution, a distributed resource lock is applied to the target cloud device, marking it as occupied. This prevents the target cloud device from being preempted by other test tasks in the same task waiting queue or other task waiting queues during task execution. The resource lock uses a Redis-based distributed lock mechanism. The lock granularity is a single cloud device, the lock's unique identifier is the device ID, the lock ownership identifier is the current task's global transaction number, and the lock's validity period is the estimated task execution time plus 5 minutes, preventing permanent lock occupancy due to abnormal task interruption. The distributed lock is deployed on the local Redis cluster of the edge node, supporting millisecond-level lock operations, high-concurrency lock preemption, and real-time lock state synchronization, avoiding latency and data inconsistency issues caused by cross-node lock operations.

[0046] In this embodiment, during the execution of distributed resource locking, the edge scheduling engine first selects a set of candidate cloud real device devices that are idle, healthy, and highly adaptable from the elastic dynamic resource pool. The number of candidate devices is no less than 1.5 times the number of tasks to be matched, and redundant devices are reserved to improve the matching success rate. Then, a batch distributed lock pre-emption operation is initiated on the candidate devices, using the unique device ID of the cloud real device as the lock key, the global transaction number of the test task to be assigned as the lock value, and the lock validity period as 15 minutes. Redis locking is executed, and locking is successful only if the lock key does not exist, and fails if the lock key already exists. For the cloud real device devices that have been successfully locked, the optimal adaptation and matching between the test task and the locked cloud real device is completed through a multi-constraint weighted intelligent matching algorithm. If a cloud-based physical device fails to preempt the lock, it will be removed from the candidate list and will no longer participate in the multi-constraint weighted intelligent matching algorithm matching in this round.

[0047] In this embodiment, during lock conflict and exception handling, if a lock conflict occurs during lock preemption, Redis locks the device to ensure that only one task successfully acquires the lock while other tasks fail directly, preventing deadlocks and resource contention. If the lock is about to expire during task execution, the edge scheduling engine automatically performs a lock renewal operation, extending the lock's validity by 5 minutes to prevent the lock from being accidentally released or the device from being preempted during normal task execution. If the task is abnormally interrupted, the lock is automatically released after timeout, the device returns to an idle state, and can rejoin scheduling, avoiding permanent resource occupation. If the task is completed normally, the edge scheduling engine actively releases the lock, updates the device state to idle, and releases resources for subsequent tasks.

[0048] In this embodiment, the backlog of tasks on the current edge nodes and the overall load of the cloud real device are monitored in real time. When an abnormality occurs in the queue, the tasks waiting at the tail of the task waiting queue are automatically intelligently distributed to other edge nodes in the cloud real device cluster that are under low load and idle, thereby dynamically adjusting the dequeueing rhythm of the task waiting queue. Intelligent task offloading is triggered by conditions such as excessive queue backlog, full device resource load, high node load, or task execution delay. The target node for offloading prioritizes edge nodes with low load rates. During offloading execution, low-priority, long-duration, and poorly adaptable tasks are selected from the tail of the queue. Offloading task data is batch-packaged and transmitted to the target edge node via an encrypted high-speed channel, supporting breakpoint resumption, data verification, and transmission retries. Upon receiving the offloading task, the target edge node automatically verifies the data, parses the task, adds it to its local task waiting queue, and executes it according to local scheduling rules. Simultaneously, the dequeueing rhythm of the source and target nodes is dynamically adjusted. The source node reduces its dequeueing rate to prioritize high-priority tasks, while the target node increases its dequeueing rate to quickly process offloading tasks and release resources, achieving cluster-level load balancing and optimal resource utilization.

[0049] In this embodiment, during peak task periods, two edge nodes experience a concentrated distribution of tasks, resulting in a device occupancy rate of 98%, only three idle devices, and a queue backlog that is four times the number of idle devices. This triggers intelligent task routing, selecting 1,000 low-priority tasks from the tail of the queue and evenly distributing them to four low-load edge nodes within the cluster. The total routing time does not exceed three minutes. The routed tasks are executed quickly on the target nodes, the load on the source nodes drops rapidly, and the normal scheduling rhythm is restored. The overall cluster load is balanced, and the scheduling is stable. The average task waiting time is reduced from 45 seconds to 12 seconds, significantly improving scheduling efficiency.

[0050] It should be further explained that, in specific implementation, the execution process of the multi-constraint weighted intelligent matching algorithm is as follows: The edge scheduling engine retrieves idle cloud real device data and test task parameters from the elastic dynamic resource pool, sets weighting factors, and calculates device-task matching degree to obtain the optimal adaptive scheduling. The weighting factors include device model compatibility weighting factor, device health weighting factor, resource idleness weighting factor, and task timeliness weighting factor. It should be noted that the device-task matching degree is obtained by weighted summation of device model compatibility, device health, resource idleness, and task timeliness, along with their corresponding weighting factors. Specifically, device model compatibility determines whether the device model matches the task's hardware constraints: 100 points for a complete match, 80 points for a compatible match, 50 points for a partial match, and 0 points for a non-match. Device health directly uses the device profile's health score. Resource idleness is scored based on device idle time, concurrent task count, and resource utilization. Task timeliness is scored based on task priority, estimated execution time, and deadline.

[0051] The optimally adapted and scheduled cloud-based physical devices are used as the optimal execution carriers for tasks, thereby achieving optimal adaptation and scheduling operations. For test tasks that are not matched with cloud real devices, they are kept in the task waiting queue and will be matched again after resources are released.

[0052] It should be further explained that, in the specific implementation process, the fault self-healing mechanism operates as follows: Edge nodes leverage their proximity to monitor the operational and task execution status of cloud-based physical devices in real time. If a device malfunction is detected, it is temporarily removed from the elastic dynamic resource pool, marked as pending repair, and prohibited from being assigned new tasks. If a test task is abnormally interrupted, the current execution breakpoint, test logs, and runtime data are automatically saved. The system then retrieves suitable backup cloud-based physical devices from the elastic dynamic resource pool, seamlessly migrating the task and resuming testing without requiring retrying. Device operational status includes, but is not limited to, device online status, virtualization process liveness, CPU utilization, memory utilization, disk I / O, network status, health, alarm information, resource leaks, temperature, and battery virtual parameters. Monitoring is performed once per second, with monitoring data uploaded in real-time to the edge scheduling engine and the cloud-based global management module. This enables global status synchronization and real-time anomaly detection. When a device status becomes abnormal, a device fault alarm is immediately triggered, and alarm information is pushed to the edge scheduling engine and the cloud-based global management module.

[0053] Task execution status includes, but is not limited to, task running status, execution progress, number of executed test cases, number of remaining test cases, execution duration, CPU utilization, memory utilization, log output, error messages, alarm messages, and breakpoint save status. The monitoring frequency is once per second, monitoring data is uploaded in real time, and task abnormality alarms are triggered immediately when an anomaly occurs, and alarm messages are pushed. Abnormal task status includes execution timeout, test case failure rate exceeding 30%, process crash, network disconnection, and abnormal interruption.

[0054] In this embodiment, during the execution of 8,000 tasks, there were 0 device monitoring alarms and 12 task monitoring alarms, all of which were temporary network fluctuations that recovered automatically. There were no serious equipment failures or serious task anomalies, and the monitoring system was stable and reliable, with timely and accurate anomaly detection.

[0055] In this embodiment, when the fault self-healing mechanism is executed, the device fault handling process is as follows: after a device fault is detected, the faulty device is immediately removed from the elastic dynamic resource pool, marked as a fault pending repair state, prohibited from new task allocation, and prohibited from participating in subsequent scheduling; the distributed lock on the faulty device is forcibly released, resource occupation is released, and lock permanent occupation is avoided; the test task being executed on the faulty device is terminated and marked as an abnormal interruption; the faulty device repair process is automatically triggered, the virtualization instance is attempted to restart, the driver is repaired, the initial environment is restored, the repair time does not exceed 5 minutes, and after successful repair, the device is re-added to the resource pool and marked as idle; if the repair fails, it is marked as a permanent fault, the instance is destroyed, physical resources are released, and it is no longer reused.

[0056] In this embodiment, the task anomaly self-healing process is as follows: After an abnormal task interruption is detected, the current task execution breakpoint is automatically fixed, including a list of executed test cases, execution progress, test logs, running data, intermediate results, screenshots, screen recordings, encrypted storage of breakpoint data, associated task ID, validity period of 7 days, ensuring the breakpoint is complete and recoverable; a backup cloud real device of the same type, configuration, idle, healthy, and highly adaptable is retrieved from the elastic dynamic resource pool, with the number of backup devices not less than 1.2 times the number of abnormal tasks, ensuring sufficient backup; the fixed breakpoint data, test cases, execution parameters, and configuration information are automatically migrated to the backup device, the migration process is encrypted, verified, and resumes from the breakpoint, the migration time does not exceed 2 minutes; after receiving the migration data, the backup device continues to execute the test task from the fixed breakpoint, without retrying from the beginning, without re-executing completed test cases, saving test time, avoiding repetitive work, and ensuring the continuity of test results; after the migration is completed, the task status is updated to running, the device status is updated to occupied, and a self-healing completion notification is sent to the cloud management module and the user console, informing them that the task has automatically recovered and is executing normally.

[0057] In this embodiment, during the execution of 8,000 tasks, 3 devices experienced temporary failures and 12 tasks were abnormally interrupted. The fault self-healing mechanism was automatically triggered, all 3 faulty devices were successfully restarted and repaired, and the tasks were re-added to the resource pool. All 12 abnormally interrupted tasks had their breakpoints fixed, were migrated to backup devices, and the breakpoints were successfully resumed. There was no task loss, no data loss, no need for manual intervention, a 100% self-healing success rate, and an average self-healing time of no more than 3 minutes, which greatly improved the stability and reliability of the test tasks.

[0058] Example 2: like Figure 4As shown, the cloud real machine cluster automated test scheduling system based on edge computing includes: The cloud-based global management module is used to receive high-concurrency automated testing tasks, perform structured parsing, generate standardized task data, and distribute it to the corresponding edge nodes. The edge intelligent scheduling module is used to deploy edge scheduling engines on each edge node of the cloud real machine cluster, pushing scheduling computing power down to the edge side; it collects full-dimensional information of cloud real machine devices within its jurisdiction through the edge scheduling engine, constructs multi-dimensional profiles of the devices, and then dynamically builds and updates the elastic dynamic resource pool of the cloud real machine devices in real time; the edge nodes construct task waiting queues based on task priorities, and perform queue management and resource locking diversion processing according to the task waiting queues; the edge scheduling engine obtains the optimal matching and scheduling of high-concurrency automated test tasks and cloud real machine devices after diversion processing through a multi-constraint weighted intelligent matching algorithm, combined with the device status of the corresponding elastic dynamic resource pool, and forms scheduling instructions; The device status monitoring module is used to monitor the operating status and task execution status of cloud real device in real time, and trigger the fault self-healing mechanism after identifying anomalies, automatically remove faulty devices, and realize task breakpoint resume testing and seamless switching of backup cloud real device devices. The task execution module is used to execute scheduling instructions to achieve automated testing scheduling of the cloud real machine cluster within the jurisdiction. Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0059] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0060] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more electronic devices to execute all or part of the steps of the methods described in the various embodiments of this application.

[0061] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0062] In the several embodiments provided in this application, it should be understood that the disclosed application can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0063] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0064] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0065] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. An automated test scheduling method for cloud real machine clusters based on edge computing, characterized in that, The method includes: Deploy edge scheduling engines on each edge node of the cloud real machine cluster to push scheduling computing power down to the edge side; By collecting full-dimensional information on cloud real device devices within the jurisdiction through the edge scheduling engine, a multi-dimensional profile of the devices is constructed, and then an elastic dynamic resource pool of cloud real device devices is dynamically constructed and updated in real time. The cloud-based management system receives high-concurrency automated test tasks and performs structured parsing, generates standardized task data, and distributes it to the corresponding edge nodes. The edge nodes construct task waiting queues based on task priorities and perform queue management and resource locking based on the task waiting queues. The edge scheduling engine uses a multi-constraint weighted intelligent matching algorithm, combined with the device status of the corresponding elastic dynamic resource pool, to obtain the optimal matching and scheduling of high-concurrency automated test tasks and cloud real machine devices after traffic splitting, and generates scheduling instructions to realize automated test scheduling of cloud real machine clusters within the jurisdiction. Edge nodes monitor the real-time operating status and task execution status of cloud real devices. Upon identifying anomalies, they trigger a fault self-healing mechanism, automatically removing faulty devices and enabling task breakpoint continuation testing as well as seamless switching to backup cloud real devices.

2. The automated test scheduling method for cloud real machine clusters based on edge computing according to claim 1, characterized in that, The process of building and updating the elastic dynamic resource pool is as follows: The edge scheduling engine performs a full scan of all connected cloud real device devices within its jurisdiction to obtain multi-dimensional parameters of the cloud real device devices and build a multi-dimensional profile of the devices. Based on multi-dimensional device profiles, cloud-based real-device devices are categorized and aggregated into multiple resource groups, thereby constructing an elastic and dynamic resource pool. Edge nodes poll the status of all devices at a preset polling period, update the status tags of cloud real devices in the elastic dynamic resource pool in real time, and automatically remove failed cloud real devices or add newly connected cloud real devices.

3. The automated test scheduling method for cloud real machine clusters based on edge computing according to claim 2, characterized in that, The structured parsing process of the high-concurrency automated testing task is as follows: Receive high-concurrency automated test tasks, perform structured parsing of the high-concurrency automated test tasks, including extracting hardware constraints, task attribute constraints, and execution constraints; Based on the hardware constraints, task attribute constraints, and execution constraints, standardized task data is generated and distributed to the corresponding edge nodes. The corresponding edge nodes then construct task waiting queues based on task priorities.

4. The automated test scheduling method for cloud real machine clusters based on edge computing according to claim 3, characterized in that, The process of streamlining and resource locking based on the task waiting queue is as follows: The test tasks in the task waiting queue are managed in a hierarchical and partitioned manner, and long-term test tasks, short-term lightweight tasks, and retry failed tasks are isolated in the queue. At the same time, queue throttling control is performed based on the edge node computing power threshold and device load status. The edge scheduling engine scans the idle resource status and concurrent load of the elastic dynamic resource pool in real time, and retrieves tasks to be executed in an orderly manner from the head of the task waiting queue based on the carrying capacity of the cloud real device. When a task is successfully matched and ready to be executed, a distributed resource lock is applied to the target cloud real device, marking the target cloud real device as occupied, and restricting the target cloud real device from being preempted by other test tasks in the same task waiting queue or test tasks in other task waiting queues during task execution; Real-time monitoring of the current task backlog at edge nodes and the overall load of cloud real device equipment. When an abnormality occurs in the queue, the system automatically performs intelligent diversion of the tasks waiting at the tail of the task waiting queue, and distributes the excess test tasks evenly to other edge nodes in the cloud real device cluster that are under low load and in idle state, thereby dynamically adjusting the dequeueing rhythm of the task waiting queue.

5. The automated test scheduling method for cloud real machine clusters based on edge computing according to claim 4, characterized in that, The process of applying distributed resource locking to the target cloud physical device is as follows: A distributed lock mechanism is introduced to lock the state of cloud real machine resources that have been allocated test tasks, preventing multiple test tasks from competing for the same device resources; The edge scheduling engine first selects a set of idle candidate cloud real machine devices from the elastic dynamic resource pool, and prioritizes the batch initiation of distributed lock preemption operations on the candidate cloud real machine devices; the unique device ID of the cloud real machine device is used as the lock, and the global transaction number of the currently assigned test task is used as the lock ownership identifier, and the pre-lock preemption is realized based on the edge node distributed memory mechanism; If the cloud physical device is successfully locked, the cloud physical device will be temporarily locked and marked as pending scheduling and occupation. The device that successfully acquired the lock will be included in the set of matchable resources. For cloud-based real device devices that have been successfully locked, the optimal matching between the test task and the locked cloud-based real device is achieved through a multi-constraint weighted intelligent matching algorithm. If a cloud-based physical device fails to preempt the lock, it will be removed from the candidate list and will no longer participate in the multi-constraint weighted intelligent matching algorithm matching in this round.

6. The automated test scheduling method for cloud real machine clusters based on edge computing according to claim 5, characterized in that, The execution process of the multi-constraint weighted intelligent matching algorithm is as follows: The edge scheduling engine retrieves data of idle cloud real devices and parameters of test tasks to be scheduled from the elastic dynamic resource pool, sets weighting factors and calculates the device task matching degree, thereby obtaining the optimal adaptive scheduling. By using the optimally adapted and scheduled cloud-based physical devices as the optimal execution carriers for tasks, optimal adaptation and scheduling operations can be achieved. For test tasks that are not matched with cloud real devices, they are kept in the task waiting queue and will be matched again after resources are released.

7. The automated test scheduling method for cloud real machine clusters based on edge computing according to claim 6, characterized in that, The fault self-healing mechanism's processing procedure is as follows: Edge nodes leverage their proximity to collect data to monitor the operational status and task execution status of cloud-based real-world devices in real time. If a device malfunction is detected, it is temporarily removed from the elastic dynamic resource pool, marked as faulty and awaiting repair, and new task assignment is prohibited. If a test task is abnormally interrupted, the current execution breakpoint, test logs, and runtime data are automatically saved. The appropriate cloud-based real-world devices within the elastic dynamic resource pool are retrieved to seamlessly migrate the task and resume testing from the breakpoint, eliminating the need to retry the task from the beginning.

8. An automated testing scheduling system for cloud real machine clusters based on edge computing, implementing the automated testing scheduling method for cloud real machine clusters based on edge computing as described in any one of claims 1 to 7, characterized in that, include: The cloud-based global management module is used to receive high-concurrency automated testing tasks, perform structured parsing, generate standardized task data, and distribute it to the corresponding edge nodes. The edge intelligent scheduling module is used to deploy the edge scheduling engine on each edge node of the cloud real machine cluster, and to push the scheduling computing power down to the edge side. By collecting full-dimensional information on cloud real device devices within the jurisdiction through the edge scheduling engine, a multi-dimensional profile of the devices is constructed, and then an elastic dynamic resource pool of cloud real device devices is dynamically constructed and updated in real time. Edge nodes construct task waiting queues based on task priorities, and perform queue management and resource locking diversion processing according to the task waiting queues; The edge scheduling engine uses a multi-constraint weighted intelligent matching algorithm, combined with the device status of the corresponding elastic dynamic resource pool, to obtain the optimal adaptation and scheduling of high-concurrency automated test tasks and cloud real device after traffic splitting, and forms scheduling instructions. The device status monitoring module is used to monitor the operating status and task execution status of cloud real device in real time, and trigger the fault self-healing mechanism after identifying anomalies, automatically remove faulty devices, and realize task breakpoint resume testing and seamless switching of backup cloud real device devices. The task execution module is used to execute scheduling instructions to achieve automated test scheduling of cloud real machine clusters within the jurisdiction.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images