System testing method, apparatus, device, and storage medium

Abstract

The application relates to the technical field of function testing, and discloses a system testing method, device, equipment and computer readable storage medium, the method comprises the following steps: obtaining a configuration file summary and an application scenario by analyzing a configuration file; generating a test index of a system to be tested according to a test index type and the configuration file summary; encoding a test script executed in a container orchestration cluster; setting a fault injection parameter of the application scenario according to a target component to be tested and the test script; generating a test task description file based on an execution sequence of a test stage, the test script and the fault injection parameter; sending the test task description file to the container orchestration cluster; injecting the fault injection parameter into the target component to be tested; monitoring a test index of the target component to be tested in each test stage; and generating a test report based on state data obtained by monitoring. The application can be applied to a financial technology, medical health and other business system platform, and can realize intelligent and automatic testing of a distributed system.

Description

Technical Field

[0001] This invention relates to the field of functional testing technology, and in particular to a system testing method, apparatus, equipment, and storage medium. Background Technology

[0002] In cloud-native architectures, distributed systems need to maintain the stability of core services in the event of failures. To test the resilience of distributed systems, chaos engineering is used to inject faults (such as service interruptions and network latency) and monitor key metrics (such as availability and latency) to assess system resilience. However, existing automated testing methods struggle to dynamically generate targeted test logic and fault experiments based on specific business scenarios, resulting in tests that are detached from actual business needs.

[0003] In the healthcare field, a single point of failure in a remote consultation or imaging diagnostic system could directly impact patient care; its "steady state" requires not only high availability but also data consistency and latency sensitivity. In the fintech sector, payment or transaction systems have extremely high requirements for service continuity; a brief period of unavailability could lead to financial losses or compliance risks. Their testing metrics typically include multi-dimensional constraints such as transaction success rate, end-to-end latency, and error rate.

[0004] However, current tools (such as Chaos Mesh and LitmusChaos) rely on users manually configuring fault types, target components to be tested, and test scripts. They cannot automatically identify the business context from container orchestration configurations (such as inferring "online medical consultation" or "cross-border payment" scenarios from service tags), nor can they dynamically determine appropriate test metrics, thresholds, and corresponding testable fault modes. As a result, tests are either too general and miss critical defects, or too complex to be implemented, severely restricting the large-scale application of elastic testing in critical industries.

[0005] Therefore, there is an urgent need for an automated testing method that can automatically understand business scenarios based on container orchestration configuration and intelligently generate scenario-based steady-state test logic and corresponding fault experiments accordingly. Summary of the Invention

[0006] In view of the above, it is necessary to provide a system testing method. The purpose of this method is to provide an automated testing method that can automatically understand business scenarios based on container orchestration configuration and intelligently generate scenario-based steady-state test logic and corresponding fault experiments accordingly.

[0007] Firstly, a system testing method is provided, including:

[0008] Receive a test request for the system to be tested, and deploy the configuration file of the system to be tested to a container orchestration cluster in a preset test namespace according to the test request; Analyze the resource configuration information in the configuration file, generate a configuration file summary of the system to be tested based on the resource configuration information, and determine the application scenario of the system to be tested based on the service identification information in the configuration file; According to the application scenario, the test indicator type corresponding to the application scenario is matched from the preset scenario-indicator type mapping table. The test indicator of the system to be tested is determined according to the test indicator type and the configuration file summary. The observable data items to be collected and the corresponding thresholds are obtained from the test indicators. The test script is generated according to the observable data items and the thresholds. According to the preset configuration risk-component mapping table, system components with preset configuration risks are selected from the configuration file summary as target components to be tested, and fault injection parameters corresponding to the application scenario are set according to the target components to be tested and the test script. The testing process of the system under test is divided into a preset number of test phases. A test task description file is generated based on the execution order of each test phase, the test scripts to be called, and the corresponding fault injection parameters. The test task description file is then sent to the container orchestration cluster. The fault injection parameters are injected into the target component under test using the fault injection controller in the container orchestration cluster, and the test script is executed to monitor the status data of the test indicators of the target component under test in each test stage, and a test report is generated based on the monitored status data.

[0009] Secondly, a system testing apparatus is provided, comprising: The deployment module is used to receive test requests for the system to be tested and deploy the configuration file of the system to be tested to a container orchestration cluster in a preset test namespace according to the test request. The module is used to analyze the resource configuration information in the configuration file, generate a configuration file summary of the system to be tested based on the resource configuration information, and determine the application scenario of the system to be tested based on the service identification information in the configuration file. The matching module is used to match the test indicator type corresponding to the application scenario from a preset scenario-indicator type mapping table, determine the test indicator of the system to be tested according to the test indicator type and the configuration file summary, obtain the observable data items to be collected and the corresponding thresholds from the test indicators, and generate a test script according to the observable data items and the thresholds. The configuration module is used to select system components with preset configuration risks as target components to be tested from the configuration file summary according to the preset configuration risk-component mapping table, and set fault injection parameters corresponding to the application scenario according to the target components to be tested and the test script. The partitioning module is used to divide the testing process of the system under test into a preset number of test phases, generate a test task description file based on the execution order of each test phase, the test scripts to be called and the corresponding fault injection parameters, and send the test task description file to the container orchestration cluster. The analysis module is used to inject the fault injection parameters into the target component under test using the fault injection controller in the container orchestration cluster, and execute the test script to monitor the status data of the test indicators of the target component under test in each test stage, and generate a test report based on the monitored status data.

[0010] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described system testing method.

[0011] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described system testing method.

[0012] Compared to existing technologies, this invention analyzes the resource configuration information in the configuration file to obtain a configuration file summary, determines the application scenario based on the service identification information in the configuration file, identifies the application scenario by parsing the configuration, and dynamically generates test indicators that fit business needs by combining a preset scenario-indicator type mapping table, so that the test standards are aligned with the actual business reliability requirements.

[0013] Based on the preset configuration risk-component mapping table, related system components are selected from the configuration file summary as target components to be tested. Applicable fault types are matched and fault injection parameters are configured to ensure that fault experiments focus on real weaknesses and avoid blind disturbances. The test is divided into pre-testing, fault injection, and post-testing phases. Test indicators are continuously monitored through test scripts to determine whether the system is unstable under disturbances and whether it can recover, thereby scientifically assessing the system's resilience.

[0014] This invention deeply integrates business scenarios, system configurations, observability metrics, and fault experiments to construct an intelligent, automated, and closed-loop distributed system elastic testing system. It solves the problems of "mismatched standards, lack of specificity for faults, difficulty in quantifying results, and lack of guidance for repair" in traditional testing, effectively ensuring the reliable operation of cloud-native applications under complex fault conditions. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of an application environment for a system testing method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a system testing method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a system testing device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention.

[0016] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0018] It should be noted that the descriptions involving "first," "second," etc., in this invention are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0019] The system testing method provided in this embodiment of the invention can be applied to, for example, Figure 1In this application environment, the client communicates with the server via a network. The server can receive test requests for the system under test, deploy the configuration file of the system under test to a container orchestration cluster in a preset test namespace according to the test request; analyze the resource configuration information in the configuration file, generate a configuration file summary of the system under test based on the resource configuration information, and determine the application scenario of the system under test based on the service identification information in the configuration file; according to the application scenario, match the test indicator type corresponding to the application scenario from a preset scenario-metric type mapping table, determine the test indicators of the system under test based on the test indicator type and the configuration file summary, obtain the observable data items to be collected and the corresponding thresholds from the test indicators, and generate test scripts based on the observable data items and the thresholds. Based on a preset configuration risk-component mapping table, system components with preset configuration risks are selected from the configuration file summary as target components to be tested. Fault injection parameters corresponding to the application scenario are set according to the target components to be tested and the test script. The testing process of the system to be tested is divided into a preset number of test stages. A test task description file is generated based on the execution order of each test stage, the required test scripts, and the corresponding fault injection parameters. The test task description file is sent to the container orchestration cluster. The fault injection controller in the container orchestration cluster injects the fault injection parameters into the target components to be tested and executes the test script to monitor the status data of the test metrics of the target components to be tested in each test stage. A test report is generated based on the monitored status data.

[0020] This invention targets fields such as financial enterprises and healthcare. It analyzes the resource configuration information in the configuration file to obtain a configuration file summary, determines the application scenario based on the service identification information in the configuration file, identifies the application scenario by parsing the configuration, and dynamically generates test indicators that fit business needs by combining a preset scenario-indicator type mapping table, so that the test standards are aligned with the actual business reliability requirements.

[0021] Based on the preset configuration risk-component mapping table, related system components are selected from the configuration file summary as target components to be tested. Applicable fault types are matched and fault injection parameters are configured to ensure that fault experiments focus on real weaknesses and avoid blind disturbances. The test is divided into pre-testing, fault injection, and post-testing phases. Test indicators are continuously monitored through test scripts to determine whether the system is unstable under disturbances and whether it can recover, thereby scientifically assessing the system's resilience.

[0022] This invention deeply integrates business scenarios, system configurations, observability metrics, and fault experiments to build an intelligent, automated, and closed-loop distributed system testing system. It solves the problems of "mismatched standards, lack of specificity for faults, difficulty in quantifying results, and lack of guidance for repair" in traditional testing, effectively ensuring the reliable operation of cloud-native applications under complex fault conditions.

[0023] Reference Figure 2 The diagram shown is a schematic flowchart of a system testing method provided in an embodiment of the present invention. This method is executed by a device.

[0024] In this embodiment, a system testing method includes: S1. Receive a test request for the system to be tested, and deploy the configuration file of the system to be tested to a container orchestration cluster in a preset test namespace according to the test request. In this embodiment, the user initiates a test request for the system under test on the client, and deploys the configuration file of the system under test to a container orchestration cluster in a preset test namespace according to the test request.

[0025] The systems under test can be applied to various critical business scenarios, such as remote consultation platforms and medical image processing systems in the healthcare field, or online payment gateways and real-time risk control engines in the fintech field. These systems have high requirements for availability, data consistency, and service continuity.

[0026] Configuration files are declarative configuration documents that conform to container orchestration specifications, such as Kubernetes YAML format files, and contain one or more resource object definitions, such as service instance templates, network access points, configuration parameter sets, external access rules, etc.

[0027] The configuration file undergoes syntax validation and structure parsing to obtain the resource configuration, ensuring it conforms to the API specifications of container orchestration clusters (such as Kubernetes-based clusters). The parsed resource configuration is then submitted to the container orchestration cluster by calling its control plane interface. A container orchestration cluster is a group of collaborative compute nodes, managed uniformly by a container orchestration system, serving as an infrastructure platform for automated deployment, scaling, and operation.

[0028] The cluster controller of a container orchestration cluster automatically schedules container runtimes on worker nodes based on resource configurations, pulls specified images, creates Pod instances, and binds network and storage resources, bringing all system components of the system under test into a running state. For example, in a healthcare scenario, the system might deploy services containing patient data processing modules, requiring assurance that instances have high availability configurations and encrypted storage bindings.

[0029] Deploying the configuration file to the container orchestration cluster allows the system under test to run realistically, ensuring the authenticity of the test and testing elasticity under the same operating conditions as the production environment, thus avoiding misjudgments from static analysis.

[0030] S2. Analyze the resource configuration information in the configuration file, generate a configuration file summary of the system to be tested based on the resource configuration information, and determine the application scenario of the system to be tested based on the service identification information in the configuration file; In this embodiment, resource configuration information from the configuration file is extracted, including but not limited to: the number of service instance replicas; the requested and limited values ​​of CPU and memory declared for each container; whether readiness probes and liveness probes are configured; and the network exposure method (e.g., whether access is provided externally through a service type of ClusterIP or LoadBalancer). A structured configuration file summary is obtained based on the extracted information.

[0031] In one embodiment, determining the application scenario of the system to be tested based on the service identifier information in the configuration file includes: Extract keywords related to the scene semantics from the service name, namespace, and tag fields in the configuration file; The keywords are matched with a preset business scenario keyword library, and the application scenario of the system to be tested is determined based on the matching results.

[0032] The system parses the service identification information in the configuration file, including the service name, namespace, and user-defined labels. Text analysis of these fields extracts keywords with business semantics. For example, if the service name contains "image," "dicom," or "radiology," it is associated with the "telemedicine" scenario; if the namespace is "payment" or the label contains "transaction," it is associated with the "financial payment" scenario.

[0033] The extracted keywords are matched against a pre-defined business scenario keyword library. This library predefines multiple application scenarios and their corresponding keyword sets. A successful match determines the application scenario of the system to be tested.

[0034] Traditional methods require maintenance personnel to manually label services such as "this is a payment service" and "that is a medical imaging service," which is prone to errors and difficult to maintain. This invention directly extracts keywords related to the semantics of the scenario from existing configuration files (such as service names containing "payment," tags containing "env=prod," and "team=finance"), automatically inferring the business scenario and reducing the cost of human intervention.

[0035] S3. Based on the application scenario, match the test indicator type corresponding to the application scenario from the preset scenario-indicator type mapping table, determine the test indicator of the system to be tested based on the test indicator type and the configuration file summary, obtain the observable data items to be collected and the corresponding thresholds from the test indicators, and generate a test script based on the observable data items and the thresholds. In this embodiment, based on the determined application scenario, the system queries a preset scenario-metric type mapping table to find matching test metric types. For example, in the healthcare scenario, the focus is on test metric types such as "service availability" and "instance readiness ratio," while in the fintech scenario, priority is given to test metric types such as "request success rate," "end-to-end latency," and "transaction consistency." Specific test metrics are generated by combining the test metric types with service identification information (such as service name and namespace) in the configuration file summary. Test metrics are specific, quantifiable, and monitorable technical indicators used to characterize the service quality or operational health of a distributed system when it is in a normal, stable operating state (i.e., "steady state"). For example, "service availability" can be bound to "ECG analysis service" to form a monitorable metric expression: "The available instance ratio of ECG analysis service is not less than 100%"; or "end-to-end latency" can be associated with "cross-border payment service" to generate "Cross-border payment service P95 response latency does not exceed 200 milliseconds."

[0036] In one embodiment, the preset scenario-index type mapping table is obtained in the following way: Obtain a preset number of document samples corresponding to known business scenarios, and mark the known business scenarios in each document sample with the corresponding scenario identifier; Extract test constraints for the distributed system from the document sample; The test constraints are mapped to the corresponding test indicator types, and a mapping relationship between each scenario identifier and the corresponding test indicator type is established. Store all mapping relationships in the scenario-metric type mapping table.

[0037] Obtain document samples corresponding to multiple known business scenarios. These samples are derived from actual operation and maintenance systems or industry standards, such as Service Level Agreement (SLA) documents or compliance technical requirements documents. Each document sample clearly corresponds to a specific business scenario, such as "Remote Medical Imaging Diagnosis System" or "Real-time Cross-border Payment Platform." Assign a scenario identifier to each document sample's corresponding business scenario. Extract test constraints related to the system's steady-state operation from the document samples. Constraints are typically expressed in quantitative or categorical form, including but not limited to: availability requirements, latency limits, or data consistency levels. Availability requirements: e.g., "Annual service availability rate not less than 99.95%"; Latency limits: e.g., "End-to-end response time for user requests not exceeding 300 milliseconds."

[0038] The above test constraints are mapped to common test metric types. For example, "Availability Requirement" is mapped to "Service Availability" or "Ready Instance Ratio"; "Latency Limit" is mapped to "End-to-End Request Latency (P95 / P99)". Finally, the correspondence between scenario identifiers and test metric types is established, and all mapping relationships are stored in a structured form in the scenario-metric type mapping table.

[0039] This invention constructs a scenario-metric type mapping table, realizing a structured association between business semantics and quantifiable test objectives. This enables the testing system to dynamically generate test metrics that meet business SLA requirements based on automatically identified application scenarios, thereby significantly improving the relevance, professionalism, and automation level of elasticity testing.

[0040] In one embodiment, matching the test metric type corresponding to the application scenario from a preset scenario-metric type mapping table according to the application scenario includes: Obtain the scene identifier of the application scenario; Based on the scenario identifier, query the scenario-metric type mapping table to find the matching test metric type; The matched test metric type is used as the test metric type for the application scenario.

[0041] The application scenario is extracted from the configuration information of the system under test, and the corresponding scenario identifier is determined accordingly. This scenario identifier is a structured tag that uniquely represents the business type, typically automatically generated from service names, namespaces, or keywords in configuration tags. Using this scenario identifier as the query key, a matching search is performed in a pre-defined scenario-metric type mapping table. This mapping table is a structured data table that pre-stores the correspondence between various scenario identifiers and their applicable test metric types. For example, the scenario identifier "telemedicine" corresponds to test metric types including "service availability," "instance readiness ratio," and "data write success rate"; the scenario identifier "financial_payment" corresponds to test metric types including "request success rate," "end-to-end latency (P95)," and "transaction commit consistency." The retrieved test metric types are used as the test metric types that the system under test should follow in the current application scenario. Test metric types are business-scenario-oriented, general, and reusable service quality monitoring dimension categories, used to guide the generation of observable test rules for specific services.

[0042] This invention achieves automatic alignment between test objectives and business semantics by querying the corresponding test indicator type from a preset mapping table based on the scenario identifier of the application scenario. This ensures that the subsequently generated verification logic, fault injection strategy, and evaluation criteria closely match the real steady-state requirements of the scenario.

[0043] In one embodiment, generating test metrics for the system under test based on the test metric type and the service identifier information in the configuration file summary includes: Extract service data associated with the service identification information from the configuration file summary; the service data includes the service name and namespace. Determine the initial indicator name based on the test indicator type; The service name and namespace are appended as tag conditions to the initial metric name to generate the metric expression for the test metric of the system under test.

[0044] Service data includes metadata such as service name and namespace. For example, if the service name described in the configuration file summary is "Medical Imaging Service" and the namespace is "Telemedical Production Environment", then the extracted service data is the combination of that name and namespace.

[0045] The initial metric name is a predefined, generic observable identifier in the monitoring system. For example, when the test metric type is "request success rate", the corresponding initial metric name is "service request success rate".

[0046] The service name and namespace are used as tag conditions and appended to the initial metric name to form a specific test metric expression. The test metric expression is used to uniquely identify the target object to be monitored within the container orchestration cluster. For example: "Request processing latency of cross-border payment services in a financial production environment"; the initial metric name "Percentage of ready instances" + service name "ECG monitoring service" + namespace "telemedicine production environment" generates the test metric expression, which is then used as the corresponding test metric.

[0047] The test indicators obtained by this invention can clearly define the service quality requirements that the system should meet under normal conditions, serving as a direct basis for constructing monitoring and judgment logic. By comparing actual observation values ​​with indicator thresholds, the impact of faults can be accurately assessed.

[0048] In one embodiment, the step of obtaining observable data items to be collected and corresponding thresholds from the test metrics, and generating a test script based on the observable data items and the thresholds, includes: Based on the test metrics, determine the observable data items to be collected during the operation of the system under test; Construct test conditions for determining whether the observable data item meets the threshold of the test metric; The test conditions are encoded into test scripts that can be executed in the container orchestration cluster.

[0049] Identify the observable data items to be collected during the operation of the system under test based on the test metrics. Observable data items are raw monitoring data that reflect the steady-state state of the system, and their type is determined by the semantics of the test metrics. For example, if the test metric is "service request success rate is not less than 99.99%", then the corresponding observable data items include: the total number of requests received by the service and the number of requests that were successfully responded to.

[0050] Based on the preset thresholds in the test metrics, test conditions are constructed to determine whether the system maintains a steady state. These test conditions are logical expressions used to calculate and judge observable data items. For example, for the "request success rate" metric, the test condition is: "Number of successful requests ÷ Total number of requests ≥ 0.9999".

[0051] The system generates script code that conforms to the syntax of the target testing framework based on the test conditions. Test conditions include observable data items (such as HTTP request success rate, P95 latency) and their corresponding judgment thresholds (such as ≥99.9%, ≤200ms). Based on a preset script template, the system converts the test conditions into executable code containing data acquisition logic and assertion statements.

[0052] The test script implements data acquisition, calculation, and judgment logic in the form of programmatic instructions, and can be periodically called by the test task scheduler. When the test script runs, it obtains real-time observable data items from the cluster's monitoring agent or indicator interface, executes test conditions, and outputs judgment results (such as "pass" or "fail") for analysis in subsequent test phases.

[0053] This invention transforms abstract test metrics into automated verification logic by encoding test conditions into test scripts that can be executed in a container orchestration cluster, ensuring that the verification process strictly aligns with the steady-state requirements of the business. The test scripts can be directly executed by the cluster scheduler, supporting multi-stage, periodic monitoring and outputting judgment results in a standardized manner. This significantly improves the automation level, execution consistency, and result reliability of elasticity testing, resolving the verification bias and implementation difficulties caused by relying on manually written or generic probes in existing technologies.

[0054] S4. Based on the preset configuration risk-component mapping table, select system components with preset configuration risks from the configuration file summary as target components to be tested, and set fault injection parameters corresponding to the application scenario according to the target components to be tested and the test script; In this embodiment, a configuration risk-component mapping table is pre-constructed. This pre-constructed table is built as follows: based on historical root cause analysis of distributed system resilience, several types of configuration risk characteristics are identified, each corresponding to a resource configuration pattern that can be parsed from a container orchestration system configuration file; each type of configuration risk characteristic is associated with a corresponding component identification condition, which is used to determine whether a component in the configuration file summary has the configuration risk; the configuration risk characteristics and their corresponding component identification conditions are stored as key-value pairs to form the configuration risk-component mapping table.

[0055] The configuration risk-component mapping table defines several types of configuration risk characteristics and their corresponding target component identification conditions in a structured form. Configuration risk characteristics include: Insufficient high availability: the number of service instance replicas is less than 2; Unaware health status: the container is not configured with a readiness probe; Missing resource boundaries: no upper limit is set for CPU or memory usage.

[0056] After obtaining the configuration file summary, each configuration risk feature in the configuration risk-component mapping table is traversed, and the corresponding field in the configuration file summary is matched against the component identification conditions. If the configuration attribute of a system component meets the component identification conditions of any configuration risk feature, the component is determined to have a preset configuration risk and added to the list of target components to be tested. For example, if the replicas field value of a service in the configuration file summary is 1, it matches the "insufficient high availability" risk feature, and the service component is selected as the target component. Finally, all successfully matched components are output as the target components to be tested in this elasticity test, used for subsequent fault injection parameter configuration and perturbation experiment execution.

[0057] In one embodiment, setting fault injection parameters corresponding to the application scenario based on the target component to be tested and the test script includes: Select the fault types to be tested that are suitable for the application scenario from the preset set of fault types; Select a fault type from the fault types to be tested that matches the configuration risk of the target component to be tested; Configure the injection parameters for the matching fault type based on the configuration characteristics of the target component to be tested and the test metrics.

[0058] The system selects suitable fault types for the current application scenario from a pre-defined set of fault types. This set is a structured knowledge base containing applicability constraints for various fault types, such as whether it involves data persistence corruption, whether it causes complete service unavailability, or whether it violates data integrity requirements. Based on the business tolerance implied by the identified application scenario (such as "telemedicine" or "online payment"), inapplicable fault types are excluded.

[0059] From the list of fault types to be tested, a fault type matching the configuration risk of the target component to be tested is selected. This matching is based on a preset risk-fault mapping relationship. For example, if the target component has a configuration risk of "replica count less than 2", then the "service instance termination" fault is matched. The injection parameters for the selected fault type are configured according to the configuration characteristics of the target component to be tested (such as service name, namespace, resource request value) and the monitoring dimensions corresponding to the test metrics. This invention achieves precision and scenario adaptation in fault experiments by dynamically configuring fault injection parameters by combining the configuration characteristics of the target component to be tested with the specific requirements of the test metrics (such as thresholds, monitoring dimensions). This mechanism ensures that the disturbance intensity effectively exposes system weaknesses while remaining within a business-acceptable safety boundary, significantly improving the effectiveness, security, and reproducibility of elasticity testing, and solving the problem that fault parameters in existing chaos engineering tools rely on experience-based settings, easily leading to test failures or environmental damage.

[0060] In one embodiment, the preset set of fault types is obtained as follows: Obtain a library of common fault modes in cloud-native environments, which includes fault types at the node, network, application, and storage levels. For each type of failure, define its applicability constraints, including whether it involves data persistence corruption, whether it causes the service to be completely unavailable, or whether it violates preset data integrity requirements; The fault types and their corresponding applicability constraints are stored as a structured set of fault types.

[0061] For each identified potential problem, select a fault type that semantically matches the type of fault to be tested. The matching criterion is whether the impact of the fault on the system can effectively expose the potential problem. For example, if the potential problem is "single-replica deployment", then select "termination of target instance" to test the risk of service interruption; if the potential problem is "no resource limits configured", then select "inject high CPU load" to test the performance degradation under resource contention.

[0062] By combining the resource attributes of the target component under test (such as service name, namespace, and node) and the monitoring dimensions corresponding to the test metrics (such as success rate, latency, and availability), specific injection parameters for the selected fault type are configured. Injection parameters include the fault's target object, intensity, duration, and scope. For example, for the "Terminate Instance" fault, the injection parameters are: target service name "ECG Analysis Service", namespace "telemedicine", and duration 30 seconds; for the "Network Latency" fault, the injection parameters are: target network interface, latency 200 milliseconds, affecting both inbound and outbound traffic, and duration 60 seconds. This invention achieves secure governance and intelligent scheduling of chaotic engineering disturbances by constructing a structured fault type set containing multi-level fault types and their applicability constraints. It not only clarifies the technical impact boundaries of various faults (such as whether they damage data or cause service interruption), but also provides a calculable and strategizable decision-making basis for subsequent fault screening and parameter configuration based on application scenarios, component configurations, and test targets.

[0063] Fault injection parameters refer to the set of specific configuration items used to precisely control fault injection behavior during system testing. Their purpose is to define "which system components to target, what type of fault to apply, and with what intensity and duration," ensuring that fault experiments are repeatable, observable, and aligned with the testing objectives.

[0064] S5. Divide the testing process of the system under test into a preset number of test phases, generate a test task description file based on the execution order of each test phase, the test scripts to be called and the corresponding fault injection parameters, and send the test task description file to the container orchestration cluster. In this embodiment, the entire resilience testing process is divided into three logically consecutive testing phases: the pre-test phase, the fault injection phase, and the post-test phase. The pre-test phase is used to confirm that the system under test is in a steady state before the fault is injected, that is, all test indicators meet the preset thresholds; the fault injection phase is used to execute fault disturbances and apply specified faults to the target component under test according to the configured fault injection parameters; the post-test phase is used to monitor the system's recovery capability after the fault stops and test whether it can return to a steady state.

[0065] Based on the needs of each stage, the following information is aggregated: Execution order: Dependencies between stages (e.g., faults can only be injected after pre-verification is completed); Test scripts: Identifiers of the verification scripts to be called in each stage and their execution frequency; Fault injection parameters: Only used in the fault injection stage, including target component, fault type, duration, and intensity.

[0066] Based on the above information, a structured test task description file is generated, using a format parsable by a container orchestration system (such as YAML), the core of which is a sequentially arranged list of stages.

[0067] In one embodiment, the testing phase includes a pre-testing phase, a fault injection phase, and a post-testing phase. The test task description file is generated based on the execution order of each testing phase, the required test scripts, and the corresponding fault injection parameters, including: Configure a phase identifier, execution timing information, associated test script path, and applicable fault injection parameters for each test phase; The configuration information for each testing phase is organized into a structured test task description file, which adopts a declarative format that can be parsed by container orchestration clusters.

[0068] This invention uses the generation of test task description files as a bridge connecting test intent and automated execution, transforming resilience testing from "manual operation" into a standardized, schedulable, and reproducible programmatic task. It is the core carrier for realizing large-scale, high-efficiency distributed system resilience testing.

[0069] S6. The fault injection parameters are injected into the target component under test using the fault injection controller in the container orchestration cluster, and the test script is executed to monitor the status data of the test indicators of the target component under test in each test stage, and a test report is generated based on the monitored status data.

[0070] In this embodiment, the fault injection controller in the container orchestration cluster accurately applies pre-configured fault injection parameters (such as terminating instances, increasing latency, etc.) to the target component under test, ensuring that the fault experiment matches the potential problems and business scenarios of the system under test, and avoiding blind or invalid injection.

[0071] While injecting faults, test scripts are executed in parallel to continuously monitor key test metrics of the target component under test (such as request success rate, latency, and resource utilization), thereby objectively recording the actual performance of the system under disturbances and providing a data basis for determining elasticity capabilities.

[0072] In one embodiment, the step of injecting the fault injection parameters into the target component under test using the fault injection controller in the container orchestration cluster, and executing the test script to monitor the status data of the test metrics of the target component under test in each test phase, includes: At the start of the fault injection phase, the fault injection controller is triggered to inject the fault injection parameters into the target component under test; During the fault injection phase and the subsequent testing phase, the test script is periodically executed to collect status data of the target component under test, including at least one of service request success rate, end-to-end latency, or resource utilization.

[0073] When the testing process enters the fault injection phase, an execution command is sent to the fault injection controller in the container orchestration cluster, along with the configured fault injection parameters. The fault injection controller identifies the target component to be tested (such as a service instance or compute node) based on the parameters and applies the corresponding fault behavior. For example, if the fault injection parameter specifies "terminate service instance," the controller calls the cluster interface to delete the running instance of the target service.

[0074] Throughout the fault injection phase and in the subsequent post-test phase, the test script is periodically invoked at fixed time intervals (e.g., every 5 seconds or every 10 seconds). This test script retrieves real-time operational data of the target component from the cluster's monitoring agent or metric collection system based on predefined test metric expressions, and calculates key service quality metrics.

[0075] Test metrics should include at least one of the following types: Service request success rate: the percentage of user requests that are successfully processed out of the total number of requests; End-to-end latency: the time it takes for a user request to be sent and for a response to be received, usually expressed as the P95 or P99 percentile; Resource utilization: the percentage of CPU, memory, or network bandwidth consumed by the target component under test out of the total allocated resources.

[0076] The collected status data is recorded and used to determine whether the system deviates from steady state under disturbances and whether it effectively recovers after a fault stops. All monitoring results, along with timestamps, are stored in the test log to provide a basis for generating subsequent test reports.

[0077] This invention enables full-process, multi-dimensional quantitative observation of the system's resilient behavior by periodically collecting state data of the target component under test during the fault injection and post-testing phases. It can not only objectively determine whether the system maintains a steady state of service under disturbances, but also reveal key information such as transient performance degradation, resource bottlenecks, and recovery capabilities, providing reliable data support for resilient capability assessment, root cause analysis, and system optimization.

[0078] In one embodiment, generating a test report based on the monitored status data includes: If the pre-test phase fails, the automated resilience testing process is terminated, and a test report indicating the pre-test failure is generated. If the pre-test phase passes but the subsequent test phase fails, the cause of steady-state failure is analyzed based on the configuration file and the failed test script logs, and a test report containing executable repair suggestions is generated based on the cause. If both the pre-test and post-test phases pass, the automated resilience testing process ends, and a test report indicating that the test has passed is generated.

[0079] The pre-test phase executes test scripts. If any test metric fails to reach a preset threshold (e.g., service not ready, request success rate below baseline), the pre-test is deemed a failure. In this case, subsequent testing processes are immediately terminated to prevent injecting faults into an unstable environment, thus rendering the test ineffective. A pre-test failure report is generated. This report includes the failure time, the name of the failed metric, a comparison of the actual observed value with the expected threshold, and a message stating, "The initial state of the system under test is abnormal; it is recommended to check the deployment configuration or dependent services."

[0080] If the pre-test phase passes, proceed to the fault injection and post-test phases. Analyze the test script logs from the post-test phase. If the test metrics in this phase fail to recover to the threshold range (e.g., service remains unavailable after a fault stop, latency continues to exceed limits), the post-test is considered a failure. By combining configuration files (such as replica count, resource limits, probe configuration) with detailed logs from the test scripts (such as metric change curves, error code distribution, instance state transitions), the root cause of the steady-state failure is automatically analyzed.

[0081] If both the pre-test and post-test phases pass, meaning the system successfully maintains or recovers to a steady state after a fault disturbance, the resilience test is considered successful. The system then concludes the testing process and generates a test success report, which includes the test scenario, the type of injected fault, trend charts of indicators for each phase, and the conclusion that "the system possesses the expected resilience capabilities."

[0082] This invention achieves precise diagnosis of system health and resilience by generating differentiated test reports based on the results of pre-testing and post-testing phases. In particular, when post-testing fails, the system can automatically generate executable repair suggestions by combining configuration context and runtime logs, significantly improving problem localization and repair efficiency, and providing structured input for subsequent automated closed-loop optimization.

[0083] In one embodiment, after generating the test report, the method further includes: If the test report is a failed test, an updated system configuration file is generated based on the configuration file. Deploy the updated system configuration file to the container orchestration cluster; Based on the test script and the fault injection parameters, the test process of the system under test is repeated until the test script passes both the pre-test and post-test phases.

[0084] Determine if the test report is a failure type (including pre-test or post-test failure); if so, extract executable repair suggestions (such as "increase the number of replicas to 2", "configure ready probes", "set resource limits"), and generate an updated system configuration file based on the original configuration file - only modify the fields related to the suggestions, and keep the rest of the structure unchanged.

[0085] The updated configuration is submitted by calling the deployment interface of the container orchestration cluster, triggering a system redeployment. The cluster controller then creates or replaces the service instance to make the repair effective. After the system stabilizes, the original test scripts and fault injection parameters are reused to execute the complete elasticity testing process (pre-testing, fault injection, post-testing). If it still fails, the "analysis-repair-redeployment-retesting" loop is repeated; if it passes, the iteration terminates. This closed loop continues to run until both pre-testing and post-testing meet the test metric thresholds, indicating that the system has the expected elasticity capabilities. This invention constructs an automated, closed-loop fault recovery and system resilience verification process, which not only improves the robustness and maintainability of the system but also lays the foundation for achieving highly available, self-healing, and observable cloud-native systems.

[0086] In one embodiment, after generating the test report, the method further includes: Based on the test results, repair records, and the final passed configuration version during the testing process, a structured final test report is generated; The updated system configuration file that last successfully passed the test during the test process is identified as the target system configuration file, and the target system configuration file and the final test report are output.

[0087] When the system under test passes all pre-test and post-test metrics in a certain round of testing, the repair-retest cycle terminates, and key information from the entire process is summarized: test results for each round, reasons for failure, repair operation records (including configuration changes and suggested sources), and the updated system configuration file used to finally pass the test. Based on this key information, a structured final test report is automatically generated, including: test summary, process summary, repair path, final conclusion, and attachments. Simultaneously, the updated system configuration file corresponding to the last successful test is marked as the target system configuration file and output along with the final test report. This can be saved as a file, returned via an API, or pushed to the configuration management center for deployment, auditing, or compliance purposes.

[0088] This invention generates a structured final test report after the test loop is completed and outputs a target system configuration file that has been fully and resiliently verified, thus achieving the integrated delivery of "verifiable configuration" and "process evidence". This not only provides a highly reliable configuration baseline for production deployment, but also builds a complete resilient verification audit trail, supporting compliance review, knowledge reuse and continuous optimization.

[0089] like Figure 3 The diagram shown is a schematic diagram of a system testing device provided in an embodiment of the present invention.

[0090] The system testing device 100 of this invention can be installed in a device. Depending on the functions implemented, the system testing device 100 may include a deployment module 110, an acquisition module 120, a matching module 130, a setting module 140, a partitioning module 150, and an analysis module 160. The module described in this invention can also be called a unit, which refers to a series of computer program segments that can be executed by the device processor and perform a fixed function, and which are stored in the device's memory.

[0091] In this embodiment, the functions of each module / unit are as follows: The deployment module 110 is used to receive test requests for the system to be tested and deploy the configuration file of the system to be tested to a container orchestration cluster in a preset test namespace according to the test requests. The module 120 is used to analyze the resource configuration information in the configuration file, generate a configuration file summary of the system to be tested based on the resource configuration information, and determine the application scenario of the system to be tested based on the service identification information in the configuration file. The matching module 130 is used to match the test indicator type corresponding to the application scenario from a preset scenario-indicator type mapping table according to the application scenario, determine the test indicator of the system to be tested according to the test indicator type and the configuration file summary, obtain the observable data items to be collected and the corresponding thresholds from the test indicators, and generate a test script according to the observable data items and the thresholds. The setting module 140 is used to select system components with preset configuration risks as target components to be tested from the configuration file summary according to the preset configuration risk-component mapping table, and set fault injection parameters corresponding to the application scenario according to the target components to be tested and the test script. The partitioning module 150 is used to divide the testing process of the system under test into a preset number of test stages, generate a test task description file based on the execution order of each test stage, the test scripts to be called and the corresponding fault injection parameters, and send the test task description file to the container orchestration cluster. The analysis module 160 is used to inject the fault injection parameters into the target component under test using the fault injection controller in the container orchestration cluster, and execute the test script to monitor the status data of the test indicators of the target component under test in each test stage, and generate a test report based on the monitored status data.

[0092] In one embodiment, module 120 is obtained, specifically for: Extract keywords related to the scene semantics from the service name, namespace, and tag fields in the configuration file; The keywords are matched with a preset business scenario keyword library, and the application scenario of the system to be tested is determined based on the matching results.

[0093] In one embodiment, the matching module 130 is specifically used for: Obtain a preset number of document samples corresponding to known business scenarios, and mark the known business scenarios in each document sample with the corresponding scenario identifier; Extract test constraints for the distributed system from the document sample; The test constraints are mapped to the corresponding test indicator types, and a mapping relationship between each scenario identifier and the corresponding test indicator type is established. Store all mapping relationships in the scenario-metric type mapping table.

[0094] In one embodiment, the matching module 130 is specifically used for: Obtain the scene identifier of the application scenario; Based on the scenario identifier, query the scenario-metric type mapping table to find the matching test metric type; The matched test metric type is used as the test metric type for the application scenario.

[0095] In one embodiment, the matching module 130 is specifically used for: Extract service data associated with the service identification information from the configuration file summary; the service data includes the service name and namespace. Determine the initial indicator name based on the test indicator type; The service name and namespace are appended as tag conditions to the initial metric name to generate the metric expression for the test metric of the system under test.

[0096] In one embodiment, the matching module 130 is specifically used for: Based on the test metrics, determine the observable data items to be collected during the operation of the system under test; Construct test conditions for determining whether the observable data item meets the threshold of the test metric; The test conditions are encoded into test scripts that can be executed in the container orchestration cluster.

[0097] In one embodiment, the setting module 140 is specifically used for: Select the fault types to be tested that are suitable for the application scenario from the preset set of fault types; Select a fault type from the fault types to be tested that matches the configuration risk of the target component to be tested; Configure the injection parameters for the matching fault type based on the configuration characteristics of the target component to be tested and the test metrics.

[0098] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a system testing method on the server side.

[0099] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a system testing method on the client side.

[0100] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Receive a test request for the system to be tested, and deploy the configuration file of the system to be tested to a container orchestration cluster in a preset test namespace according to the test request; Analyze the resource configuration information in the configuration file, generate a configuration file summary of the system to be tested based on the resource configuration information, and determine the application scenario of the system to be tested based on the service identification information in the configuration file; According to the application scenario, the test indicator type corresponding to the application scenario is matched from the preset scenario-indicator type mapping table. The test indicator of the system to be tested is determined according to the test indicator type and the configuration file summary. The observable data items to be collected and the corresponding thresholds are obtained from the test indicators. The test script is generated according to the observable data items and the thresholds. According to the preset configuration risk-component mapping table, system components with preset configuration risks are selected from the configuration file summary as target components to be tested, and fault injection parameters corresponding to the application scenario are set according to the target components to be tested and the test script. The testing process of the system under test is divided into a preset number of test phases. A test task description file is generated based on the execution order of each test phase, the test scripts to be called, and the corresponding fault injection parameters. The test task description file is then sent to the container orchestration cluster. The fault injection parameters are injected into the target component under test using the fault injection controller in the container orchestration cluster, and the test script is executed to monitor the status data of the test indicators of the target component under test in each test stage, and a test report is generated based on the monitored status data.

[0101] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0102] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0103] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0104] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0105] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A system testing method, characterized in that, The method includes: Receive a test request for the system to be tested, and deploy the configuration file of the system to be tested to a container orchestration cluster in a preset test namespace according to the test request; Analyze the resource configuration information in the configuration file, generate a configuration file summary of the system to be tested based on the resource configuration information, and determine the application scenario of the system to be tested based on the service identification information in the configuration file; According to the application scenario, the test indicator type corresponding to the application scenario is matched from the preset scenario-indicator type mapping table. The test indicator of the system to be tested is determined according to the test indicator type and the configuration file summary. The observable data items to be collected and the corresponding thresholds are obtained from the test indicators. The test script is generated according to the observable data items and the thresholds. According to the preset configuration risk-component mapping table, system components with preset configuration risks are selected from the configuration file summary as target components to be tested, and fault injection parameters corresponding to the application scenario are set according to the target components to be tested and the test script. The testing process of the system under test is divided into a preset number of test phases. A test task description file is generated based on the execution order of each test phase, the test scripts to be called, and the corresponding fault injection parameters. The test task description file is then sent to the container orchestration cluster. The fault injection parameters are injected into the target component under test using the fault injection controller in the container orchestration cluster, and the test script is executed to monitor the status data of the test indicators of the target component under test in each test stage, and a test report is generated based on the monitored status data.

2. The system testing method as described in claim 1, characterized in that, The step of determining the application scenario of the system to be tested based on the service identifier information in the configuration file includes: Extract keywords related to the scene semantics from the service name, namespace, and tag fields in the configuration file; The keywords are matched with a preset business scenario keyword library, and the application scenario of the system to be tested is determined based on the matching results.

3. The system testing method as described in claim 1, characterized in that, The preset scenario-index type mapping table is obtained in the following way: Obtain a preset number of document samples corresponding to known business scenarios, and mark the known business scenarios in each document sample with the corresponding scenario identifier; Extract test constraints for the distributed system from the document sample; The test constraints are mapped to the corresponding test indicator types, and a mapping relationship between each scenario identifier and the corresponding test indicator type is established. Store all mapping relationships in the scenario-metric type mapping table.

4. The system testing method as described in claim 1, characterized in that, The step of matching the test metric type corresponding to the application scenario from a preset scenario-metric type mapping table, based on the application scenario, includes: Obtain the scene identifier of the application scenario; Based on the scenario identifier, query the scenario-metric type mapping table to find the matching test metric type; The matched test metric type is used as the test metric type for the application scenario.

5. The system testing method as described in claim 1, characterized in that, Determining the test metrics of the system under test based on the test metric type and the configuration file summary includes: Extract service data associated with the service identification information from the configuration file summary; the service data includes the service name and namespace. Determine the initial indicator name based on the test indicator type; The service name and namespace are appended as tag conditions to the initial metric name to generate the test metrics for the system under test.

6. The system testing method as described in claim 1, characterized in that, The step of obtaining observable data items to be collected and corresponding thresholds from the test metrics, and generating test scripts based on the observable data items and the thresholds, includes: Based on the test metrics, determine the observable data items to be collected during the operation of the system under test; Construct test conditions for determining whether the observable data item meets the threshold of the test metric; The test conditions are encoded into test scripts that can be executed in the container orchestration cluster.

7. The system testing method as described in claim 1, characterized in that, The step of setting fault injection parameters corresponding to the application scenario based on the target component to be tested and the test script includes: Select the fault types to be tested that are suitable for the application scenario from the preset set of fault types; Select a fault type from the fault types to be tested that matches the configuration risk of the target component to be tested; Configure the injection parameters for the matching fault type based on the configuration characteristics of the target component to be tested and the test metrics.

8. A system testing device, characterized in that, The device includes: The deployment module is used to receive test requests for the system to be tested and deploy the configuration file of the system to be tested to a container orchestration cluster in a preset test namespace according to the test request. The module is used to analyze the resource configuration information in the configuration file, generate a configuration file summary of the system to be tested based on the resource configuration information, and determine the application scenario of the system to be tested based on the service identification information in the configuration file. The matching module is used to match the test indicator type corresponding to the application scenario from a preset scenario-indicator type mapping table, determine the test indicator of the system to be tested according to the test indicator type and the configuration file summary, obtain the observable data items to be collected and the corresponding thresholds from the test indicators, and generate a test script according to the observable data items and the thresholds. The configuration module is used to select system components with preset configuration risks as target components to be tested from the configuration file summary according to the preset configuration risk-component mapping table, and set fault injection parameters corresponding to the application scenario according to the target components to be tested and the test script. The partitioning module is used to divide the testing process of the system under test into a preset number of test phases, generate a test task description file based on the execution order of each test phase, the test scripts to be called and the corresponding fault injection parameters, and send the test task description file to the container orchestration cluster. The analysis module is used to inject the fault injection parameters into the target component under test using the fault injection controller in the container orchestration cluster, and execute the test script to monitor the status data of the test indicators of the target component under test in each test stage, and generate a test report based on the monitored status data.

9. A device, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a system test program that can be executed by the at least one processor, the system test program being executed by the at least one processor to enable the at least one processor to perform the system test method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a system test program, which can be executed by one or more processors to implement the system test method as described in any one of claims 1 to 7.

Images