Operating system automatic test method, system, electronic device and storage medium

Abstract

This application relates to the field of computer science and provides an automated testing method, system, electronic device, and storage medium for operating systems. The method includes: if an interface test case does not trigger a first preset skip rule, performing automated interface testing on the interface test case, capturing the first runtime output data stream and interface execution exceptions during execution, and generating interface test results; if a system script test case does not trigger a second preset skip rule, performing automated script testing on the system script test case, capturing the second runtime output data stream and script execution exceptions during execution, and generating script test results; and generating automated test results based on the interface test results and script test results. This application can achieve fully automated integrated testing of API interfaces and system scripts, meeting the testing standards of high timeliness, high coverage, and high repeatability, significantly improving testing efficiency, and significantly reducing labor costs.

Description

Technical Field

[0001] This application relates to the field of computers, and in particular to an automated testing method, system, electronic device, and storage medium for operating systems. Background Technology

[0002] An operating system consists of a series of interconnected system software programs. Its main functions are to manage and regulate the operation and scheduling of computer hardware and software resources, provide general basic services, and enable the orderly organization of human-computer interaction. Version iteration runs through the entire lifecycle of an operating system's development and maintenance. A scientifically sound iteration mechanism is crucial for improving software quality, shortening development cycles, and controlling project costs.

[0003] As operating systems (such as Windows, Linux, macOS, etc.) are updated more frequently, relying on traditional manual testing methods makes it difficult to meet the testing standards of high timeliness, high coverage, and high repeatability, which leads to a series of problems such as inefficient testing processes, increased risk of missing vulnerabilities, and excessive consumption of human and hardware resources.

[0004] Therefore, existing technologies need further improvement. Summary of the Invention

[0005] In view of this, embodiments of this application provide an automated testing method, system, electronic device, and storage medium for operating systems, in order to solve the problem that traditional manual testing methods are difficult to meet the testing standards of high timeliness, high coverage, and high repeatability, which leads to a series of problems such as inefficient testing processes, increased risk of missing vulnerabilities, and excessive consumption of human and hardware resources.

[0006] A first aspect of this application provides an automated testing method for an operating system, comprising: Respond to automated testing commands and build interface test cases and system script test cases; If the interface test case does not trigger the first preset skip rule, then the interface test case will be executed with automated interface testing, and the first run output data stream and interface execution exception during the execution process will be captured to generate interface test results; If the system script test case does not trigger the second preset skip rule, then the system script test case will be executed with script automation testing, and the second run output data stream and script execution exceptions during the execution process will be captured to generate script test results; Based on the interface test results and script test results, generate automated test results for the target operating system. Execute automated interface tests on the interface test cases, capture the first run output data stream and interface execution exceptions during the execution process, and generate interface test results, including: Construct the interface test requests corresponding to the interface test cases, and send the interface test requests to the backend business services deployed on the target operating system; If an interface execution exception is captured during the execution of automated interface testing, the exception handling strategy for the interface execution exception is determined. Based on the exception handling strategy, exceptions in interface execution are handled, exception handling results are generated, and the current automated interface test ends. Determine the exception handling strategy for interface execution exceptions, including: If the interface execution exception is an invalid URL exception, the exception handling strategy for the interface execution exception is to terminate the sending of interface test requests to the server and mark the first exception identifier. If the interface execution exception is a network link exception, the exception handling strategy for the interface execution exception is to trigger the preset exponential backoff automatic retry mechanism. When the maximum number of retries is reached and the network link exception is still displayed, a second exception identifier is marked. If the interface execution exception is a request timeout exception, the exception handling strategy for the interface execution exception is to release the connection with the backend business service of the target operating system and mark it with a third exception identifier. If the interface execution exception is a connection rejection exception, the exception handling strategy for the interface execution exception is to execute the preset fast circuit breaker strategy and mark it with the fourth exception identifier.

[0007] A second aspect of this application provides an automated operating system testing system, comprising: The data-driven management module is configured to respond to automated test commands and build interface test cases and system script test cases. The interface automation testing module is configured to perform interface automation testing on the interface test cases if the interface test cases do not trigger the first preset skip rule, and capture the first run output data stream and interface execution exceptions during the execution process to generate interface test results. The script automation testing module is configured to perform script automation testing on the system script test cases if the system script test cases do not trigger the second preset skip rule, and capture the second run output data stream and script execution exceptions during the execution process to generate script test results; The results generation module is configured to generate automated test results for the target operating system based on interface test results and script test results. Execute automated interface tests on the interface test cases, capture the first run output data stream and interface execution exceptions during the execution process, and generate interface test results, including: Construct the interface test requests corresponding to the interface test cases, and send the interface test requests to the backend business services deployed on the target operating system; If an interface execution exception is captured during the execution of automated interface testing, the exception handling strategy for the interface execution exception is determined. Based on the exception handling strategy, exceptions in interface execution are handled, exception handling results are generated, and the current automated interface test ends. Determine the exception handling strategy for interface execution exceptions, including: If the interface execution exception is an invalid URL exception, the exception handling strategy for the interface execution exception is to terminate the sending of interface test requests to the server and mark the first exception identifier. If the interface execution exception is a network link exception, the exception handling strategy for the interface execution exception is to trigger the preset exponential backoff automatic retry mechanism. When the maximum number of retries is reached and the network link exception is still displayed, a second exception identifier is marked. If the interface execution exception is a request timeout exception, the exception handling strategy for the interface execution exception is to release the connection with the backend business service of the target operating system and mark it with a third exception identifier. If the interface execution exception is a connection rejection exception, the exception handling strategy for the interface execution exception is to execute the preset fast circuit breaker strategy and mark it with the fourth exception identifier.

[0008] A third aspect of this application provides an electronic device, 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 method.

[0009] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0010] Compared with existing technologies, the beneficial effects of this application's embodiments include at least the following: This application provides an automated testing method for operating systems. It constructs interface and system script test cases in response to automated testing instructions. When the corresponding skip rule is not triggered, it executes two types of automated tests separately, captures output data streams and execution exceptions, generates corresponding test results, and finally summarizes and generates automated test results for the target operating system, achieving fully automated testing of API interfaces and system scripts. Compared with traditional manual testing, this method improves testing efficiency by more than 30%, reduces labor costs by approximately 50%, adapts to multiple scenarios including enterprise-level testing, comprehensively covers operating system testing needs, shortens the deployment iteration cycle, improves software quality, reduces operation and maintenance and defect repair costs, provides efficient and reliable technical support for the industry, and helps standardize and automate testing processes. Attached Figure Description

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

[0012] Figure 1 This is a flowchart illustrating an embodiment of an automated operating system testing method provided in this application; Figure 2 This is a flowchart illustrating an automated operating system testing method provided in another embodiment of this application; Figure 3 This is a structural block diagram of an automated operating system testing system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0014] The following will describe in detail, with reference to the accompanying drawings, an operating system automated testing method and system according to embodiments of this application.

[0015] Figure 1 This is a flowchart illustrating an embodiment of an automated operating system testing method provided in this application. This method can be executed by a backend executor. Please refer to... Figure 1 The method includes the following steps: Step S101: Respond to automated testing instructions and construct interface test cases and system script test cases.

[0016] As an example, users can send automated test commands to the backend executor by triggering pre-installed automated test function icons / buttons on the front-end interface (such as the client interface); the backend executor responds to the automated test command and loads the test case set from the specified storage location (such as backend memory, cloud server, etc.).

[0017] Step S102: If the interface test case does not trigger the first preset skip rule, then perform automated interface testing on the interface test case, capture the first running output data stream and interface execution exception during the execution process, and generate interface test results.

[0018] An API test case is the smallest unit of execution that uses an API interface (such as an HTTP interface) as the test object and standardizes the definition of request methods, access addresses, request headers, request parameters, and assertion verification rules.

[0019] The first preset skip rule is the configuration exception skip rule. When a configuration defect is detected in a test case, the skip logic is automatically triggered. For example, if a test case is missing a necessary configuration field, the HTTP interface test case is not configured with a request address URL, or the validator is not registered, the execution of the current test case will be automatically skipped.

[0020] The first runtime output data stream includes standard interface output and standard interface error. Standard interface output refers to the data returned by the interface during normal business operations; standard interface error refers to the business-related error messages actively returned by the interface.

[0021] Interface execution exceptions include interface execution environment exceptions, interface execution process exceptions, interface assertion failures, and system-level exceptions. Interface execution environment exceptions mainly include situations such as command non-existence, insufficient operation permissions, DNS resolution failure, and network link unreachability. These exceptions are all caused by external runtime environment factors and must not cause the test system to crash during handling. The exception context information must be completely retained for subsequent problem tracing and troubleshooting. Interface execution process exceptions mainly include runtime failures such as HTTP request timeouts and HTTP client call exceptions. Interface assertion failures specifically refer to situations where the validator returns a failure result, indicating that the test process has completed normally, but the actual output result does not meet the preset expectations. System-level exceptions can occur at any stage of the test execution process, specifically including internal failures such as abnormal program termination (panic), runtime errors, null pointer access, and slice index out of bounds. These exceptions must be intercepted and recovered through a capture mechanism and uniformly converted into standardized, readable test results. It is strictly prohibited for low-level exceptions to be directly exposed to upper-level business processes.

[0022] API interfaces are the core interaction method of operating systems. By conducting automated interface testing, the service availability, response status codes, and accuracy of returned data of API interfaces can be effectively verified, while also verifying the interface's operational performance and long-term stability.

[0023] In the pre-test execution phase, if an unrecoverable error such as a configuration exception is detected, the test case will be marked as failed or not executed (Failed / NotRun), terminating the subsequent test process. This can avoid invalid requests, reduce resource waste, and improve the efficiency and stability of automated execution.

[0024] Step S103: If the system script test case does not trigger the second preset skip rule, then execute the script automated test on the system script test case, capture the second running output data stream and script execution exception during the execution process, and generate the script test result.

[0025] System script test cases are the smallest automated execution units that take operating system commands and low-level script programs as test objects and define standardized execution instructions, running parameters, constraints and verification rules.

[0026] The first preset skip rule is the configuration exception skip rule. When a configuration defect is detected in a test case, the skip logic is automatically triggered. For example, if a test case is missing a necessary configuration field, the command in a Command test case is empty, or the Validator has not been registered, the execution of the current test case will be automatically skipped.

[0027] The second runtime output data stream includes script standard output and script standard error. Script standard output refers to the standard output information generated after a command or script is executed normally, indicating successful execution; script standard error refers to the business error messages generated during the execution of a command or script, indicating execution failure.

[0028] Script execution exceptions include script execution environment exceptions, script execution process exceptions, script assertion failures, and system-level exceptions. Script execution environment exceptions mainly include situations such as command non-existence, insufficient operation permissions, DNS resolution failure, and network link unreachability. These exceptions are all caused by external runtime environment factors and must not cause the test system to crash during handling. The exception context information must be completely preserved for subsequent problem tracing and troubleshooting. Script execution process exceptions are mainly manifested by the command execution function `exec.Command.Run()` returning error messages. Script assertion failures specifically refer to situations where the validator returns a failure result, indicating that the test process executed normally, but the actual output result does not meet the preset expectations. System-level exceptions can occur at any stage of the test execution process, specifically including abnormal program termination (panic), runtime errors, null pointer access, slice index out of bounds, and other internal faults. These exceptions must be intercepted and recovered through a capture mechanism and uniformly converted into standardized, readable test results. It is strictly forbidden for low-level exceptions to be directly exposed to upper-level business processes.

[0029] In practical applications, it is crucial to strictly distinguish between execution anomalies and test failures to ensure the stable, reliable, and efficient operation of the automated testing system. For example, the criteria for distinguishing between execution anomalies and test failures are shown in Table 1: Table 1 Furthermore, assertions and anomalies are fundamentally different, and their main differences are shown in Table 2: Table 2 During the execution of interface test cases and system script test cases, a global panic fallback recovery mechanism and a defer+recover mechanism are set up to intercept system-level fatal exceptions throughout the entire lifecycle of test execution, and these exceptions are uniformly converted into standardized system exception objects. A dedicated exception-to-result function is provided to bind various exceptions with the original test cases and uniformly map them to generate standardized test results. This can completely prevent the leakage of low-level exceptions to the upper layers, ensure the continuous and stable operation of a large number of automated test tasks, and ensure that all fault information can be recorded, traced, and displayed in a standardized manner.

[0030] As an example, the code implementation of the panic fallback mechanism is as follows: defer func() { if r := recover(); r != nil { / / Convert to SystemException } }().

[0031] As an example, the code implementation for the conversion logic from exception to TestResult is as follows: func ExceptionToResult(tc TestCase, ex TestException) TestResult.

[0032] As an example, when the backend test executor executes interface test cases and system script test cases, it adopts an exception handling architecture that features layered pre-validation, non-intrusive business logic throwing, global unified fallback, and global result normalization. The execution and exception routing logic is divided into stages as follows: Phase 1: Pre-entry verification (interception before execution) 1) Skip Check: As the first step in the entire process, it only determines whether the current test case needs to be skipped directly based on preset rules, and does not handle any business exceptions itself. If a low-level system panic such as a null pointer exception or runtime error is triggered at this stage, it is directly thrown outward and handled by the global fallback mechanism.

[0033] 2) Parameter Validation (Input Parameter Validity Check): This step performs a full-dimensional validation of the required fields, data format, value range, parameter type, and business dependency rules for the test cases. If the validation passes, the test proceeds to the formal execution phase; if the validation fails, a configuration parameter exception is thrown, and the test does not proceed to the next execution step. This step does not capture parameter exceptions; all thrown exceptions proceed directly to the unified exception capture stage in step 4).

[0034] Phase 2: Core Business Execution (Stateless Raw Execution) 3) Test Case Execution (HTTP Request / System Command Execution): Executes core business logic, including initiating HTTP requests, executing system commands, and calling target service interfaces. If execution is successful, the execution result is obtained and the process proceeds to the next step; if execution fails (e.g., request timeout, network connection failure, server returning a 500 error, business execution exception, etc.), an execution exception is thrown directly. This step does not catch any exceptions; all exceptions are thrown upwards to the unified exception handling layer.

[0035] Phase 3: Global Unified Anomaly Handling 4) Global Execution Exception Capture: As a globally unified exception capture point, it is responsible for capturing all exceptions thrown in steps 2) and 3), including parameter validation exceptions, execution timeout exceptions, network link exceptions, business execution exceptions, and internal system exceptions. The processing rules are as follows: after capturing an exception, record the exception information, mark the execution status as failed, skip step 5), and directly proceed to the result encapsulation in step 7); if no exception is captured, proceed normally to step 5) to execute the assertion.

[0036] Phase 4: Post-Result Judgment and Normalized Output 5) Assertion execution: The Validator will only be triggered to execute custom assertion logic if there are no execution exceptions throughout the process.

[0037] 6) Assertion failure handling: This is handled separately only for assertion failure scenarios where "the process executes successfully, but the business result does not meet expectations." It is completely isolated from execution-related exceptions and does not interfere with each other.

[0038] 7) Result encapsulation: As the final closing node of the process, regardless of whether the test case is skipped, executed successfully, executed abnormally, or assertion fails, all branches eventually converge here and are uniformly encapsulated into a standardized TestResult test result model output, realizing the unification of the entire process results.

[0039] In system-level automated testing, many critical verification tasks (such as CPU / memory / disk resource usage detection; system service status check; log integrity verification; driver, process, and port status detection; system environment consistency verification, etc.) are not suitable for completion through API interfaces. Instead, they must be completed by interacting directly with the operating system, hardware resources, or underlying services through system scripts (Shell / Bash / Python, etc.).

[0040] Before executing automated script tests, if the second preset skip rule is met, the test case will be directly intercepted without actually running the script. This avoids risks such as illegal execution, permission errors, and system crashes, and also greatly improves the stability and efficiency of automated batch execution.

[0041] Step S104: Based on the interface test results and script test results, generate automated test results corresponding to the target operating system.

[0042] This application provides an automated testing method for operating systems, capable of simultaneously supporting fully automated testing of both API interfaces and system scripts. Compared to traditional manual testing methods, this method improves overall testing efficiency by over 30%, and is widely applicable to enterprise applications, large-scale software projects, and continuous integration deployment scenarios. Simultaneously, it effectively reduces manpower input for testing, decreasing manpower costs by approximately 50%. This method comprehensively covers the testing needs of various operating system scenarios, significantly shortening the launch and iteration cycle of operating system products, effectively improving overall software quality, reducing subsequent maintenance and defect repair costs, and ultimately providing efficient and reliable technical support for enterprises and developers in the operating system field, facilitating the standardization and automation transformation and upgrading of industry testing processes.

[0043] In some embodiments, constructing interface test cases and system script test cases includes: Load the test data corresponding to the target operating system; Based on the preset data-driven configuration model, the test data is parsed into test cases for interfaces to be configured and test cases for scripts to be configured. Configure the interface test cases with variables, runtime environment parameters and test logic related to interface automation testing to build the interface test cases; Configure the variables, runtime environment parameters, and test logic related to script automation testing for the script test cases to be configured, so as to build the system script test cases.

[0044] The target operating system can be Windows, Linux, macOS, or other operating systems.

[0045] In automated testing systems, data-driven approaches are the core design philosophy. This philosophy aims to decouple test logic from test data, relying on structured test data to drive the overall test execution process. This results in easily maintainable test cases, rapidly expandable test scope, reusable execution engines, configurable test behaviors, and dynamic test parameters, effectively improving the flexibility and versatility of the automated testing system.

[0046] The data-driven configuration model is a test architecture model with data as its core carrier, adhering to the design philosophy of decoupling test logic from test data. This model uses standardized, structured formats to uniformly manage various test case data, and dynamically drives the test execution engine to complete scheduling and execution through external configuration data. It enables the addition of test cases, scenario expansion, parameter adjustment, and execution strategy configuration without modifying the underlying code, significantly improving the versatility, scalability, and maintainability of the test system.

[0047] As an example, a data-driven configuration model can be the ConfigTestCase generic configuration test case structure, used to hold standardized, configurable test case data. For instance, Table 3 illustrates some of the fields, types, JSON tags, characteristics, and meanings of this structure.

[0048] Table 3 The core of the validator registration mechanism in Table 3 above consists of two parts: first, defining a unified standard for validator functions; and second, ensuring that all custom validation logic strictly adheres to this unified input and output parameter specification. For example, a unified interface standard for validator functions can be predefined: `type ValidatorFunc func(string) (bool, string)`; where the function input is a string type, and its content can be the interface response body or the raw stdout output of the script; the function has two return values: the first is a boolean type, indicating the validation result, where `true` represents validation passed and `false` represents validation failed; the second is a string type, used to return validation details, result prompts, or specific reasons for failure.

[0049] Taking the http_status_200 status code validator as an example, the implementation code of its registration process is as follows: func init() { validatorRegistry["http_status_200"] = func(output string) (bool,string) { if strings.Contains(output, "Status: 200") { The HTTP status code verification passed. } return false, "HTTP status code not 200" } The core logic of this validator is as follows: it checks whether the execution result string contains the Status:200 identifier; if it does, it returns true and a success message; if it does not, it returns false and the reason for the failure. This validator is mainly used for validating the HTTP response status of API interfaces and checking interface connectivity.

[0050] Taking the contains_success generic keyword validator as an example, the implementation code of its registration process is as follows: validatorRegistry["contains_success"] = func(output string) (bool,string) { if strings.Contains(output, "success") { The function `return true` indicates that the message "success" is included. } The message "success not included" returns false. } } This validator is used to detect whether the execution result contains the keyword "success". If it does, it returns a successful verification mark and corresponding prompt information; otherwise, it returns a failed verification mark and reason explanation. It can be used for result verification of both API interface testing and system script testing.

[0051] As an example, a pluggable management system for pre-skip mechanisms (design of a first preset skip rule and a second preset skip rule) can be implemented by defining a global skip rule registry (skipRegistry). Taking the env_not_prod environment skip rule as an example, this rule determines the current runtime environment by obtaining the system environment variable ENV. If it is a non-production environment, it returns a skip flag and the corresponding reason, terminating the test case execution; if it is a production environment, it does not skip, ensuring that test cases are executed according to environment differences, thus improving the security and flexibility of automated testing.

[0052] As an example, the backend executor responds to automated test commands and, based on the data-driven configuration model shown in Table 1 above, reads and loads core test data such as test cases, execution parameters, and assertion rules adapted to the target operating system in batches from JSON structured data files, YAML configuration files, and the backend database. It then maps / parses this test data into interface test cases and script test cases to be configured for the target operating system.

[0053] As an example, the steps for constructing interface test cases include: First, determining the request type, access address, business scenario, and compatible operating system range of the API interface to be tested; then, configuring variables related to interface automation testing, such as global public variables, interface request variables, dynamic parameters, authentication credentials, and business-defined variables; configuring runtime environment parameters related to interface automation testing, such as request timeout, request headers, request encoding, network configuration, environment domain name, and service connectivity parameters; configuring test logic related to interface automation testing, such as pre-skip rules (i.e., the first preset skip rule), exception retry strategies (such as exponential backoff), circuit breakers, request parameter assembly rules, and interface dependency execution order; configuring interface result verification logic, defining assertion rules and judgment criteria for response status codes, interface standard output, business return fields, and interface standard errors; binding test case categories, tags, execution permissions, and runtime constraints to complete full configuration integration; finally, formatting and encapsulating the configuration content and performing legality verification to generate standardized, executable, and complete interface test cases.

[0054] As an example, the steps for constructing system script test cases include: First, determining the system commands to be executed, script paths, instruction functions, and compatible operating system types; then, configuring variables related to script automation testing, such as system environment variables, script input parameter variables, path variables, permission variables, and custom global variables; configuring runtime environment parameters related to script automation testing, covering script execution timeout thresholds, system running permissions, working directory, command execution encoding, and system architecture adaptation parameters; configuring test logic related to script automation testing, such as operating system matching verification, pre-permission detection, dependency file pre-verification, process start / stop control, and high-risk operation interception strategies; configuring script result verification logic, defining assertion rules and result judgment criteria for process exit codes, script standard output, script standard errors, and script execution exceptions; configuring script-specific pre-skip rules (i.e., the second preset skip rule), execution whitelist / blacklist, runtime load constraints, and multi-system compatibility adaptation strategies; finally, unifying and standardizing script instructions, parameters, verification rules, and control strategies, completing configuration legality verification and structured encapsulation, and generating complete system script test cases that can be scheduled for execution.

[0055] In some embodiments, automated interface testing is performed on interface test cases, and interface standard output, interface standard errors, and interface execution exceptions are captured during the execution process to generate interface test results, including: Construct the interface test requests corresponding to the interface test cases, and send the interface test requests to the backend business services deployed on the target operating system; If a test response is received from the backend business service in response to the interface test request, and no interface execution exception is captured during the execution of the interface automated test, then the interface test result is generated based on the test response information. The test response information includes the interface standard output and interface standard error during the execution of the interface automated test.

[0056] Specifically, the backend executor assembles and generates a corresponding standardized interface test request based on the constructed interface test cases. The core key fields of this request are shown in Table 4. Subsequently, the backend executor initiates and sends the interface test request to the backend business service deployed on the target operating system.

[0057] Table 4 After initiating an API test request, the backend executor completes the entire process of response reception, exception handling, and result generation by following these steps: 1) The backend executor waits for the target service to respond and fully receives the test response information, such as the response message, status code, and response header, returned by the interface.

[0058] 2) The backend executor monitors in real time whether there are any interface execution exceptions such as network errors, connection timeouts, service unreachability, or request failures during the interface call process, and captures the exception information.

[0059] 3) If the test response information is successfully received and no interface execution exception is captured, proceed to the test result generation stage; otherwise, mark it as execution failure.

[0060] 4) Parse the interface standard output (response body / normal return data) and interface standard error (error code, error message) from the response information.

[0061] 5) Based on the preset validator, assertions are made on the standard output and standard error. Combined with the response status and execution status, a complete interface test result is generated, which includes test case ID, execution status, success / failure, time consumption, and log information.

[0062] In some embodiments, after sending an interface test request to the server, the method further includes: If an interface execution exception is captured during the execution of automated interface testing, the exception handling strategy for the interface execution exception is determined. Based on the exception handling strategy, exceptions in interface execution are handled, exception handling results are generated, and the current automated interface test ends.

[0063] During automated API testing, common API execution exceptions mainly fall into four categories: invalid URL exceptions, network link exceptions, request timeout exceptions, and connection rejection exceptions. Invalid URL exceptions are generally caused by defects in test case configuration, specifically manifested as incorrect URL format, invalid access address, invalid domain name, and other configuration-related issues. Network link exceptions are low-level network failures, encompassing network fluctuations, link communication interruptions, and unreachable routing. Request timeout exceptions occur when an API request exceeds the system's preset maximum response time, and the target service fails to return a response for an extended period. Connection rejection exceptions indicate that the target business service actively refuses to establish a connection; common causes include service not starting normally, listening ports not being open, and firewall policy blocking.

[0064] In some embodiments, determining an exception handling strategy for interface execution exceptions includes: If the interface execution exception is an invalid URL exception, the exception handling strategy for the interface execution exception is to terminate the sending of interface test requests to the server and mark the first exception identifier. If the interface execution exception is a network link exception, the exception handling strategy for the interface execution exception is to trigger the preset exponential backoff automatic retry mechanism. When the maximum number of retries is reached and the network link exception is still displayed, a second exception identifier is marked. If the interface execution exception is a request timeout exception, the exception handling strategy for the interface execution exception is to release the connection with the backend business service of the target operating system and mark it with a third exception identifier. If the interface execution exception is a connection rejection exception, the exception handling strategy for the interface execution exception is to execute the preset fast circuit breaker strategy and mark it with the fourth exception identifier.

[0065] The first exception identifier can be configured to indicate an invalid URL. The second exception identifier can be configured to indicate a network link error. The third exception identifier can be configured to indicate a request timeout error. The fourth exception identifier can be configured to indicate a connection rejection error.

[0066] The exponential backoff automatic retry mechanism is an intelligent fault-tolerant retry strategy for transient failures. This mechanism pre-configures the maximum number of retries and the basic waiting latency. When test execution encounters temporary anomalies such as network jitter, brief service overload, or request timeouts, it does not execute high-frequency immediate retries. Instead, the waiting interval between adjacent retries increases exponentially. Simultaneously, random jitter can be introduced to disrupt the retry sequence, preventing instantaneous traffic from overwhelming the target service. If any call succeeds during the retry process, the test is considered normal; if all retries are exhausted and the test still fails, it is considered a failure. This mechanism can significantly improve the pass rate of tests in occasional scenarios while ensuring the operational stability of the system under test and the test cluster.

[0067] As an example, the backend test executor captures various interface execution exceptions in real time during the interface automation testing process, and executes corresponding differentiated handling strategies according to the exception type. The specific implementation steps are as follows: 1) Real-time capture of interface execution exceptions: The backend executor continuously listens for exception information throughout the entire process of interface test request construction, interface test request sending, and waiting for response, and accurately identifies the exception type.

[0068] 2) Execute corresponding handling strategies based on the exception type: ① If it is a URL invalid exception, immediately terminate the current interface test request sending process, do not initiate any network requests to the operating system's backend business service, and mark it with the first exception identifier, recording the URL invalid exception. ② If it is a network link exception, trigger the preset exponential backoff automatic retry mechanism, and re-initiate the interface test request at exponentially increasing intervals; if the network link exception still exists after the number of retries reaches the preset maximum number of retries, stop retries and mark it with the second exception identifier. ③ If it is a request timeout exception, actively release the network connection resources between the target operating system's backend business service, close the current timeout request to avoid connection occupation and leakage, and mark it with the third exception identifier. ④ If it is a connection rejection exception, determine that the target service is unavailable, immediately execute the fast circuit breaker strategy, block the sending of subsequent requests to prevent invalid retries, and mark it with the fourth exception identifier.

[0069] 3) Generate abnormal test results: After completing the corresponding abnormal handling, write the abnormal identifier, abnormal type, abnormal description and other information into the interface test results to form a standardized execution report that is traceable and can be displayed.

[0070] The HTTP interface test construction mechanism and request exception handling scheme provided in this application embodiment include a complete interface test execution process including: First, the standardized request creation process: The backend test executor constructs an HTTP request object based on the configured standardized interface test cases, completes the request header configuration and content-type data format setting in sequence, and finally formally initiates an interface test request to the backend business service of the target operating system.

[0071] Second, a full-link hierarchical anomaly tolerance mechanism: For typical anomaly scenarios that are common throughout the entire lifecycle of an interface call, such as invalid URLs, network link fluctuations, request response timeouts, and server connection rejections, it achieves unified capture, accurate classification and identification, and differentiated fault tolerance fallback processing. This not only avoids the interruption of the overall automated batch testing tasks due to single-point interface failures, but also retains complete source tracing log information such as anomaly types and fault links, which is convenient for subsequent location and investigation.

[0072] Third, standardized response parsing and data output design: After successfully receiving the response message returned by the backend business service, the system extracts and encapsulates three core response data types in a structured manner: the response status code resp.StatusCode, the response header resp.Header, and the response payload body resp.Body. This provides comprehensive, well-organized, and reliable raw data support for the assertion verification logic of the subsequent general validator and the standardized generation of the final test results (such as automatic JSON formatting).

[0073] This solution significantly improves the operational stability, robustness, and long-term maintainability of the operating system automated interface testing system through an overall architecture design that combines standardized forward execution processes, full coverage of abnormal failure scenarios, hierarchical fault tolerance, and precise source tracing. It is especially suitable for high-concurrency, high-volume, and high-frequency automated regression testing business scenarios.

[0074] In some embodiments, automated script testing is performed on system script test cases, and standard script output, standard script errors, and script execution exceptions are captured during the execution process to generate script test results, including: Create a command-line script corresponding to the system script test cases, and execute the command-line script. If no script execution exception is captured during the execution of the script running from the command line, then collect the script's standard output and standard error from the command line. The script test results are generated based on the script's standard output and standard errors.

[0075] As an example, the data structure of the system script test case is as follows: type TestCase struct { IDstring Namestring Description string Command[]string Validatorfunc(string) (bool, string) SkipCheckfunc() (bool, string) } The key fields for this use case include ID (a unique identifier for the use case, supporting Suite grouping), Command (script execution command), and Validator (assertions on the script output).

[0076] As an example, the system script test case is defined as follows: { ID:"07 source_occupy-check_mem", Name: "002 Monitoring Memory Resources" Description: "Check memory source" - Monitor memory resources. Command:[]string{"sh","-c",". / scripts / sysbase-07-source / 002-check_mem_source.sh"}, Validator: func(output string) (bool, string) { if strings.Contains(output, "pass") { The message "Memory resource usage is normal" returns true. } The message "Memory resource usage is abnormal" returned false. }, }, This script test case specifies the path to the memory resource monitoring script to be executed in the operating system under test by configuring basic metadata such as a unique ID, test case name, and function description. It also includes standardized result verification logic: after executing the memory monitoring script, if the output contains the keyword "pass," the system memory resource usage is considered normal; otherwise, it is considered abnormal. This test case can be automatically parsed, scheduled, and executed by the backend executor, thus achieving automated, unattended verification of operating system resource scenarios.

[0077] This test case fully demonstrates the typical characteristics of the system script testing module: First, the execution logic is completely externalized, with specific business testing capabilities implemented by an independent Shell script; second, the Go language framework layer is only responsible for script scheduling, output collection, and result assertion; and third, the final execution result of the test case is entirely driven by the script output, possessing highly flexible, easily extensible, and easily maintainable characteristics.

[0078] As an example, the standardized execution flow of system script test cases is as follows: The backend executor first receives and parses the system script test cases (TestCase) to be run; then it performs a pre-skip check (SkipCheck) to determine whether the current test case needs to be skipped directly based on environment, permission, and other rules; if no skipping is required, it creates a corresponding command-line script instance (i.e., the command execution object exec.Command) based on the command information configured in the system script test case, and binds standard output (stdout) and standard error (stderr) pipes to collect complete execution logs; then it initializes the command-line script and starts its execution; and finally, it listens for and captures the execution of the command-line script. The test case will detect any exceptions that may occur during the execution process. If a script execution exception is successfully captured, the test case will be marked as failed and the exception information will be recorded. If no script execution exceptions are captured during the execution of the script from the command line (such as script not existing, insufficient permissions, crash, forced exit, etc.), the script's standard output (stdout) and standard error (stderr) will be merged and formatted. After the script finishes running, the corresponding validator will be called to assert the merged output. Finally, based on the validation results, a script test result (TestResult) containing the execution status, output logs, and exception information will be generated, completing the full lifecycle execution of a single system script test case.

[0079] In some embodiments, the interface test results and script test results are encapsulated to obtain automated test results corresponding to the target operating system, including: Extract common output features from interface test results and script test results, and define a unified automated test result model; The interface test results and script test results are mapped to the automated test result model respectively to obtain the automated test results corresponding to the target operating system.

[0080] Specifically, the backend executor performs commonality analysis on the interface test results and script test results, extracting common output features of the two types of results, including test case identifier, test case name, execution status, execution time, standard output information, standard error information, verification results, exception identifiers, and exception descriptions. Based on these common features, a standardized, generalized, and scalable unified automated test result model is defined. Next, the raw results generated by HTTP interface tests are mapped one-to-one according to the field specifications of the unified automated test result model, completing the formatted encapsulation of execution status, response data, verification conclusions, and exception information, forming standardized interface results conforming to the unified model. The raw results generated by system script tests are mapped and populated according to the same unified automated test result model, completing the encapsulation of script execution output, verification conclusions, exception information, and runtime logs, forming standardized script results conforming to the unified model. Finally, the standardized interface results and standardized script results after model mapping are integrated, categorized, and aggregated, organized uniformly by test case dimension, execution stage, and exception type, ultimately generating the final automated test results for the target operating system that cover all scenarios, have a unified format, and are easy to display and analyze.

[0081] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0082] Figure 2 This is a flowchart illustrating an automated operating system testing method according to another embodiment of this application. Please refer to... Figure 2 The method includes the following steps: a) Respond to automated testing commands and build interface test cases and system script test cases; b1) Determine whether the interface test case triggers the first preset skip rule; b2) Determine whether the system script test case triggers the second preset skip rule; c1) If the interface test case does not trigger the first preset skip rule, then perform interface automated testing on the interface test case; if the interface test case triggers the first preset skip rule, then proceed to step c3) mark the skip status and record the skip reason; c2) If the system script test case does not trigger the second preset skip rule, then execute the script automated test on the system script test case; if the system script test case triggers the second preset skip rule, then jump to step c4) mark the skip status and record the skip reason; d1) Determine whether an interface execution exception was captured during the automated testing process of the interface test cases; d2) Determine whether any script execution exceptions were captured during the automated testing of system script test cases; e1) If an interface execution exception or script execution exception is caught, mark the execution status as failed and proceed to step g). e2) If no interface execution exception is caught, the validator is invoked to perform assertions on the interface test results; if no script execution exception is caught, the validator is invoked to perform assertions on the script test results. f1) If the interface test result assertion passes, mark the assertion status as passed; if the script test result assertion passes, mark the assertion status as passed. f2) If the interface test result assertion fails, mark the assertion status as failed; if the script test result assertion fails, mark the assertion status as failed. g) Encapsulate the interface test results and script test results to obtain the automated test results corresponding to the target operating system; h) Push automated test results to the front end in real time, or generate automated test reports.

[0083] The operating system automated testing method provided in this application takes full-process automation as its core capability, and fully covers the entire chain of test preparation, task scheduling and execution, result analysis and report output. It can be compatible with mainstream multi-operating system environments such as Windows, Linux, and macOS to carry out cross-platform consistency testing.

[0084] This testing system adopts a highly cohesive and loosely coupled modular architecture, with Go as the core development language, integrating mature automation frameworks such as Selenium and Appium, while also taking into account both GUI graphical interface automation and command-line automation scenarios; and natively supporting flexible extensions with mainstream scripting languages ​​such as Bash and PowerShell.

[0085] The system's core capabilities include full lifecycle management of test cases, distributed automated scheduling and execution, multi-dimensional test result statistics, hierarchical global exception handling, and automatic generation of visual test reports, comprehensively ensuring the efficiency, stability, full controllability, and full traceability of the overall testing process.

[0086] The following are system embodiments of this application, which can be used to execute the method embodiments of this application. For details not disclosed in the system embodiments of this application, please refer to the method embodiments of this application.

[0087] Figure 3 This is a structural block diagram of an automated operating system testing system provided in an embodiment of this application. Figure 3 As shown, the automated testing system 300 for the operating system includes: The data-driven management module 301 is configured to respond to automated test commands and build interface test cases and system script test cases. The interface automation testing module 302 is configured to perform interface automation testing on the interface test cases if the interface test cases do not trigger the first preset skip rule, and capture the interface standard output, interface standard error, and interface execution exception during the execution process, and generate interface test results. Among them, interface standard output refers to the normal business return data of the interface; interface standard error refers to the business class error message actively returned by the interface; and interface execution exception refers to the underlying communication and operation failures generated in the call chain and during the operation. The script automation testing module 303 is configured to perform script automation testing on the system script test cases if the second preset skip rule is not triggered, and to capture the script standard output, script standard error, and script execution exception during the execution process, and generate script test results. Among them, script standard output refers to the standard output information generated after the command or script is executed normally, which represents successful execution; script standard error refers to the business error prompt information generated during the execution of the command or script, which represents execution failure; script execution exception refers to the underlying runtime failure that occurs during the startup or running phase of the command or script. The result generation module 304 is configured to generate automated test results for the target operating system based on the interface test results and script test results. Execute automated interface tests on the interface test cases, capture the first run output data stream and interface execution exceptions during the execution process, and generate interface test results, including: Construct the interface test requests corresponding to the interface test cases, and send the interface test requests to the backend business services deployed on the target operating system; If an interface execution exception is captured during the execution of automated interface testing, the exception handling strategy for the interface execution exception is determined. Based on the exception handling strategy, exceptions in interface execution are handled, exception handling results are generated, and the current automated interface test ends. Determine the exception handling strategy for interface execution exceptions, including: If the interface execution exception is an invalid URL exception, the exception handling strategy for the interface execution exception is to terminate the sending of interface test requests to the server and mark the first exception identifier. If the interface execution exception is a network link exception, the exception handling strategy for the interface execution exception is to trigger the preset exponential backoff automatic retry mechanism. When the maximum number of retries is reached and the network link exception is still displayed, a second exception identifier is marked. If the interface execution exception is a request timeout exception, the exception handling strategy for the interface execution exception is to release the connection with the backend business service of the target operating system and mark it with a third exception identifier. If the interface execution exception is a connection rejection exception, the exception handling strategy for the interface execution exception is to execute the preset fast circuit breaker strategy and mark it with the fourth exception identifier.

[0088] This automated testing system possesses comprehensive capabilities across the entire operating system automation testing process, covering test preparation, automated execution, result analysis, and report output. It is compatible with mainstream operating systems such as Windows, Linux, and macOS. The system adopts a modular design, is developed based on the Go programming language, and integrates components such as Selenium and Appium to achieve graphical interface and command-line automation. It also supports scripting language extensions such as Bash and PowerShell. Core capabilities include test case management, automated execution, result statistics, exception handling, and report generation, ensuring efficient operation and full traceability throughout the testing process.

[0089] In terms of test case management, the system supports the creation, editing, and hierarchical management of test cases. YAML and JSON format test case files can be imported via a visual interface or command line. Execution paths, data specifications, and expected results can be customized for file read / write operations. The system integrates Git version control, enabling test case iteration tracking and reuse. It also supports parametric testing, automatically generating multiple sets of derived test cases by configuring variable ranges to improve test coverage. Test cases can also be categorized and grouped according to functional modules and risk priorities, facilitating unified management of large-scale testing tasks.

[0090] At the automation level, it supports multiple execution modes including serial, parallel, and distributed execution, and can automatically complete test environment deployment, dependency installation, and virtual machine scheduling. It can simulate system scenarios such as multi-threaded operation and resource scheduling, monitor CPU and memory usage in real time, and verify system stability and deadlock risks. The execution process incorporates timeout control, exception retry, and environment snapshot rollback mechanisms. Before execution, it automatically checks the system version, hardware configuration, and other basic environment parameters to unify the test baseline. Relying on distributed interfaces, it can link multiple test devices to conduct simultaneous cross-platform collaborative testing.

[0091] In terms of results statistics and visualization, the system provides real-time statistics on test case status, including pass, failure, non-execution, and skipped status, and dynamically updates statistical indicators. The front-end utilizes mature components to build a visualization panel, using color labels to distinguish different execution results and supporting detailed queries such as logs, screenshots, and operation replays. Combined with data analysis capabilities, it automatically generates statistical charts such as version iteration failure trends and defect distribution, intuitively pinpointing testing shortcomings and system bottlenecks.

[0092] In terms of exception handling, the framework has built-in full-process exception capture capabilities, which can identify various faults such as system crashes, network interruptions, and permission violations, and classify and handle them differently from program defects and environmental issues. For recoverable exceptions, it supports automatic retry or downgrade skipping, and allows configuration of pre- and post-hook functions to complete resource pre-checks; all exception logs are stored in a unified structure and can be exported and archived, and combined with email and Webhook alert mechanisms, high-priority fault information is pushed in a timely manner.

[0093] In terms of report generation, it supports exporting reports in multiple formats such as HTML, PDF, and Excel. The content includes overall statistical data, single test case execution details, and performance metrics. It provides customizable template configurations, allowing for customized display content and styles. The system automatically generates visual statistical charts and can connect to defect platforms such as Jira and Bugzilla to achieve automatic issue archiving and closed-loop management.

[0094] Furthermore, the system offers global parameter configuration, supporting customization of timeout thresholds, log levels, and proxy policies. Its plug-in architecture allows for the integration of third-party tools such as memory monitoring. Sensitive data encryption and role-based access control ensure platform security. The system balances onboarding for new users with advanced API customization capabilities, delivering excellent performance and efficiently handling large-scale test case execution. Future development can incorporate intelligent algorithms to optimize test case scheduling strategies, fully meeting the routine regression testing needs of enterprise-level operating systems and significantly improving overall testing efficiency.

[0095] This automated testing system provides an initialization guide for novice users and offers comprehensive secondary development APIs for advanced users. It has undergone deep performance optimization and can stably handle the concurrent scheduling of thousands of test cases in a general standard hardware environment, with system response latency controlled within 1 second. Subsequent versions will introduce artificial intelligence capabilities, relying on machine learning algorithms to achieve intelligent prediction and accurate screening of high-risk test cases. This system is feature-rich and comprehensive, fully adaptable to various operating system testing scenarios, improving overall testing efficiency by approximately 40%, and fully meeting the needs of enterprise-level routine testing applications.

[0096] In some implementations, the data-driven management module 301 described above can be specifically configured as follows: Load the test data corresponding to the target operating system; based on the preset data-driven configuration model, parse the test data into interface test cases to be configured and script test cases to be configured; configure variables, runtime environment parameters and test logic related to interface automation testing for the interface test cases to be configured, so as to construct the interface test cases; configure variables, runtime environment parameters and test logic related to script automation testing for the script test cases to be configured, so as to construct the system script test cases.

[0097] In some implementations, after constructing the interface test request corresponding to the interface test case and sending the interface test request to the backend business service deployed on the target operating system, the method further includes: if the test response information returned by the backend business service in response to the interface test request is received, and no interface execution exception generated during the execution of the interface automated test is captured, then the interface test result is generated based on the test response information, and the test response information includes the interface standard output and interface standard error during the execution of the interface automated test.

[0098] In some implementations, the script-automated testing module 303 described above may be specifically configured as follows: Create a command-line script corresponding to the system script test cases and execute the command-line script; if no script execution exception is captured during the execution of the command-line script, collect the script standard output and script standard error of the command-line script; generate script test results based on the script standard output and script standard error.

[0099] In some implementations, the interface test results and script test results are encapsulated to obtain automated test results corresponding to the target operating system, including: Extract common output features from interface test results and script test results, and define a unified automated test result model; map the interface test results and script test results to the automated test result model respectively to obtain the automated test results corresponding to the target operating system.

[0100] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0101] Figure 4 This is a schematic diagram of the electronic device 400 provided in an embodiment of this application. Figure 4 As shown, the electronic device 400 of this embodiment includes a processor 401, a memory 402, and a computer program 403 stored in the memory 402 and executable on the processor 401. When the processor 401 executes the computer program 403, it implements the steps in the various method embodiments described above. Alternatively, when the processor 401 executes the computer program 403, it implements the functions of each module / unit in the various device embodiments described above.

[0102] Electronic device 400 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 400 may include, but is not limited to, processor 401 and memory 402. Those skilled in the art will understand that... Figure 4This is merely an example of electronic device 400 and does not constitute a limitation on electronic device 400. It may include more or fewer components than shown, or different components.

[0103] The processor 401 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0104] The memory 402 can be an internal storage unit of the electronic device 400, such as a hard disk or RAM of the electronic device 400. The memory 402 can also be an external storage device of the electronic device 400, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 400. The memory 402 can also include both internal and external storage units of the electronic device 400. The memory 402 is used to store computer programs and other programs and data required by the electronic device.

[0105] 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 merely 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. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0106] If an integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in a computer-readable medium can be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0107] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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. Such 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 this application, and should all be included within the protection scope of this application.

Claims

1. An automated testing method for an operating system, characterized in that, include: Respond to automated testing commands and build interface test cases and system script test cases; If the interface test case does not trigger the first preset skip rule, then the interface test case is subjected to automated interface testing, and the first runtime output data stream and interface execution exception during the execution process are captured to generate interface test results; If the system script test case does not trigger the second preset skip rule, then the system script test case is subjected to automated script testing, and the second runtime output data stream and script execution exceptions during the execution process are captured to generate script test results; Based on the interface test results and script test results, generate automated test results corresponding to the target operating system; Execute automated interface testing on the interface test cases, capture the first runtime output data stream and interface execution exceptions during the execution process, and generate interface test results, including: Construct the interface test request corresponding to the interface test case, and send the interface test request to the backend business service deployed on the target operating system; If an interface execution exception is captured during the execution of automated interface testing, the exception handling strategy for the interface execution exception is determined. Based on the aforementioned exception handling strategy, the exceptions executed on the interface are processed, exception handling results are generated, and the current automated interface test ends. The exception handling strategy for determining the interface execution exception includes: If the interface execution exception is an invalid URL exception, the exception handling strategy for the interface execution exception is to terminate the sending of the interface test request to the server and mark it with the first exception identifier. If the interface execution exception is a network link exception, the exception handling strategy for the interface execution exception is to trigger a preset exponential backoff automatic retry mechanism. When the maximum number of retries is reached and the network link exception is still displayed, a second exception identifier is marked. If the interface execution exception is a request timeout exception, the exception handling strategy for the interface execution exception is to release the connection with the backend business service of the target operating system and mark it with a third exception identifier. If the interface execution exception is a connection rejection exception, the exception handling strategy for the interface execution exception is to execute the preset fast circuit breaker strategy and mark the fourth exception identifier.

2. The method according to claim 1, characterized in that, Construct interface test cases and system script test cases, including: Load the test data corresponding to the target operating system; Based on a preset data-driven configuration model, the test data is parsed into test cases for interfaces to be configured and test cases for scripts to be configured. Configure the interface test cases to be configured with variables, runtime environment parameters and test logic related to interface automation testing, so as to construct the interface test cases; Configure the variables, runtime environment parameters, and test logic related to script automation testing for the script test cases to be configured, so as to construct the system script test cases.

3. The method according to claim 1, characterized in that, After sending the interface test request to the backend business service deployed on the target operating system, the process also includes: If the backend business service receives the test response information returned for the interface test request, and no interface execution exception is captured during the execution of the interface automated test, then the interface test result is generated based on the test response information, which includes a first runtime output data stream.

4. The method according to claim 1, characterized in that, The system script test cases are executed with automated script testing, and the second runtime output data stream and script execution exceptions during the execution process are captured to generate script test results, including: Create a command-line script corresponding to the system script test case, and execute the command-line script. If no script execution exception is detected during the execution of the command-line script, then the second execution output data stream during the execution of the command-line script is collected. Based on the second runtime output data stream, the script test results are generated.

5. The method according to claim 1, characterized in that, The interface test results and script test results are encapsulated to obtain the automated test results corresponding to the target operating system, including: Extract the common output features of the interface test results and script test results, and define a unified automated test result model; The interface test results and script test results are mapped to the automated test result model to obtain the automated test results corresponding to the target operating system.

6. An automated testing system for an operating system, characterized in that, include: The data-driven management module is configured to respond to automated test commands and build interface test cases and system script test cases. The interface automation testing module is configured to perform interface automation testing on the interface test case if the interface test case does not trigger the first preset skip rule, and capture the first run output data stream and interface execution exception during the execution process to generate interface test results. The script automation testing module is configured to perform script automation testing on the system script test cases if the system script test cases do not trigger the second preset skip rule, and capture the second running output data stream and script execution exceptions during the execution process to generate script test results; The result generation module is configured to generate automated test results corresponding to the target operating system based on the interface test results and script test results. Execute automated interface testing on the interface test cases, capture the first runtime output data stream and interface execution exceptions during the execution process, and generate interface test results, including: Construct the interface test request corresponding to the interface test case, and send the interface test request to the backend business service deployed on the target operating system; If an interface execution exception is captured during the execution of automated interface testing, the exception handling strategy for the interface execution exception is determined. Based on the aforementioned exception handling strategy, the exceptions executed on the interface are processed, exception handling results are generated, and the current automated interface test ends. The exception handling strategy for determining the interface execution exception includes: If the interface execution exception is an invalid URL exception, the exception handling strategy for the interface execution exception is to terminate the sending of the interface test request to the server and mark it with the first exception identifier. If the interface execution exception is a network link exception, the exception handling strategy for the interface execution exception is to trigger a preset exponential backoff automatic retry mechanism. When the maximum number of retries is reached and the network link exception is still displayed, a second exception identifier is marked. If the interface execution exception is a request timeout exception, the exception handling strategy for the interface execution exception is to release the connection with the backend business service of the target operating system and mark it with a third exception identifier. If the interface execution exception is a connection rejection exception, the exception handling strategy for the interface execution exception is to execute the preset fast circuit breaker strategy and mark the fourth exception identifier.

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

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 5.

Images