Methods, devices, electronic equipment, and storage media for detecting null pointer defects.

Abstract

This disclosure provides a method, apparatus, electronic device, and storage medium for detecting null pointer defects, belonging to the field of software testing technology. The method for detecting null pointer defects includes: constructing accessibility dependencies between pointers in a target data structure; and generating at least one test scenario based on the accessibility dependencies, wherein each test scenario defines a combination of null or non-null pointers, and the combination of null or non-null pointers satisfies the accessibility dependencies. This method can efficiently detect null pointer access defects in complex software data structures.

Description

Technical Field

[0001] This disclosure relates to the field of software testing technology, and in particular to a method, apparatus, electronic device, and storage medium for detecting null pointer defects. Background Technology

[0002] Null pointer dereferencing is a critical quality and reliability issue in software development. This defect occurs when a program attempts to access memory through a null pointer or reference, immediately triggering the operating system to terminate the program and throw an exception. On Linux / Unix systems, this will result in a "segmentation fault" signal, and on Windows systems, an "access violation" signal. Null pointer dereferencing is one of the root causes of software crashes, security vulnerabilities, and unpredictable behavior.

[0003] As software systems grow in scale and data structures become increasingly complex, especially with the prevalence of pointers and references in object-oriented programs, the concealment of null pointer errors has significantly increased, making their detection exceptionally difficult. Therefore, how to efficiently detect null pointer access errors in complex software data structures has become a pressing problem in this field. Summary of the Invention

[0004] This disclosure provides a method, apparatus, electronic device, and storage medium for detecting null pointer defects; it can efficiently detect null pointer access defects in complex software data structures.

[0005] The technical solution disclosed herein is implemented as follows:

[0006] In a first aspect, this disclosure provides a method for detecting null pointer defects. The method includes: constructing accessibility dependencies between pointers in a target data structure; and generating at least one test scenario based on the accessibility dependencies, wherein each test scenario defines a combination of null or non-null pointers, and the combination of null or non-null pointers satisfies the accessibility dependencies.

[0007] Secondly, this disclosure provides a null pointer defect detection device, which includes a construction part and a generation part; the construction part is configured to construct accessibility dependencies between pointers in a target data structure; the generation part is configured to generate at least one test scenario based on the accessibility dependencies, wherein each test scenario defines a combination of null or non-null pointers, and the combination of null or non-null pointers satisfies the accessibility dependencies.

[0008] Thirdly, this disclosure provides an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the null pointer defect detection method as described in the first aspect.

[0009] Fourthly, this disclosure provides a computer-readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the null pointer defect detection method as described in the first aspect.

[0010] Fifthly, this disclosure provides a computer program product, wherein the computer program product includes a computer program or instructions, which, when run on a processor, cause the processor to execute the computer program or instructions to implement the steps of the null pointer defect detection method as described in the first aspect.

[0011] In a sixth aspect, this disclosure provides a chip including a processor and a communication interface coupled to the processor, the processor being used to run programs or instructions to implement the null pointer defect detection method as described in the first aspect.

[0012] This disclosure provides a method for detecting null pointer defects. By analyzing the target data structure, it constructs the accessibility dependencies between the pointers included in the target data structure. Based on these accessibility dependencies, it generates test scenarios for null pointer defects. Whether a pointer in each test scenario is null is constrained by the accessibility dependencies, ensuring that each test scenario is syntactically or semantically valid. In other words, each test scenario is a valid input, avoiding a large number of invalid random inputs in traditional fuzz testing. This allows testing resources to be focused on detecting trigger paths where defects may actually exist, thereby significantly improving testing efficiency. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a method for detecting null pointer defects provided in this disclosure.

[0014] Figure 2 This is a flowchart illustrating the null pointer defect detection method implemented using a pointer dependency graph, as provided in this disclosure.

[0015] Figure 3 This is a schematic diagram of a pointer dependency graph provided in this disclosure.

[0016] Figure 4 This is a flowchart illustrating the method for determining whether a pointer is null or not provided in this disclosure.

[0017] Figure 5This is a flowchart illustrating another method for detecting null pointer defects provided in this disclosure.

[0018] Figure 6 This is a flowchart illustrating another method for detecting null pointer defects provided in this disclosure.

[0019] Figure 7 This is a structural block diagram of a null pointer defect detection device provided in this disclosure.

[0020] Figure 8 This is a schematic diagram of the hardware structure of an electronic device provided in this disclosure. Detailed Implementation

[0021] The technical solutions in the embodiments of this disclosure will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure are within the scope of protection of this disclosure.

[0022] In related technologies, null pointer defects are typically detected through static code analysis, traditional unit testing, or conventional fuzz testing.

[0023] Static code analysis infers potential null pointer accesses by analyzing code paths at compile time. This method relies on developer experience, and manually analyzing static code is time-consuming and laborious.

[0024] Traditional unit testing relies primarily on developers manually writing specific test cases, such as passing a null pointer as an argument to certain functions to verify whether the function handles null pointer exceptions. However, this approach cannot systematically cover all combinations of null values ​​for pointer variables, especially in nested pointer structures with dependencies, resulting in testing blind spots.

[0025] Conventional fuzzing is an automated testing technique that generates a large amount of input data randomly or mutated in order to trigger program crashes. However, due to a lack of understanding of the pointer relationships in data structures, the random inputs generated are blind. When dealing with complex data structures, the success rate of generating test cases that truly delve into the program logic is extremely low. A large amount of computing resources are wasted on testing syntactically or logically invalid inputs, resulting in low testing efficiency.

[0026] Based on the above problems, this disclosure aims to provide an efficient and accurate method for detecting null pointer defects such as null pointer dereferencing in complex software, such as... Figure 1 As shown, the method may include the following steps S101 and S102.

[0027] In step S101, accessibility dependencies between pointers in the target data structure are constructed.

[0028] The target data structure refers to the data structure to be tested for null pointer exceptions, such as the EData class. Accessibility dependencies, in object-oriented programming (e.g., C++), refer to the reachability of a nested pointer along a propagation path, influenced by the value of its preceding pointer. For example, accessing from A to B requires that the pointer A corresponding to its parent node is a valid, non-null object. If the pointer A corresponding to the parent node is null, any access from A to B—whether reading, writing, or using B itself as a pointer to the parent node (e.g., accessing from A to B to C)—is logically unreachable and will immediately cause a crash during execution.

[0029] In step S102, at least one test scenario is generated based on accessibility dependencies.

[0030] Each test scenario defines a combination of null or non-null pointers, and this combination satisfies accessibility dependencies. Specifically, all pointers in the target data structure are set to null or non-null, and the nullability of a pointer is constrained by accessibility dependencies. For example, for accessing data from A to B, traditional fuzzing generates test scenarios such as: A null and B null, A null and B non-null, A non-null and B null, and A non-null and B non-null. This disclosure generates test scenarios such as: A non-null and B null, and A non-null and B non-null, significantly reducing the number of effective test scenarios compared to traditional fuzzing. In practical applications, for the `prepare data` function in a project, there are dereference operations on 18 different pointer types. In traditional fuzzing, only considering whether each pointer is null, the number of possible test scenarios is 2. 18 =262,144. After adopting the solution disclosed in this publication, the number of possible test scenarios is 13,770, which is a reduction of 262,144 - 13,770 = 248,374, greatly reducing meaningless and invalid test scenarios.

[0031] One possible approach is to constrain accessibility dependencies during the generation of each test scenario; another possible approach is to randomly generate multiple initial test scenarios and determine the initial test scenario that satisfies the accessibility dependencies as at least one final test scenario.

[0032] In this embodiment of the disclosure, by analyzing the target data structure, accessibility dependencies between the pointers included in the target data structure are constructed. Based on these accessibility dependencies, test scenarios for null pointer defects are generated. Whether a pointer in each test scenario is null is constrained by the accessibility dependencies, ensuring that each test scenario is syntactically or semantically valid. That is, each test scenario is a valid input, avoiding a large number of invalid random inputs in traditional fuzz testing. This allows test resources to be focused on detecting trigger paths that may actually contain defects, thereby significantly improving test efficiency.

[0033] In some embodiments, such as Figure 2 As shown, the detection method for the null pointer defect includes the following steps S201 to S203.

[0034] In step S201, a pointer dependency graph is constructed with the target data structure as the root node.

[0035] In this graph, each node corresponds to a pointer variable in the target data structure, and the edges of the graph represent the accessibility dependencies between pointer variables.

[0036] The construction process can be as follows: take the target data structure, such as a global singleton EData, as the root node of the pointer dependency graph; recursively traverse EData and all its child objects, and create a node for each pointer variable encountered; establish edges according to the access paths of the pointers. For example, if there is a pointer A in EData, and the type pointed to by A has a pointer B, then establish a directed edge from A to node B. This edge represents the accessibility dependency between pointer variables, which means that the accessibility of node B depends on the non-null state of node A.

[0037] For example, such as Figure 3 As shown, this is a pointer dependency graph constructed with EData as the root node. The graph includes four nodes, each representing a pointer: root node EData, child node A, child node B, and child node C. The lines with arrows are directed edges. For example, EData is the root node, and its child nodes are A and B. A and B are the parent nodes of C.

[0038] In addition, each node can be defined as a data structure containing attribute information, such as: the node's unique identifier, the pointer's declared type, the complete path from the root node to the pointer, a list of all parent nodes pointing to the current node in the pointer dependency graph, a list of child nodes pointed to by the current node in the pointer dependency graph, whether the pointer is allowed to be null in the business logic, and the node's depth in the dependency graph, etc.

[0039] In step S202, the topological sort list of the pointer dependency graph is obtained.

[0040] A topological sorting list is a linear ordering of all nodes in a pointer dependency graph (directed acyclic graph). For each directed edge in the graph, such as A to B (i.e., B depends on A), in the topological sorting list, node A comes before node B; that is, the parent node of any node comes before its child nodes. Topological sorting ensures that before processing any child node, the state of all its parent nodes (whether they are empty or not) has been determined. The topological sorting list transforms a complex pointer dependency graph into a linear processing list. When traversing this list to a child node, all its parent nodes have already been traversed in the list, meaning the state of the parent nodes has been determined. Without a topological sorting list (e.g., random traversal), the algorithm might visit the child node first, before the parent node's state has been generated, making it impossible to determine whether the child node should be forcibly set to empty, thus generating invalid test cases.

[0041] In step S203, the nodes in the pointer dependency graph are traversed according to the order of the topological sort list to obtain a combination of empty or non-empty pointers.

[0042] In some feasible ways, such as Figure 4 As shown, the specific method for determining whether a pointer is null or not null includes the following steps S401 to S403.

[0043] In step S401, when all parent nodes of the first node are empty, the first node in the combination of empty or not empty pointers is determined to be empty.

[0044] This is because if the parent node is completely empty, the child node is logically unreachable and must be set to empty to ensure the validity of the test scenario.

[0045] If child nodes of a parent node that is entirely null are assigned non-null values—that is, attempting to create an object A through B where A is a null pointer—this design is meaningless input and will cause ambiguity in testing. It will be impossible to determine whether the crash is caused by the null pointer of A or by creating a null pointer from A to B. Furthermore, this state will fail when executing A through B (or earlier), preventing the testing of deeper logic.

[0046] In step S402, when at least one parent node of the second node is not empty, the second node in the null or non-null pointer combination is determined to be either null or non-null.

[0047] In step S403, when the third node is not null in the business logic, the third node in the null or not null pointer combination is determined to be not null.

[0048] Since the business logic does not allow null values, the probability of this pointer being null in practice is very small. Therefore, in the test scenario, this pointer is set to be non-null.

[0049] In this context, the first node, the second node, and the third node are all any nodes in the pointer dependency graph.

[0050] In this embodiment, in order to efficiently represent the null or non-null combination of pointers, the null or non-null combination of pointers is represented as a 01 sequence, where each bit in the 01 sequence corresponds to a pointer variable, where 0 represents null and 1 represents non-null.

[0051] The specific process for generating the 01 sequence is as follows: Create a bit sequence of the same length as the number of nodes in the target data structure, with all bits initialized to 0. Obtain the topological sorted list of the pointer dependency graph. Traverse the nodes in the pointer dependency graph according to the order of the topological sorted list. Determine if it is a root node. If it is a root node, it can be randomly defined as 0 or 1 in the 01 sequence. If it is a non-root node, check the state of all its parent nodes. When all parent nodes are defined as null (i.e., all 0) in the null or non-null pointer combination, the non-root node is defined as null (i.e., 0) in the 01 sequence. When at least one parent node of the non-root node is defined as non-null (i.e., 1) in the 01 sequence, the non-root node is randomly defined as 0 or 1 in the 01 sequence. When a node can be randomly defined as 0 or 1, it can be further determined whether the node is specified as non-null in the business logic. If so, it is set to 1; otherwise, it is randomly defined.

[0052] The embodiments disclosed herein completely avoid a large number of invalid random inputs in traditional fuzz testing. Each 01 sequence generated represents a syntactically and semantically valid executable program state, enabling testing resources to be focused on probing truly potential defect triggering paths.

[0053] This disclosure, through the introduction of a pointer dependency graph as a constraint, ensures that each generated 01 sequence represents a logically (or data structurally) valid executable program state, avoiding a large number of invalid (semantically illegal) random inputs in traditional fuzzing. This allows testing resources to be concentrated on probing truly potential defect triggering paths, realizing a shift from blind coverage to intelligent coverage. Furthermore, since various possible test scenarios that satisfy the pointer dependency graph are randomly generated, an approximate exhaustive coverage of the null pointer defect state space is achieved.

[0054] In some embodiments, such as Figure 5 As shown, the detection method for the null pointer defect includes the following steps S501 to S505.

[0055] In step S501, accessibility dependencies between pointers in the target data structure are constructed.

[0056] In step S502, at least one test scenario is generated based on accessibility dependencies.

[0057] In step S503, at least one test scenario is executed.

[0058] In some feasible approaches, to avoid generating all possible combinations of null or non-null pointers, leading to excessive useless test cases and long test execution times, deterministic specific tests can be performed first. Unlike the random generation in fuzzing, the execution logic of deterministic specific tests is highly precise and controlled, targeting only core pointers related to the core business logic, rather than all pointers. Scenario construction is achieved using the controlled variable method. That is, when testing a specific core pointer, it is explicitly set to null, while simultaneously ensuring that all other pointers in the target data structure are non-null (valid). This extreme, deterministic scenario verifies whether the system can safely report errors when core components are missing, rather than crashing directly.

[0059] In other words, the embodiments of this disclosure can adopt a hybrid testing strategy, which concentrates resources on core pointers for deterministic specific testing (ensuring depth), while using fuzz testing (ensuring breadth) for non-core global data. Deterministic specific testing can serve as a supplement to the intelligent fuzzy testing of this disclosure, which is constrained by accessibility dependencies.

[0060] In step S504, when at least one test scenario causes the program to crash during execution, the hit test scenario that caused the program to crash is recorded.

[0061] When at least one test scenario is executed, if any test scenario causes the program to crash, the test scenario that causes the program to crash is identified as the hit test scenario. The 01 sequence corresponding to the null or non-null pointer combination, the program state at the time of the crash, and the stack trace information are recorded.

[0062] In step S505, regression test cases are generated based on the hit test scenario.

[0063] Regression test cases are software test scripts or code specifically designed to verify whether fixed defects reappear. Their purpose is to ensure that after software modifications (such as bug fixes or new feature additions), the original functionality remains normal and the previous bugs do not recur. Regression test cases can be added to deterministic specific tests for easier subsequent testing.

[0064] Since test scenarios that cause program crashes may contain many redundant null pointers (meaning pointers whose value, whether null or null, has no impact on whether the program crashes), it's possible to minimize the test scenarios that cause crashes during execution. This removes null pointers that don't affect the reproducibility of the crash from the resulting hit test scenarios.

[0065] Specifically, the minimization process is an iterative process that iterates through all null pointers in the test scenario that caused the crash, attempts to flip them to non-null values ​​one by one, and re-executes the test. If the crash still occurs after flipping, the null pointer is considered redundant and is permanently set to non-null; if the crash does not occur again, the null pointer is considered necessary and is restored to null. This ensures that the final output represents the most concise steps to reproduce the crash, improving the efficiency of regression testing.

[0066] In this embodiment of the disclosure, the crashes discovered by fuzzing are often random. These random crashes are transformed into fixed regression test cases, thereby permanently locking the specific null pointer defect. Each time the code is updated, this regression test case will be run to detect whether the defect will reappear.

[0067] In some embodiments, such as Figure 6 As shown, the detection method for the null pointer defect includes the following steps S601 to S605.

[0068] In step S601, accessibility dependencies between pointers in the target data structure are constructed.

[0069] In step S602, at least one test scenario is generated based on accessibility dependencies.

[0070] In step S603, a recovery point is set.

[0071] Among them, the recovery point is used to skip the code that caused the program to crash when an exception signal caused by null pointer dereference is caught. Setting a recovery point means saving the current stack context.

[0072] In step S604, at least one test scenario is executed.

[0073] In step S605, when an abnormal signal is captured during the execution of the test scenario, the process jumps to the recovery point.

[0074] Specifically, a signal handler is set up to catch exception signals (such as segmentation fault signals) caused by null pointer dereference and skip the code that caused the crash. A recovery point is set at the current execution point, which saves the current stack context and executes the test scenario. When the exception signal is caught by the set signal handler, a non-local jump mechanism is used to skip the code that caused the program to crash, forcing the program execution flow to return to the set recovery point to continue executing subsequent tests, such as executing the next test scenario.

[0075] Standard unit testing frameworks (such as Qt Test) terminate immediately upon encountering an abnormal signal, causing all subsequent test scenarios (whether in the current round or other rounds) to fail to execute. However, in this embodiment of the disclosure, by setting a recovery point, the test process can jump to the recovery point and continue executing subsequent test scenarios upon encountering an abnormal signal, making the test process more robust.

[0076] Figure 7 This is a structural block diagram of a null pointer defect detection device disclosed herein, as shown in the figure. Figure 7 As shown, the detection device for the null pointer defect includes: a construction part 701 and a generation part 702; the construction part 701 is configured to construct accessibility dependencies between pointers in the target data structure; the generation part 702 is configured to generate at least one test scenario based on the accessibility dependencies, wherein each test scenario defines a combination of null or non-null pointers, and the combination of null or non-null pointers satisfies the accessibility dependencies.

[0077] In some embodiments, the construction part 701 is configured to construct a pointer dependency graph with the target data structure as the root node, where each node of the pointer dependency graph corresponds to a pointer variable in the target data structure, and the edges of the pointer dependency graph represent the accessibility dependencies between pointer variables; the generation part 702 is configured to obtain a topological sort list of the pointer dependency graph; and traverse the nodes in the pointer dependency graph according to the order of the topological sort list to obtain a combination of empty or non-empty pointers.

[0078] In some embodiments, the generation part 702 is configured to determine that the first node in the pointer null or non-null combination is null when all parent nodes of the first node are null, and the first node is any node in the pointer dependency graph; and to determine that the second node in the pointer null or non-null combination is null or non-null when at least one parent node of the second node is not null, and the second node is any node in the pointer dependency graph.

[0079] In some embodiments, the generation part 702 is configured to determine that the third node in the pointer null or non-null combination is non-null when the third node is non-null in the business logic, and the third node is any node in the pointer dependency graph.

[0080] In some embodiments, the null pointer defect detection device further includes an execution part and a recording part, wherein the execution part is configured to execute at least one test scenario; the recording part is configured to record the hit test scenario that causes the program to crash when the at least one test scenario causes the program to crash during execution; and the generation part 702 is configured to generate regression test cases based on the hit test scenarios.

[0081] In some embodiments, the null pointer defect detection device further includes a processing unit configured to minimize test scenarios that cause program crashes during execution, thereby obtaining hit test scenarios.

[0082] In some embodiments, the null pointer defect detection device further includes a setting section and a jump section. The setting section is configured to set a recovery point; the jump section is configured to jump to the recovery point when an abnormal signal is captured during the execution of a test scenario, so as to continue executing subsequent test scenarios.

[0083] In this embodiment, each part can implement the null pointer defect detection method provided in the above method embodiment and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0084] See Figure 8 , Figure 8 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. The electronic device can be a computing device, such as a personal computer, workstation, server, or cloud computing instance. It can serve as a local testing device for developers or as an automated testing node in a continuous integration / continuous delivery pipeline.

[0085] like Figure 8 As shown, the electronic device may include: one or more processors 810 (e.g., central processing unit, CPU), memory 820, and one or more communication interfaces 830.

[0086] The processor 810 is the control center of the electronic device, used to execute various programs and process data.

[0087] The memory 820 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 820 may include a non-transitory computer-readable storage medium. The memory 820 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 820 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the various method embodiments described above, etc.; the data storage area may store data created according to the use of the electronic device, etc. The memory 820 is used to store computer program instructions and data. In this embodiment, the memory 820 stores an operating system and one or more functional parts provided in this disclosure.

[0088] Specifically, the memory 820 stores the null pointer defect detection system provided in this disclosure. When the processor 810 executes the computer program instructions corresponding to the null pointer defect detection system, the above-described null pointer defect detection method embodiment can be implemented (e.g., Figures 1 to 6 This involves all or part of the steps shown, thereby enabling efficient and automated null pointer defect detection of a target software project (e.g., a target data structure stored in memory 820).

[0089] The communication interface 830 is used for communication between electronic devices and other devices (such as code repository servers and CI / CD coordinators). It should be noted that... Figure 8 The hardware structure shown is merely an example. The apparatus disclosed herein is not limited to this structure and may include more or fewer components, or employ different component layouts, as needed.

[0090] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include a display screen, camera assembly, microphone, speaker, radio frequency circuit, input unit, sensors (such as accelerometer, angular velocity sensor, light sensor, etc.), audio circuit, WiFi module, power supply, Bluetooth module, etc., which will not be described in detail here.

[0091] This disclosure also provides a computer-readable storage medium storing at least one instruction that is executed by a processor to implement the null pointer defect detection method as described in the above embodiments.

[0092] This disclosure also provides a computer program product including computer instructions stored in a computer-readable storage medium; a processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the null pointer defect detection method described in the above embodiments.

[0093] This disclosure also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described null pointer defect detection method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0094] It should be understood that the chip mentioned in the embodiments of this disclosure may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0095] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, servers, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0096] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0097] Furthermore, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0098] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or all or part 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 disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0099] Those skilled in the art will recognize that the functions described in this disclosure in one or more of the examples above can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer.

[0100] It should be noted that the technical solutions described in this disclosure can be combined arbitrarily as long as they do not conflict.

[0101] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for detecting a null pointer defect, the method comprising: The null pointer defect detection method comprises: constructing an accessibility dependency relationship between pointers in a target data structure; generating at least one test scenario based on the accessibility dependency relationship, wherein each test scenario defines a pointer null or non-null combination, and the pointer null or non-null combination satisfies the accessibility dependency relationship; the constructing an accessibility dependency relationship between pointers in a target data structure comprises: constructing a pointer dependency graph with the target data structure as a root node, each node of the pointer dependency graph corresponding to a pointer variable in the target data structure, and an edge of the pointer dependency graph representing an accessibility dependency between the pointer variables; the generating at least one test scenario based on the accessibility dependency relationship comprises: obtaining a topological sorting list of the pointer dependency graph; traversing nodes in the pointer dependency graph in the order of the topological sorting list to obtain the pointer null or non-null combination.

2. The method of detecting a null pointer defect of claim 1, wherein, the traversing nodes in the pointer dependency graph in the order of the topological sorting list to obtain the at least one test scenario comprises: when all parent nodes of a first node are null, determining the first node in the pointer null or non-null combination to be null, the first node being any node in the pointer dependency graph; when at least one parent node of a second node is not null, determining the second node in the pointer null or non-null combination to be null or non-null, the second node being any node in the pointer dependency graph.

3. The method of detecting a null pointer defect of claim 2, wherein, the traversing nodes in the pointer dependency graph in the order of the topological sorting list to obtain the at least one test scenario comprises: when a third node is non-null in a business logic, determining the third node in the pointer null or non-null combination to be non-null, the third node being any node in the pointer dependency graph.

4. The method of detecting a null pointer defect of claim 1, wherein, the null pointer defect detection method further comprises: executing the at least one test scenario; when the at least one test scenario causes a program to crash during execution, recording a hit test scenario that causes the program to crash; generating a regression test case based on the hit test scenario.

5. The method of detecting a null pointer defect of claim 4, wherein, the null pointer defect detection method further comprises: performing minimization processing on the test scenario that causes the program to crash during execution to obtain the hit test scenario.

6. The method of detecting a null pointer defect of claim 4, wherein, the null pointer defect detection method further comprises: setting a recovery point; when an exception signal is captured during execution of the test scenario, jumping to the recovery point to continue executing a subsequent test scenario.

7. A null pointer defect detection apparatus, comprising: the null pointer defect detection apparatus comprises a construction part and a generation part; the construction part is configured to construct an accessibility dependency relationship between pointers in a target data structure; the generation part is configured to generate at least one test scenario based on the accessibility dependency relationship, wherein each test scenario defines a pointer null or non-null combination, and the pointer null or non-null combination satisfies the accessibility dependency relationship; the constructing an accessibility dependency relationship between pointers in a target data structure comprises: constructing a pointer dependency graph with the target data structure as a root node, each node of the pointer dependency graph corresponding to a pointer variable in the target data structure, and edges of the pointer dependency graph representing accessibility dependencies between the pointer variables; generating at least one test scenario based on the accessibility dependencies, including: obtaining a topological sorting list of the pointer dependency graph; traversing nodes in the pointer dependency graph in an order of the topological sorting list to obtain the null or non-null combination of the pointer variables.

8. An electronic device, comprising: A computer device comprising a processor, a memory, and a program or instructions stored on the memory and executable on the processor, the program or instructions being executed by the processor to implement the steps of the method for detecting a null pointer defect according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, A computer readable storage medium storing a program or instructions, the program or instructions being executed by a processor to implement the steps of the method for detecting a null pointer defect according to any one of claims 1 to 6.

Images