Method for long-time running composite scene automatic test based on analog chaotic cloud server

Abstract

This application discloses an automated testing method and system for long-term operation of cloud servers in a complex scenario based on simulated chaotic states. The method includes: configuration loading and rule parsing, establishing a state-operation mapping and dynamic decision rule base; real-time acquisition and pre-verification of virtual machine status, filtering a set of legal operations; OpenAPI client initialization and authentication; intelligent random composite operation execution, realizing a closed loop of "state query → pre-verification → action decision → secure execution → result feedback"; long-term cyclic testing and result aggregation, supporting batch concurrent / serial scheduling and fault tolerance. This invention, through JSON configuration-driven, state mutual exclusion verification, random composite decision-making, and long-term cyclic execution, accurately simulates the real-world usage behavior of customers on existing virtual machines, solving the problems of scenario distortion and inability to conduct long-term testing in existing technologies. It possesses advantages such as high simulation, high stability, and high reusability, significantly improving the effectiveness and coverage of cloud platform virtual machine testing.

Description

Technical Field

[0001] This application relates to the field of automated testing of cloud platforms, and in particular to an automated testing method, system, computer-readable storage medium, and electronic device based on a long-term operation of a cloud server in a simulated chaotic state. Background Technology

[0002] With the widespread adoption of cloud computing and virtualization technologies, automated testing of Elastic Compute Service / Virtual Machines (ECS / VMs) has become a core means of quality assurance. Existing technologies primarily rely on fixed-process scripts, Application Programming Interface (API) calls, and scheduled tasks for functional verification, regression testing, and stress testing. They generally employ preset steps, fixed sequences, and single-operation serial execution modes, automating basic operations such as power-on, power-off, restart, migration, and configuration changes. However, when dealing with scenarios involving long-term operation of existing virtual machines, simulation of real-world customer behavior, and high stability and compatibility verification, existing technologies have the following shortcomings:

[0003] 1. Rigid operational logic, severely disconnected from real customer behavior: Existing automated tests all use hard-coded scripts with fixed sequences, operations, and processes. The operation paths and execution sequences are completely preset, failing to simulate users' real-world usage habits that are on-demand, random, complex, and unpredictable. The test scenarios are highly "artificial," differing significantly from the long-term complex operational behavior of existing virtual machines in the production environment, leading to distorted test conclusions and difficulty in exposing real operational risks.

[0004] 2. Lack of state mutual exclusion and pre-emptive security checks, easily leading to illegal operations: Existing solutions generally do not perceive the real-time status of virtual machines and do not perform multi-dimensional state checks such as running state, locked state, high availability (HA) state, and monitoring state, directly issuing operation commands. Illegal operations such as "repeatedly powering on while running," "performing recovery while stopped," and "forcibly migrating from a locked state" often occur, causing interface errors, task blocking, or even virtual machine anomalies, resulting in poor stability and security.

[0005] 3. Does not support continuous testing of long-term, random, and complex operations: Existing automation is mainly based on short cycles, single operations, and single executions, lacking loop control, interval control, batch scheduling, and random decision-making capabilities. It cannot support long-term aging and stability testing of several hours or even days, and it is difficult to reproduce hidden problems such as memory leaks, resource contention, state drift, and occasional anomalies caused by long-term complex operations in the production environment.

[0006] 4. Strong coupling between configuration and logic, resulting in poor scalability and reusability: Operation rules, state mappings, mutual exclusion conditions, virtual machine lists, etc., are mostly hard-coded in the scripts. Modifications require code changes and recompilation and deployment. Dynamic loading of configuration files is not supported, leading to high costs for cross-platform, cross-version, and cross-scenario adaptation, and making it difficult to quickly adapt to different cloud platform open APIs and differentiated testing needs.

[0007] 5. Lack of unified scheduling and standardized result loop for batch virtual machines: Existing technologies mostly use a single virtual machine as the operating unit, lacking batch concurrent / serial scheduling capabilities. Parallel testing of multiple virtual machines is prone to resource contention and execution conflicts. Furthermore, the lack of a unified mechanism for status acquisition, operation logs, result judgment, and anomaly tracking leads to high costs for problem localization, untraceable test data, and an inability to support large-scale batch automated testing.

[0008] 6. Lack of fault tolerance mechanism, easy to interrupt and exit during long-term testing: In abnormal scenarios such as operation failure, abnormal status, interface timeout, network jitter, etc., the existing system has no retry, skip, alarm and degradation mechanism, which can easily lead to the interruption of the entire test process and cannot meet the reliability requirements of 7×24 hours uninterrupted long-term stable testing.

[0009] 7. Primarily focused on newly created resources, with weak reuse capabilities for existing virtual machines: Most testing frameworks primarily create entirely new virtual machines for testing, resulting in insufficient support for existing, aging, and long-term running virtual machines on the platform. This leads to low resource utilization, high testing costs, and an inability to complete critical scenario verifications such as compatibility and long-term stability of existing instances.

[0010] In summary, existing technologies cannot meet the large-scale, highly realistic, and long-cycle testing requirements of cloud platforms. There is an urgent need for an automated testing solution that can simulate real customer behavior, has a complete state verification and fault tolerance mechanism, and supports long-term continuous testing. Summary of the Invention

[0011] To address the aforementioned issues, this application proposes a novel automated testing method and system for long-term, complex scenarios of cloud server operation based on simulated chaotic states. More specifically, this invention provides a long-term, randomized, complex automated testing method for cloud server virtual machines based on state mutual exclusion rules and JSON configuration-driven approaches. Through dynamic state awareness, operational security verification, randomized complex decision-making, long-term cyclic execution, and batch unified scheduling, it accurately simulates long-term real-world customer operations on existing virtual machines. This solves the pain points of existing technologies, such as scenario distortion, poor security, weak scalability, insufficient stability, and inability to conduct long-term simulation testing, significantly improving the realism, effectiveness, and coverage of cloud platform virtual machine testing.

[0012] To achieve the above objectives, the present invention employs the following technical strategies:

[0013] (1) State-driven action mutual exclusion verification technology: Based on the JSON configuration file, a mapping library, mutual exclusion rule library and precondition library of virtual machine state and operation are built. The state-action mapping and mutual exclusion verification are driven by the JSON configuration. The virtual machine running status, locked status, HA status and monitoring status are obtained in real time. The legal operation is dynamically filtered, and the operation is automatically judged to allow / prohibit. Illegal operation and state conflict are avoided. It also supports random compounding and long-term loop execution to simulate real user behavior and realize the safe and compliant execution of virtual machine operation throughout the entire life cycle.

[0014] (2) Dynamic rule-driven technology for decoupling configuration and logic: Using external JSON configuration to uniformly manage virtual machine information, operation permissions, status rules, mutual exclusion relationships, and preconditions, test strategies can be dynamically updated, operation types can be expanded, and different cloud platforms can be adapted without modifying the code, thus achieving complete decoupling of test logic and configuration data.

[0015] (3) Long-term random composite operation automated execution technology: It supports random selection of operations based on the legal operation pool, cyclic execution, and interval control to simulate the real operation behavior of customers on existing virtual machines for a long time, in a non-directional and composite manner. It can support 7×24 hours of uninterrupted stability testing and realize long-term high-simulation stability testing.

[0016] (4) Modular layered encapsulation unified scheduling technology: configuration management, OpenAPI communication, virtual machine operation, automation logic and main program entry are layered and decoupled and encapsulated to provide a unified standardized interface and support unified scheduling, secure execution, result collection and fault tolerance for single / batch virtual machines.

[0017] (5) Full-process closed-loop automated testing technology: forming a complete closed loop of "status query → pre-verification → action decision → safe execution → result feedback → status tracking". Each step has verification, recording and fault tolerance to ensure that the testing process is stable, reproducible and traceable.

[0018] Specifically, the present invention provides the following technical solutions:

[0019] The first aspect of this invention provides an automated testing method for long-term operation of a cloud server in a complex scenario based on simulated chaotic states, such as... Figure 1 As shown, the method includes the following steps:

[0020] S1. Configuration Loading and Rule Parsing: Load the JSON configuration file, parse it to obtain the list of virtual machines, the mapping relationship between virtual machine status and operation, operation mutual exclusion rules, action preconditions and default execution parameters, establish a three-layer mapping relationship of status-allowed operation, status-prohibited operation, and action-preconditions, and form a dynamic decision rule base.

[0021] S2. Real-time acquisition and pre-verification of virtual machine status: Real-time query of virtual machine running status, locked status, high availability status and monitoring status, and perform mutual exclusion rule verification and pre-condition judgment based on the dynamic decision rule base to filter the set of legal and executable operations under the current status.

[0022] S3. OpenAPI Client Initialization and Authentication: Create an HTTP communication client, complete the cloud platform OpenAPI signature authentication, key loading, domain name and interface address configuration, and establish an API call channel;

[0023] S4. Intelligent random composite operation execution: Based on the legally executable operation set, a dynamic operation pool is generated. The target operation is selected using a random decision mode or a specified operation mode. The corresponding operation function is called to complete the API request sending and response parsing, realizing the whole process closed loop of "status query → pre-verification → action decision → safe execution → result feedback". The standardized data containing virtual machine ID, pre-execution status, execution action, execution result and final status is returned.

[0024] S5. Long-term loop testing and result summary: The test is executed based on the preset number of loops or the infinite loop mode. It supports setting the operation interval and performs concurrent or serial scheduling of batch virtual machines. After each round of operation, the virtual machine ID, the state before and after execution, the execution action and result information are recorded to form a complete test link log. Fault tolerance processing is performed in the case of operation failure, abnormal state or interface timeout to ensure the continuous operation of the test process.

[0025] Furthermore, in the method of this application, the JSON configuration file mentioned in step S1 includes:

[0026] Virtual machine information configuration, including virtual machine ID and region identifier;

[0027] State operation mapping configuration defines the set of operations that are allowed to be executed in each state;

[0028] Mutual exclusion rule configuration defines the prohibition relationship between states and operations;

[0029] Precondition configuration defines the state conditions that each operation must meet.

[0030] Execution parameter configuration, including loop count, operation interval and scheduling strategy.

[0031] Furthermore, in the method of this application, step S1 also includes: reading the loop count, operation interval, target virtual machine list, and concurrent / serial execution strategy to complete the test environment initialization.

[0032] Furthermore, in the method of this application, the real-time query in step S2 includes: calling the status query interface to obtain the virtual machine running status, calling the lock status query interface to obtain the virtual machine lock status, calling the high availability status query interface to obtain the virtual machine high availability status, and calling the monitoring status query interface to obtain the virtual machine monitoring installation status.

[0033] The mutual exclusion rule verification mentioned above is implemented through ecs_config.is_action_allowed();

[0034] The aforementioned precondition judgment is implemented through get_pre_condition_for_action().

[0035] Furthermore, in the method of this application, step S3 also includes: pre-verifying the availability of the core interfaces for virtual machine query, status acquisition, operation execution, and result callback; and configuring an exception handling mechanism for interface timeout threshold, maximum number of retries, and failure degradation strategy.

[0036] Furthermore, in the method of this application, the random decision-making mode in step S4 includes: randomly selecting an operation from the dynamic operation pool based on the current real-time state of the virtual machine to simulate the user's real usage behavior at irregular intervals and without direction; the specified operation mode includes: forcibly executing the target operation to meet the requirements of targeted verification.

[0037] Furthermore, in the method of this application, the fault tolerance processing described in step S5 includes: automatically retrying or skipping when the operation fails; automatically marking and continuing execution when the state is abnormal; automatically waiting and retrying when the state is locked or busy; and executing retry or degradation strategies when the interface times out or the network jitters.

[0038] Furthermore, in the method of this application, the concurrent or serial scheduling of batch virtual machines in step S5 includes: supporting multiple virtual machines to execute different composite operations in parallel, or to execute them serially according to a preset strategy, so as to avoid resource contention and execution conflicts.

[0039] A second aspect of the present invention provides an automated testing system for long-term operation of complex scenarios based on a simulated chaotic cloud server. The system, when running, implements the steps of the aforementioned automated testing method for long-term operation of complex scenarios based on a simulated chaotic cloud server, such as... Figure 5 As shown, the system includes:

[0040] The configuration management module is used to load JSON configuration files, parse virtual machine information, status operation mapping relationships, mutual exclusion rules and preconditions, establish a dynamic decision rule base, and provide an operation legality verification interface;

[0041] The OpenAPI communication module is used to create an HTTP communication client, complete the cloud platform OpenAPI signature authentication, key loading, domain name and interface address configuration, and realize request sending, response receiving, exception retry and failure degradation.

[0042] The operation execution module is used to encapsulate various virtual machine operation functions, unify the input and output parameter standards, and complete API request assembly and response parsing.

[0043] The automation logic module is used to acquire the multi-dimensional status of virtual machines in real time, perform pre-verification based on the dynamic decision rule base, generate a dynamic operation pool, execute random or specified operation decisions, control the cyclic execution and interval, and realize the closed-loop automation of the entire process.

[0044] The main scheduling module provides a unified call entry point and supports multiple call methods, including single virtual machine, batch virtual machine, loop mode, and specified operation, to complete concurrent or serial scheduling.

[0045] The data output module is used to standardize the output of execution results, record the virtual machine ID, the state before and after execution, the execution actions, the result information and error information, and form a complete test link log.

[0046] A third aspect of the present invention provides an electronic device, comprising: a memory and a processor;

[0047] Memory: Used to store computer programs;

[0048] Processor: Used to execute the computer program to implement the steps of the aforementioned automated testing method for long-term operation of complex scenarios based on a simulated chaotic cloud server.

[0049] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the steps of the aforementioned automated testing method for long-term operation of complex scenarios based on a simulated chaotic cloud server.

[0050] In summary, compared with existing cloud platform virtual machine automated testing technologies, this invention achieves highly realistic testing that more closely resembles actual customer usage behavior through an integrated design of state-driven, configuration-driven, random decision-making, long-term looping, and security verification, and has the following significant advantages:

[0051] (1) The test scenario is highly realistic and closely resembles real customer behavior: This invention abandons the traditional test mode with fixed order and fixed process, dynamically filters legal operations based on the real-time status of virtual machine, and supports the execution of random compound operations. It can truly simulate the user's untimely, undirected, compound, and long-term usage behavior, greatly improve the test effectiveness and problem discovery capability, and solve the defects of existing technology in terms of scenario distortion.

[0052] (2) Operation is safe and controllable, avoiding illegal operations and state conflicts: Built-in state-action mutual exclusion rules and multi-dimensional precondition verification automatically identify the virtual machine running state, locked state, HA state and monitoring state, and only allow legal and compliant operations to be executed, eliminating erroneous operations such as repeated startup, cross-state migration and unauthorized configuration from the source, significantly improving test stability and security.

[0053] (3) Support for long-term and long-cycle composite stability testing: It has the ability to perform loop execution, interval control and batch scheduling, and can support 7×24 hours of uninterrupted long-term stability testing for several hours to several days. It can effectively expose hidden problems that will only appear after long-term operation, such as memory leaks, state drift, resource leaks and occasional anomalies, and fill the gap in existing technologies that cannot perform long-term simulation testing.

[0054] (4) Decoupling of configuration and logic, with strong scalability and reusability: The virtual machine information, state mapping, mutual exclusion rules and operation permissions are all externally configured. Rules can be quickly updated, scenarios can be switched and different cloud platform OpenAPIs can be adapted without modifying the code, reducing maintenance costs and improving cross-platform adaptability.

[0055] (5) Clear modular architecture and efficient and stable test execution: This system adopts a five-layer decoupled architecture of configuration management, HTTP client, operation encapsulation, automation logic and main entry. The interface is standardized and the functions are modular. It supports unified scheduling and concurrent execution of single / batch virtual machines, resulting in high test efficiency, traceable problems and quantifiable results.

[0056] (6) The whole process has a sound fault tolerance mechanism and the long-term test is uninterrupted: It has fault tolerance mechanisms such as operation failure retry, status abnormality skipping, interface timeout retry, and automatic abnormal recording. It can continue to execute in scenarios such as interface jitter, network fluctuation, and virtual machine abnormality, ensuring that the long-term test is stable and uninterrupted throughout the process.

[0057] (7) Existing virtual machine friendly, high resource utilization and low testing cost: Directly conduct testing on existing long-term running virtual machines on the cloud platform, without the need to frequently create and destroy resources, reducing resource consumption and testing costs. At the same time, it can complete the stability and compatibility verification of aging instances and long-term instances, which meets the needs of cloud platforms for efficient resource utilization.

[0058] (8) Standardized and traceable results facilitate problem location and review: Each round of operation outputs standardized data including virtual machine ID, pre-execution state, execution action, execution result and final state, forming a complete test link log, which facilitates quick location of anomalies, reproduction of problems and generation of test reports, and improves test management efficiency. Attached Figure Description

[0059] To more clearly illustrate the technical solution of this application, the accompanying drawings involved in the description of this invention will be briefly introduced below. It should be noted that the drawings only show some embodiments of the invention. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0060] Figure 1 This is a flowchart illustrating the overall implementation process of the automated testing method for long-term operation of a cloud server in a simulated chaotic state, based on the present invention.

[0061] Figure 2 This is a schematic diagram of the code architecture in an embodiment of the present invention.

[0062] Figure 3 This is a flowchart illustrating the code execution process in an embodiment of the present invention.

[0063] Figure 4 This is a schematic diagram of chaotic state switching in an embodiment of the present invention.

[0064] Figure 5 This is a structural diagram of the automated testing system for long-term operation of a cloud server in a simulated chaotic state, based on the present invention.

[0065] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be noted that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0067] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.

[0068] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."

[0069] Example 1: An automated testing method for long-term operation of a cloud server in a complex scenario based on simulated chaotic state.

[0070] Figure 2 This is a schematic diagram of the code architecture in an embodiment of the present invention. Figure 3 This is a flowchart of the code execution process. Figure 4 This is a diagram illustrating the transition between chaotic states.

[0071] This invention achieves automated operation testing of cloud platform virtual machines for extended periods, under random, complex, and secure conditions through the following closed-loop collaborative workflow, accurately simulating real-world customer usage behavior:

[0072] Step 1: Configuration Loading and Rule Parsing

[0073] (1) Read the configuration file. When the test starts, the system automatically loads the specified JSON configuration file and completes the parsing through the EcsConfigManager configuration management class to obtain the list of virtual machines (ecs_id, region_id), the mapping relationship between virtual machine status and operation, operation mutual exclusion rules, action preconditions, and default execution parameters.

[0074] (2) Rule initialization: Establish a three-layer mapping relationship of status-allowed operation, status-prohibited operation, and action-precondition to form a dynamic decision rule base, which supports unified rule management for various virtual machine operations such as power-on, power-off, restart, suspension, recovery, cold and hot migration, configuration change, snapshot, image, lock, HA, and monitoring.

[0075] (3) Parameter initialization: Read long-term test parameters such as loop count, operation interval, target virtual machine list, concurrent / serial execution strategy, etc., and complete the test environment initialization.

[0076] Step 2: Real-time acquisition and pre-check of virtual machine status

[0077] (1) Multi-dimensional status query calls get_current_status, get_ecs_lock_status, get_ecs_monitor_status, get_ecs_ha_status and other interfaces to obtain the virtual machine running status (running / stopped / suspended, etc.), lock status, monitoring installation status, HA high availability status in real time.

[0078] (2) Mutual exclusion rule verification: The system automatically determines the executable / invalid operation under the current state through ecs_config.is_action_allowed(), filters out illegal operations, and avoids execution failure caused by state conflict.

[0079] (3) Precondition judgment: Check the preconditions required for the target operation according to get_pre_condition_for_action(). If they are not met, skip or wait to ensure that the operation is safe and legal.

[0080] Step 3: OpenAPI Client Initialization and Authentication

[0081] (1) Create an HTTP communication client; instantiate the OpenApiHttp class to automatically complete the cloud platform OpenAPI signature authentication, key loading, domain name and interface address configuration, and establish a stable and reliable API call channel.

[0082] (2) Interface capability verification: pre-verify the availability of core interfaces such as virtual machine query, status acquisition, operation execution, and result callback to ensure stable API communication during the test and avoid test interruption due to authentication or link abnormalities.

[0083] (3) Register the exception handling mechanism, configure the interface timeout, retry count, and failure degradation strategy to ensure communication stability during long-term testing.

[0084] Step 4: Execution of Intelligent Random Composite Operation

[0085] (1) Optional operation pool generation: Based on the current virtual machine real-time status, a list of legal executable operations is selected from the rule base to form a dynamic operation pool.

[0086] (2) Random / Specified Operation Decision: Random mode: Randomly selects an operation from the operation pool to simulate the user's non-directional real behavior; Specified mode: Supports forced execution of target operations to meet the requirements of targeted verification.

[0087] (3) Execute operations securely, call the corresponding operation functions in ecs_operations.py (power on, power off, restart, migrate, change configuration, snapshot, etc.), complete the API request sending and response result parsing, and return execution success / failure, time taken, and error information.

[0088] (4) Automatic encapsulation of a single virtual machine: The auto_operate_ecs interface is used to realize the closed loop of the whole process of "checking status → judging permission → selecting operation → executing → checking result", and returns standardized data containing ecs_id, previous and subsequent status, execution action and result.

[0089] Step 5: Long-term cycle testing and result summary

[0090] (1) Loop control logic, which implements a specified number of times / infinite number of loop executions through long_time_auto_operate, supports setting the operation interval, and simulates the long-term continuous use behavior of customers.

[0091] (2) Batch virtual machine concurrent / serial scheduling: Supports distributed scheduling of batch virtual machines, allowing multiple virtual machines to perform different composite operations in parallel at the same time, thereby improving test coverage.

[0092] (3) Status tracking and result recording: After each round of operation is completed, the virtual machine ID, pre-execution status, execution action, execution result, final status and error information are automatically recorded to form a complete test link log.

[0093] (4) Error tolerance mechanism: automatic retry / skip when operation fails; automatic marking and continued execution when the status is abnormal; automatic waiting and retry when locked / busy; uninterrupted test process throughout.

[0094] Example 2: An automated testing system for long-term operation of a cloud server in a simulated chaotic state, simulating complex scenarios.

[0095] This system adopts a six-layer decoupled modular architecture, with each module independently encapsulated and working collaboratively.

[0096] Configuration management module: EcsConfigManager is responsible for rule loading, action validation, and mutual exclusion judgment;

[0097] Communication module: OpenApiHttp is responsible for signature, request, response, and retries;

[0098] Operation execution module: various virtual machine operation functions, uniformly encapsulated, with unified input and output parameters;

[0099] Automation logic modules: status acquisition, pre-filtering, secure execution, loop control, and intelligent decision-making;

[0100] The main scheduling module (scheduling entry layer): ecs_op.py provides a unified call entry point and supports multiple call methods such as batch, single, loop, and specified operation;

[0101] Data output module: Standardizes the return of execution results, facilitating integration with logs, reports, and monitoring.

[0102] All the above modules interact through a unified interface, are loosely coupled and highly scalable, and can be quickly adapted to different cloud platform OpenAPIs, allowing access to new platforms without modifying the core logic.

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of systems, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.

[0104] like Figure 6 As shown in the illustration, an embodiment of this application also discloses an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the aforementioned automated testing method for long-term operation of complex scenarios based on a simulated chaotic state cloud server.

[0105] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).

[0106] The operations described in this application can be implemented by writing computer program code using one or more programming languages ​​or a combination thereof. The programming languages ​​include, but are not limited to, the following types:

[0107] Object-oriented programming languages, such as Java, Smalltalk, C++, etc.

[0108] Conventional procedural programming languages, such as "C" or similar programming languages.

[0109] The execution methods of program code include, but are not limited to:

[0110] It runs entirely on the user's computer;

[0111] Part of it executes on the user's computer, and part of it executes on a remote computer;

[0112] Execute as a standalone software package;

[0113] It is executed entirely on a remote computer or server.

[0114] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers through an internet service provider, for example, by utilizing the internet for connection.

[0115] Furthermore, this application also discloses a computer-readable storage medium, which, when the instructions in the computer-readable storage medium are executed by the processor of an electronic device, enables the electronic device to perform the various steps of the automated testing method for long-term operation of complex scenarios based on a simulated chaotic cloud server disclosed in this application.

[0116] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following:

[0117] (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.

[0118] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.

[0119] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.

[0120] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.

[0121] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.

[0122] (6) Fiber optic storage devices: storage media based on fiber optic technology.

[0123] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.

[0124] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.

[0125] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.

[0126] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.

[0127] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.

[0128] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program contains program code for executing the automated testing method for long-term operation of complex scenarios based on a simulated chaotic cloud server disclosed in this application. When this computer program is executed by a processing system, it can achieve the functions defined in the embodiments of this application.

[0129] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0130] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An automated testing method for long-term operation of a cloud server in a complex scenario based on simulated chaotic state, characterized in that, Includes the following steps: S1. Configuration Loading and Rule Parsing: Load the JSON configuration file, parse it to obtain the list of virtual machines, the mapping relationship between virtual machine status and operation, operation mutual exclusion rules, action preconditions and default execution parameters, establish a three-layer mapping relationship of status-allowed operation, status-prohibited operation, and action-preconditions, and form a dynamic decision rule base. S2. Real-time acquisition and pre-verification of virtual machine status: Real-time query of virtual machine running status, locked status, high availability status and monitoring status, and perform mutual exclusion rule verification and pre-condition judgment based on the dynamic decision rule base to filter the set of legal and executable operations under the current status. S3. OpenAPI Client Initialization and Authentication: Create an HTTP communication client, complete the cloud platform OpenAPI signature authentication, key loading, domain name and interface address configuration, and establish an API call channel; S4. Intelligent random composite operation execution: Based on the legally executable operation set, a dynamic operation pool is generated. The target operation is selected using a random decision mode or a specified operation mode. The corresponding operation function is called to complete the API request sending and response parsing, realizing the whole process closed loop of "status query → pre-verification → action decision → safe execution → result feedback". Standardized data containing virtual machine ID, pre-execution status, execution action, execution result and final status is returned. S5. Long-term loop testing and result summary: The test is executed based on the preset number of loops or the infinite loop mode. It supports setting the operation interval and performs concurrent or serial scheduling of batch virtual machines. After each round of operation, the virtual machine ID, the state before and after execution, the execution action and result information are recorded to form a complete test link log. Fault tolerance processing is performed in the case of operation failure, abnormal state or interface timeout to ensure the continuous operation of the test process.

2. The method according to claim 1, characterized in that, The JSON configuration file mentioned in step S1 includes: Virtual machine information configuration, including virtual machine ID and region identifier; State operation mapping configuration defines the set of operations that are allowed to be executed in each state; Mutual exclusion rule configuration defines the prohibition relationship between states and operations; Precondition configuration defines the state conditions that each operation must meet. Execution parameter configuration, including loop count, operation interval and scheduling strategy.

3. The method according to claim 1, characterized in that, Step S1 also includes: reading the loop count, operation interval, target virtual machine list, concurrent / serial execution strategy, and completing the test environment initialization.

4. The method according to claim 1, characterized in that, The real-time query in step S2 includes: calling the status query interface to obtain the virtual machine running status, calling the lock status query interface to obtain the virtual machine lock status, calling the high availability status query interface to obtain the virtual machine high availability status, and calling the monitoring status query interface to obtain the virtual machine monitoring installation status. The mutual exclusion rule verification mentioned above is implemented through ecs_config.is_action_allowed(); The aforementioned precondition judgment is implemented through get_pre_condition_for_action().

5. The method according to claim 1, characterized in that, Step S3 also includes: pre-verifying the availability of core interfaces for virtual machine query, status acquisition, operation execution, and result callback; configuring exception handling mechanisms for interface timeout thresholds, maximum number of retries, and failure degradation strategies.

6. The method according to claim 1, characterized in that, The random decision-making mode mentioned in step S4 includes: randomly selecting an operation from the dynamic operation pool based on the current real-time state of the virtual machine to simulate the user's real usage behavior at irregular intervals and without direction; the specified operation mode includes: forcibly executing the target operation to meet the requirements of targeted verification.

7. The method according to claim 1, characterized in that, The fault tolerance process described in step S5 includes: automatically retrying or skipping when the operation fails; automatically marking and continuing execution when the status is abnormal; automatically waiting and retrying when the status is locked or busy; and executing retry or degradation strategies when the interface times out or the network jitters.

8. The method according to claim 1, characterized in that, The concurrent or serial scheduling of batch virtual machines described in step S5 includes: supporting multiple virtual machines to execute different composite operations in parallel, or to execute them serially according to a preset strategy, so as to avoid resource contention and execution conflicts.

9. An automated testing system for long-term operation of a complex scenario based on a cloud server simulating chaotic states, characterized in that, The system runtime implements the steps of the automated testing method for long-term operation of complex scenarios based on a simulated chaotic cloud server as described in any one of claims 1-8, including: The configuration management module is used to load JSON configuration files, parse virtual machine information, status operation mapping relationships, mutual exclusion rules and preconditions, establish a dynamic decision rule base, and provide an operation legality verification interface; The OpenAPI communication module is used to create an HTTP communication client, complete the cloud platform OpenAPI signature authentication, key loading, domain name and interface address configuration, and realize request sending, response receiving, exception retry and failure degradation. The operation execution module is used to encapsulate various virtual machine operation functions, unify the input and output parameter standards, and complete API request assembly and response parsing. The automation logic module is used to acquire the multi-dimensional status of virtual machines in real time, perform pre-verification based on the dynamic decision rule base, generate a dynamic operation pool, execute random or specified operation decisions, control the cyclic execution and interval, and realize the closed-loop automation of the entire process. The main scheduling module provides a unified call entry point and supports multiple call methods, including single virtual machine, batch virtual machine, loop mode, and specified operation, to complete concurrent or serial scheduling. The data output module is used to standardize the output of execution results, record the virtual machine ID, the state before and after execution, the execution actions, the result information and error information, and form a complete test link log.

10. An electronic device, characterized in that, include: Memory and processor; Memory: Used to store computer programs; Processor: Used to execute the computer program to implement the steps of the automated testing method for long-term operation of complex scenarios based on a simulated chaotic cloud server as described in any one of claims 1-8.

Images