Runtime anomaly detection method fusing slice testing and form verification

Abstract

The invention provides a slice test and form verification fused runtime anomaly detection method, which comprises the following steps of: extracting a minimum code snippet related to a potential abnormal program point from a to-be-detected program by adopting a program slice; generating a test case on the basis of the minimized code snippets related to the potential abnormal points; executing the minimum code snippets containing the test cases to obtain a detection result; according to the method, through an integrated form verification and program slicing technology, known anomalies can be detected, more potential anomalies, especially anomalies caused by complex input scenes and dynamic behaviors, can be covered through automatic path analysis, the abnormal path can be recognized in advance, and the method has the advantages that the method is simple and convenient to operate and high in practicability. And postmortem analysis after dependence on actual abnormity is reduced.

Description

Technical Field

[0001] The present invention belongs to the field of computer science and technology, and specifically is a runtime anomaly detection method integrating slice testing and formal verification. Background Art

[0002] In software development, a runtime exception is an error caused by code logic errors, data problems, or environment mismatches during program execution. This type of exception cannot be detected at compile time and does not need to be explicitly captured or declared. 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] In order to solve system crashes and errors caused by runtime anomalies, the industry has developed a variety of technical means to detect and locate anomalies. For example:

[0004] 1. Test-Based Formal Verification (TBFV)

[0005] TBFV is an integrated test-based and formal verification method that aims to ensure the correctness of all traversed paths in a program. It verifies the behavior of the path by generating test cases and uses Hoare logic to deduce the preconditions and postconditions of the path. Its main advantage is that it can discover some runtime exceptions during the development phase and avoid them from occurring when the program is running. However, TBFV needs to traverse a large number of program paths, which can lead to excessive computational overhead, especially when dealing with complex input conditions or data structures. In addition, TBFV makes it difficult to ensure that all abnormal paths are covered, especially in complex path combinations or multi-threaded environments.

[0006] 2. Program Slicing

[0007] Program slicing is an analysis technique that extracts code snippets related to a specific variable or condition from the code. It can effectively narrow the scope of debugging and exception detection. This method has been widely used in debugging and fault location to reduce debugging time by screening out code related to exceptions. However, in complex programs, program slicing technology often cannot accurately distinguish code that is not related to exceptions, resulting in redundant slicing results. In addition, program slicing mostly relies on static analysis, which makes it difficult to capture dynamic behavior and runtime data flow, resulting in insufficient detection of certain abnormal paths.

[0008] 3. Exception location method of stack backtrace and dynamic analysis

[0009] This method captures the program's stack information when a runtime exception occurs, and combines dynamic analysis to trace back the call chain to locate the root cause of the exception. Dynamic stack tracing can record the execution path and status of the program, helping developers track the source of exceptions in complex control flows or multi-threaded programs. This method is particularly suitable for locating problems after an exception occurs, but it relies on the actual occurrence of the exception and cannot be predicted or prevented in advance.

[0010] 4. D-REX: Anomaly Detection Based on Deep Learning

[0011] D-REX is a runtime anomaly detection tool based on deep learning models. It uses a large-scale code base to train models to identify the correlation between code snippets and common exception types. By analyzing the code structure, D-REX can predict which code areas are likely to cause specific exception types, such as null pointer exceptions or array out-of-bounds exceptions. Its advantage is that it can detect potential problems in advance when the code is submitted, reducing the troubleshooting time after the exception occurs.

[0012] 5. MAESTRO: Anomaly resolution based on recommendation system

[0013] MAESTRO is a tool based on a recommendation system that aims 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 help to developers. However, its effectiveness depends on the quality of the recommendation database, and it can only provide assistance after the exception occurs, lacking prevention capabilities.

[0014] Although the above implementation schemes have achieved certain results in runtime anomaly detection and location, they still have the following problems and shortcomings:

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

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

[0017] 2. Program slicing analysis redundancy and insufficient dynamic behavior capture

[0018] Although program slicing technology can reduce the debugging scope and improve the efficiency of exception location, its results often contain a large number of redundant code snippets, which increases the workload of subsequent analysis. Especially in programs with complex control flow and exception handling logic, the slicing results may be mixed with code that is not related to the exception. In addition, program slicing is mainly based on static analysis, which makes it difficult to capture the dynamic behavior 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. Post-mortem limitations of stack backtrace and dynamic analysis

[0020] Exception location methods based on stack backtrace and dynamic analysis rely on the stack information captured when the program actually has an exception, so they can only be analyzed after the exception occurs. This means that developers cannot identify and prevent abnormal paths in advance, especially in critical systems. This post-processing method increases the risk of system crashes and data loss. In addition, stack backtrace 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. D-REX’s generalization ability is insufficient and its computational cost is high

[0022] D-REX relies on training data from large-scale code bases to predict the occurrence of runtime exceptions. Although this method performs well in detecting common types of exceptions, its generalization ability is limited. When dealing with new types of exceptions or complex business logic, the model's prediction effect may drop significantly. In addition, D-REX's deep learning model requires a lot of computing resources during training and reasoning, especially when detecting large-scale code bases. This high resource consumption greatly increases the difficulty of practical application.

[0023] 5. MAESTRO’s recommended quality reliance and lack of prevention capabilities

[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-event auxiliary tool, and cannot be used for anomaly detection and prevention, and cannot work before the anomaly occurs.

[0025] These problems and shortcomings result in that there is still a lot of room for improvement in the existing technologies in the detection and location of runtime anomalies, especially in improving detection efficiency, reducing computational costs, and enhancing the ability to capture dynamic behaviors. Summary of the invention

[0026] Purpose of the invention: In view of the shortcomings of the runtime anomaly detection and location methods in the prior art, the present invention proposes a runtime anomaly detection method that integrates slice testing and formal verification. By combining multiple technical means, the accuracy and efficiency of anomaly detection are improved, the computing cost is reduced, and the problems of insufficient coverage and difficulty in capturing dynamic behaviors in the prior art are solved.

[0027] Technical solution: A runtime anomaly detection method integrating slice testing and formal verification, comprising the following steps:

[0028] Program slicing is used to extract minimized code snippets related to potential abnormal program points from the program to be detected;

[0029] Generate test cases based on minimized code snippets related to potential anomalies;

[0030] Execute the minimized code snippet containing the test case and get the detection results.

[0031] Furthermore, the program slicing is used to extract the minimized code fragments related to the potential abnormal points from the code to be detected, specifically including:

[0032] The choice may be due to the variable v 1 ,…,v n The potential abnormal program point pr that triggers the runtime exception r, and marks the key variables that may affect the potential abnormal program point pr;

[0033] Using the slicing criteria, starting from the potential exception program point pr, trace all code paths that may affect key variables, extract relevant statements, and generate minimized program slices;

[0034] An auxiliary variable flag is introduced in the minimized program slice to mark whether the exception path is triggered to obtain the rewritten slice code.

[0035] Furthermore, the introduction of an auxiliary variable flag in the minimized program slice to mark whether an abnormal path is triggered to obtain a rewritten slice code specifically includes:

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

[0037] Furthermore, the replacement of the potential exception program point pr with flag=1 may be replaced by: adding a statement flag=1 at the potential exception program point pr to obtain a rewritten slice code.

[0038] Furthermore, before generating test cases based on the minimized code snippets associated with potential abnormal points, the following steps are performed:

[0039] In the rewritten slice code, add a precondition pre for each potential exception program point r , the precondition r Used to ensure that no runtime exceptions are triggered.

[0040] Furthermore, the test cases are generated based on the minimized code snippets related to the potential abnormal points, and the specific operations include:

[0041] Automatically generate test conditions T according to the input variable types of the program to be tested;

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

[0043] Furthermore, the execution of the minimized code snippet containing the test case to obtain the test result specifically includes:

[0044] S1: Execute the rewritten slice code containing test case t and obtain a method condition MC i The actual execution path path t ;

[0045] S2: Check whether the auxiliary variable flag is in the actual execution path path t is set to 1 if the auxiliary variable flag is in the actual execution path path t If it is set to 1, it means the actual execution path path t A potential runtime exception is triggered, a specified condition D is introduced, and the specified condition D is set as a precondition pre r ; and remove the declaration statement of the auxiliary variable flag and flag=1 added at the beginning of the minimized program slice to obtain the simplified path path t '; If the auxiliary variable flag is in the actual execution path path t is set to 0, the specified condition D is set to true, and the actual execution path path t Extract path condition C t ;

[0046] S3: From the simplified path path t 'The post-condition D∧FS starts to derive the path condition C t∧D′∧FS′, where D∧FS means that both the specified condition D and the terminal state FS are satisfied, D′ represents the specified condition represented by the input variable, and FS′ represents the terminal state represented by the input variable; by judging Is it a permanent true type? Verify the security of the path. If it is true only, it means that all the conditions satisfying T∧C t No input will trigger a potential runtime exception.

[0047] Furthermore, if When it is not a permanent true form, the theorem prover will give a counterexample tc of the 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 according to S1 to S3 until an input classification standard is found to completely divide the test cases into two categories: those that trigger exceptions and those that do not trigger exceptions.

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

[0050] 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 to S3.

[0051] Furthermore, in S3, if the simplified path t ' 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 anomaly detection coverage: The method of the present invention integrates formal verification and program slicing technology to 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 abnormal paths in advance and reduce reliance on post-analysis after the actual anomaly occurs.

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

[0055] (3) Ensure the security and stability of the program: The method of the present invention can not only detect inputs that may trigger runtime exceptions, but also ensure the normal termination of certain inputs, thereby avoiding program crashes under critical inputs; the method of the present invention improves the overall stability and security of the software system by identifying and preventing exceptions before program execution;

[0056] (4) Handling complex dynamic behaviors: Compared with static analysis techniques, the method of the present invention can effectively capture the dynamic behaviors of programs during runtime by combining program slicing and formal verification, especially in scenarios with multi-threading, concurrent execution, or complex data structures, which helps to identify and prevent potential anomalies in advance;

[0057] (5) Improve development efficiency and reduce abnormal debugging time: The method of the present invention provides an automated abnormality detection and prevention mechanism, which helps developers quickly discover potential abnormal problems during the development phase, reduces the workload of later debugging and troubleshooting, and improves development efficiency;

[0058] (6) Reduce redundant verification: Automatically generated preconditions and path derivation based on Hoare logic help eliminate code paths that are unlikely to trigger exceptions, reduce unnecessary verification steps, and optimize the entire verification process;

[0059] (7) Stronger adaptability and scalability: This method is applicable to programs that contain 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 and help identify more potential exceptions;

[0060] (8) Enhance code reliability: By distinguishing between safe and unsafe inputs, this method ensures that test cases fully cover exceptions without generating false positives, making the code more reliable during actual runtime;

[0061] (9) Balance between accuracy and comprehensiveness: By narrowing the analysis scope in the PS stage and formal verification in the TBFV stage, this method can cover all possible situations of abnormal triggering while ensuring accuracy. This approach effectively reduces missed detections and false detections and improves the comprehensiveness of detection. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0063] Figure 2 Figure 1 is a flow chart of the test-based formal verification phase. DETAILED DESCRIPTION

[0064] By referring to the exemplary embodiments, the objects and functions of the present invention and the methods for achieving these objects and functions will be explained. However, the present invention is not limited to the exemplary embodiments disclosed below; it can be implemented in different forms. The essence of the description is only to help those skilled in the relevant art to comprehensively understand the specific details of the present 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 slicing testing and formal verification, which is used to automatically detect and locate runtime exceptions. The present invention combines program slicing (PS) with testing-based formal verification (TBFV) to achieve efficient analysis and verification of potential exception paths in the code. The technical implementation scheme of the TBFV-PS framework will be elaborated in detail below, and its workflow will be explained through specific cases.

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

[0068] Phase 1: Program slicing phase (PS phase): Through program slicing technology, the minimized code fragments related to potential abnormal points are extracted to reduce the analysis scope and improve the subsequent verification efficiency.

[0069] Phase 2: Test-based formal verification phase (TBFV phase): Based on the minimized code snippets related to potential exception points obtained in the program slicing phase, test cases are generated and formally verified to classify input conditions and identify and prevent exception triggering.

[0070] Now combined Figure 1 The program slicing stage (PS stage) is further explained.

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

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

[0073]

[0074]

[0075] Step 2: Generate slices: Use the slice criterion (pr, {v 1 ,…,v n}) Obtain minimized program slices; for example: application slicing technology, starting from the exception program point (13,z), traces all code paths that may affect the z value, extracts related statements, and generates minimized program slices.

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

[0077]

[0078] Before entering the TBFV phase, add a precondition precondition to each abnormal program point that may cause a runtime exception in the rewritten slice code. r , ensuring that no runtime exception is triggered. For example, if an abnormal program point contains a division: t = t 1 / t 2 , then the precondition t should be added 2 ≠0 to ensure that no runtime exceptions occur. This step innovatively introduces a safety check before verification, thereby improving the accuracy of anomaly detection.

[0079] The test-based formal verification phase (TBFV phase) is now further explained.

[0080] After the exception-related program slices are generated in the PS phase, the TBFV phase generates test cases and executes the rewritten slice code, combined with formal verification methods, to analyze and classify input conditions and identify input values ​​that may trigger exceptions. Figure 2The TBFV stage is further explained as follows:

[0081] Step 1: Test condition generation and execution: Test condition T is automatically generated according to the input variable type of the program. For example, for an integer input variable, test condition T requires the input value to be an integer (such as ). Based on the test condition T, a test case t that satisfies the test condition T is randomly generated.

[0082] Step 2: Execute the rewritten slice code containing test case t to obtain a method condition MC i The actual execution path path t . Check if flag is in path path t If flag = 1, it means path t A potential exception is triggered. No further conditions are needed to prevent the exception from being triggered. Set D to pre r In addition, we remove "intflag=0" and "flag=1" to get a simpler path path t '. On the contrary, if flag = 0, set D to true and extract path condition C t This step uses Hoare logic to gradually derive and simplify the path conditions, effectively reducing unnecessary verification workload and making the generation and verification process of path conditions more systematic and rational. Among them, D represents the prescribed condition, which represents the constraint that exceptions will not occur; MC refers to the guard condition of the method call, which ensures that the method will only be executed when specific conditions are met.

[0083] Step 3: During the path condition verification process, t 'The post-condition D∧FS starts to derive the path condition C t ∧D′∧FS′. D∧FS means that both D and FS are satisfied. If there is no method call, FS does not exist. FS represents the terminal state, D' represents the specified condition represented by the input variable, and FS' represents the terminal state represented by the input variable.

[0084] Step 4: Judge Is it a permanent true type? Verify the security of the path. If true, it means that all paths that satisfy T∧C t The input will not cause an exception; otherwise, the theorem prover will give a counterexample t c , and shows that t c A runtime exception will be triggered. Next, execute the counterexample t cThe rewritten slice code is then executed, i.e., Step 2 is repeated until a sufficient input classification standard is found to completely divide the test cases into two categories: those that trigger exceptions and those that do not. This step divides the test cases into two categories: those that may trigger exceptions and those that do not trigger exceptions by classifying counterexamples (abnormality-inducing test cases). This refined classification method helps determine which inputs will cause abnormalities and helps identify high-risk input sets.

[0085] If only a few counterexamples exist during the verification process, Update the original test condition T and execute Step 2, that is, repeat the verification process. Ultimately, this process will ensure that all input paths that do not trigger exceptions meet the requirements, while ensuring that the path conditions that trigger exceptions are fully defined.

[0086] Example: For the above obtained program, the test condition T is Randomly select an input value of 0, and then obtain the traversal path and the derivation process of the precondition 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∧xy≠0}

[0092] z=0

[0093] {y≥0∧xy≠0}

[0094]

[0095] {xy≠0}

[0096] z=xy

[0097] {z≠0}

[0098] in, Indicates that the truth value of the conditional statement y<0 is false. Since this example does not contain a method call, neither FS nor FS' exists, and D' is 10-in.nextInt()≠0, and D is z≠0. The following implication conditions need to be verified:

[0099]

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

[0101]

[0102] This is a tautology, so it can be judged that if the test case leads to the above path, a runtime exception will be triggered. Therefore, the test condition should be considered And randomly generate a test case of -5. Similarly, the preconditions for 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 is obviously a tautology. Therefore, it can be ensured that No runtime exception will be triggered.

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

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

[0115] Through the method of this embodiment, developers can actively identify and prevent runtime anomalies in the early stage of program execution, solve the problems of low detection efficiency, insufficient coverage, and high computing cost in the prior art, and thus provide higher stability and reliability for the software system. The method of this embodiment not only optimizes detection accuracy, efficiency, and resource consumption, but also has stronger anomaly prevention capabilities. It provides more efficient and reliable technical support for the development and operation of software systems, reduces development and maintenance costs, and improves system stability and user experience.

Claims

1. A runtime anomaly detection method integrating slice testing and formal verification, characterized in that: The following steps are involved: Program slicing is used to extract minimized code snippets related to potential abnormal program points from the program to be detected; Generate test cases based on minimized code snippets related to potential anomalies; Execute the minimized code snippet containing the test case and get the detection results.

2. The runtime anomaly detection method integrating slice testing and formal verification according to claim 1, characterized in that: The program slicing is used to extract the minimized code fragments related to the potential abnormal points from the code to be detected, specifically including: The selection may be due to the variables v1,…,v n The potential abnormal program point pr that triggers the runtime exception r, and marks the key variables that may affect the potential abnormal program point pr; Using the slicing criteria, starting from the potential exception program point pr, trace all code paths that may affect key variables, extract relevant statements, and generate minimized program slices; An auxiliary variable flag is introduced in the minimized program slice to mark whether the exception path is triggered to obtain the rewritten slice code.

3. The runtime anomaly detection method integrating slice testing and formal verification according to claim 2, characterized in that: The introduction of an auxiliary variable flag in the minimized program slice is used to mark whether the abnormal path is triggered to obtain the rewritten slice code, which specifically includes: A declaration statement about the auxiliary variable flag is added at the beginning of the minimized program slice, and the potential exception program point pr is replaced with flag=1 to obtain the rewritten slice code.

4. The runtime anomaly detection method integrating slice testing and formal verification according to claim 3 is characterized in that: The replacing of the potential exception program point pr with flag=1 may be replaced by: adding a statement flag=1 at the potential exception program point pr to obtain a rewritten slice code.

5. A runtime anomaly detection method integrating slice testing and formal verification according to claim 3 or 4, characterized in that: Before executing the described generation of test cases based on the minimized code snippets associated with potential anomalies, perform the following steps: In the rewritten slice code, add a precondition pre for each potential exception program point r , the precondition r Used to ensure that no runtime exceptions are triggered.

6. The runtime anomaly detection method integrating slice testing and formal verification according to claim 5 is characterized in that: The test cases are generated based on the minimized code snippets related to the potential abnormal points, and the specific operations include: Automatically generate test conditions T according to the input variable types of the program to be tested; Based on the test condition T, a test case t that satisfies the test condition T is randomly generated.

7. The runtime anomaly detection method integrating slice testing and formal verification according to claim 6 is characterized in that: The execution includes the minimized code snippet of the test case to obtain the test result, and the specific operations include: S1: Execute the rewritten slice code containing test case t and obtain a method condition MC i The actual execution path path t ; S2: Check whether the auxiliary variable flag is in the actual execution path path t is set to 1 if the auxiliary variable flag is in the actual execution path path t If it is set to 1, it means the actual execution path path t A potential runtime exception is triggered, a specified condition D is introduced, and the specified condition D is set as a precondition pre r ; and remove the declaration statement of the auxiliary variable flag and flag=1 added at the beginning of the minimized program slice to obtain the simplified path path t '; If the auxiliary variable flag is in the actual execution path path t is set to 0, the specified condition D is set to true, and the actual execution path path t Extract path condition C t ; S3: From the simplified path path t 'The post-condition D∧FS starts to derive the path condition C t ∧D′∧FS′, where D∧FS means that both the specified condition D and the terminal state FS are satisfied, D′ represents the specified condition represented by the input variable, and FS′ represents the terminal state represented by the input variable; by judging Is it a permanent true type? Verify the security of the path. If it is true only, it means that all the conditions satisfying T∧C t No input will trigger a potential runtime exception.

8. The runtime anomaly detection method integrating slice testing and formal verification according to claim 7 is characterized in that: like When it is not a permanent true form, the theorem prover will give a counterexample tc of the test case T and show that the counterexample tc will trigger a runtime exception; Execute the rewritten slice code containing the counterexample tc, and repeat the process according to S1 to S3 until an input classification standard is found to completely divide the test cases into two categories: those that trigger exceptions and those that do not trigger exceptions.

9. The runtime anomaly detection method integrating slice testing and formal verification according to claim 8, characterized in that: If the number of counterexamples is less than the set threshold, Update the original test condition T, where Indicates the path condition C t The truth value of 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 to S3.

10. The runtime anomaly detection method integrating slice testing and formal verification according to claim 7, characterized in that: In S3, if the simplified path path t ' does not contain a method call, then neither FS nor FS' exists.

Images