A runtime exception detection method fusing slice testing and formal verification

Abstract

The application provides a runtime exception detection method fusing slice testing and formal verification, comprising the following steps: adopting program slicing to extract a minimized code segment related to a potential abnormal program point from a program to be detected; generating a test case based on the minimized code segment related to the potential abnormal program point; and executing the minimized code segment containing the test case to obtain a detection result; the method can not only detect known exceptions, but also cover more potential exceptions through automatic path analysis, especially complex input scenarios and dynamic behavior triggered exceptions, and the scheme can identify abnormal paths in advance and reduce post-analysis after actual exception occurrence.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computer science, and specifically relates to a runtime exception detection method combining slicing test and formal verification. BACKGROUND

[0002] In software development, runtime exceptions are errors caused by code logic errors, data problems, or environmental mismatches during program execution. These exceptions cannot be detected at compile time and do not require explicit capture or declaration. However, once a runtime exception occurs, it usually causes the program to terminate abnormally, affecting system stability and user experience. Common runtime exceptions include NullPointerException, ArrayIndexOutOfBoundsException, and ArithmeticException.

[0003] To solve the system crashes and errors caused by runtime exceptions, the industry has developed various techniques for detecting and locating exceptions. For example:

[0004] 1. Test-based formal verification (TBFV)

[0005] TBFV is a method that integrates testing and formal verification, aiming to ensure the correctness of all traversed paths in the program. It verifies the behavior of the path by generating test cases and uses Hoare logic to derive the preconditions and postconditions of the path. Its main advantage is that it can discover some runtime exceptions during development, avoiding their occurrence during program execution. However, TBFV requires traversing a large number of program paths, which can lead to high computational overhead, especially when dealing with complex input conditions or data structures. In addition, TBFV cannot guarantee that all exception paths are covered, especially in complex path combinations or multi-threaded environments.

[0006] 2. Program slicing technology

[0007] Program slicing is an analysis technique that extracts code fragments related to a specific variable or condition from the code, effectively reducing the scope of debugging and exception detection. This method has been widely used in debugging and fault localization, reducing debugging time by filtering out irrelevant code related to exceptions. However, in complex programs, program slicing technology often cannot accurately distinguish between code unrelated to exceptions, resulting in redundant slicing results. In addition, program slicing mostly relies on static analysis and cannot capture dynamic behavior and runtime data flow, leading to insufficient detection of some exception paths.

[0008] 3. Stack backtracking and dynamic analysis exception localization method

[0009] This method locates the root cause of an exception by capturing the program's stack information and dynamically analyzing the call chain. Dynamic stack tracing can record the execution path and state of the program, helping developers trace the source of exceptions in complex control flow or multi-threaded programs. This method is particularly suitable for problem localization after an exception occurs, but it relies on the actual occurrence of exceptions and cannot be used for early prediction or prevention.

[0010] 4. D-REX: Deep Learning-based Exception Detection

[0011] D-REX is a runtime exception detection tool based on deep learning models, which uses large-scale code libraries to train models to identify the relevance between code fragments and common exception types. Through analysis of code structure, D-REX can predict which code regions are prone to specific exception types, such as null pointer exceptions or array out-of-bound exceptions. Its advantage is that it can detect potential problems in advance when code is submitted, reducing the time spent on troubleshooting after an exception occurs.

[0012] 5. MAESTRO: Exception Solution Based on Recommendation System

[0013] MAESTRO is a tool based on a recommendation system, aiming to recommend the most relevant technical resources and solutions to developers by analyzing exception information. MAESTRO can automatically match exceptions with relevant Stack Overflow posts or documents to provide direct assistance to developers. However, its effectiveness depends on the quality of the recommendation database, and it can only provide assistance after an exception occurs, lacking preventive capabilities.

[0014] The above implementation schemes have achieved certain results in runtime exception detection and localization, but still have the following problems and shortcomings:

[0015] 1. TBFV's insufficient path coverage and high computational cost

[0016] TBFV has obvious limitations in path coverage and computational cost. Due to the limitations of test data generation, TBFV cannot cover all possible input combinations and execution paths, especially when dealing with complex programs, it is easy to miss potential exception paths. In addition, when deriving loop invariants, TBFV needs to perform complex logical calculations, which greatly increases the verification cost, making it difficult to efficiently apply in large-scale programs.

[0017] 2. Analysis redundancy of program slicing and insufficient dynamic behavior capture

[0018] Although program slicing techniques can narrow down the debugging scope and improve the efficiency of exception localization, the results often contain a large number of redundant code fragments, increasing the workload of subsequent analysis. In particular, in programs with complex control flow and exception handling logic, the slicing results may be mixed with code unrelated to the exception. In addition, program slicing is mainly based on static analysis, making it difficult to capture dynamic behaviors of the program, such as concurrent processing, asynchronous calls, or external input dependencies. This makes it less comprehensive in detecting exceptions in some complex scenarios.

[0019] 3. Limitations of post-mortem analysis of stack backtraces and dynamic analysis

[0020] Exception localization methods based on stack backtraces and dynamic analysis rely on the stack information captured when the program actually encounters an exception, so they can only be analyzed after the exception occurs. This means that developers cannot identify and prevent exception paths in advance, especially in critical systems. This post-mortem approach increases the risk of system crashes and data loss. In addition, stack backtraces and dynamic analysis require recording a large amount of execution data, resulting in high computational overhead, especially in large-scale systems and multi-threaded environments, where performance issues are particularly prominent.

[0021] 4. Insufficient generalization ability and high computational cost of D-REX

[0022] D-REX relies on large-scale codebase training data to predict the occurrence of runtime exceptions. Although this approach performs well in detecting common exception types, its generalization ability is limited, and the model's prediction performance may decrease significantly when dealing with new types of exceptions or complex business logic. In addition, the deep learning model of D-REX requires a large amount of computational resources during training and inference, especially when detecting large-scale codebases. This high resource consumption significantly increases the difficulty of practical application.

[0023] 5. Dependence of MAESTRO's recommendation quality and insufficient prevention ability

[0024] MAESTRO provides developers with exception solutions based on a recommendation system, and its effectiveness depends on the quality of the recommendation algorithm and database. In the absence of high-quality technical resources or insufficient discussion of specific exceptions, MAESTRO may not be able to provide effective solutions. At the same time, the system can only be used as a post-mortem aid and cannot be used for exception detection and prevention, and cannot play a role before the exception occurs.

[0025] These problems and shortcomings result in a large optimization space for existing technologies in the detection and localization of runtime exceptions, especially in improving detection efficiency, reducing computational cost, and enhancing the ability to capture dynamic behaviors. SUMMARY

[0026] Invention purposes: In view of the deficiencies of the prior art runtime exception detection and positioning method, the application provides a runtime exception detection method combining slice testing and formal verification, which improves the accuracy and efficiency of exception detection, reduces the calculation cost, and solves the problems of insufficient coverage and difficulty in capturing dynamic behavior in the prior art.

[0027] Technical scheme: A runtime exception detection method combining slice testing and formal verification, comprising the following steps:

[0028] Program slicing is used to extract the minimum code segment related to the potential abnormal program point from the program to be detected;

[0029] Test cases are generated based on the minimum code segment related to the potential abnormal point;

[0030] The minimum code segment containing the test case is executed to obtain the detection result.

[0031] Further, the minimum code segment related to the potential abnormal point is extracted from the code to be detected by using program slicing, specifically including:

[0032] Select the variables v1,…,v n The potential abnormal program point pr that causes the runtime exception r is triggered, and the key variables that may affect the potential abnormal program point pr are marked;

[0033] Using slice criteria, all code paths that may affect the key variables are tracked from the potential abnormal program point pr, the related statements are extracted, and the minimum program slice is generated;

[0034] An auxiliary variable flag is introduced in the minimum program slice to mark whether the exception path is triggered, and the rewritten slice code is obtained.

[0035] Further, the auxiliary variable flag is introduced in the minimum program slice to mark whether the exception path is triggered, and the rewritten slice code is obtained, specifically including:

[0036] A declaration statement about the auxiliary variable flag is added at the beginning of the minimum program slice, and the potential abnormal program point pr is replaced with flag=1 to obtain the rewritten slice code.

[0037] Further, the potential abnormal program point pr can be replaced with flag=1, which can be replaced with adding a statement flag=1 at the potential abnormal program point pr to obtain the rewritten slice code.

[0038] Further, before performing the generating test case based on the minimized code segment related to the potential abnormal point, the following steps are performed:

[0039] A precondition pre is added in the rewritten slice code for each potential abnormal program point r The precondition pre r is used to ensure that the runtime exception is not triggered.

[0040] Further, the generating test case based on the minimized code segment related to the potential abnormal point includes:

[0041] Automatically generating a test condition T according to the input variable type of the program to be detected;

[0042] Based on the test condition T, a test case t satisfying the test condition T is randomly generated.

[0043] Further, the executing the minimized code segment containing the test case to obtain a detection result includes:

[0044] S1: executing the rewritten slice code containing the test case t to obtain an actual execution path path t containing a method condition MC i ;

[0045] S2: checking whether the auxiliary variable flag is set to 1 in the actual execution path path t , if the auxiliary variable flag is set to 1 in the actual execution path path t , it indicates that the actual execution path path t triggers a potential runtime exception, introducing a specified condition D, and setting the specified condition D as the precondition pre r ; and removing the declaration statement and flag = 1 about the auxiliary variable flag added at the beginning of the minimized program slice to obtain a simplified path path t '; if the auxiliary variable flag is set to 0 in the actual execution path path t , the specified condition D is set to true, and the path condition C t is extracted from the actual execution path path t .

[0046] S3: starting from the postcondition D FS of the simplified path path t ', the path condition C t∧D′∧FS′, where D∧FS represents a condition that satisfies both the specified condition D and the final state FS, D′ represents the specified condition represented by the input variable, and FS′ represents the final state represented by the input variable; by judging... Whether it is a tautology verifies the safety of the path; if it is only true, it indicates that all paths satisfying T∧C t The input will not trigger any potential runtime exceptions.

[0047] Furthermore, if When it is not a tautology, the theorem prover will provide a counterexample tc for test case T and show that the counterexample tc will trigger a runtime exception.

[0048] Execute the rewritten slice code containing the counterexample tc, and repeat the process from S1 to S3 until an input classification criterion is found that completely divides the test cases into two categories: those that trigger exceptions and those that do not.

[0049] Furthermore, if the number of counterexamples is less than a set threshold, then... Update the original test condition T, where, Represents path condition C t The truth value of is false;

[0050] Based on the updated test conditions T, test cases that satisfy the updated test conditions T are randomly generated, and the process is repeated according to S1 to S3.

[0051] Furthermore, in S3, if the simplified path is... t If ' does not contain a method call, then neither FS nor FS' exists.

[0052] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0053] (1) Enhanced coverage of anomaly detection: The method of this invention integrates formal verification and program slicing techniques, which can not only detect known anomalies, but also cover more potential anomalies through automated path analysis, especially anomalies caused by complex input scenarios and dynamic behaviors. This solution can identify anomaly paths in advance and reduce reliance on post-analysis after the actual anomaly occurs.

[0054] (2) Improve detection efficiency and reduce computational cost: The method of the present application extracts and analyzes only the code fragments directly related to the exception through precise program slicing technology, so that the exception detection can be verified for smaller code fragments and more specific path conditions, reducing unnecessary code analysis, thereby significantly improving the detection efficiency; compared with the traditional stack-based and deep learning-based methods, this scheme significantly reduces the consumption of computing resources, and is suitable for application in large-scale software systems and real-time systems; compared with the traditional global analysis method, this scheme can lock the potential exception more quickly;

[0055] (3) Ensure the safety and stability of the program: The method of the present application not only can detect the input that may trigger the runtime exception, but also can ensure the normal termination of certain input, avoiding the program crash under the key input; the method of the present application improves the overall stability and safety of the software system by identifying and preventing exceptions before program execution;

[0056] (4) Handle complex dynamic behavior: Compared with static analysis technology, the method of the present application can effectively capture the dynamic behavior of program runtime by combining program slicing and formal verification, especially in the scenarios of multi-threading, concurrent execution or complex data structure, which helps to identify and prevent potential exceptions in advance;

[0057] (5) Improve development efficiency and reduce exception debugging time: The method of the present application provides an automated exception detection and prevention mechanism, which helps developers quickly find potential exception problems in the development stage, reduces the workload of later debugging and troubleshooting, and improves the development efficiency;

[0058] (6) Reduce redundant verification: The automatically generated preconditions and path derivation based on Hoare logic help to exclude code paths that cannot trigger exceptions, reducing unnecessary verification steps and optimizing the entire verification process;

[0059] (7) Stronger adaptability and scalability: The method is applicable to programs containing multiple exception types and can flexibly handle different exception situations such as division by zero, array out-of-bounds, etc. At the same time, it can adapt to different input conditions to help identify more potential exceptions;

[0060] (8) Enhance code reliability: By distinguishing between safe and unsafe inputs, the method ensures complete coverage of exceptions while avoiding false positives, making the code more reliable in actual operation;

[0061] (9) Balance accuracy and comprehensiveness: By narrowing the analysis range in the PS stage and formal verification in the TBFV stage, the method can ensure accuracy while covering all possible cases of exception triggering. This approach effectively reduces missed and false detections, improving the comprehensiveness of detection. Attached Figure Description

[0062] Figure 1 This is a flowchart illustrating the process of the program slicing stage;

[0063] Figure 2 This is a flowchart illustrating the test-based formal verification phase. Detailed Implementation

[0064] The objects and functions of the present invention, as well as the methods for achieving these objects and functions, will be clarified by referring to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below; it can be implemented in various forms. The purpose of this specification is merely to help those skilled in the art to comprehensively understand the specific details of the invention.

[0065] Embodiments of the present invention will now be described with reference to the accompanying drawings.

[0066] This embodiment proposes a runtime exception detection method that integrates program slicing (PS) and formal verification for automatic detection and location of runtime exceptions. This invention achieves efficient analysis and verification of potential exception paths in code by combining program slicing (PS) with test-based formal verification (TBFV). The technical implementation scheme of the TBFV-PS framework will be described in detail below, and its workflow will be illustrated through specific examples.

[0067] The TBFV-PS framework is mainly divided into two stages:

[0068] Phase 1: Program Slicing Phase (PS Phase): Through program slicing technology, the minimum code snippets related to potential anomalies are extracted, reducing the scope of analysis and improving the efficiency of subsequent verification.

[0069] Phase Two: Test-Based Formal Verification Phase (TBFV Phase): Based on the minimized code snippets related to potential anomalies obtained in the program slicing phase, test cases are generated and formally verified, input conditions are categorized, and anomaly triggering is identified and prevented.

[0070] Now combined Figure 1 Further explanation of the program slicing stage (PS stage).

[0071] The main goal of the program slicing stage is to narrow down the analysis scope, retaining only the key code related to anomalies, thereby reducing unnecessary code interference and improving the accuracy and efficiency of anomaly detection. For example... Figure 1 As shown, the specific steps are as follows:

[0072] Step 1: Selecting the exception point: Selecting the exception point that may be caused by variables v1, ..., vn The abnormal program point pr that triggers the runtime exception r is found, and the key variables that can affect the abnormal program point pr are marked. For example, in the following code, "v = w / z" in line 13 can trigger an arithmetic exception because z can be zero, so z is selected as the key variable, and the abnormal program point is (13, z).

[0073]

[0074]

[0075] Step 2: Generate a slice: use the slice criterion (pr, {v1,..., vn}) to obtain a minimized program slice; for example: apply the program slicing technique, starting from the abnormal program point (13, z), track all code paths that can affect the value of z, extract relevant statements, and generate a minimized program slice. n

[0076] Step 3: Insert auxiliary variables: introduce auxiliary variables flag in the minimized program slice to mark whether the exception path is triggered. Add a declaration statement "int flag = 0;" at the beginning of the minimized program slice, and replace the abnormal program point "v = w / z;" with "flag = 1;" or add a statement "flag = 1;" at the abnormal program point "v = w / z;", so as to monitor the reachability of the exception path in the subsequent verification phase. The rewritten slice code is as follows:

[0077]

[0078] Before entering the TBFV phase, add a precondition pre r for each abnormal program point that can trigger a runtime exception in the rewritten slice code to ensure that the runtime exception is not triggered. For example, if an exception program point contains a division: t = t1 / t2, a precondition t2 ≠ 0 should be added to ensure that the runtime exception does not occur. This step innovatively introduces a safety check before verification, thereby improving the accuracy of exception detection.

[0079] Now further explain the test-based formal verification phase (TBFV phase).

[0080] After generating the exception-related program slice in the PS phase, the TBFV phase generates test cases and executes the rewritten slice code, analyzes and classifies input conditions, and identifies input values that can trigger exceptions by combining formal verification methods. Now further explain the TBFV phase, as follows: Figure 2

[0081] ​​Step 1: Test Condition Generation and Execution: Test condition T is automatically generated based on the type of the program's input variables. For example, for integer input variables, test condition T requires the input value to be an integer (e.g., ...). Based on the test condition T, test cases t that satisfy the test condition T are randomly generated.

[0082] Step 2: Execute the rewritten slice code containing test case t to obtain a MC containing method conditions. i actual execution path t Check if the flag is in the path. t The value is set to 1. If flag = 1, it indicates the path. t A potential exception has been triggered. No further conditions are needed to prevent the exception from being triggered. Set D to pre. r Additionally, we removed "intflag=0" and "flag=1" to obtain a simpler path. t Conversely, if flag = 0, set D to true and extract the path condition C. t This step utilizes Hoare logic to progressively derive and simplify path conditions, effectively reducing unnecessary verification workload and making the generation and verification process of path conditions more systematic and rational. Here, D represents the specified condition, indicating a constraint that prevents exceptions from occurring; MC refers to the guard condition of the method call, ensuring that the method will only execute when specific conditions are met.

[0083] Step 3: During the path condition validation process, from the path... t The postcondition D∧FS begins the derivation of the path condition C. t ∧D′∧FS′. Where D∧FS represents a condition that satisfies both D and FS; if no method is called, FS does not exist. Here, FS represents the final state, D' represents the specified condition represented by the input variables, and FS' represents the final state represented by the input variables.

[0084] Step 4: By making a judgment Whether it is a tautology verifies the safety of the path. If true, it indicates that all paths satisfying T∧C... t No input will trigger an exception; otherwise, the theorem prover will provide a counterexample t. c and indicate t c This will trigger a runtime exception. Next, execute the code containing the counterexample t. cthe rewritten slice code and perform Step 2, i.e., repeat the verification process until a sufficient input classification criterion is found to completely separate the test cases into two classes, one that triggers the exception and one that does not. This step separates the test cases into two classes, one that can induce the exception and one that cannot, through counterexample (exception-inducing test case) classification. This refined classification method helps determine which inputs will cause the exception and aids in identifying the high-risk input set.

[0085] If only a few counterexamples exist in the verification process, the process is updated by updating the original test condition T and performing Step 2, i.e., repeating the verification process. Eventually, this process will ensure that all input paths that do not trigger the exception meet the requirements while ensuring that the path conditions that trigger the exception are sufficiently defined.

[0086] Example: For the above-mentioned program, the test condition T is Randomly select the input value as 0, then the derivation process of the traversed path and the precondition is as follows:

[0087] {in.nextInt()≥0∧10-in.nextInt()≠0}

[0088] x=10

[0089] {in.nextInt()≥0∧x-in.nextInt()≠0}

[0090] y=in.nextInt()

[0091] {y≥0∧x-y≠0}

[0092] z=0

[0093] {y≥0∧x-y≠0}

[0094]

[0095] {x-y≠0}

[0096] z=x-y

[0097] {z≠0}

[0098] wherein, the true value of the conditional statement y<0 is false. Since this example does not contain method calls, FS and FS' do not exist, and D' is 10-in.nextInt()≠0, and D is z≠0. The next implication condition to be verified is:

[0099]

[0100] Obviously, in.nextInt() = 10 is a counterexample, because it triggers a runtime exception. By extracting in.nextInt() = 10 from the premise, we obtain:

[0101]

[0102] This is a tautology, so we can conclude that if the test case leads to the above path, a runtime exception will be triggered. Therefore, we should consider the test condition and generate a test case randomly as -5. Similarly, the preconditions of the corresponding path are as follows:

[0103] {in.nextInt() < 0 ∧ true}

[0104] x = 10

[0105] {in.nextInt() < 0 ∧ true}

[0106] y = in.nextInt()

[0107] {y < 0 ∧ true}

[0108] z = 0

[0109] {y < 0 ∧ true}

[0110] y < 0

[0111] {true}

[0112] Implication condition Obviously, it is a tautology. Therefore, we can ensure that a runtime exception will not be triggered.

[0113] In summary, for any in.nextInt() ≥ 0 except in.nextInt() = 10, the program will not trigger a runtime exception caused by a zero denominator.

[0114] The method of this embodiment combines program slicing (PS) with test-based formal verification (TBFV), where the program slicing phase is used to narrow the scope of exception analysis and reduce the detection complexity, and the formal verification phase ensures that the program does not trigger a runtime exception through path and condition verification. This integration is innovative in terms of method, making exception detection more efficient.

[0115] Through the method of the embodiment, developers can actively identify and prevent runtime exceptions in the early stage of program execution, solving the problems of low detection efficiency, insufficient coverage, high computational cost, and other problems in the prior art, thereby providing higher stability and reliability for software systems. The method of the embodiment not only optimizes the detection accuracy, efficiency and resource consumption, but also has stronger exception prevention capability. It provides more efficient and reliable technical support for the development and operation of software systems, reduces the development and maintenance cost, and improves the stability and user experience of the system.

Claims

1. A method of runtime exception detection that fuses slice testing and formal verification, the method comprising: The method comprises the following steps: adopting program slicing to extract a minimized code segment related to the potential abnormal program point from the program to be detected; generating a test case based on the minimized code segment related to the potential abnormal program point; executing the minimized code segment containing the test case to obtain a detection result; The step of adopting program slicing to extract a minimized code segment related to the potential abnormal program point from the program to be detected comprises the following steps: The selection can be based on a variable v1,..., vn n raising a runtime exception r a potential abnormal program point pr and marking out the key variables that can affect the potential abnormal program point pr ; Using slicing criteria, from potential abnormal program points pr Starting from the potential abnormal program points, trace all code paths that can affect the key variables, extract the relevant statements, and generate the minimal program slices. Introducing auxiliary variables in a minimization program slice flag for marking whether an exception path is triggered, to get a rewritten slice code; The auxiliary variable introduced in the minimized program slice flag , for marking whether to trigger an exception path, to obtain a rewritten slice code, and specifically comprises: Add information about auxiliary variables at the beginning of the minimized program slice. flag The declaration statement, and the potential exception point. pr Replace with flag = 1. Obtain the rewritten slice code; Before the step of generating a test case based on the minimized code segment related to the potential abnormal program point, the following steps are performed: In the rewritten slice code, a precondition is added for each potential exception program point pre r The precondition pre r to ensure that a runtime exception is not triggered. The step of generating a test case based on the minimized code segment related to the potential abnormal program point comprises the following steps: automatically generating a test condition T according to the input variable type of the program to be detected; randomly generating a test case t satisfying the test condition T based on the test condition T; The step of executing the minimized code segment containing the test case to obtain a detection result comprises the following steps: S1 : execute the rewritten slice code containing test case t, to obtain an actual execution path path of the method condition MC i t ;​ S2: Check auxiliary variable flag if the actual execution path path t has been set to 1, if the auxiliary variable flag has been set to 1 in the actual execution path path t , then it is concluded that the actual execution path path t triggered a potential runtime exception, introduce the prescribed condition D, and set the prescribed condition D as a precondition pre r ; and remove the declaration statement about the auxiliary variable flag and flag = 1 added at the beginning of the minimized program slice, to obtain the refined path path t '; if the auxiliary variable flag has been set to 0 in the actual execution path path t , then set the prescribed condition D as true, extract the path condition C t from the actual execution path path t ; S3: From the reduced path path t the postcondition D ∧ FS starts to derive the path condition C t where D ∧ FS denotes that both the specification condition D and the final state FS are satisfied, D' denotes the specification condition represented by the input variables, and FS' denotes the final state represented by the input variables; by judging whether it is a tautology, the safety of the path is verified, and only true indicates that all inputs satisfying T ∧ C t will not trigger potential runtime exceptions; If If the theorem is not a tautology, the theorem prover will give a counterexample tc for the test case T and show that the counterexample tc triggers a runtime exception. Executing the rewritten slice code containing the counterexample tc, repeating the process according to S1-S3 until an input classification standard is found, which completely classifies the test cases into two categories of triggering abnormality and not triggering abnormality.

2. The method of claim 1, wherein the method further comprises: The potential abnormal program point pr is replaced by flag = 1, can be replaced by adding a statement at the potential abnormal program point pr flag = 1, to obtain the rewritten slice code.​ 3. The method of claim 1, wherein: If the number of counterexamples is less than a set threshold, then T ^ ¬ C t Update the original test condition T, where ¬ C t represents the path condition C t is false. Based on the updated test condition T, a test case satisfying the updated test condition T is randomly generated, and the process is repeated according to S1-S3.

4. The method of claim 1, wherein: In S3, if the reduced path path t does not contain a method call, then neither FS nor FS' exists.

Images