Defect detection method and device for interaction code coverage, equipment and medium

Abstract

The application provides a defect detection method, device and equipment of interactive code coverage and a medium. The defect detection method of interactive code coverage comprises the following steps: performing static analysis on a target system by using a hook function to obtain a stain set and a call graph of the interactive code configured by the target system; determining a running state graph of the target system according to the stain set and the call graph; obtaining the configuration coverage and the call stack information of the target system subjected to a workload by using the hook function, and testing the target system according to the configuration coverage, the call stack information and the running state graph to obtain a seed pool and a variation configuration parameter of the test; and performing iterative testing according to the seed pool and the variation configuration parameter to obtain a configuration defect detection result. The application has the beneficial effect of improving the configuration interactive code coverage and the overall code coverage.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, and medium for detecting defects in interactive code coverage. Background Technology

[0002] Large-scale software systems contain hundreds or even thousands of configuration parameters. Users can modify these parameters to alter the system's resource allocation, load balancing, and fault tolerance behaviors. Existing research has found that setting specific configuration combinations helps explore the system's runtime environment. The operation of configuration parameters has two main characteristics: First, from the perspective of the parameter itself, the operation of a single parameter is multi-stage. During the initialization phase, the software system parses and checks the configuration value and handles errors accordingly; valid configuration values ​​continue to propagate and influence software behavior. Second, from the perspective of the overall system operation, due to its complex functions and components, the system uses different configuration parameters at different stages of operation. Deep configuration interaction defects refer to situations where, after the software system has completed initialization and is executing normally, a defect in the deepest configuration interaction code causes a serious system failure when a specific set of configuration parameters is used.

[0003] The characteristics of deep configuration interaction defects are: the failure usually occurs after the software starts normally, that is, after the configuration parameters have undergone the initial check of the code, the failure occurs during the execution of normal logical functions, and simple injection configuration errors cannot trigger such defects; it can only be triggered when multiple configuration parameters are covered by the test program.

[0004] To cover deep configuration interaction code and trigger software faults caused by correct configuration settings, a mutation strategy needs to be set according to the characteristics of deep configuration interaction defects. However, existing technologies have the following problems:

[0005] (1) Abstraction of system state: The operating state of large-scale software systems is relatively complex. Overly fine-grained abstraction will introduce huge time overhead and is not conducive to improving code coverage. On the other hand, coarse-grained abstraction cannot accurately describe the relationship between configuration parameters and system state, which is not conducive to configuration variation.

[0006] (2) Variation of configuration parameters: Configuration parameters usually have a wide range of values ​​and multiple possible combinations. Simple configuration variation may not trigger the boundary conditions of the configuration code, trigger defects, and cannot guarantee improved coverage of configuration interaction code.

[0007] (3) Adjusting the workload, i.e., relying solely on variable configurations cannot effectively improve coverage. Summary of the Invention

[0008] The main objective of this invention is to provide a defect detection method, apparatus, device, and medium for interactive code coverage, thereby improving the defect detection efficiency and code coverage of software systems.

[0009] One aspect of the present invention provides a defect detection method for interactive code coverage, comprising:

[0010] Static analysis was performed on the target system using hook functions to obtain the taint set and call graph of the target system's configuration interaction code;

[0011] Based on the taint set and the call graph, determine the operating state diagram of the target system;

[0012] The configuration coverage and call stack information of the target system to which the workload is applied are obtained through hook functions. The target system is then tested based on the configuration coverage, call stack information and runtime state graph to obtain the test seed pool and mutation configuration parameters.

[0013] Iterative tests are performed based on the seed pool and mutation configuration parameters to obtain configuration defect detection results.

[0014] According to the defect detection method for interaction code coverage, static analysis is performed on the target system using hook functions to obtain the taint set and call graph of the target system's configuration interaction code, including:

[0015] The configuration parameters of the target system are identified, including the use of static analysis to identify the code statements that the configuration parameters go through during the propagation process, and the identification results of the configuration interaction code are obtained. The static analysis includes field analysis and context-sensitive analysis.

[0016] The configuration values ​​in the configuration files or command lines of the target system are identified to obtain the configuration parsing interface identification results;

[0017] The Cflow method and the configuration parsing interface identification results are used to perform configuration taint analysis on the target system to obtain the configuration propagation process identification results;

[0018] Based on the identification results of configuration interaction code, configuration parsing interface, and configuration propagation process, the configuration interaction code is determined. Hook functions are inserted into each piece of configuration interaction code using instrumentation. The taint set and call graph of the target system's configuration interaction code are obtained through the hook functions.

[0019] According to the defect detection method for interaction code coverage, the Cflow method and configuration parsing interface identification results are used to perform configuration taint analysis on the target system to obtain configuration propagation process identification results, including:

[0020] By identifying the configuration interface function in the configuration parsing interface result, the object field of the configured and assigned class is propagated and traced to obtain tainted variables, where the tainted variables are the usage locations of the object field.

[0021] Based on the interaction relationship between tainted variables and constants and variables in the target system, the program execution point of the configuration interaction code is obtained. The configuration propagation process identification result is determined based on the configuration interface function, interaction relationship and program execution point.

[0022] According to the defect detection method for interaction code coverage, determining the runtime state graph of the target system based on the taint set and the call graph includes:

[0023] The hook function obtains the set of configured taints and the call graph describing the overall call relationship of the system. Based on the set of taints and the call graph, the runtime state graph of the target system is determined. The runtime state graph includes nodes and the call relationship between nodes. Nodes represent methods, and each node includes the configuration taint object of the method.

[0024] According to the aforementioned defect detection method for interactive code coverage, the configuration coverage and call stack information of the target system to which the workload is applied are obtained through hook functions. The target system is then tested based on the configuration coverage, call stack information, and runtime state graph to obtain the test seed pool and mutation configuration parameters, including:

[0025] The configuration coverage and call stack information for each test are obtained through hook functions. The call graph is then analyzed based on the configuration coverage and call stack information to obtain the reachability of the configuration interaction code.

[0026] Restore the execution sequence of the test and determine the reachability of deep configuration interaction code for the nodes that have been covered in each execution sequence;

[0027] If any node has reachable deep configuration interaction code in its subsequent nodes, add the node's configuration parameters to the seed pool to obtain the updated seed pool and mutated configuration parameters.

[0028] According to the defect detection method for interactive code coverage, the method further includes:

[0029] A pruning algorithm is used to prune the call graph, including checking each node in the target system to obtain configuration-related taints; identifying taint information of the successor nodes of the nodes; if no taint information is found, the node and its corresponding successor nodes are pruned from the call graph; and checking whether the successor nodes of the removed nodes contain taint information, until the call graph only retains nodes with potential impact.

[0030] According to the defect detection method for interactive code coverage, the method further includes:

[0031] The system retrieves the value of each configuration parameter after each round of testing through hook functions, and obtains the default value of the configuration parameter through configuration files or configuration parsing functions. It then uses heuristic rules to obtain the mutated configuration parameters based on the values ​​and default values ​​of the configuration parameters. Finally, it obtains the dependencies of the configuration parameters, determines the dependency set, and performs mutation processing on the dependency configurations of the mutated configuration parameters according to the dependency set.

[0032] Another aspect of the present invention provides a defect detection device for interactive code coverage, comprising:

[0033] The first module is used to perform static analysis on the target system using hook functions to obtain the taint set and call graph of the target system's configuration interaction code;

[0034] The second module is used to determine the operating state diagram of the target system based on the taint set and the call graph;

[0035] The third module is used to obtain the configuration coverage and call stack information of the target system to which the workload is applied through hook functions, and to test the target system based on the configuration coverage, call stack information and running status diagram to obtain the test seed pool and mutation configuration parameters.

[0036] The fourth module is used to perform iterative tests based on the seed pool and mutation configuration parameters to obtain configuration defect detection results.

[0037] Another aspect of the present invention provides an electronic device, including a processor and a memory;

[0038] The memory is used to store programs;

[0039] The processor executes the program to implement the method as described above.

[0040] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the methods described above.

[0041] The beneficial effects of this invention are as follows: by analyzing program behavior through configuration taint analysis, call graphs, and program call stacks, and designing configuration mutation strategies based on fine-grained configuration interaction code coverage, the invention improves the identification of configuration interaction defects, especially deep-level configuration interaction defects, and also improves configuration interaction code coverage and overall code coverage. Attached Figure Description

[0042] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which:

[0043] Figure 1 This is a schematic diagram of the defect detection process for interactive code coverage according to an embodiment of the present invention.

[0044] Figure 2 This is a schematic diagram of the configuration interaction code recognition and instrumentation process according to an embodiment of the present invention.

[0045] Figure 3 This is a schematic diagram of the configuration propagation process identification flow according to an embodiment of the present invention.

[0046] Figure 4 This is a code example diagram after instrumentation in an embodiment of the present invention.

[0047] Figure 5 This is a schematic diagram of the seed pool and mutation configuration parameter generation process in an embodiment of the present invention.

[0048] Figure 6 This is a schematic diagram of the reachability analysis process of deep configuration interaction code in an embodiment of the present invention.

[0049] Figure 7 This is a pseudocode diagram of the pruning algorithm according to an embodiment of the present invention.

[0050] Figure 8 This is an example diagram of a program call in an embodiment of the present invention.

[0051] Figure 9 This is a C→P type configuration interaction code diagram of an embodiment of the present invention.

[0052] Figure 10 This is a configuration numerical relationship dependency graph according to an embodiment of the present invention.

[0053] Figure 11 These are depth growth trend graphs of ARIANDE and its variants in four target software systems according to embodiments of the present invention, wherein (a) is the depth growth trend graph of HBase database, (b) is the depth growth trend graph of HDFS file system, (c) is the depth growth trend graph of KafKa event stream processor, and (d) is the depth growth trend graph of ZooKeeper configuration manager.

[0054] Figure 12 This is a comparison chart of the efficiency of ARIANDE and its variants in detecting defects according to embodiments of the present invention.

[0055] Figure 13 This is a diagram of a defect detection device for interactive code coverage according to an embodiment of the present invention. Detailed Implementation

[0056] The embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings. Throughout the description, the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions. In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the purpose of illustrative purposes and have no specific meaning in themselves. Therefore, "module," "part," or "unit" can be used interchangeably. Terms such as "first," "second," etc., are used only to distinguish technical features and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features, or implicitly indicating the sequential relationship of the indicated technical features. In the following description, the consecutive reference numerals for method steps are for ease of review and understanding. Adjusting the implementation order of steps, in conjunction with the overall technical solution of the present invention and the logical relationship between the various steps, will not affect the technical effect achieved by the technical solution of the present invention. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0057] Terminology Explanation:

[0058] ARIANDE, an embodiment of the present invention for performing defect detection of interactive code coverage.

[0059] refer to Figure 1 ,in Figure 1 This is a schematic diagram of the defect detection process for interactive code coverage according to an embodiment of the present invention, which includes, but is not limited to, steps S100~S400:

[0060] S100: Perform static analysis on the target system using hook functions to obtain the taint set and call graph of the target system's configuration interaction code.

[0061] In some embodiments, reference Figure 2 The schematic diagram of the configuration interaction code recognition and instrumentation process shown includes, but is not limited to, steps S110~S140:

[0062] S110, Identify the configuration parameters of the target system, including using static analysis to identify the code statements that the configuration parameters go through during the propagation process, and obtain the configuration interaction code identification results. The static analysis includes field analysis and context-sensitive analysis.

[0063] In some embodiments, ARIANDE needs to analyze and collect all statements that configuration parameters pass through during propagation. By defining a configuration parsing interface, ARIANDE first identifies configuration variables that store configuration parameter values ​​defined in configuration files or command lines; then it performs field- and context-sensitive static analysis until the configuration variables are finally used.

[0064] S120 identifies the configuration values ​​in the target system's configuration file or command line and obtains the configuration parsing interface identification results.

[0065] In some embodiments, configuration parsing interfaces are identified. Different software systems define different configuration interfaces to read and parse configuration values ​​defined by the user in configuration files or command lines. For example, Hadoop-related software typically uses a series of getter and setter functions as interface functions for parsing configuration values ​​(such as getInt, getLong, and getBoolean). After parsing, the configuration value is stored in a configuration variable. ARIANDE uses these variables as the starting point for static taint analysis and external function calls and control branches as the endpoints for propagating this configuration parameter.

[0066] S130 uses the Cflow method and configuration parsing interface identification results to perform configuration taint analysis on the target system and obtain the configuration propagation process identification results.

[0067] In some embodiments, the Cflow method performs configuration taint analysis on the entire system based on the program's call graph.

[0068] In some embodiments, reference Figure 3 The schematic diagram of the configuration propagation process identification flow shown includes, but is not limited to, steps S131-S132:

[0069] S131, by identifying the configuration interface function in the configuration parsing interface result, the object field of the class that is configured and assigned is propagated and traced to obtain the tainted variable, where the tainted variable is the usage location of the object field;

[0070] S132, based on the interaction relationship between tainted variables and constants and variables in the target system, obtain the program execution point of the configuration interaction code, and determine the configuration propagation process identification result based on the configuration interface function, interaction relationship and program execution point.

[0071] In some embodiments, ARIANDE fully considers the characteristics of configuration parameters propagating through fields. For assigned object fields, ARIANDE tracks the propagation of the object and identifies the location where the configured assigned field is used as a tainted variable. In the target system's configuration execution and interaction mode, after identifying the entry point for configuration parsing, ARIANDE identifies the program execution point where the configuration interaction code is located based on the interaction relationship between tainted variables and constants and variables in the program. It is important to emphasize that, due to the trade-off between analysis accuracy and overhead, and the characteristics of configuration interaction code, ARIANDE only focuses on explicit data flow propagation and does not analyze implicit call propagation. At the same time, ARIANDE supports propagation analysis within procedures, such as assignment, numerical computation, and logical computation, and also supports cross-procedure analysis. For example, tainted variables propagate across procedures via parameter passing or return values, ultimately reaching the endpoint of configuration propagation through the use of control branches and external function calls (such as standard library functions). Taking the propagation of the configuration parameter "hbase.auth.key.update.interval" as an example, ARIANDE tracks the propagation of the variable "keyUpdateInterval" by identifying the configuration interface function getLong(), and then propagates it through function parameter passing and field assignment, ultimately using it in the control branch. The code statements of the configuration parameter in the usage phase are regarded as configuration interaction code.

[0072] S140: Based on the configuration interaction code identification results, configuration parsing interface identification results, and configuration propagation process identification results, determine the configuration interaction code. Insert hook functions into each configuration interaction code segment using an instrumentation method. Obtain the taint set and call graph of the target system's configuration interaction code through the hook functions.

[0073] In some embodiments, for each configuration interaction code segment, ARIANDE of this embodiment inserts a hook function call statement after it to ensure that ARIANDE can capture the coverage of the configuration interaction statements. Simultaneously, ARIANDE implements a lightweight proxy library to ensure communication between the target system and the ARIANDE system. During runtime, if the test process covers a configuration interaction statement, its corresponding hook function sends an RPC request to the ARIANDE controller. This request includes the configuration parameter name, configuration parameter value type, configuration value, and the signature of the method containing the interaction statement. Figure 4The example code demonstrates instrumentation where configuration variables "threadWakeFrequency" and "versionFileWriteAttempts" are parsed by the interface method `getInt` and used to store configuration values. When these variables are passed as parameters to other methods, ARIANDE instruments a call to the hook function "inforState" in the next line of code. The hook function generates an object `info` representing the execution state based on the passed configuration parameters and sends this object to the ARIANDE server.

[0074] S200, based on the taint set and call graph, determine the operating state diagram of the target system.

[0075] In some embodiments, a set of configuration taint objects and a call graph describing the overall call relationships of the system are obtained through hook functions. The runtime state graph of the target system is determined based on the taint set and the call graph. The runtime state graph includes nodes and the call relationships between nodes. Each node represents a method, and each node includes the configuration taint object of the method.

[0076] In some embodiments, after static analysis, ARIANDE generates a system runtime state graph based on the call graph. This graph contains a set of all configuration tainted objects within the target system and a call graph describing the overall call relationships of the system. Each tainted object contains the code statement and method containing the tainted information. Based on the call graph and the set of configuration tainted objects, ARIANDE constructs a system runtime state graph containing configuration tainted information. Similar to the call graph, each node in the system runtime state graph represents a method, each edge of the tree represents a call relationship, and each node stores the configuration tainted objects contained within that method.

[0077] S300 obtains the configuration coverage and call stack information of the target system to which the workload is applied through hook functions. Based on the configuration coverage, call stack information and runtime state diagram, the target system is tested to obtain the test seed pool and mutation configuration parameters.

[0078] In some embodiments, reference Figure 5 The diagram shown illustrates the seed pool and mutation configuration parameter generation process, including steps S310-330:

[0079] S310 obtains the configuration coverage and call stack information for each test through hook functions, analyzes the call graph based on the configuration coverage and call stack information, and obtains the reachability of the configuration interaction code.

[0080] S320, resumes the execution sequence of the test, and determines the reachability of deep configuration interaction code for nodes that have been covered in each execution sequence.

[0081] In some embodiments, reference Figure 6 The diagram shown illustrates the reachability analysis process for deep configuration interaction code, including but not limited to steps S321-S323:

[0082] S321, a pruning algorithm is used to prune the call graph, including checking each node in the target system to obtain configuration-related taints;

[0083] S322, identify the taint information of the successor node of the node. If there is no taint information, perform pruning on the node and its corresponding successor node from the call graph.

[0084] S323, perform a check on the successor nodes of the removed node to see if they include taint information, until the calling graph retains only nodes with potential impact.

[0085] In some embodiments, after each round of testing, the ARIANDE server obtains the configuration coverage and call stack information returned by the hook functions of the target software system. Then, ARIANDE analyzes the current execution status based on the call graph and identifies deep-level interaction code that may be covered in the next round of testing. Based on a call graph pruning algorithm using configuration taint information, this embodiment of ARIANDE combines the call graph with monitoring information to analyze the current execution status of the target software system. The core idea of ​​this algorithm is to iteratively eliminate all leaf nodes that do not contain configuration taint information by checking whether the successor nodes of each node contain configuration-related taint information, while retaining only the necessary intermediate nodes between the root node and deep configuration interaction nodes. These nodes are method (function) nodes, such as... Figure 7 The pseudocode diagram of the pruning algorithm shown is as follows:

[0086] Traverse each node in the call graph and check each node for configuration-related taints; prune: if a node's successor node (i.e., the method it is called) does not contain any taint information, remove that node and all its successors from the call graph; recursively process: for all successors of the removed node, continue to perform the same checks to ensure that only nodes with potential impact are retained in the entire call graph.

[0087] refer to Figure 8The example call graph shown illustrates that, after pruning, nodes that do not contain configuration taints, either themselves or their successors, will be pruned. It's worth noting that although the `createStatus` node does not contain configuration taint information, it is retained because its successor (left child) contains configuration interaction code. Through pruning, ARIANDE can significantly reduce the size of the call graph, thereby reducing the time complexity of subsequent analysis. Taking HBase as an example, before pruning, its call graph contained over 170,000 nodes. After the pruning algorithm described above, the complexity of the call graph was reduced to only 3,000 nodes with configuration taints and a few necessary intermediate nodes, reducing the analysis scale by two orders of magnitude. Therefore, ARIANDE can perform system status assessments in a shorter time.

[0088] In some embodiments, the analysis also includes system runtime status analysis. First, the system runtime status is analyzed based on call stack information, i.e., which nodes in the call graph are currently being executed. Modern large-scale software systems, especially distributed software systems, contain multiple services, nodes, and components. Therefore, the call graph generated by the target software system is highly complex, with multiple root nodes. Taking HBase as an example, the services belonging to Master and RegionServer originate from different root nodes (HMaster's start() method and HRegionServer's run() method). Due to the high concurrency of the software system, execution results will also cover the leaf nodes of multiple subtrees in the call graph, increasing the complexity of the analysis. Therefore, when returning call stack information through hook functions, ARIANDE first numbers the call stack information within the same node to facilitate divide-and-conquer analysis. Second, for the call sequence within the same node, ARIANDE traverses from the end of the sequence, determines its position in the call graph through its method signature, and reconstructs the call sequence from the root node to that node. These call sequences represent the current runtime status of the target software system.

[0089] by Figure 8 For example, if the deepest node after a certain round of testing is purgeExpiredTasks, then ARIANDE will restore the call sequence in that round of running: initialize → createStatus → purgeExpiredTasks.

[0090] S330, if any node has reachable deep configuration interaction code in its subsequent nodes, add the node's configuration parameters to the seed pool to obtain the updated seed pool and mutated configuration parameters.

[0091] Accessibility analysis of deep configuration interaction code. After recovering all current call sequences, ARIANDE designed an algorithm to analyze the accessibility of deep configuration interaction code. Specifically, ARIANDE first sorts the call sequences by depth and analyzes each sequence from deep to shallow. For a call sequence, ARIANDE traverses each node in the call sequence in reverse and obtains its successor node to determine whether there is any uncovered deep interaction code starting from that node. If there is uncovered configuration interaction code in the successor node of that node, the configuration parameters in that node are added to the seed pool, and the configuration parameters contained in that node are mutated in subsequent tests. Figure 8 For example, if a certain round of call sequence ends with initializeRegionInternals, analysis shows that there are uncovered nodes containing configuration taint information in the successor nodes of this node, and the configuration parameters contained in the initializeRegionInternals node will be added to the seed pool.

[0092] ARIANDE's configuration mutation strategy, prioritizing deep configuration interaction code, selects seeds for mutation sequentially based on their addition time to the seed pool after each test round. However, a function may use multiple configuration parameters, and only some of these parameters affect the program's execution path. Therefore, adding all configuration parameters to the seed pool can also lead to low test efficiency. For example, the constructor of the SimpleRpcScheduler RPC scheduler uses eight configuration parameters, each with a different value range. Generally, the types of configuration parameters that may affect the program's execution path and their interaction modes include the following:

[0093] (1) P: The configuration parameters of the Boolean data type independently affect the software control flow, that is, determine the execution path of the program in the branch statement;

[0094] (2) C→P: This interaction mode is usually used for checking configuration parameters and handling errors. Any type of configuration parameter may have this type of interaction code.

[0095] (3) P→V: Numerical configuration parameters serve as thresholds for workload, and corresponding operations are usually triggered when the threshold is reached;

[0096] (4) P − C − V: This interaction pattern is also common in Boolean type configuration items, where it works with other variables to determine the program execution path.

[0097] In some embodiments, reference Figure 9The C→P type configuration interaction code shown includes string-type configuration parameters, such as pathnames and IP addresses. While these parameters may appear in C→P type configuration interaction code and affect the program's execution path, they typically only change the execution path when the configuration parameter value is invalid. Furthermore, error handling does not substantially affect subsequent method calls. Figure 9 For example, if a configuration parameter value is invalid (less than 0), the default value of the parameter will be used, and the normal logic function of the software will continue to be executed. Therefore, C→P type configuration interaction code may not change the program's execution path. In order to ensure efficient exploration of deep configuration interaction code and expose more configuration interaction defects, when selecting configuration parameters to be mutated at a certain node, this embodiment of the invention will only consider Boolean and numeric type configuration parameters.

[0098] In this embodiment of the invention, ARIANDE obtains the value of each configuration parameter from the hook function after each round of testing. For Boolean type configuration parameters, its value is flipped. For numeric type configuration parameters, unlike previous configuration fault injection methods, ARIANDE focuses on how to expand the program's runtime space to cover deeper configuration parameters. However, the range of values ​​for this type of configuration parameter is enormous, making it impossible to enumerate all valid values ​​for testing. This embodiment of the invention employs heuristic rules, including obtaining the default value of the configuration (through the configuration file or configuration parsing function), and then multiplying or dividing by the integer "2" between "0" and the default value, and between the default value and positive infinity, taking five values ​​respectively, and using "0" and "-1" as candidate mutation values ​​for the configuration parameter. It is worth noting that although ARIANDE does not focus on injecting configuration faults, it still takes "-1" as a candidate value for the following reasons:

[0099] The value "-1" is still a valid value in certain configuration parameters of some software systems. For example, the configuration parameter hbase.regions.recovery.store.file.ref.count is a numeric configuration parameter that represents the threshold for counting refs of HBase stored files. A value of "-1" means that this function is not enabled. In some interactive modes, "-1" may directly lead to changes in the program execution path. If the value of the parameter maxListCachePoolsResponses is "-1", it will directly enter the if branch and return a batch of list items.

[0100] It is understandable that there may be numerical or logical dependencies between configuration parameters, such as... Figure 10The configuration values ​​shown are dependent. If the sum of the values ​​of the three configuration parameters, such as hbase.lru.blockcache.multi.percentage, is not equal to "1", the program will throw an exception, ultimately causing the software system to terminate unexpectedly. Therefore, ignoring the dependencies between configurations will, on the one hand, generate a large number of false positives during testing, i.e., premature crashes of the software system; on the other hand, premature crashes of the software system are not conducive to improving code coverage and make it difficult to explore deeper levels of configuration interaction code.

[0101] S400 performs iterative testing based on the seed pool and variant configuration parameters to obtain configuration defect detection results.

[0102] In some embodiments, ARIANDE implements a workload driver to run the target software system. This embodiment selects existing, representative workloads as test cases for running the target system, such as official test cases. To adapt to the testing requirements of this embodiment, the test cases are extended as follows:

[0103] (1) Multi-client workload: The ARIANDE driver creates multiple clients to interact with the server node of the target system. This makes the workload closer to the real deployment environment and facilitates the observation of the target system's status through multiple client nodes.

[0104] (2) Multi-stage observable workload: Unlike the seeds used in traditional fuzzing techniques, ARIANDE abstracts the workload of each target software system at a high level and divides the execution of the workload into multiple stages, such as creating data, reading data, and writing data. The ARIANDE server can observe the execution status of the workload in each stage and proceed to the next round of execution after all workloads have been executed. Each client sends the execution status of each stage to the ARIANDE server. If the execution process of a client times out or encounters an exception, ARIANDE can also interrupt the execution and proceed directly to the next stage.

[0105] (3) Scalable and configurable workloads: The results of the interaction between configuration parameters and different workloads may have different effects on software behavior. ARIANDE implements a configurable workload driver that supports adjusting the workload scale based on the running results after each round of testing, such as the number of client nodes, the number of rows (columns) of the table created, and the number of requests sent.

[0106] In some embodiments, in each round of testing, the value of each configuration parameter after each round of testing is obtained through a hook function, and the default value of the configuration parameter is obtained through a configuration file or configuration parsing function. Heuristic rules are used to obtain the mutated configuration parameter based on the value of the configuration parameter and the default value of the configuration parameter. The dependency relationship of the configuration parameter is obtained, the dependency set is determined, and the mutation processing is performed on the dependency configuration of the mutated configuration parameter according to the dependency set.

[0107] In some embodiments, after each round of testing, the seed pool adds all configuration parameters of a node that may affect the program execution path to the seed pool. If mutating these configuration parameters fails to improve coverage, ARIANDE will adjust the workload. Specifically, ARIANDE will increase and decrease the number of clients, the number of read and write requests, or other software-specific operations in the next two rounds of testing, respectively. If coverage is improved, the adjustment ends and the subsequent configuration mutation process begins.

[0108] In this embodiment of the invention, ARIANDE examines the observation results of the target software to confirm whether faults exist in each round. Configuration-related software fault symptoms are complex, including software crashes, performance degradation, and hangs. Fuzzing tools often use crashes and hangs as indicators of faults; however, existing work has found that large-scale software systems, especially distributed software systems, have some faults, such as service nodes being online but unable to connect to client nodes. ARIANDE checks for faults by scanning the output of each node in the target software and employs two strategies when determining faults:

[0109] (1) Crash check: Similar to existing work, ARIANDE checks operating system signals to check whether the target system has abnormal symptoms such as crashes, interruptions and node exits;

[0110] (2) Consistency check: ARIANDE scans the output of all client nodes to check whether the states of different client observation servers are consistent and whether the client behavior is as expected.

[0111] ARIANDE is highly scalable, allowing the addition of different types of troubleshooting programs based on the developer's needs and the specific symptoms of the fault.

[0112] This invention evaluates, through experiments, whether ARIANDE can achieve its intended design goal, namely, detecting deep-seated configuration interaction defects. Secondly, ARIANDE instrumentes all configuration interaction code to monitor its code coverage. Therefore, this invention evaluates the configuration interaction code coverage based on feedback from hook functions. Finally, this invention evaluates whether call graph-based configuration mutation strategies and workload adjustment strategies help improve ARIANDE's efficiency in detecting defects and increasing coverage.

[0113] The target software system of this invention selected four stable versions of large-scale software systems to conduct experimental evaluation of ARIANDE, as shown in Table 1. These software systems (1) include various types such as databases, file systems and configuration management systems, (2) and are relatively mature with a good maintenance history. For example, HBase has more than 5,000 favorites on Github.

[0114] Table 1 Software System

[0115]

[0116] The evaluation metrics for ARIANDE involve three core metrics: the ability to detect configuration interaction defects, improve code coverage, and the depth of configuration interaction code. For detection capability, this embodiment uses the number of historically unknown configuration interaction code defects detected by ARIANDE as the evaluation metric. For code coverage, this embodiment uses the ratio of the number of hook functions returned by ARIANDE embedded in the target software system to the total number of instrumented code as the configuration interaction code coverage rate. Similar to related works [113,114], this embodiment uses branch coverage as the metric for overall code coverage. ARIANDE inserts hook functions at the beginning of each branch in the program, and calculates branch coverage by collecting the number of hook function returns. Simultaneously, this embodiment uses the depth of configuration interaction code to verify the effectiveness of the mutation strategy, defined as: the number of functions containing configuration interaction code called starting from the root node of the call graph. Figure 8 For example, the depth of the canPurge node is 2, and the depth of the getWALRootRir node is 3.

[0117] In this embodiment of the invention, false positive verification is performed on each configuration interaction defect detected by ARIANDE. The ARIANDE experimental environment consists of an Intel 24-core 3.6GHz CPU, an Ubuntu 20.04 operating system, 32GB DDR5 memory, and JDK 8+Soot 4.3.0, as shown in Table 2.

[0118] Table 2 ARIADNED Experimental Environment

[0119]

[0120] False positive verification includes manual reproduction and code confirmation. In this embodiment of the invention, the system will be rerun using the configuration and workload set in the round where the defect occurred, and the symptoms of the target software system will be observed to see if they are consistent with those during the testing process. Simultaneously, the code related to configuration parameters will be examined at the source code level, and the root cause of the defect will be diagnosed based on log information. Configuration interaction defects that pass the false positive test will be further reported to the developers for confirmation and repair.

[0121] For the experimental benchmark, this embodiment of the invention selected ECFuzz[7] as the experimental benchmark tool. ECFuzz is currently the most advanced configuration-oriented fuzzing tool. It uses Ctest

[42] to filter unit tests related to configuration parameters in the target system and uses the configuration parameter values ​​that cause unit test failures as the initial seed library to detect configuration defects in the target software system. In order to prove the advanced nature of each component of ARIANDE, this embodiment of the invention implements three variants of ARIANDE: ARIANDEDECFuzz, ARIANDEDW−, and ARIANDEDD. Specifically, ARIANDEDECFuzz uses the same configuration mutation strategy and workload as ECFuzz, uses the configuration parameters that cause unit test failures as the initial seed, and uses a fixed workload, that is, it does not use the workload adjustment strategy of ARIANDE. ARIANDEDW− does not apply the workload adjustment strategy and still uses the configuration mutation strategy guided by configuration interaction code coverage. ARIANDEDD uses a random configuration selection strategy, and its configuration value mutation strategy is the same as the heuristic method of ARIANDE. This embodiment of the invention compares the above variants with ARIANDED in detecting configuration interaction code defects and code coverage. Since ECFuzz was not tested on the Kafka system,

[0122] In the subsequent description of this embodiment, ARIANDE DEECFuzz will not be experimented with on Kafka. To fully test the configuration-related code and evaluate code coverage, this embodiment will run each target software on the ARIANDE system and all its variants for 24 hours.

[0123] (RQ1) Ariadened Defect Detection Capability: Large-scale software systems often possess fault tolerance and recovery capabilities. Regarding configuration errors, software systems typically check user configurations and handle them appropriately during startup. When an incorrect configuration is detected, the software system assigns the configuration variable a default value and continues executing the software's normal logic. Existing work also demonstrates that software systems often have the ability to tolerate configuration errors. Therefore, for some deep-level configuration interaction code, specific configuration combinations and test cases (workloads) are required for coverage, and implementation defects are difficult to expose to developers, leading to potential software system failures.

[0124] ARIANDE detected a total of seven configuration interaction code defects in four target software systems, with interaction types including P-V, P→V, and P-C-V. Symptoms included explicit software crashes and implicit software partial failures, as shown in Table 3. This embodiment of the invention reported these detected defects to the developer community and received a positive response.

[0125] Table 3. Historical Unknown Configuration Interaction Code Defects Detected by ARIADNED

[0126]

[0127] Meanwhile, this embodiment of the invention conducted a depth measurement of the configuration interaction code related to 14 defects detected by ECFuzz based on fault reports and related configuration parameters. The results showed that most of the defects (12 / 14) occurred during the software system initialization process. For example, in defect case HBASE-26114, zookeeper.session.timeout was set to -1. This configuration parameter is used to set the Zookeeper session timeout when the HBase cluster starts. If the master node has not finished starting, the startup process will wait according to the value of this configuration parameter. However, since this configuration parameter was set to -1, the cluster terminated when starting the HMaster master node, and the call sequence remained at the startActiveMasterManager function, with a depth of only 1. The depth of the configuration interaction code involved in the remaining 11 defects was similar to this defect, all not exceeding 5.

[0128] The present invention has found that ARIANDE can detect configuration defects with deeper interaction levels and more interaction types. Taking HBase as an example, the average depth of defects detected by ARIANDE is 25.4, which is much higher than the average depth of defects detected by ECFuzz (3.5).

[0129] Case Study HBASE-28881: In one round of testing, ARIANDE changed the value of the configuration parameter `hbase.master.procedure.threads` to -1. HMaster and HRegionServer started and initialized normally without any error messages, and their logs contained no error messages. However, when clients attempted to connect to the HMaster node and perform table creation operations, connection timeouts and interruptions occurred, and all client worker processes failed to execute. Ultimately, the entire software system was forced to shut down due to exceeding the preset timeout threshold (20 seconds) for the test round. However, throughout the entire process, neither the HMaster nor HRegionServer nodes logged any information about this failure, making it difficult for users to accurately diagnose the error. Referring to the following HBASE-28881 source code diagram, it can be seen that after parsing, this configuration parameter stores its value in the variable `numThreads`, and is ultimately used in a loop to initialize a certain number of threads. However, when this configuration value is accidentally configured to -1, the program will break out of this loop, meaning that no threads are available to interact with the client, causing the client to fail to connect. It is worth noting that there are no related logs throughout the process, including configuration information and thread pool creation information.

[0130] In summary, ARIADNED can detect deeper-level defects in configuration interaction code. Existing methods are unable to detect system configuration failures caused by valid configuration values. For HBASE-28881, the relevant source code is...

[0131] / * HBase / HMaster.java * /

[0132] final int numThreads =

[0133] conf.getInt(MasterProcedureConstants.MASTER_PROCEDURE_THREADS, …);

[0134] procedureExecutor.init(numThreads, abortOnCorruption);

[0135] / * HBase / ProcedureExecutor.java * /

[0136] public void init(int numThreads, boolean abortOnCorruption) {

[0137] this.corePoolSize = numThreads;

[0138] …

[0139] workerThreads = new CopyOnWriteArrayList<>();

[0140] for (int i = 0; i <corePoolSize; ++i) {

[0141] workerThreads.add(new WorkerThread(threadGroup));

[0142] }

[0143] }

[0144] No thread will be created!

[0145] (RQ2) ARIANDE Code Coverage: To evaluate the testing efficiency of ARIANDE, this embodiment of the invention collects the changes in the coverage of configuration interaction code and overall code during a 24-hour run of ARIANDE, and compares it with the state-of-the-art method ECFuzz (ARIADNEDECFuzz). The configuration interaction code coverage is shown in Table 4. Compared to ARIANDEECFuzz, ARIANDE demonstrates a significant performance improvement.

[0146] Table 4. Configuration interaction code coverage results for ARIADNED and its variants

[0147]

[0148] Table 5 Overall code coverage of ARIADNED and its variants

[0149]

[0150] Among them, Zookeeper achieved the highest improvement of 18.4%. ECFuzz uses the parameter values ​​of failed test cases as the initial seed pool. This embodiment of the invention investigated the test cases and configuration parameters filtered by Ctest and found that the number of filtered configuration parameters differed significantly from the configuration parameters contained in the source code. This is because only some configuration parameters are used in unit tests. In the HDFS unit test, only 296 configuration parameters were involved. After unit test filtering, the number of parameters injected into the target software system will be further reduced. However, ARIANDE, through taint analysis and instrumentation, found that HDFS contains 744 configuration parameters, including default configuration parameters exposed in the configuration file and high-level configuration parameters hidden in the program. In addition, most of these parameter values ​​are illegal configuration values, that is, they cannot pass the semantic check of configuration parameters. This resulted in a small number of seeds in the ARIANDE ECFuzz seed pool, which reached its peak code coverage in a short time and hardly changed. ARIANDE obtains the global running status through the results of each round of execution and the call graph, analyzes the configuration interaction code that may be covered in the next round of execution, mutates the configuration parameters, and dynamically updates the seed pool. Meanwhile, ARIANDE uses a constant workload throughout the testing process. Therefore, when configuration mutation fails to improve coverage, it cannot adjust the workload to penetrate deeper functional code, making it difficult to break through the code coverage bottleneck. ARIANDE, on the other hand, adjusts the workload when configuration mutation strategies fail to improve coverage, thereby penetrating nodes in the call graph to cover deeper configuration interaction code.

[0151] To comprehensively evaluate ARIANDE's performance, this invention introduces branch coverage as a metric for overall code coverage. Configuration parameters control most of the software system's functions and behaviors, so covering more configuration interaction code can improve overall code coverage. This invention found that ARIANDE achieves an average performance improvement of 12.1% compared to the state-of-the-art work ARIANDE's ARIDNEDECFuzz. The highest improvement achieved was 14.8% overall coverage on HBase. Regarding configuration interaction code depth, ARIANDE is a test framework designed to cover deep configuration interaction code. This invention evaluates the maximum depth that ARIANDE and its variants can cover. Table 6 shows that ARIANDE's ability to explore deep configuration interaction code in the target software system is weak, exhibiting a significant gap compared to ARIANDE.

[0152] Table 6 Maximum Test Depth of ARIADNED and its variants in the target software system

[0153]

[0154] refer to Figure 11 , Figure 11 The graph shows the depth growth trend of ARIANDE and its variants on four target software systems, with the horizontal axis representing the test time. It's worth noting that if the variant value is an invalid configuration value, the target system may fail to boot, resulting in a decrease in depth. Figure 11 In the diagram, the vertical axis represents the deepest layer of configuration interaction code covered by the test framework within the current time period. Experimental results show that ARIANDE typically achieves a rapid increase in depth within a short period, followed by a slow rise. In contrast, ARIANDE's seed database contains only a subset of configuration parameters, many of which are invalid, making it difficult to increase the execution depth of the target software system. For example, when testing Zookeeper, ARIANDE rapidly increased its depth to around 30 within 60 minutes, gradually increasing thereafter. This embodiment of the invention also found that ARIANDE's depth reaches its peak quickly and then remains unchanged because it cannot perceive the target software system's operational status, has a limited seed database, and does not dynamically update based on operational conditions.

[0155] In this embodiment of the invention, branch coverage of the target software system is used as the evaluation metric for overall code coverage. Specifically, compared to ARIANDE, ARIANDE demonstrates a 16.3% improvement in configuration interaction code coverage, a 12.1% improvement in overall code coverage (branch coverage), and a 49.2% improvement in depth. These experimental results fully answer RQ2.

[0156] Overall, ARIANDE demonstrates better performance than the existing work ECFuzz in terms of code coverage and exploration depth of configuration interaction code.

[0157] (RQ3) Impact of ARIANDE Components on Performance: This embodiment of the invention implements two variants of ARIANDE. ARIANDED replaces the deep interaction-first configuration mutation strategy with a random selection mutation strategy for configuration parameters; ARIANDEW- does not use a workload adjustment strategy. This embodiment of the invention will comprehensively analyze the impact of each ARIANDE component on test performance based on code coverage, depth, and defect detection capabilities. Static Analysis Overhead: Static analysis typically incurs significant time overhead. For example, existing static analysis tools can take up to 20 minutes to analyze the data flow and control flow propagation of a single configuration parameter. Since the target software systems selected in this embodiment of the invention all have a large number of configuration parameters (e.g., HDFS has over 700 configuration parameters), excessive static analysis overhead is unacceptable. Therefore, the static analysis module of ARIANDE only considers the explicit data flow propagation of configuration parameters and does not consider the implicit control flow propagation. This embodiment of the invention uses ARIANDE to perform five static analyses and instrumentations on all target software systems and takes the average value as the time overhead of ARIANDE on that software system. The results are shown in Table 7.

[0158] Table 7. ARIADNED Static Analysis Costs

[0159]

[0160] ARIADNED's static analysis can be completed within 30 minutes. For all target software systems, regardless of the number of tests, static analysis and instrumentation only need to be performed once, so the time spent on static analysis is not included in the subsequent testing time. Furthermore, after 10 hours of testing, ARIADNED's code coverage and depth become difficult to increase further. This means that ARIADNED can quickly and comprehensively test the configuration and interaction code of the target software in a short time. Unlike traditional fuzzing tools, ARIADNED does not rely on Table 7. ARIADNED's static analysis overhead is a long execution time (7 days or even longer). The detailed static analysis phase combines configuration taints with the call graph, constructing a state graph of program execution for ARIADNED, which is the foundation for efficient testing in subsequent executions. Therefore, the maximum 30-minute static analysis overhead is acceptable for ARIADNED. For the configuration mutation module, ARIADNED uses global runtime information and the dependencies between configuration parameters as a reference for efficient configuration mutation, achieving a comprehensive improvement in code coverage and defect detection efficiency. Randomness is a relatively simple strategy; ARIADNED adopts a strategy of randomly selecting configuration items. Previous work has shown that randomization strategies, while simple, often exhibit excellent performance. However, for configuration testing, randomization does not seem to achieve ideal performance. Randomly selecting configuration parameters does not take into account the dependencies between configuration parameters, leading to more false positives and reducing testing efficiency. Therefore, as... Figure 12 As shown, ARIANDED's depth increases relatively slowly. However, after a long testing period, ARIANDED's testing depth will eventually surpass existing state-of-the-art work. This is because ECFuzz only focuses on some configuration parameters of the target software system, while ARIANDE, through more precise taint analysis, can identify almost all configuration parameters contained in the source code that can affect the target software system. Therefore, random mutation will slowly increase depth and code coverage, eventually surpassing existing work. Regarding defect detection capabilities, refer to... Figure 12The efficiency comparison chart of ARIANDED and its variants for detecting defects shows that ARIANDED can quickly detect all defects within 400 minutes, while the random mutation method can only detect two defects and no other defects are detected in the following 20 hours. The workload tuning module ARIANDE will use a workload tuning strategy when the configuration mutation strategy reaches a performance bottleneck. As shown in Tables 4 and 5, using only the configuration mutation strategy, although ARIANDEDW- can also achieve high code coverage, it cannot fully cover deep configuration interaction code, and its ability to explore deep configuration interaction defects is weaker than ARIANDE. Taking HBase as an example, the HBase cluster is managed by Zookeeper, and all nodes are considered as znodes in Zookeeper. `jute.maxbuffer` defines the amount of data stored in a single znode. The logical function processing of this configuration parameter is only triggered when the data scale within the node is large. If the workload tuning strategy is not used, the amount of data stored in the HBase master node will not change, and the relevant interaction code of this configuration parameter will not be covered. Without workload tuning, ARIADNEEDW- detected 5 defects. However, after approximately 2 hours of testing, the number of defects detected by ARIADNEEDW- remained unchanged, and no defects were detected for the remainder of the test. This is because simply considering variations in configuration parameters can lead to a coverage bottleneck; without workload tuning, the test space will be limited to the current workload. In conclusion, all components of ARIADNEEDW- improve defect detection efficiency and code coverage.

[0161] Figure 13 This is a diagram of a defect detection and analysis device for interactive code coverage according to an embodiment of the present invention. The device includes a first module 1310, a second module 1320, a third module 1330, and a fourth module 1340.

[0162] The system comprises four modules: the first module performs static analysis on the target system using hook functions to obtain a taint set and call graph of the target system's configuration interaction code; the second module determines the runtime state graph of the target system based on the taint set and call graph; the third module obtains the configuration coverage and call stack information of the target system under applied workload through hook functions, and tests the target system based on the configuration coverage, call stack information, and runtime state graph to obtain the test seed pool and mutated configuration parameters; and the fourth module performs iterative testing based on the seed pool and mutated configuration parameters to obtain configuration defect detection results.

[0163] For example, with the cooperation of the first to fourth modules in the device, the embodiment device can implement any of the aforementioned methods for detecting defects in interaction code coverage. Specifically, it performs static analysis on the target system using hook functions to obtain a taint set and call graph of the target system's configuration interaction code; determines the target system's runtime state graph based on the taint set and call graph; obtains the configuration coverage and call stack information of the target system under applied workload through hook functions; tests the target system based on the configuration coverage, call stack information, and runtime state graph to obtain a test seed pool and mutation configuration parameters; and performs iterative testing based on the seed pool and mutation configuration parameters to obtain configuration defect detection results. The beneficial effects of this invention are: by analyzing program behavior through configuration taint analysis, call graphs, and program call stacks, and designing configuration mutation strategies based on fine-grained configuration interaction code coverage, it improves the detection of configuration interaction defects, especially deep-level configuration interaction defects, and improves both configuration interaction code coverage and overall code coverage.

[0164] This invention also provides an electronic device, which includes a processor and a memory;

[0165] The memory stores the program;

[0166] The processor executes a program to perform the aforementioned interactive code coverage defect detection method; the electronic device has the function of carrying and running the software system for interactive code coverage defect detection provided in the embodiments of the present invention, such as a personal computer, minicomputer, mainframe, workstation, network or distributed computing environment, standalone or integrated computer platform, or communicating with charged particle tools or other imaging devices, etc.

[0167] This invention also provides a computer-readable storage medium storing a program that is executed by a processor to implement the defect detection method for interactive code coverage as described above.

[0168] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented in the embodiments of this invention. Alternative embodiments are contemplated, in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0169] This invention also discloses a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer instructions from the computer-readable storage medium and execute the computer instructions, causing the computer device to perform the aforementioned method for detecting defects in interactive code coverage.

[0170] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the described functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, considering the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed in the embodiments of the invention, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0171] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0172] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0173] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0174] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0175] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0176] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0177] The above is a detailed description of the preferred embodiments of the present invention, but the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method of defect detection for interactive code coverage, the method comprising: The method comprises the following steps: performing static analysis on the target system by using a hook function to obtain a pollution set of configuration interaction code and a call graph of the target system; determining a running state graph of the target system according to the pollution set and the call graph, comprising: obtaining the pollution set configured and the call graph describing the overall calling relationship of the system through the hook function, and determining the running state graph of the target system according to the pollution set and the call graph, wherein the running state graph comprises nodes and calling relationships between the nodes, and each node represents a method, and each node comprises a configuration pollution object of the method; obtaining the configuration coverage and the call stack information of the target system subjected to a workload by using the hook function, and testing the target system according to the configuration coverage, the call stack information and the running state graph to obtain a seed pool and a variation configuration parameter of the test, comprising: obtaining the configuration coverage and the call stack information of each test by using the hook function, analyzing the call graph according to the configuration coverage and the call stack information to obtain the reachability of the configuration interaction code; restoring the execution sequence of the test, and determining the reachability of the deep configuration interaction code for the nodes that have been covered in each execution sequence; performing pruning processing on the call graph by using a pruning algorithm, comprising: checking each node in the target system to obtain the pollution related to the configuration; identifying the pollution information of the successor nodes of the node, and if there is no pollution information, performing pruning processing on the node and the corresponding successor nodes; performing checking on whether the successor nodes of the removed nodes include pollution information until the call graph only retains the nodes with potential impact; if there is reachable deep configuration interaction code in the successor nodes of any node, adding the configuration parameter of the node to the seed pool to obtain an updated seed pool and a variation configuration parameter; wherein the value of each configuration parameter after each test is obtained by using the hook function, the default value of the configuration parameter is obtained by using a configuration file or a configuration parsing function, the variation configuration parameter is obtained according to the value of the configuration parameter and the default value of the configuration parameter by using a heuristic rule; the dependency relationship of the configuration parameter is obtained, the dependency set is determined, and the dependent configuration of the variation configuration parameter is subjected to variation processing according to the dependency set; performing iterative testing according to the seed pool and the variation configuration parameter to obtain a configuration defect detection result.

2. The method of defect detection for interaction code coverage according to claim 1, wherein, The method of performing static analysis on the target system by using a hook function to obtain a pollution set of configuration interaction code and a call graph of the target system comprises the following steps: identifying the configuration parameters of the target system, comprising: identifying the code statements experienced by the configuration parameters in the propagation process by using static analysis to obtain a configuration interaction code identification result, wherein the static analysis comprises field analysis and context-sensitive analysis; identifying the configuration values in the configuration file or the command line of the target system to obtain a configuration parsing interface identification result; performing configuration pollution analysis on the target system by using the Cflow method and the configuration parsing interface identification result to obtain a configuration propagation process identification result; According to the configuration interaction code recognition result, the configuration parsing interface recognition result and the configuration propagation process recognition result, configuration interaction code is determined, and a hook function is inserted into each configuration interaction code by a patching method, and a hook function is used to obtain a pollution set and a call graph of the target system configuration interaction code.

3. The method of defect detection of interaction code coverage according to claim 2, wherein, The configuration pollution analysis is performed on the target system by using the Cflow method and the configuration parsing interface recognition result, and a configuration propagation process recognition result is obtained, including: According to the configuration interface function in the configuration parsing interface recognition result, the object field of the configured class is tracked, and a pollution variable is obtained, wherein the pollution variable is the use position of the object field; According to the interaction relationship between the pollution variable and the constant and variable in the target system, a program execution point of the configuration interaction code is obtained, and the configuration propagation process recognition result is determined according to the configuration interface function, the interaction relationship and the program execution point.

4. A defect detection apparatus of interactive code coverage, characterized by, It includes: The first module is used for performing static analysis on the target system by using a hook function, and obtaining a pollution set and a call graph of the target system configuration interaction code; The second module is used for determining the running state graph of the target system according to the pollution set and the call graph, including: obtaining the pollution set of the configuration and the call graph describing the overall calling relationship of the system by the hook function, and determining the running state graph of the target system according to the pollution set and the call graph, wherein the running state graph includes nodes and calling relationship between nodes, and the node represents a method, and each node includes a configuration pollution object of the method; The third module is used for obtaining the configuration coverage and the call stack information of the target system subjected to the workload by the hook function, and testing the target system according to the configuration coverage, the call stack information and the running state graph, to obtain a seed pool and a variation configuration parameter of the test, including: obtaining the configuration coverage and the call stack information of each test by the hook function, analyzing the call graph according to the configuration coverage and the call stack information, and obtaining the reachability of the configuration interaction code; restoring the execution sequence of the test, and determining the reachability of the deep configuration interaction code for the node that has been covered in each execution sequence; pruning the call graph by using a pruning algorithm, including checking each node in the target system to obtain the configuration-related pollution; identifying the pollution information of the successor node of the node, if there is no pollution information, the node and the corresponding successor node are pruned from the call graph; checking whether the successor node of the removed node includes pollution information, until the call graph only retains the nodes with potential impact; if there is reachable deep configuration interaction code in the successor node of any node, the configuration parameter of the node is added to the seed pool, to obtain an updated seed pool and a variation configuration parameter; wherein the value of each configuration parameter after each test is obtained by the hook function, and the default value of the configuration parameter is obtained by a configuration file or a configuration parsing function, and the variation configuration parameter is obtained by using a heuristic rule according to the value of the configuration parameter and the default value of the configuration parameter; the dependency relationship of the configuration parameter is obtained, the dependency set is determined, and the dependent configuration of the variation configuration parameter is processed by variation according to the dependency set; A fourth module is configured to perform iterative testing according to the seed pool and the mutation configuration parameter to obtain a configuration defect detection result.

5. An electronic device, comprising: comprise a processor and a memory; The memory is configured to store a program. The processor executes the program to implement the defect detection method of the interactive code coverage according to any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The storage medium stores a program, and the program is executed by the processor to implement the defect detection method of the interactive code coverage according to any one of claims 1-3.

Images