Test method and device, storage medium and electronic equipment

Abstract

The invention discloses a test method and device, a storage medium and electronic equipment, and relates to the technical field of tests.The method comprises the steps that firstly, fault scripts in test scripts are obtained; determining a fault type corresponding to the fault script; then, according to the dependency graph corresponding to the test scripts, determining associated scripts corresponding to the fault scripts from the test scripts; and finally, testing the associated script based on the fault type to obtain a test result of the test script. According to the method, the fault script in the test script and the fault type causing the fault of the fault script can be obtained, then the correlation script associated with the fault script is searched from the test script by utilizing the dependency relationship graph corresponding to the test script, and the correlation script is tested in combination with the currently detected fault type; the associated scripts of the fault scripts are positioned, the fault detection range of the test scripts is narrowed, and potential problems of a system can be deeply mined according to fault types.

Description

Technical Field

[0001] The present disclosure relates to the field of testing technology, and in particular to a testing method, device, storage medium, and electronic device. Background Art

[0002] In order to analyze potential problems in distributed storage systems, a variety of testing methods and tools can be used to ensure the stable operation of the system.

[0003] Currently, related technologies perform multiple tests on test scripts to obtain test results corresponding to each test script.

[0004] However, it is difficult in the related art to deeply explore potential problems of the system based on the test results corresponding to each test script, which in turn affects the accuracy of the test results. Summary of the Invention

[0005] The present disclosure provides a testing method, apparatus, storage medium, and electronic device, the main purpose of which is to solve the problem that related technologies are difficult to deeply explore potential problems of the system based on the test results corresponding to each test script, thereby affecting the accuracy of the test results.

[0006] In a first aspect, the present application provides a testing method, comprising:

[0007] Get the fault script in the test script;

[0008] Determine the fault type corresponding to the fault script;

[0009] According to the dependency graph corresponding to the test script, determine the associated script corresponding to the fault script from the test script;

[0010] The associated script is tested based on the fault type, and the test result of the test script is obtained.

[0011] In a second aspect, the present application provides a testing device, comprising:

[0012] An acquisition module is configured to acquire a fault script in a test script;

[0013] A determination module is configured to determine a fault type corresponding to the fault script;

[0014] A determination module is configured to determine, from the test scripts, an associated script corresponding to the faulty script based on a dependency graph corresponding to the test scripts;

[0015] The acquisition module is configured to test the associated script based on the fault type and obtain the test result of the test script.

[0016] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, which implements the method of the first aspect when the computer program is executed by a processor.

[0017] In a fourth aspect, the present application provides an electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the method of the first aspect when executing the computer program.

[0018] In a fifth aspect, the present application provides a computer program product having a computer program stored thereon, which implements the method of the first aspect when the computer program is executed by a processor.

[0019] The present disclosure provides a test method, device, storage medium, and electronic device, wherein the method includes: first obtaining a fault script in a test script; and determining the fault type corresponding to the fault script; then, based on the dependency graph corresponding to the test script, determining the associated script corresponding to the fault script from the test script; and finally, testing the associated script based on the fault type to obtain the test result of the test script. The present application can obtain the fault script in the test script, as well as the fault type that causes the fault script to fail, and then use the dependency graph corresponding to the test script to find the associated script associated with the fault script from the test script, and test the associated script in combination with the currently detected fault type, thereby realizing the positioning of the associated script of the fault script, narrowing the fault detection range of the test script, and facilitating in-depth exploration of potential problems of the system based on the fault type, thereby improving the accuracy of the test results.

[0020] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0022] Figure 1 A flow chart of a testing method provided in an embodiment of the present application is shown;

[0023] Figure 2 A schematic diagram of another testing method provided in an embodiment of the present application is shown;

[0024] Figure 3 A schematic diagram showing an example provided by an embodiment of the present application is shown;

[0025] Figure 4 A schematic structural diagram of a testing device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0026] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0027] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0028] With the rapid development of cloud computing and big data technologies, distributed storage systems have become the core architecture for modern data processing and storage due to their high scalability, high availability, and high fault tolerance. Consequently, the complexity of distributed storage systems has also increased, especially when handling diverse and highly concurrent business scenarios, where the interaction and collaboration between their components becomes particularly complex. Distributed systems store data across multiple physical or logical storage nodes, enabling data sharing and management over a network.

[0029] Specifically, distributed storage business scenarios often involve complex processes such as large-scale data read and write operations, data migration, data backup and recovery, and data consistency verification. Under specific business models, such as high concurrent writes, uneven distribution of data hotspots, and node failures, these processes can lead to a series of problems, such as data loss, data inconsistency, performance degradation, and even system crashes, impacting the user experience.

[0030] To address potential issues in distributed storage systems, various testing methods can be applied, including unit testing, integration testing, stress testing, and fault injection testing. However, these methods still have some shortcomings when dealing with the complexity of distributed storage business scenarios. Therefore, distributed storage has introduced chaos testing. Chaos testing can improve the ability to detect potential system issues by randomly introducing various faults during system operation. However, in the context of distributed storage systems, existing chaos testing methods lack efficient algorithms tailored to the characteristics of distributed architectures to accurately locate the associated modules after discovering a problem. Moreover, the random fault injection strategy lacks systematicity and specificity, making it difficult to delve deeper into the problem from multiple dimensions. This results in inefficient troubleshooting and repair, and fails to fully guarantee the stable operation of the distributed storage system.

[0031] In order to improve the technical problem that the current related technologies are difficult to deeply explore the potential problems of the system according to the test results corresponding to each test script, thereby affecting the accuracy of the test results.

[0032] This embodiment provides a testing method, such as Figure 1 As shown, the method comprises the following steps:

[0033] Step 101: Obtain a fault script in a test script.

[0034] In some embodiments, a testing platform (such as a chaos testing platform) can be used to test each node in a distributed storage system. Test scripts (standard components) for chaos testing can be constructed, along with fault models that cause system failures or anomalies. The system's performance under different failure scenarios can be tested to identify potential weaknesses in the system and ensure that the system remains stable and reliable in the face of unforeseen problems. The standard component can be a specific functional characteristic test method.

[0035] Specifically, a test script may include a script used to perform specific test tasks during testing. In chaos testing, this can be used to simulate system behavior under normal operating conditions to verify that the system functions as expected. Fault scripts may include test scripts for failures or anomalies detected during testing. For example, if a standard component fails to operate, it is considered a problem and the standard component can be recorded as a fault script (failed standard component).

[0036] Step 102: Determine the fault type corresponding to the fault script.

[0037] The fault types of a faulty script may include, but are not limited to, forced deletion of critical data blocks, violation of data consistency protocols, network delays, inter-node communication interruptions, data collection errors, logging delays, etc. For example, when it is detected that an error occurs during the execution of a test script or that the expected results are not achieved, the test script may be identified as a faulty script, and the fault type injected into the faulty script during the test may be further detected to clarify the cause of the test script failure and facilitate in-depth exploration of potential faults in the test script.

[0038] Step 103: According to the dependency graph corresponding to the test script, determine the associated script corresponding to the fault script from the test script.

[0039] Exemplarily, the dependency graph can list all test scripts and the dependencies between scripts through graph nodes and directed edges (indicating dependency directions), such as: direct dependencies (other scripts that depend on the script, other scripts that the script depends on), indirect dependencies (dependency chains formed through a series of other scripts). Graph nodes can be used to represent standard parts, scripts, modules, services, components, etc. Each node can be attached with detailed node attribute information, such as functional descriptions, input and output interface definitions, etc. Correspondingly, the dependency graph has a specific real-time update mechanism that can be updated according to the dynamic characteristics of the distributed storage system to ensure that the graph can promptly reflect changes during system operation, so that scripts associated with faulty scripts can be fully detected during the test process, facilitating the rapid and comprehensive determination of all modules associated with the problem and the nodes where they are located.

[0040] In some embodiments, users can determine the test scope in the chaos testing platform and build a dependency graph corresponding to the test script based on the test scope, so that the dependency graph includes the dependencies between the test scripts. When there is a fault node, first determine the position of the fault node in the dependency graph, and then identify all scripts that directly or indirectly depend on it, as well as all scripts it depends on, as associated scripts corresponding to the fault script, so as to systematically analyze the fault propagation path, facilitate the location of the affected test scripts, and thus improve the test efficiency and ensure the stability of the system.

[0041] Step 104: Test the associated script based on the fault type and obtain the test result of the test script.

[0042] In some embodiments, the identified associated scripts can be tested again based on the detected fault type, and a test set can be generated based on the fault model and associated script corresponding to the fault type to narrow the test scope. In-depth exploration of fault problems can be performed within the test scope to facilitate the exploration of potential problems in the test scripts, thereby improving the accuracy of the test results.

[0043] Compared with the current existing technology, this embodiment first obtains the fault script in the test script; and determines the fault type corresponding to the fault script; then, based on the dependency graph corresponding to the test script, determines the associated script corresponding to the fault script from the test script; finally, tests the associated script based on the fault type to obtain the test result of the test script. The present application can obtain the fault script in the test script and the fault type that causes the fault script to fail, and then use the dependency graph corresponding to the test script to find the associated script associated with the fault script from the test script, and test the associated script in combination with the currently detected fault type, thereby realizing the positioning of the associated script of the fault script, narrowing the fault detection range of the test script, and facilitating in-depth mining of potential problems of the system based on the fault type, thereby improving the accuracy of the test results.

[0044] In order to further illustrate the specific implementation process of the method of this embodiment, this embodiment provides the following Figure 2 The specific method shown includes:

[0045] Step 201: Obtain a fault script in a test script.

[0046] In some embodiments, a test task issued by a user through a chaos testing platform can be received, and the platform can be used to detect the test progress of the test task. Chaos testing may include multiple rounds of testing of the test script, randomly introducing a fault model in the first round of testing, obtaining the first round of test results of the test script, and obtaining the fault script in the test script based on the first round of test results. By introducing random and uncertain fault models, situations that may occur in the actual operating environment are simulated to detect system stability.

[0047] For example, users can issue chaos testing tasks through the chaos testing platform and perform detailed configuration on the platform. The configuration information may include but is not limited to the node information to be tested, the standard parts selection set for the task start, and the preset execution success number threshold for in-depth exploration of test problems. When this threshold is reached, it can be considered that the problem module set has been discovered and can be deleted from the database.

[0048] Specifically, targeting the architectural characteristics of distributed storage systems, we construct specialized chaos testing standard components. Based on a distributed fault model, we randomly inject faults into the system. Utilizing real-time monitoring in the chaos testing backend, we determine a problem is discovered when a standard component fails. We then record the failed standard component and the fault model injected at that time. We then search for all the standard components that the standard component depends on. This, along with the currently injected fault, forms the test set for this problem discovery. Subsequently, we will inject the current fault separately and randomly inject other faults, combining this with randomly selected problematic standard components for testing until the problem no longer recurs.

[0049] Step 202: Determine the fault type corresponding to the fault script.

[0050] In some embodiments, a chaos testing platform is used to detect the execution status of each test script in real time. When a faulty script with abnormal execution is detected, the fault type randomly introduced by the faulty script during the test is obtained, and the faulty script and its corresponding fault type are recorded to facilitate multi-dimensional fault problem analysis and in-depth exploration of system faults.

[0051] Step 203: According to the dependency graph corresponding to the test script, determine the associated script corresponding to the fault script from the test script.

[0052] In some embodiments, a standard parts dependency graph of a distributed storage system is constructed and stored in a backend database. Associated scripts may include but are not limited to scripts that a faulty node depends on, scripts that depend on a faulty node, etc. These associated scripts may be affected by the fault, or may be the cause of the fault, so as to determine whether the problem originates from the faulty script itself or from the scripts it depends on, and take corresponding repair measures based on the test results, such as correcting script errors, adjusting dependencies, etc.

[0053] Optionally, step 203 may specifically include: in the dependency graph, taking the fault script as a search starting point, searching for scripts that the fault script depends on and scripts that depend on the fault script; and determining the searched scripts as associated scripts.

[0054] In some embodiments, when a test problem is discovered, the node where the module corresponding to the fault script where the problem occurs is located can be used as the search starting point in the graph to start the associated module search algorithm to search for the associated script. Specifically, a strategy based on distributed breadth-first search (DBFS) can be adopted, and the distributed computing framework can be used to perform search tasks in parallel on multiple nodes. First, the node where the starting module is located is added to a distributed queue. When the queue is not empty, the head node of the queue is taken out in a distributed manner, and all its outgoing edges (i.e., the nodes where other modules on which the module depends are located) are traversed in parallel. For each adjacent node that has not been visited, it is marked as visited and added to the queue. At the same time, the incoming edges of the module (i.e., the nodes where other modules that depend on the module are located) are traversed in parallel, and the same operation is performed on the adjacent nodes of the unvisited incoming edges. Through this distributed, parallel, bidirectional search method, all modules associated with the problem and their nodes can be quickly and comprehensively determined, and a set of problem-associated modules can be constructed, thereby narrowing the test scope of the test standard parts, facilitating in-depth excavation of specific fault causes, and thus improving test efficiency and accuracy.

[0055] Step 204: Determine the fault injection frequency of the fault type corresponding to the associated script according to the test priority of the associated script.

[0056] Optionally, step 204 may specifically include: determining a test priority of the associated script according to the system level of the functional module corresponding to the associated script; and determining a fault injection frequency of the fault type corresponding to the associated script according to a preset frequency corresponding to the test priority.

[0057] Among them, the preset frequency can be the probability that different faults may be injected into the test script, which can be preset in the test platform according to the test priority of each test script to achieve dynamic fault injection and adapt to the impact of each functional module on the system architecture.

[0058] In some embodiments, to discover problems in distributed storage systems from a wider range of perspectives, a hierarchical, dynamic, and distributed-adaptive random fault injection strategy can be designed for the set of associated modules corresponding to the identified associated scripts. Specifically, a hierarchical strategy can be constructed to divide functional modules into different system layers based on their hierarchy within the distributed storage system architecture and their impact on data storage and core system functions. The fault injection frequency of the fault type during the associated script testing can be adjusted according to the different system layers, thereby optimizing the random fault injection strategy and improving the accuracy of chaos testing.

[0059] For example, for modules that are in the core data storage and management layers and are critical to the system data consistency and availability, the preset frequency and intensity of fault injection are increased, and more destructive fault types are selected for injection, such as forced deletion of key data blocks, destruction of data consistency protocols, etc.; for middle-layer modules responsible for network communication and node coordination, a moderate fault injection frequency and intensity are used as the preset frequency, and fault types such as network delays and inter-node communication interruptions are selected; for peripheral auxiliary modules, such as monitoring modules, logging modules, etc., the preset frequency and intensity of fault injection are appropriately reduced, and relatively mild fault types are used, such as short-term data collection errors, logging delays, etc.

[0060] Step 205: Based on the fault injection frequency, determine the target fault model from the fault model set corresponding to the test script.

[0061] Optionally, step 205 may specifically include: determining a target type among the fault types based on the fault injection frequency; selecting a fault model corresponding to the target type and a randomly selected fault model from a set of fault models; and combining the fault model corresponding to the target type and the randomly selected fault model to obtain a target fault model.

[0062] In some embodiments, during the chaos testing process, a target type can be selected from the fault types detected in the current test round based on the fault injection frequency of the fault type corresponding to the associated script, and the fault model corresponding to the target type can be extracted from the fault model set. Other fault models can also be randomly selected from the fault model set for combination as the target fault model to constitute the fault model set of the associated script in the next test round.

[0063] Optionally, a distributed data analysis tool is used to analyze the test data of the test script during the test process, and the fault injection frequency corresponding to the fault type is adjusted according to the analysis result.

[0064] As a possible implementation method, during the test process, the subsequent fault injection strategy is dynamically adjusted according to the response of the distributed storage system to the injected fault. Distributed data analysis tools are used to analyze the massive operating data generated by the system in real time, including the performance indicators of each node, data transmission status, system error logs, etc. If the system shows serious abnormalities or even partial service interruption after injecting a certain type of fault, the injection frequency of faults of the same type or similar severity will be appropriately reduced in the future, and other types of faults will be explored instead; if the system shows strong tolerance to certain faults, the complexity of such faults will be increased or other faults will be combined for joint injection. For example, on the basis of network delay, node resource competition failures will be superimposed to further explore potential problems in the system. At the same time, taking into account the differences in nodes in the distributed system, the fault injection parameters are dynamically adjusted according to factors such as the hardware configuration and load conditions of different nodes to ensure the effectiveness and pertinence of the fault injection.

[0065] In this way, the fault injection strategy in the test round can be adjusted based on the fault injection frequency, making the injected fault model more targeted, so as to facilitate the exploration of potential problems in functional modules at higher levels of the system, and make full use of distributed computing resources and data processing capabilities, so that the test time is greatly shortened, the test results are more accurate and reliable, and the testing cost of the distributed storage system is effectively reduced, the software quality is improved, and a strong guarantee is provided for the stable operation of the distributed storage system.

[0066] Step 206: Use the target fault model to test the associated script and obtain the test result of the test script.

[0067] In some embodiments, by performing a first round of testing on the test script, the associated script corresponding to the fault script is identified. In the second round of testing, the target fault model can be selected based on the fault type that causes the test script to fail. A test subset (a set of problems to be discovered) is formed according to the target fault type and the associated script, and the target fault model is used to inject the re-selected fault into the associated script.

[0068] In this way, test results with a smaller test scope can be obtained based on the associated script, and fault injection can be performed using the target fault model, making the test scope more targeted and thereby improving the accuracy of the test results.

[0069] Optionally, step 206 may specifically include: randomly selecting a target script from the associated scripts; testing the target script using a target fault model, and obtaining a test result corresponding to the test script.

[0070] In some embodiments, for a set of associated scripts (associated modules), standard parts that need to be tested are randomly selected as target scripts for testing to achieve in-depth testing and problem mining. During the test process, the optimized random fault injection strategy is continuously executed, and the response of the module under various fault scenarios is closely observed, including whether the module functions normally, whether it triggers a chain reaction of other modules, the changing trend of system performance indicators, whether data consistency is affected, etc. By conducting a detailed analysis of the large amount of distributed data generated during the test, deep mining of potential problems is achieved, which facilitates the determination of the root cause of the problem, the scope of impact, and the correlation between the problems.

[0071] For example, by analyzing the time series data of data read and write operations and combining it with node status information, the root cause module of excessively high data read and write delays can be located; using a data consistency verification algorithm, the propagation path and impact range of data consistency errors can be detected.

[0072] Optionally, obtaining the test results corresponding to the test script may specifically include: forming a test subset based on the target fault model and the associated script; and obtaining the test results corresponding to the test subset according to a preset number of tests corresponding to the test subset.

[0073] In some embodiments, the preset number of tests may include a threshold of the number of successful executions of the configured test subset when the test platform issues a task. When the threshold is reached, it can be considered that the problem module set corresponding to the test subset has been discovered and can be deleted from the database.

[0074] For example, if during multiple rounds of chaos testing, the number of consecutive successful executions of a test subset reaches a successful execution threshold, the test subset in the database can be deleted, and the test results are generated based on the deleted test set; if during multiple rounds of chaos testing, the number of consecutive successful executions of a test subset does not reach a successful execution threshold, the test subset continues to be tested, and the target scripts continue to be randomly selected from the associated scripts for combination, and faults are randomly injected for testing.

[0075] In this way, the execution results of the test subset can be automatically detected and updated according to the execution results, thereby reducing the occupation of storage space and improving the utilization of storage resources.

[0076] In some embodiments, the results of the deep test are systematically organized and deeply analyzed to generate a detailed and comprehensive test report. The report content includes, but is not limited to, a detailed description of the problem (including the problems discovered for the first time and the new problems discovered during the deep testing process), complete information about the associated modules (module list, module function description, dependency diagram between modules, node location), detailed records of fault injection (injected fault type, time, frequency, combination, distribution at each node), test result analysis (module response in different fault scenarios, root cause analysis of the problem, sorting out the correlation between problems, performance evaluation based on distributed data), and targeted improvement suggestions (specific repair measures for the problems found, system optimization direction, strategies to prevent similar problems from recurring, and consideration of the scalability and compatibility of distributed systems).

[0077] As a possible implementation method, Figure 3 As shown, a problem deep discovery test method based on distributed storage chaos testing is provided. The specific implementation process may include the following steps:

[0078] (1) Development and configuration of a chaos test platform that supports parallel execution of test tasks based on different distributed storage application scenarios. For example, test tasks can be executed simultaneously for objects, files, and fast scenarios. The platform can be used to observe the progress of the current test task, the set of standard parts for each test round, and the test results (successful and failed standard parts, detailed failure information) in real time. At the same time, the platform can also perform detailed statistics by project / standard part.

[0079] (2) Construction and maintenance of distributed dependency graphs;

[0080] (3) The test platform issues a task to execute the chaos test for the first time and configures the threshold value W for the number of successful executions;

[0081] (4) If the test task has a standard part that fails to execute, execute step (5);

[0082] (5) Search and determine the associated standard parts through failed standard parts;

[0083] (6) The standard parts set and the injected fault model in step (5) are stored in the database and marked as a set of problems to be discovered;

[0084] (7) Randomly combine the standard parts in step (6) for testing and optimize the random fault injection strategy;

[0085] (8) If the test in step (7) is successfully executed continuously and reaches the set threshold W, then execute step (9); otherwise, execute step (10);

[0086] (9) deleting the set of problems to be discovered from the database;

[0087] (10) Output test results and reports.

[0088] For example, during a distributed storage chaos test, mounting a CIFs share, creating a Windows user, and then mounting the share from the client failed. This issue occurred because the system could not dynamically load and recognize the new Windows user when adding it. To address this issue, we searched for user mapping-related modules and built a collection of related problem modules, including the creation of Windows authenticated users. Further testing of this module revealed a new issue: the randomly generated name when creating a local Windows user could not begin with a dot. This issue required synchronization between the storage management software platform and the core software.

[0089] Compared with the current existing technology, this embodiment uses fault scripts to search for associated scripts, and combines distributed dependency graphs for distributed, parallel bidirectional searches, which can quickly and comprehensively determine all modules associated with the problem and their nodes, facilitate the construction of a test subset for the problem to be discovered, thereby narrowing the test scope of the test standard parts, facilitating in-depth exploration of specific fault causes, and thus improving test efficiency and accuracy, achieving efficient and accurate positioning of associated scripts, greatly improving the efficiency of distributed storage system problem troubleshooting, avoiding module omissions or blind troubleshooting that may occur in traditional methods, and is particularly suitable for the complex architecture of large-scale distributed storage systems; it also realizes multi-dimensional deep problem mining, a layered, dynamic, and distributed-adaptive random fault injection strategy, combined with a comprehensive and in-depth test plan and advanced distributed data analysis technology, which can test associated scripts from different levels and angles, fully explore the potential problems of distributed storage systems in various complex fault scenarios, significantly improve the comprehensiveness and depth of problem discovery, and can discover more hidden system defects, effectively ensuring the data integrity and service availability of distributed storage systems.

[0090] At the same time, it improves the test efficiency and quality, and optimizes the entire test process, including efficient associated module search, intelligent fault injection strategy and in-depth problem analysis. It fully utilizes distributed computing resources and data processing capabilities, greatly shortens the test time, and makes the test results more accurate and reliable. It effectively reduces the testing cost of the distributed storage system, improves the software quality, and provides a strong guarantee for the stable operation of the distributed storage system. It also enhances the system stability and reliability. By comprehensively and deeply discovering and solving potential problems in the distributed storage system, it significantly enhances the stability and reliability of the system in complex and abnormal environments, reduces the risk of serious failures such as data loss and service interruption during actual operation, improves users' trust and satisfaction with the distributed storage system, and promotes the widespread application of distributed storage technology in various fields.

[0091] The embodiment of the present application also provides a testing device, as Figure 1 and Figure 2 The specific implementation of the method shown is as follows Figure 4 As shown, the device includes: an acquisition module 31 and a determination module 32.

[0092] An acquisition module 31 is configured to acquire a fault script in a test script;

[0093] A determination module 32 is configured to determine a fault type corresponding to the fault script;

[0094] The determination module 32 is configured to determine, from the test scripts, an associated script corresponding to the faulty script based on a dependency graph corresponding to the test scripts;

[0095] The acquisition module 31 is configured to test the associated script based on the fault type and obtain the test result of the test script.

[0096] In some examples of this embodiment, the acquisition module 31 is specifically configured to determine the fault injection frequency of the fault type corresponding to the associated script based on the test priority of the associated script; based on the fault injection frequency, determine the target fault model from the fault model set corresponding to the test script; use the target fault model to test the associated script and obtain the test result of the test script.

[0097] In some examples of this embodiment, the determination module 32 is specifically configured to determine a target type among the fault types based on the fault injection frequency; select a fault model corresponding to the target type and a randomly selected fault model from the fault model set; and combine the fault model corresponding to the target type and the randomly selected fault model to obtain a target fault model.

[0098] In some examples of this embodiment, the determination module 32 is specifically configured to determine the test priority of the associated script according to the system level of the functional module corresponding to the associated script; and determine the fault injection frequency of the fault type corresponding to the associated script according to the preset frequency corresponding to the test priority.

[0099] In some examples of this embodiment, the acquisition module 31 is specifically configured to randomly select a target script from the associated scripts; test the target script using the target fault model, and obtain a test result corresponding to the test script.

[0100] In some examples of this embodiment, the acquisition module 31 is specifically configured to construct a test subset based on the target fault model and the associated script; and acquire the test result corresponding to the test subset according to the preset number of tests corresponding to the test subset.

[0101] In some examples of this embodiment, the determination module 32 is specifically configured to search for scripts that the fault script depends on and scripts that depend on the fault script in the dependency graph, taking the fault script as the search starting point; and determine the searched scripts as associated scripts.

[0102] It should be noted that for other corresponding descriptions of the functional units involved in the test device provided in this embodiment, please refer to Figure 1 and Figure 2 The corresponding description in will not be repeated here.

[0103] Based on the above Figure 1 and Figure 2 The method shown in FIG. 1 is a method for performing the above-mentioned steps. Accordingly, this embodiment further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the above-mentioned steps are performed. Figure 1 and Figure 2 The method shown.

[0104] Based on the above Figure 1 and Figure 2 The method shown in FIG. 1 is a method for performing the above-mentioned operations. Accordingly, this embodiment further provides a computer program product having a computer program stored thereon. When the computer program is executed by a processor, the above-mentioned Figure 1 and Figure 2 The method shown.

[0105] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.

[0106] Based on the above Figure 1and Figure 2 The method shown, and Figure 4 In order to achieve the above-mentioned purpose, the embodiment of the present application further provides an electronic device, such as a personal computer or a server, which includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 1 and Figure 2 The method shown.

[0107] In some embodiments, the physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a Wi-Fi module, etc. The user interface may include a display, an input unit such as a keyboard, etc. Optional user interfaces may also include a USB interface, a card reader interface, etc. The network interface may include a standard wired interface, a wireless interface (such as a Wi-Fi interface), etc. in some embodiments.

[0108] Those skilled in the art will understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.

[0109] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device, supporting the execution of information processing programs and other software and / or programs. The network communication module is used to enable communication between components within the storage medium, as well as with other hardware and software within the physical information processing device.

[0110] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform, or by hardware. By applying the solution of this embodiment, compared with the current existing technology, this embodiment uses fault scripts to search for associated scripts, and combines distributed dependency graphs to perform distributed, parallel, bidirectional searches. This can quickly and comprehensively determine all modules associated with the problem and their nodes, facilitating the construction of a test subset for the problem to be discovered, thereby narrowing the test scope of the test standard parts and facilitating in-depth exploration of specific fault causes, thereby improving test efficiency and accuracy. This achieves efficient and accurate positioning of associated scripts, greatly improving the efficiency of distributed storage system problem troubleshooting, avoiding module omissions or blind troubleshooting that may occur in traditional methods, and is particularly suitable for the complex architecture of large-scale distributed storage systems. It also implements multi-dimensional in-depth problem mining, a layered, dynamic, and distributed-adaptive random fault injection strategy, combined with a comprehensive and in-depth test plan and advanced distributed data analysis technology, and can test associated scripts from different levels and angles, fully exploring potential problems of distributed storage systems in various complex fault scenarios, significantly improving the comprehensiveness and depth of problem discovery, discovering more hidden system defects, and effectively ensuring the data integrity and service availability of distributed storage systems.

[0111] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device that includes the element.

[0112] The above are merely specific embodiments of the present application, which are intended to enable those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to these embodiments herein, but rather is intended to conform to the widest scope consistent with the principles and novel features of the present application.

Claims

1. A testing method, characterized in that: include: Get the fault script in the test script; Determine the fault type corresponding to the fault script; Determining, from the test scripts, an associated script corresponding to the fault script according to a dependency graph corresponding to the test scripts; The associated script is tested based on the fault type, and a test result of the test script is obtained.

2. The method according to claim 1, characterized in that The testing of the associated script based on the fault type and obtaining a test result of the test script includes: Determining a fault injection frequency of a fault type corresponding to the associated script according to a test priority of the associated script; Based on the fault injection frequency, determining a target fault model from a set of fault models corresponding to the test script; The associated script is tested using the target fault model to obtain a test result of the test script.

3. The method according to claim 2, characterized in that The determining, based on the fault injection frequency, a target fault model from a set of fault models corresponding to the test script includes: determining a target type among the fault types based on the fault injection frequency; Selecting a fault model corresponding to the target type and a randomly selected fault model from the fault model set; The fault model corresponding to the target type and the randomly selected fault model are combined to obtain the target fault model.

4. The method according to claim 2, characterized in that The determining, according to the test priority of the associated script, the fault injection frequency of the fault type corresponding to the associated script includes: Determining the test priority of the associated script according to the system level of the functional module corresponding to the associated script; According to the preset frequency corresponding to the test priority, the fault injection frequency of the fault type corresponding to the associated script is determined.

5. The method according to claim 2, characterized in that The testing of the associated script using the target fault model to obtain a test result of the test script includes: randomly selecting a target script from the associated scripts; The target script is tested using the target fault model to obtain a test result corresponding to the test script.

6. The method according to claim 5, characterized in that The obtaining of the test result corresponding to the test script includes: Constructing a test subset based on the target fault model and the associated script; According to the preset number of tests corresponding to the test subset, the test result corresponding to the test subset is obtained.

7. The method according to any one of claims 1 to 6, characterized in that The determining, from the test script according to the dependency graph corresponding to the test script, an associated script corresponding to the fault script includes: In the dependency graph, taking the fault script as the search starting point, search for scripts that the fault script depends on and scripts that depend on the fault script; The searched script is determined as the associated script.

8. A testing device, characterized in that: include: An acquisition module is configured to acquire a fault script in a test script; A determination module, configured to determine a fault type corresponding to the fault script; a determination module configured to determine, from the test scripts, an associated script corresponding to the faulty script based on a dependency graph corresponding to the test scripts; The acquisition module is configured to test the associated script based on the fault type and acquire a test result of the test script.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

10. An electronic device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

Images