A test case generation method and apparatus

Abstract

This disclosure provides a test case generation method and apparatus, belonging to the field of computer software testing and verification technology. The test case generation method includes: converting the control flow and data dependencies in the software code under test into a logical equivalence model; determining at least one input condition that activates the fault effect value corresponding to the current fault site in the logical equivalence model and propagates the fault effect value to the observation point; and generating test cases corresponding to the current fault site based on at least one input condition. This method is capable of generating test cases for deterministic detection of null pointer dereference defects in software code.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer software testing and verification, and in particular to a test case generation method and device. BACKGROUND

[0002] In the development process of embedded systems, operating system kernels, and high-reliability industrial control software, memory safety has always been a core challenge. Among them, null pointer dereference, as the most common and destructive defect type, often causes the program to trigger a hardware exception when trying to access memory through a null pointer, thereby causing system crashes or shutdowns, seriously affecting system reliability.

[0003] The current mainstream null pointer detection methods include fuzz testing and unit testing, but both have obvious limitations. Fuzz testing tries to trigger abnormal behavior by injecting a large amount of random or semi-random data into the program, but it is essentially a blind search. For null pointer errors that need to meet specific complex condition branches to trigger, due to the problem of path combination explosion, the probability of random input covering all paths is extremely low, resulting in low testing efficiency and inability to guarantee the completeness of defect detection. Unit testing can write test cases for specific functions, but it is highly dependent on the experience of developers, and manual writing is difficult to cover deep logic and boundary conditions, which is costly and susceptible to blind spots.

[0004] As can be seen, the existing null pointer detection methods generally lack a mathematical complete test case generation theory support. Therefore, it is urgent to develop a method that can generate test cases that can certainly trigger null pointer crashes for specific pointer dereference operations, to fundamentally improve the reliability and efficiency of defect detection. SUMMARY

[0005] The present disclosure provides a test case generation method and device; which can generate test cases for deterministic detection of null pointer dereference defects in software code.

[0006] The technical solution of the present disclosure is implemented as follows:

[0007] In a first aspect, the present disclosure provides a test case generation method, which includes: converting control flow and data dependency relationships in the software code under test into a logical equivalent model; determining at least one input condition that activates a fault effect value corresponding to a current fault site in the logical equivalent model and propagates the fault effect value to an observation point; and generating a test case corresponding to the current fault site based on the at least one input condition. The present disclosure ensures that if there is a feasible path in the software code under test that allows null pointer dereference to be observed, a corresponding test case can be generated, thereby achieving high-reliability, automated null pointer defect detection in critical software.

[0008] In some embodiments, the logical equivalence model is a software gate-level netlist, which converts the control flow and data dependencies in the software code under test into a logical equivalence model. This includes: mapping conditional statements in the software code under test to logical nodes in the software gate-level netlist; mapping pointer variables in the software code under test to signal lines connecting logical nodes; and determining the topological connections between signal lines and logical nodes based on data dependencies. By transforming the dynamic branching behavior of software into the static gating logic of a circuit, and transforming the data flow in memory into the electrical signal flow in the circuit, this mapping constructs a software gate-level netlist that can perform topology traversal and Boolean operations, thereby enabling mature circuit testing algorithms to be applied to software testing.

[0009] In some embodiments, the state of the signal line includes: a logic value indicating that the pointer is not null, a logic value indicating that the pointer is null, and a fault effect value indicating that the pointer was expected to be not null but was actually null. Compared to traditional Boolean logic which only has 0 and 1 and cannot distinguish between normal null pointers and faulty null pointers, this disclosure extends the pointer state to three or more values, making it possible to simultaneously deduce and determine the behavior of normal and faulty programs.

[0010] In some embodiments, determining at least one input condition for activating the fault effect value corresponding to the current fault site in the logical equivalence model and propagating the fault effect value to the observation point includes: determining a first input condition for activating the current fault site; backtracking based on the topology of the logical equivalence model to determine a second input condition for reaching the current fault site; and forward propagating based on the topology of the logical equivalence model to determine a third input condition for reaching the observation point from the current fault site. By injecting a fault effect value into the current fault site through activation, determining the input causing the fault through backtracking, and ensuring the fault can be detected through forward propagation, this step-by-step strategy is not only logically clear, decomposing the complex test generation problem into three standard, computable sub-problems (activation, backtracking, and propagation), but also ensures the completeness of the algorithm and avoids the blindness of heuristic search.

[0011] In some embodiments, determining the first input condition for activating the current faulty site includes: assigning the current signal line corresponding to the current faulty site a fault effect value; and constraining the parent node signal line of the current signal line in the topology to a logical value indicating that the pointer is not null. Assigning the current signal line a fault effect value logically assumes that the pointer becomes null, creating a contradiction. Constraining the parent node signal line to be non-null ensures that the control flow can reach the faulty site. If the parent node is null, the program may crash at the parent node, making testing the current faulty site meaningless. The combination of these two conditions ensures that the generated test cases not only trigger the fault but are also specific to the faulty site.

[0012] In some embodiments, based on the topology of the logical equivalence model, the second input condition for reaching the current fault site is determined by backtracking. This includes: starting from the current fault site, backtracking along the topology of the logical equivalence model, and determining the combination of values ​​assigned to input variables that activate the fault effect as the second input condition. By backtracking along the topology, the specific parameter combination that can penetrate complex logic to reach the fault site is calculated, solving the problem of difficulty in inferring deep logical dependencies when manually constructing test cases, and realizing the mapping solution from internal fault states to external input parameters.

[0013] In some embodiments, based on the topology of the logical equivalence model, forward propagation determines the third input condition from the current fault site to the observation point. This includes: searching a forward path along the topology of the logical equivalence model, setting signal lines on non-fault propagation paths to logical values ​​indicating that the pointer is not null, to establish a sensitive path from the current fault site to the observation point. This sensitive path is used to propagate the fault effect value. Since even if a null pointer defect is triggered, if the logic of subsequent code intercepts the error (i.e., the defect is masked), the test cannot observe the crash. By establishing a sensitive path, signals on non-fault paths are forced to be set to non-control values ​​(such as 1 for an AND gate or 0 for an OR gate), allowing the fault effect value to be propagated losslessly to the observation point at the endpoint for observation, ensuring the effectiveness of the test.

[0014] In some embodiments, the observation point corresponds to an exception signal emitted by the operating system during the execution of the software code under test. Using the operating system exception signal as the observation point allows the testing tool to determine whether the test passes or fails simply by monitoring the process status externally, without needing to intrude into the code for instrumentation.

[0015] In some embodiments, the test case generation method further includes: determining that the current faulty site is safe on the current detection path if at least one input condition does not exist. This enables this disclosure not only to generate test cases for detecting null pointer vulnerabilities, but also to possess the attributes of a formal verification tool, namely, the ability to prove security.

[0016] Secondly, this disclosure provides a test case generation apparatus, comprising: a conversion part, a determination part, and a generation part; the conversion part is configured to convert control flow and data dependencies in the code of the software under test into a logical equivalence model; the determination part is configured to determine at least one input condition for activating the fault effect value corresponding to the current fault site in the logical equivalence model and propagating the fault effect value to the observation point; the generation part is configured to generate test cases corresponding to the current fault site based on at least one input condition.

[0017] 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 test case generation method as described in the first aspect.

[0018] 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 test case generation method as described in the first aspect.

[0019] 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 test case generation method as described in the first aspect.

[0020] 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 test case generation method as described in the first aspect.

[0021] This disclosure provides a test case generation method. By transforming unstructured source code into a logical network, i.e., a logical equivalence model, the software testing problem is transformed into a Boolean algebra problem. By setting activation and propagation targets, at least one input condition that triggers a null pointer dereference defect at the current fault site is found. In other words, the input path that triggers the null pointer dereference defect is found deterministically (non-randomly) in software testing, solving the blindness problem of traditional fuzz testing when facing complex paths and achieving precise guidance for the current fault site. The embodiments of this disclosure guarantee that if a feasible path exists in the software code under test that makes null pointer dereference observable, then a corresponding test case can be generated, thereby achieving highly reliable and automated null pointer dereference defect detection in critical software. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a test case generation method provided in this disclosure.

[0023] Figure 2 This is a flowchart illustrating another test case generation method provided in this disclosure.

[0024] Figure 3 This is a schematic diagram of the software gate-level netlist provided in this disclosure.

[0025] Figure 4 This is a flowchart illustrating yet another test case generation method provided in this disclosure.

[0026] Figure 5This is a structural block diagram of a test case generation device provided in this disclosure.

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

[0028] 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.

[0029] The technical solutions of this disclosure can be applied to various computing environments. For example, the solution can be implemented in a software testing tool that runs on a developer's workstation. After writing or modifying code (e.g., languages ​​containing pointers or references such as C, C++, and Java), the developer can call the tool to perform a complete scan for null pointer defects on specific functions, modules, or code files.

[0030] In another application scenario, the technical solution disclosed herein can be deployed on an automated test server within a continuous integration / continuous deployment (CI / CD) pipeline. Whenever a new code commit is made, the server automatically executes the test case generation method of this disclosure, analyzes the code under test, and attempts to generate test cases for all pointer dereference operations in the code. If any test cases are generated, it indicates a definite null pointer defect in the newly committed code, the pipeline can be blocked, and the generated test cases (including the input parameters and memory state required to trigger the defect) are returned to the developer for fixing.

[0031] In another application scenario, the technical solution disclosed herein can be provided as a Software as a Service. Users upload their source code or compiled intermediate representation via the network, and a cloud-based testing platform executes the test case generation method of this disclosure and returns a detailed test report to the user. The report contains all discovered null pointer defects and their corresponding reproducible test cases, or proofs indicating that certain pointer dereference operations are safe under specific constraints.

[0032] The test case generation method provided in this disclosure will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 As shown, the test case generation method may include the following steps S101 to S103.

[0033] In step S101, the control flow and data dependencies in the software code under test are converted into a logical equivalence model.

[0034] The software code under test refers to the source code or intermediate representation of a computer program that serves as input data, including various language codes that support pointer operations.

[0035] Control flow refers to the sequential order of instructions executed by a program. It is usually determined by conditional jumps, loops, and function calls. It is the path logic that determines how the program proceeds, such as if statements, while loops, and switch-case jump statements.

[0036] Data dependency refers to the data transfer and reference relationships between variables in a program, that is, how the value of one variable affects another variable. It is the data logic that determines what the program calculates. For example, in a=b+1, the data 'a' depends on 'b'.

[0037] A logical equivalence model is an abstract mathematical or graphical representation whose logical behavior (the correspondence between inputs and outputs) is completely consistent with the code of the software under test. In a logical equivalence model, the program execution path is expressed as a problem of satisfying logical constraints, and variable assignment and condition judgment are transformed into combinations of logical propositions.

[0038] Specifically, the process begins by reading the code of the software under test (e.g., functions written in C). Through lexical and syntactic analysis, the control flow structure (such as sequential execution and branching) and data dependencies (such as assignment and reference between variables) are identified. Based on this, a logical equivalence model is constructed. In the logical equivalence model, the software's execution logic is transformed into Boolean logic operations. For example, the value of a variable that determines whether a certain piece of code is executed is treated as a control signal in the logical model, determining whether the path is enabled or disabled.

[0039] In step S102, at least one input condition is determined for the fault effect value corresponding to the current fault site in the activation logic equivalence model and the fault effect value is propagated to the observation point.

[0040] A fault site refers to the specific location within the logical equivalence model selected for defect detection. In null pointer detection, it specifically refers to the code location where a pointer dereference operation occurs, such as... p, p->member, p[i], etc. are all faulty sites.

[0041] A fault effect value is a special logical state symbol used to represent a state where the expected behavior differs from the actual fault behavior. In hardware circuit testing, it is typically denoted as D or D'. In the embodiments of this disclosure, it represents a contradictory state that should logically be non-empty but is actually injected as empty.

[0042] An observation point refers to an output port in a logically equivalent model whose state change can be monitored or detected externally. It can be a program's exit point, return value, or exception signal trigger point, such as the segmentation fault signal thrown by the operating system when a program crashes.

[0043] In some feasible implementations, the observation point corresponds to an exception signal issued by the operating system during the runtime of the software code under test. An exception signal is a software interrupt notification sent by the operating system kernel to a process when it detects an illegal operation, such as an illegal memory access. For example, a segmentation fault signal is typically triggered by dereferencing a null pointer or a dangling pointer.

[0044] The test case execution environment in this embodiment includes a signal capture mechanism. Before executing the generated test cases, the testing tool calls system interfaces, such as `signal()` or `sigaction()` in Linux, to register a custom signal handling function to capture abnormal signals issued by the operating system, such as segmentation fault signals. When the test case successfully reproduces null pointer dereference, the operating system kernel issues an error signal. The testing tool captures this signal but does not terminate the program. Instead, it records a successful fault observation flag and jumps out of the current error context through mechanisms such as exception jumps, determining that the test case has passed, i.e., the defect has been successfully discovered.

[0045] Null pointer references in software often lead to hardware interruptions, which the operating system will convert into an exception signal. This disclosure uses the operating system exception signal as an observation point, so that the testing tool does not need to intrude into the code to instrument it, but only needs to monitor the process status externally to determine whether the test passes or fails.

[0046] Input conditions refer to the set of constraints that external input variables (parameters, global variables, etc.) must satisfy in order to meet specific logical path and fault triggering requirements. For example, the final input condition requires function parameter x > 10 and y == 0.

[0047] Traverse the logical equivalence model to identify all pointer dereference operations as potential failure sites. Treat any potential failure site as the current failure site, and set activation and propagation goals. The activation goal is the failure effect value that must activate the current failure site (i.e., trigger a null pointer exception), and the propagation goal is that the null pointer exception must propagate to the observation point (i.e., the location of program crash or error). This allows for the calculation of the set of constraints that the program's external inputs (such as function parameters and global variables) must satisfy to meet the above activation and propagation goals; that is, at least one input condition.

[0048] In step S103, test cases corresponding to the current faulty site are generated based on at least one input condition.

[0049] Based on at least one determined input condition (e.g., parameter A must be greater than 5, and parameter B must be NULL), the tool automatically synthesizes an executable test code or data file. When the software code under test loads and runs the test case, it will execute precisely along the calculated path and trigger a null pointer dereference at the current failure site, thereby verifying the existence of the defect.

[0050] In this embodiment, by transforming unstructured source code into a logical network, i.e., a logical equivalence model, the software testing problem is transformed into a Boolean algebra problem. By setting activation and propagation targets, at least one input condition that triggers a null pointer defect at the current fault site is found. This means that the input path triggering the null pointer defect is found deterministically (non-randomly) in software testing, solving the blindness problem of traditional fuzz testing when facing complex paths and achieving precise guidance for the current fault site. This embodiment guarantees that if a feasible path exists in the software code under test that makes null pointer dereference observable, then corresponding test cases can be generated, thereby achieving highly reliable and automated null pointer defect detection in critical software.

[0051] In some embodiments, the logical equivalence model is a software gate-level netlist, such as... Figure 2 As shown, the test case generation method includes the following steps S201 to S205.

[0052] In step S201, the conditional statements in the code of the software under test are mapped to logical nodes in the software gate-level netlist.

[0053] A software gate-level netlist is a topology graph composed of logic gates (AND, OR, NOT, etc.) and the signal lines connecting them. It is used to accurately describe software logic, essentially abstracting the software code under test (SD) into a circuit board. For example, a directed graph consisting of AND, OR, and NOT gates corresponds to the logic of the SD software code.

[0054] Conditional statements are statements in programming languages ​​used to change the execution flow based on the value of a Boolean expression; they are essentially branching structures in code. For example, `if (p!=NULL)` is a conditional statement.

[0055] By scanning the conditional statements (such as if, switch, while, etc.) in the code of the software under test, complex branching structures can be mapped to logic nodes of a multiplexer structure in a circuit. For logical AND operations, they are mapped to AND gates, and for logical OR operations, they are mapped to OR gates. For loops (such as while or for), this embodiment adopts a finite expansion strategy. For example, the loop body is copied k times (e.g., k=3), expanding it into a cascaded if-else structure.

[0056] For example, let's take a function under test in the code of the software under test as an example. The function under test is as follows.

[0057] void select_and_write(int sel, int p_primary, int p_backup) {

[0058] int current_ptr;

[0059] if (sel != 0) {

[0060] current_ptr = p_primary;

[0061] }

[0062] else {

[0063] current_ptr = p_backup;

[0064] }

[0065] current_ptr = 1024; / / It is necessary to check here whether current_ptr might be NULL, this position is the fault site.

[0066] }

[0067] The software gate-level netlist converted from the function under test is as follows: Figure 3 As shown, the if-else conditional statement in the function under test is converted into a multiplexer 301, and the if(sel!=0) conditional logic is converted into a comparator 302. `current_ptr = 1024` is converted to fault site marker 303. The input signal line `p_primary` indicates that the state of `p_primary` is selected when the condition is true (if statement); the input signal line `p_backup` indicates that the state of `p_backup` is selected when the condition is false (else statement); the input signal line `sel` indicates that the variable `sel` determines which signal is enabled by the multiplexer 301. The output signal line `current_ptr` represents the pointer state stream after logical selection.

[0068] In step S202, the pointer variables in the software code under test are mapped to signal lines connecting the logic nodes.

[0069] A logic node refers to the basic unit in a software gate-level netlist that performs Boolean logic operations, corresponding to a gate device in a circuit. A pointer variable refers to a variable type that stores a memory address; it is the object of detection in this disclosure and also the carrier of data transmitted on a signal line. A signal line refers to the edge connecting two logic nodes in a software gate-level netlist, used to transmit logical states, corresponding to a wire in a circuit. This disclosure represents the state transition of a pointer variable at different lines of code.

[0070] In some possible implementations, the states of the signal lines include: logical values ​​indicating that the pointer is not null, logical values ​​indicating that the pointer is null, and fault effect values ​​indicating that the pointer is expected to be not null but is actually null.

[0071] Logical values ​​refer to the discrete states that may occur on a signal line. In this disclosure, they are used to indicate pointer states. For example, a logical value of 1 indicates that the pointer is not null, representing that the pointer points to valid memory (not null); a logical value of 0 indicates that the pointer is null, representing NULL; a fault effect value is denoted as D, representing 1 for normal and 0 for fault. This discrete state is only an example, and more discrete state values ​​can be included in the specific case, such as a fault effect value denoted as D', representing 0 for normal and 1 for fault.

[0072] Compared to traditional Boolean logic which only uses 0 and 1 and cannot distinguish between normal null pointers and faulty null pointers, this disclosure extends the pointer state to three or more values, enabling the behavior of normal and faulty programs to be deduced simultaneously.

[0073] In step S203, the topological connection between the signal line and the logic node is determined based on the data dependency relationship.

[0074] Topology connection refers to the connection relationship between logical nodes in a software gate-level netlist based on the data flow direction, reflecting the order of code execution dependencies.

[0075] In step S204, at least one input condition is determined for the fault effect value corresponding to the current fault site in the activation logic equivalent model and the fault effect value is propagated to the observation point.

[0076] In step S205, test cases corresponding to the current faulty site are generated based on at least one input condition.

[0077] In this embodiment of the disclosure, by transforming the dynamic branching behavior of the software into the static gating logic of the circuit, and transforming the data flow in memory into the electrical signal flow in the circuit, this mapping constructs a software gate-level netlist that can perform topology traversal and Boolean operations, thereby enabling mature circuit testing algorithms to be applied to software testing.

[0078] In some embodiments, such as Figure 4 As shown, the test case generation method includes the following steps S401 to S406.

[0079] In step S401, the control flow and data dependencies in the software code under test are converted into a software gate-level netlist.

[0080] In step S402, the first input condition for activating the current faulty site is determined.

[0081] In some feasible implementations, determining the first input condition for activating the current faulty site specifically includes: assigning the current signal line corresponding to the current faulty site a fault effect value; and constraining the parent node signal line of the current signal line in the topology to a logical value indicating that the pointer is not null. Here, the first input condition includes: the value of the current signal line is the fault effect value, and the value of the parent node signal line is not null.

[0082] In software, pointers often have hierarchical dependencies, such as a structure pointer `struct A`. ptr; ptr->member. To test the faulty site ptr->member, both member and ptr need to be considered.

[0083] In this embodiment, the value of the current signal line corresponding to the current faulty site is forcibly assigned to the fault effect value D. This process injects a fault, meaning that in logical deduction, the faulty site should be 1, but is actually 0. Furthermore, for cascading pointers, if the parent node is null, the dereference operation of the child node cannot be executed at all (the program will crash prematurely at the parent node). Here, the parent node refers to the upstream node that directly dominates the current node in the pointer dependency chain or control flow dominance tree. Therefore, to accurately test the child node (faulty site), the parent node must be valid. By scanning the topology of the software gate-level netlist, all parent node signal lines of the current signal line are found, and they are forcibly constrained to the logical value 1 (not null). For example, for the code a->b->c, to test the dereference of c, c is set to D, and both a and b are set to 1.

[0084] Assigning the current signal line the fault effect value logically assumes the pointer becomes null, creating a contradiction. Constraining the parent node's signal line to be non-null ensures control flow reaches the faulty site. If the parent node were null, the program might crash at the parent node, making testing the current faulty site meaningless. These two conditions combined ensure that the generated test cases not only trigger the fault but are also targeted at a specific faulty site.

[0085] In step S403, based on the topology of the software gate-level netlist, the second input condition for reaching the current fault site is determined by backtracking.

[0086] Backtracking refers to the process of starting from the faulty site within the software gate-level netlist and tracing back towards the input end to find the input combination that satisfies the state of that node. In other words, it is the process of solving what the input X must be in order to obtain the result Y. For example, if we know that c=a&&b and require c=1, backtracking will deduce that a=1 and b=1 are required.

[0087] In some feasible approaches, based on the topology of a software gate-level netlist, the second input condition for reaching the current fault site is determined by backtracking in reverse. This includes: starting from the current fault site, backtracking along the topology of the logical equivalence model, and combining the values ​​of the input variables whose fault effect values ​​are activated to determine the second input condition.

[0088] The assignment combination of input variables refers to a specific set of numerical values ​​or states, assigned to the program's input parameters (external interface), corresponding to the core data part of the test case. For example, for the function foo(int a, char... b) The combination {a=10, b=NULL} is an assignment combination.

[0089] When the signal line activation step inside the software gate-level netlist is forcibly assigned a value (such as set to D or 1), these values ​​become the target to be solved, that is, the logic gate whose output value is determined (D) but whose input value is not determined. Based on the logic function of the logic gate (such as AND, NOT, OR, multiplexer, etc.), find out what the input is to obtain the predetermined output D.

[0090] Choose any combination of assignments and recursively proceed backward. If a conflict is encountered during backtracking—for example, a variable was required to be 0 in a previous step but is required to be 1 in this step—the algorithm backtracks, undoes the most recent assignment, and tries another branch at the decision point. When the backtracking reaches the original input of the software gate-level netlist without conflict, the combination of assignments for all input ports constitutes the second input condition.

[0091] By tracing back along the topology, the specific parameter combinations that can penetrate complex logic to reach the fault site are calculated, solving the problem of difficulty in inferring deep logical dependencies when manually constructing test cases, and realizing the mapping solution from internal fault state to external input parameters.

[0092] In step S404, based on the topology of the software gate-level netlist, the third input condition for reaching the observation point from the current fault site is determined through forward propagation.

[0093] Forward propagation refers to the process of searching from the faulty site within the software gate-level netlist towards the output, ensuring that the fault effect value reaches the observation point by setting bypass signal values. In other words, it's about ensuring a clear path between the faulty site and the observation point to allow the fault effect value to reach the observation point. For example, if the fault effect value is at one input of an AND gate, the other input of the AND gate must be set to logic true to allow D to propagate to the output.

[0094] In some feasible implementations, based on the topology of a software gate-level netlist, forward propagation determines the third input condition from the current fault site to the observation point. This includes: searching a forward path along the topology of the software gate-level netlist and setting signal lines on non-fault propagation paths to logical values ​​indicating that the pointer is not null, to establish a sensitized path from the current fault site to the observation point. The sensitized path is used to propagate the fault effect value. The third input condition includes setting signal lines on non-fault propagation paths to logical values ​​indicating that the pointer is not null.

[0095] A sensitized path refers to a path in a software gate-level netlist from a faulty station to an output point, where all non-faulty inputs of logic gates along this path are set to non-control values, allowing fault effects to propagate along the path—essentially a smooth error reporting channel. For example, if there's an AND gate on the path, and the fault effect is at input A, then for sensitization, input B must be forced to be 1. If B is 0, the output will always be 0, and the fault effect will be blocked, meaning the path is not sensitized.

[0096] In this embodiment, the process of establishing a sensitization path is as follows: The next logic gate for the propagation of the fault effect value is determined, and all other non-faulty inputs of that logic gate are forcibly set to their non-control values. For example, for AND and NAND gates, the non-control value is 1; for OR and NOR gates, the non-control value is 0. For multiplexers, if the fault effect value is at a data input, a selection signal needs to be set to select that input; if the fault effect value is at a selection input, the two data inputs need to be set to opposite logic values ​​(0 and 1) to reflect the error at the selection input to the output. The above steps are repeated until the fault effect value reaches a preset observation point. These non-control values, forcibly set to establish the path, constitute the third input condition.

[0097] Even if a null pointer exception is triggered, if subsequent code logic intercepts the error (i.e., the exception is masked), the crash cannot be observed in the test. By establishing a sensitive path, signals on non-faulty paths are forced to be set to non-control values ​​(such as 1 for an AND gate or 0 for an OR gate), allowing the fault effect to be propagated undamaged to the observation point at the endpoint, thus ensuring the effectiveness of the test.

[0098] In step S405, test cases corresponding to the current faulty site are generated based on the first input condition, the second input condition, and the third input condition.

[0099] In step S406, if there is no at least one input condition, it is determined that the current faulty site is safe on the current detection path.

[0100] Safety refers to the condition that, under the logic and constraints of the software code under test, no single input combination can trigger abnormal behavior at the currently faulty site. For example, the code `if (p!= NULL)`. p = 1, for faulty sites Because of the pre-check, it is logically impossible to simultaneously satisfy the condition that the row is reached and p is NULL, therefore the faulty site is safe.

[0101] Traditional fuzzing, if it runs for a long time without finding a null pointer exception, can only guess that the exception might not exist, but it doesn't provide a definitive conclusion. This embodiment provides a deterministic conclusion. When attempting to generate test cases for a faulty site, it iterates through all possible combinations of logical paths. If logical conflicts exist in all of them, then the faulty site is determined to be safe.

[0102] For example, during the reverse backtracking phase, after traversing all branches of the decision tree, it was found that all paths would lead to logical conflicts. For instance, to trigger a null pointer exception, one must enter the if(p==NULL) branch, but to execute dereferencing... p must then be in the else branch, leading to a contradiction where p=0 AND p=1. Alternatively, during the forward propagation phase, it may be discovered that all paths to the observation point are blocked by unsatisfiable conditions, such as mandatory null value checks (if (p)) on all paths intercepting the fault. In this case, it is determined that within the current detection range, the faulty site is absolutely safe, and the software code under test at that location does not pose a null pointer risk. This allows this disclosure to not only generate test cases for detecting null pointer defects but also possess the attributes of a formal verification tool, namely, the ability to prove security.

[0103] In this embodiment of the disclosure, a fault effect value is injected into the current fault site through an activation operation, the input that caused the fault is determined through backtracking, and the fault is detected through forward propagation. This step-by-step strategy is not only logically clear, but also decomposes the complex test generation problem into three standard, computable sub-problems (activation, backtracking, and propagation), ensuring the completeness of the algorithm and avoiding the blindness of heuristic search.

[0104] For example, in the comparison between this disclosure embodiment and fuzz testing, a piece of code of the software under test is as follows:

[0105] void complex_check(int a, int b, struct data p) {

[0106] if (a>10) {

[0107] if (b<5) {

[0108] / / ... Complex logic...

[0109] if (check_sum(a,b)) {

[0110] p = 0; / / Faulty site

[0111] }

[0112] }

[0113] }

[0114] }

[0115] Fuzz testing, which randomly generates a and b, requires a > 10, b < 5, and checksum to pass simultaneously. The probability of this is extremely low, and it might take hours to cover all possible cases. p. In this embodiment of the disclosure, during the activation phase, setting The signal line corresponding to p is D (i.e., p = NULL in practice). During the rationalization phase, backtracking to if(check_sum) sets check_sum to true, backtracking to if (b<5) requires input b<5, backtracking to if (a>10) requires input a>10, backtracking to... The source of p requires the input parameter p to be NULL, thus obtaining the input vector V ={a=11, b=4, p=NULL}, generating test cases in milliseconds, and hitting the target on the first try.

[0116] In summary, the core process of this publicly disclosed test case generation method includes: First, the logical equivalence model construction phase. The code of the software under test (e.g., C / C++) is parsed, its control flow is mapped to logic gates, and pointer variables are mapped to signal lines. During this process, a special logical state space is introduced: {0, 1, D}. Here, logic 1 represents a non-null pointer (valid), logic 0 represents a null pointer (NULL), and D represents a state that is expected to be non-null but is null under the fault assumption. Second, the fault activation phase. A pointer dereference operation is selected as the current fault site in the logical equivalence model, and the signal line state of the current fault site is forcibly set to D. This is equivalent to injecting a null pointer fault into the mathematical model. Third, the rationalization phase. Starting from the current fault site set to D, the logical equivalence model is traced back to the program's input port (function parameters or global variables). By solving the Boolean constraints of the logic gates, the required values ​​of the input variables are calculated to make the value of D true at the current fault site. For example, if the current fault location is within an if(A&&B) block, then it must be deduced that the input satisfies A=1 and B=1. Finally, in the fault propagation phase, a path is searched backward from the current fault location to the observation point (such as program termination or a specific monitoring point). The algorithm ensures that the fault effect D is not masked by subsequent logic by setting the state of the bypass signal line, and can ultimately trigger the abnormal signal of the system. If the above process is successful, the generated set of inputs constitutes the deterministic test cases; if it is proven that no solution can be found in a finite number of steps, then it is mathematically proven that the pointer is safe in the current path.

[0117] Figure 5 This is a structural block diagram of a test case generation device disclosed herein, such as... Figure 5 As shown, it includes: a transformation part 501, configured to transform the control flow and data dependencies in the code of the software under test into a logically equivalent model; a determination part 502, configured to determine at least one input condition for activating the fault effect value corresponding to the current fault site in the logically equivalent model and propagating the fault effect value to the observation point; and a generation part 503, configured to generate test cases corresponding to the current fault site based on at least one input condition.

[0118] In some embodiments, the logical equivalence model is a software gate-level netlist. The transformation part 501 is configured to map conditional statements in the software code under test to logical nodes in the software gate-level netlist; map pointer variables in the software code under test to signal lines connecting logical nodes; and determine the topological connection between signal lines and logical nodes based on data dependencies.

[0119] In some embodiments, the state of a signal line includes: a logic value indicating that the pointer is not null, a logic value indicating that the pointer is null, and a fault effect value indicating that the pointer is expected to be not null but is actually null.

[0120] In some embodiments, the determining portion 502 is configured to determine a first input condition for activating the current faulty site; backtrack to determine a second input condition for reaching the current faulty site based on the topology of the logical equivalence model; and forward propagate to determine a third input condition for reaching the observation point from the current faulty site based on the topology of the logical equivalence model.

[0121] In some embodiments, the determining part 502 is configured to assign the current signal line corresponding to the current fault site a fault effect value; and constrain the parent node signal line of the current signal line in the topology to a logical value indicating that the pointer is not null.

[0122] In some embodiments, the determining part 502 is configured to backtrack along the topology of the logical equivalence model from the current fault site and determine the combination of the values ​​of the input variables whose fault effect values ​​are activated as the second input condition.

[0123] In some embodiments, determining portion 502 is configured to search forward paths along the topology of the logical equivalence model, setting signal lines on non-fault propagation paths to logical values ​​indicating that the pointer is not null, in order to establish a sensitized path from the current fault site to the observation point, the sensitized path being used to propagate fault effect values.

[0124] In some embodiments, the observation point corresponds to an anomaly signal emitted by the operating system during the execution of the software code under test.

[0125] In some embodiments, the test case generation apparatus, determining portion 502, is configured to determine that the current faulty site is safe on the current detection path if it is determined that at least one input condition does not exist.

[0126] In this embodiment, each part can implement the test case generation method provided in the above method embodiment and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0127] refer to Figure 6 This illustration shows a schematic diagram of the hardware structure of an electronic device provided in an exemplary embodiment of this disclosure. In some examples, the electronic device may be at least one of devices such as a smartphone, smartwatch, desktop computer, laptop, virtual reality terminal, augmented reality terminal, wireless terminal, and laptop computer. The electronic device has communication functions and can access wired or wireless networks. The term "electronic device" can refer to one of multiple terminals; those skilled in the art will understand that the number of such terminals may be more or less. It is understood that the electronic device undertakes the computation and processing work of the technical solution of this disclosure, and this disclosure does not limit this aspect.

[0128] like Figure 6As shown, the electronic device in this disclosure may include one or more of the following components: processor 610 and memory 620.

[0129] Optionally, the processor 610 connects various parts within the electronic device using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 620, and by calling data stored in the memory 620. Optionally, the processor 610 can be implemented using at least one hardware form of Digital Signal Processing (DSP), Field Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 610 can integrate one or more combinations of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural-network Processing Unit (NPU), and baseband chip. Among them, the CPU mainly handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required to be displayed on the touch screen; the NPU is used to implement artificial intelligence (AI) functions; and the baseband chip is used to handle wireless communication. It is understandable that the aforementioned baseband chip may not be integrated into the processor 610, but may be implemented using a separate chip.

[0130] The memory 620 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 620 may include a non-transitory computer-readable storage medium. The memory 620 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 620 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 based on the use of the electronic device, etc.

[0131] 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, Wi-Fi module, power supply, Bluetooth module, etc., which will not be described in detail here.

[0132] This disclosure also provides a computer-readable storage medium storing at least one instruction that is executed by a processor to implement the test case generation method described in the above embodiments.

[0133] 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 test case generation method described in the above embodiments.

[0134] 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 test case generation method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0135] 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.

[0136] 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 an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

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

[0142] 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 test case generation method characterized by, The test case generation method comprises: The control flow and data dependency relationship in the software code to be tested are converted into a logic equivalent model, and the logic equivalent model is a software gate-level netlist; Determine at least one input condition for activating the fault effect value corresponding to the current fault site in the logic equivalent model and propagating the fault effect value to the observation point; Based on the at least one input condition, a test case corresponding to the current fault site is generated; The control flow and data dependency relationship in the software code to be tested are converted into a logic equivalent model, and the logic equivalent model is a software gate-level netlist; The conditional judgment statement in the software code to be tested is mapped into a logic node in the software gate-level netlist; The pointer variable in the software code to be tested is mapped into a signal line connecting the logic nodes, and the state of the signal line includes a logic value representing that the pointer is not empty, a logic value representing that the pointer is empty, and a fault effect value representing that it is expected to be not empty but actually empty; The topology connection between the signal line and the logic node is determined based on the data dependency relationship.

2. The test case generation method of claim 1, wherein, The determination of at least one input condition for activating the fault effect value corresponding to the current fault site in the logic equivalent model and propagating the fault effect value to the observation point comprises: Determine the first input condition for activating the current fault site; Based on the topology structure of the logic equivalent model, the second input condition reaching the current fault site is determined by backtracking in reverse; Based on the topology structure of the logic equivalent model, the third input condition reaching the current fault site to the observation point is determined by forward propagation.

3. The test case generation method of claim 2, wherein, The determination of the first input condition for activating the current fault site comprises: The current signal line corresponding to the current fault site is assigned to the fault effect value; The parent node signal line of the current signal line in the topology structure is constrained to a logic value representing that the pointer is not empty.

4. The test case generation method of claim 2, wherein, The determination of the second input condition reaching the current fault site based on the topology structure of the logic equivalent model by backtracking in reverse comprises: Starting from the current fault site, the assignment combination of the input variable activated by the fault effect value is determined as the second input condition by backtracking along the topology structure of the logic equivalent model.

5. The test case generation method of claim 2, wherein, The determination of the third input condition reaching the current fault site to the observation point based on the topology structure of the logic equivalent model by forward propagation comprises: Along the forward path of the topology structure of the logic equivalent model, the signal line on the non-fault propagation path is set to a logic value representing that the pointer is not empty, so as to establish a sensitization path from the current fault site to the observation point, and the sensitization path is used for propagating the fault effect value.

6. The test case generation method of claim 1, wherein, The observation point corresponds to an exception signal issued by an operating system during the running of the software code to be tested.

7. The test case generation method of claim 1, wherein, The test case generation method further comprises: If the at least one input condition does not exist, it is determined that the current fault site is safe on the current detection path.

8. A test case generation apparatus characterized by comprising: The test case generation device comprises a conversion part, a determination part and a generation part; The conversion part is configured to convert the control flow and data dependency relationship in the software code to be tested into a logic equivalent model; The determining part is configured to determine a fault effect value corresponding to a current fault site in the logic equivalent model and propagate the fault effect value to at least one input condition of an observation point; The generating part is configured to generate a test case corresponding to the current fault site based on the at least one input condition; In the logic equivalent model is a software gate level netlist, the conversion part is specifically configured to map a conditional judgment statement in the to-be-tested software code into a logic node in the software gate level netlist; and map a pointer variable in the to-be-tested software code into a signal line connecting the logic nodes, a state of the signal line including a logic value representing that the pointer is not empty, a logic value representing that the pointer is empty, and a fault effect value representing that the pointer is expected to be not empty but actually empty; and determine a topological connection between the signal line and the logic node based on the data dependency relationship.

Images