Anomaly handling and detection methods, devices, equipment, and computer storage media

Abstract

This invention relates to the field of financial technology (Fintech) and discloses an anomaly detection method. The method includes: obtaining a preset configuration table and input parameters corresponding to target logic; detecting whether the target logic meets preset detection conditions based on the preset configuration table and the input parameters; if it does, detecting whether there is an abnormal configuration in the anomaly class of the preset configuration table; if there is an abnormal configuration, constructing an anomaly scenario based on the abnormal configuration, obtaining the target anomaly corresponding to the target logic based on the anomaly scenario, and outputting the target anomaly. This invention also discloses an anomaly detection device, equipment, and a computer storage medium. This invention improves the effectiveness of anomaly detection.

Description

Technical Field

[0001] This invention relates to the field of testing technology for financial technology (Fintech), and more particularly to methods, apparatus, equipment, and computer storage media for anomaly detection. Background Technology

[0002] With the development of computer technology, more and more technologies (big data, distributed systems, blockchain, artificial intelligence, etc.) are being applied in the financial field. The traditional financial industry is gradually transforming into Fintech. However, due to the security and real-time requirements of the financial industry, higher demands are being placed on technology. In distributed systems, a complete data transaction process requires many subsystem links, and the logical processing of a subsystem often requires calling other systems multiple times. Therefore, the logic for handling exceptions in distributed systems is quite complex. Furthermore, because the actual exception scenarios are complex and often require further subdivision, such as technical exceptions, timeout exceptions, and business exceptions, the actual results of exception handling are not always ideal. Therefore, it is necessary to test these exception scenarios in advance. Currently, when testing exception scenarios, exception injection is used to inject exceptions into the target logic executed in specific steps, or to tamper with the original return value. For example, exception injection can be performed using the CHAosBlate tool. However, CHAosBlate has limitations, such as its inability to handle different exceptions based on different error codes or to determine whether to inject an exception based on the target method's input parameters. These shortcomings make the use of CHAosBlate for exception injection less than ideal, resulting in low effectiveness of exception handling detection results after testing in abnormal scenarios. Therefore, improving the effectiveness of exception handling detection has become a pressing technical problem. Summary of the Invention

[0003] The main objective of this invention is to provide an anomaly detection method, apparatus, device, and computer storage medium, aiming to improve the effectiveness of anomaly detection.

[0004] To achieve the above objectives, the present invention provides an anomaly detection method, which includes the following steps:

[0005] Obtain the preset configuration table and input parameters corresponding to the target logic, and detect whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters;

[0006] If the condition is met, then check whether there is an abnormal configuration in the abnormal class of the preset configuration table;

[0007] If an abnormal configuration exists, an abnormal scenario is constructed based on the abnormal configuration, the target exception corresponding to the target logic is obtained according to the abnormal scenario, and the target exception is output.

[0008] Optionally, after the step of detecting whether there is an abnormal configuration in the abnormal class of the preset configuration table, the following steps are included:

[0009] If no abnormal configuration is found, check if the mock return content in the preset configuration table contains a configuration content value;

[0010] If a configuration value exists, the return type of the target logic is obtained, and the configuration value is converted according to the return type to obtain the conversion result. The conversion result is then used as the return value of the target logic and output.

[0011] Optionally, the step of detecting whether there is an abnormal configuration in the preset configuration table if the condition is met includes:

[0012] If the condition is met, then check whether the configuration field in the preset configuration table has a sleep time value;

[0013] If a sleep time value exists, the target logic is subjected to sleep processing based on the sleep time value, and after the sleep processing is completed, the system checks whether there is an abnormal configuration in the exception class of the preset configuration table.

[0014] Optionally, the step of detecting whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters includes:

[0015] Check whether the input conditions in the preset configuration table contain a preset expression;

[0016] If a preset expression exists and the input parameter matches the preset expression, then it is determined whether the target logic meets the preset detection conditions based on the preset configuration table.

[0017] Optionally, the step of determining whether the target logic meets the preset detection conditions based on the preset configuration table includes:

[0018] Check if there is a configuration count value for watch in the preset configuration table;

[0019] If it exists, and the configuration count value is greater than the injection count carried by the input parameter, then the target logic is determined to meet the preset detection conditions.

[0020] Optionally, the step of obtaining the preset configuration table and input parameters corresponding to the target logic includes:

[0021] Determine the method body of the target logic, and determine the target listener based on the method body;

[0022] Based on the target listener, obtain the preset configuration table and input parameters corresponding to the target logic.

[0023] Optionally, after the step of obtaining the preset configuration table and input parameters corresponding to the target logic based on the target listener, the process includes:

[0024] Obtain the historical configuration information in memory corresponding to the target logic;

[0025] Based on the target listener, the configuration information in the preset configuration table is obtained, and it is detected whether the configuration information matches the historical configuration information;

[0026] If a match is found, then the step of detecting whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters is executed.

[0027] Furthermore, to achieve the above objectives, the present invention also provides an anomaly handling detection device, the anomaly handling detection device comprising:

[0028] The acquisition unit is used to acquire the preset configuration table and input parameters corresponding to the target logic, and to detect whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters.

[0029] The detection unit is used to detect whether there is an abnormal configuration in the preset configuration table if the condition is met.

[0030] The output unit is used to construct an abnormal scenario based on the abnormal configuration if an abnormal configuration exists, obtain the target abnormality corresponding to the target logic according to the abnormal scenario, and output the target abnormality.

[0031] In addition, to achieve the above objectives, the present invention also provides an anomaly detection device, the anomaly detection device comprising: a memory, a processor, and an anomaly detection program stored in the memory and executable on the processor, wherein the anomaly detection program, when executed by the processor, implements the steps of the anomaly detection method as described above.

[0032] In addition, to achieve the above objectives, the present invention also provides a computer storage medium storing an exception handling detection program, which, when executed by a processor, implements the steps of the exception handling detection method described above.

[0033] This invention obtains a preset configuration table and input parameters corresponding to the target logic, and detects whether the target logic meets preset detection conditions based on the preset configuration table and input parameters. If it does, it checks whether there is an abnormal configuration in the exception class of the preset configuration table. If an abnormal configuration exists, it constructs an exception scenario based on the abnormal configuration, obtains the target exception corresponding to the target logic based on the exception scenario, and outputs the target exception. By determining whether the target logic meets the preset detection conditions based on the preset configuration table and input parameters, and constructing an exception scenario based on the abnormal configuration when there is an abnormal configuration in the exception class of the preset configuration table, and then obtaining and outputting the target exception based on the exception scenario, this invention avoids the problem in the prior art where it is impossible to determine the exception handling result based on the input parameters, and it is also impossible to perform different exception handling detection for different exception scenarios, resulting in low accuracy of exception handling detection. This invention improves the accuracy and effectiveness of exception handling detection. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the structure of the abnormal handling and detection device for the hardware operating environment involved in the embodiments of the present invention;

[0035] Figure 2 This is a flowchart illustrating the first embodiment of the anomaly handling and detection method of the present invention;

[0036] Figure 3 This is a schematic diagram of the device modules of the anomaly handling and detection device of the present invention;

[0037] Figure 4 This is a schematic diagram of the module startup process in the anomaly handling and detection method of the present invention;

[0038] Figure 5 This is a schematic diagram of the exception injection and mock return process in the exception handling and detection method of the present invention.

[0039] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0040] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0041] like Figure 1 As shown, Figure 1 This is a schematic diagram of the structure of the abnormal handling and detection device for the hardware operating environment involved in the embodiments of the present invention.

[0042] The anomaly handling detection device in this embodiment of the invention can be a PC or a server device, on which a Java Virtual Machine runs.

[0043] like Figure 1As shown, the anomaly handling and detection device may include: a processor 1001, such as a CPU; a network interface 1004; a user interface 1003; a memory 1005; and a communication bus 1002. The communication bus 1002 is used to establish communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as a disk drive. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0044] Those skilled in the art will understand that Figure 1 The anomaly handling and detection device structure shown does not constitute a limitation on the device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0045] like Figure 1 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an exception handling and detection program.

[0046] exist Figure 1 In the anomaly handling detection device shown, the network interface 1004 is mainly used to connect to the backend server and communicate data with the backend server; the user interface 1003 is mainly used to connect to the client (user end) and communicate data with the client; and the processor 1001 can be used to call the anomaly handling detection program stored in the memory 1005 and execute the operations in the anomaly handling detection method described below.

[0047] Based on the above hardware structure, an embodiment of the anomaly handling and detection method of the present invention is proposed.

[0048] Reference Figure 2 , Figure 2 This is a flowchart illustrating the first embodiment of the anomaly handling and detection method of the present invention, the method comprising:

[0049] Step S10: Obtain the preset configuration table and input parameters corresponding to the target logic, and detect whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters;

[0050] In this embodiment, the terms are explained as follows: JVM-SANDBOX is a non-intrusive runtime AOP solution for the JVM platform. AOP is Aspect-Oriented Programming, a technique that achieves unified maintenance of program functionality through pre-compilation or runtime dynamic proxies. Exception injection is when a target method throws a pre-defined error message during execution. OGNL expressions are Object Graph Navigation Language. Through its simple and consistent expression syntax, it allows access to any object's attributes, invocation of object methods, traversal of the entire object's structure graph, and implementation of field type conversion, among other functions. Mock is used during testing to create a mock object to simulate the behavior of objects that are difficult to construct or obtain. A JAVA BEAN is a JAVA class that follows specific syntax. This class must have a parameterless constructor, its attributes must be private, and private attributes must be exposed to other programs through public methods. Furthermore, the naming of methods must adhere to certain naming conventions. In this embodiment, the target method is equivalent to the target logic. The preset configuration table in this embodiment is stored in a database, allowing users to dynamically adjust it according to their needs.

[0051] Before performing exception handling and detection, it is necessary to design an exception injection rule configuration table (i.e., a preset configuration table corresponding to the target logic). This allows for dynamic modification of the target class and target method (i.e., target logic), as well as the corresponding exception information and return value, by listening for changes in this configuration table. The preset configuration table can be shown in Table 1 below.

[0052]

[0053] Table 1

[0054] The detailed configuration of each exception injection rule in Table 1 is as follows:

[0055] target_method: The target method to be watched. It must include the fully qualified class name and method name, separated by #.

[0056] method_params_class: The parameter types of the target method to be watched, separated by commas; due to Java polymorphism, a class may have multiple methods with the same name. If you need to watch all methods with the same name, fill in ALL for this field.

[0057] input_condition: Input condition, supports OGNL expressions. The first parameter is param0, the second parameter is param1, and so on. The intercepted object itself is placed under root, and its properties can be directly referenced. This parameter is used to determine whether to inject exceptions based on the method input parameters.

[0058] delay: Sleep time. Note that if it is negative, the user will sleep for the specified time before the method body is executed; if it is positive, the user will sleep for the specified time after the method body is executed.

[0059] exception_class: The exception class (fully qualified name) that needs to be thrown when the watch condition is met. The exception class needs to have a constructor with two String parameters. Note that the exception will be thrown after the method body is executed. If you want to throw it immediately without executing the method body, you need to add the prefix "IMMEDIATELY:".

[0060] exception_code: Exception error code.

[0061] exception_desc: Exception description.

[0062] return_content: The content returned by the mock. If the method is of type void, fill in NULL. Note that the returned content will only change after the method body is executed. If you want to return the content immediately without executing the method body, you need to add the prefix "IMMEDIATELY:".

[0063] watch_count: The number of times to watch. If configured as null, it will watch continuously. Note that this count is only valid for a single JVM.

[0064] version: Version number. The version number needs to be incremented by 1 each time the configuration is modified. jvm-sandbox will automatically load the latest configuration after 5 seconds.

[0065] enabled: Whether to enable the configuration, 1-enabled, 0-disabled. It is recommended to set it to 0-disabled after testing to avoid affecting other people's testing.

[0066] remark: Note.

[0067] Next, a custom `sandbox-mock` module is created. This module is loaded when `jvm-sandbox` starts to extend and meet the needs of various business scenarios, including exception injection and mock returns. Within this `sandbox-mock` module, a `ModuleGenerator` class is created. `ModuleGenerator` is called when `sandbox-mock` loads, reading the configuration of the `jvm sandbox watch_conf` enable status (enabled=1) from the configuration table. For each configured target class and target method (the value of `target_method`), a `beforeEvent` event listener is added before the method body executes, and a `returnEvent` event listener is added after the method body executes. Specifically, the `beforeEvent` event listener is triggered before the target method body executes, and the `returnEvent` event listener is triggered after the target method body executes.

[0068] Therefore, in this embodiment, once the configuration table and listener have been configured, the target logic (i.e., the target method, which is equivalent to the target logic in this embodiment) to be subjected to exception handling detection can be determined. Furthermore, since the target method includes a method name, method parameters, and a method body (i.e., the content executed by the target method), the exception handling detection in this embodiment can be performed by injecting the exception before or after the method body is executed.

[0069] Therefore, it is also necessary to determine whether the method body of the target logic is before or after execution before performing exception handling detection. When the method body of the target logic is before execution, the event listener beforeEvent will be triggered first. This beforeEvent will actively obtain the input parameters when the target logic is executed, and obtain the configuration information of the target logic in the configuration table. Based on the configuration information in the preset configuration table and the input parameters, it will check whether the target logic meets the preset detection conditions, and perform different operations based on different detection results.

[0070] However, once the method body of the target logic is executed, the event listener `returnEvent` is triggered first. This `returnEvent` retrieves the input parameters of the target logic during execution and the configuration information of the target logic in the configuration table. Based on the configuration information in the preset configuration table and the input parameters, it checks whether the target logic meets preset detection conditions and performs different operations based on different detection results. The preset detection conditions can be those set by the user based on the input parameters of the target logic.

[0071] Step S20: If satisfied, check whether there is an abnormal configuration in the abnormal class of the preset configuration table;

[0072] If the target logic is found to meet the preset detection conditions, it can then check whether the configuration field in the preset configuration table has a configuration (i.e., a sleep time value). Specifically, when the target logic's method body is before execution, it's necessary to determine whether the sleep field (i.e., the configuration field) `deplay` in the preset configuration table has a configuration, and if so, that the configuration value is negative. If it does, the target logic can be put into a sleep state based on this configuration value (i.e., the sleep time value) until the sleep time value has elapsed. Then, it checks whether the exception class in the preset configuration table has an exception configuration. However, if the configuration field does not have a sleep time value, it checks whether the exception class in the preset configuration table has an exception configuration, and performs different operations based on the different detection results.

[0073] Once the target logic's method body is executing, it's necessary to determine if the `deplay` field (i.e., the configuration field) in the preset configuration table is configured, and if so, if the configuration value is positive. If it is, the target logic can be put into a sleep state based on this configuration value (i.e., the sleep time value) until the sleep time value has elapsed. Then, it checks if there is an exception configuration in the exception class of the preset configuration table. However, if the configuration field does not have a sleep time value, it can directly check if there is an exception configuration in the exception class of the preset configuration table, and perform different operations based on different detection results.

[0074] Step S30: If there is an abnormal configuration, an abnormal scenario is constructed based on the abnormal configuration, the target abnormality corresponding to the target logic is obtained according to the abnormal scenario, and the target abnormality is output.

[0075] If an exception configuration is found in the default configuration table, exception injection can be performed on the target logic. If the `exception_class` field in the default configuration table is configured, and its value does not begin with "IMMEDIATELY:", an exception scenario can be constructed based on this configuration. This involves obtaining the JVM class loader, creating an `exception_class` object via reflection, and throwing the exception (the target exception) when the input parameters are `exception_code` and `exception_desc`. The target logic then executes after the exception is thrown. However, if no exception configuration exists, mock return handling is required. If the `return_content` field in the exception class is configured, and its value begins with "IMMEDIATELY:", the return type of the target method is obtained using the API provided by jvm-sandbox. A corresponding custom handler is then retrieved based on the return type. This custom handler converts `return_content` into the target logic's return type, resulting in the target logic's return value. The target logic then executes.

[0076] In addition, to help understand the principle of anomaly handling and detection in this embodiment, an example is given below.

[0077] In this embodiment, when performing abnormal scene detection, it is necessary to perform the following: Figure 4The steps shown are as follows: After jvmsandbox starts, the custom module sandbox-mock is loaded, and ModuleGenerator is executed. Then, the configurations in the jvmsandbox watch_conf exception configuration table that are enabled (enabled=1) are read. This exception configuration table can be modified during business testing. After executing ModuleGenerator, the configuration is also polled. That is, beforeEvent and returnEvent event listeners are added to the target class method (i.e., the target logic), and the configuration is read and placed in memory. After the module starts, a task thread is started to execute the configuration change listener ModuleRefresh, and the configuration is polled again. In other words, the listener continuously reads the latest configuration from the exception injection rule configuration table and compares the latest configuration with the last read configuration (i.e., historical configuration information) (the last read configuration is placed in memory). When the latest configuration exists but not in memory, the target class method adds `beforeEvent` and `returnEvent` event listeners. When the latest configuration exists and is in memory, but the version numbers are inconsistent, the target class method first uninstalls the `beforeEvent` and `returnEvent` listeners, then re-adds the latest `beforeEvent` and `returnEvent` listeners, and resets the injection count counter to 0. When the latest configuration does not exist but is in memory, the target class method uninstalls the `beforeEvent` and `returnEvent` event listeners for this target method, updates the memory configuration, and continues listening.

[0078] Furthermore, during the execution of the target logic (i.e., during business testing), methods such as... Figure 5The steps shown are as follows: When the target method (Method) is executed, the `beforeEvent` event listener is triggered. This listener retrieves the target method's input parameters, the `input_condition` field in the configuration table, and checks if the input parameters match the condition expression. If not, the target method is executed. If yes, it checks if the configuration value in the preset configuration table is less than the injection count. If not, the target method body is executed. If yes, the injection count is incremented by 1, and it is checked whether the `sleep` field in the preset configuration table is negative. If the number is negative, a specified sleep time is determined, and the exception configuration is determined to start with IMMEDIATELY:. If so, an exception is thrown, and the method execution is complete. If not, it is determined whether the return field starts with IMMEDIATELY:. If so, a mock return is made, and the method execution is complete. If not, the target method body (i.e., the method body in the target logic) is executed. That is, after the target method is executed, the returnEvent event listener will be triggered, and the input parameters of the target method will continue to be obtained. The configuration table is configured with conditional expressions, and it is determined whether the input parameters match the conditional expressions. If so, it is determined whether the number of injections corresponding to the input parameters is greater than or equal to the number of injections. If so, it is determined whether the sleep field is positive. If so, the specified sleep time of the target logic is determined based on the sleep field. After the specified sleep time has elapsed, it is checked whether the exception configuration does not start with IMMEDIATELY:. If so, an exception is thrown, and the method execution is complete. If not, it is determined whether the return field does not start with IMMEDIATELY:. If so, a mock return is made, and the method execution is complete. If not, the target method execution is complete.

[0079] In this embodiment, a preset configuration table and input parameters corresponding to the target logic are obtained, and the target logic is checked to see if it meets preset detection conditions based on the preset configuration table and input parameters. If it does, it is checked whether there is an abnormal configuration in the exception class of the preset configuration table. If there is an abnormal configuration, an abnormal scenario is constructed based on the abnormal configuration, the target exception corresponding to the target logic is obtained based on the abnormal scenario, and the target exception is output. By determining whether the target logic meets the preset detection conditions based on the preset configuration table and input parameters corresponding to the target logic, and constructing an abnormal scenario based on the abnormal configuration when there is an abnormal configuration in the exception class of the preset configuration table, and then obtaining and outputting the target exception based on the abnormal scenario, the invention avoids the phenomenon in the prior art where it is impossible to determine the exception handling result based on the input parameters, and it is also impossible to perform different exception handling detection for different exception scenarios, resulting in low accuracy of exception handling detection. This improves the accuracy and effectiveness of exception handling detection.

[0080] Furthermore, based on the first embodiment of the anomaly handling detection method of the present invention, a second embodiment of the anomaly handling detection method of the present invention is proposed. This embodiment is step S30 of the first embodiment of the present invention, after the step of detecting whether there is an anomaly configuration in the preset configuration table, and includes:

[0081] Step a: If there is no abnormal configuration, check whether the mock return content in the preset configuration table contains a configuration content value;

[0082] If the system determines that no exception configuration exists in the exception class of the preset configuration table, it can then check if a configuration value exists in the mock return content of the preset configuration table. Different operations will be performed based on the different check results. The configuration value can be the configuration from the `return_content` field of the exception class in the preset configuration table.

[0083] Step b: If a configuration content value exists, obtain the return type of the target logic, convert the configuration content value according to the return type to obtain the conversion result, and output the conversion result as the return value of the target logic.

[0084] If the mock return value contains configuration information, it's necessary to determine whether the target logic's method body is currently executing before or after execution. If it's before execution, it checks if the configuration information value starts with "IMMEDIATELY:". If so, it uses the API provided by jvm-sandbox to obtain the target method's return type, retrieves the corresponding custom handler based on this return type, and then converts the `return_content` to the target method's return type using the custom handler. In other words, it converts the configuration information value based on the return type to obtain the conversion result, which is then output as the target logic's return value.

[0085] However, if the target logic's method body is executed after execution, it is determined whether the configuration content value does not start with IMMEDIATELY:. If so, the return type of the target method is obtained through the API provided by jvm-sandbox, and the corresponding custom handler is obtained based on this return type. Then, the return_content is converted into the result of the target method's return type based on the custom handler. That is, the configuration content value is converted according to the return type to obtain the conversion result, and the conversion result is output as the return value of the target logic.

[0086] In this embodiment, when it is determined that the mock return content contains a configuration content value, the configuration content value is converted according to the return type to obtain the return value of the target logic for output, thereby improving the accuracy of exception handling detection.

[0087] Further, if satisfied, after the step of detecting whether there is an abnormal configuration in the preset configuration table, the following steps are included:

[0088] Step c: If satisfied, check whether the configuration field in the preset configuration table has a sleep time value;

[0089] If the target logic is found to meet the preset detection conditions, it can then check whether the configuration field (i.e., the sleep time value) exists in the preset configuration table. Different operations are then performed based on the different detection results.

[0090] Step q: If a sleep time value exists, the target logic is put into sleep mode according to the sleep time value, and after the sleep mode is completed, the exception class in the preset configuration table is checked to see if there is an exception configuration.

[0091] If the system detects a sleep time value in the configuration field of the preset configuration table, it needs to determine whether the target logic's method body is before or after execution. If it's before execution, it needs to check if the sleep time value is negative. If so, it obtains the absolute value of the sleep time value and controls the target logic to perform sleep processing according to this absolute value. After the target logic's sleep processing is complete, it can continue to execute the step of checking if there are any exception configurations in the exception classes of the preset configuration table. If the target logic's method body is after execution, it needs to check if the sleep time value is positive. If it is positive, it controls the target logic to perform sleep processing according to this sleep time value. After the target logic's sleep processing is complete, it can continue to execute the step of checking if there are any exception configurations in the exception classes of the preset configuration table.

[0092] In this embodiment, the target logic is subjected to sleep processing based on the sleep time value, and the sleep processing can simulate timeout exception scenarios, making the obtained exception handling results more accurate and effective.

[0093] Further, the step of detecting whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters includes:

[0094] Step d: Detect whether a preset expression exists in the input conditions of the preset configuration table;

[0095] In this embodiment, it is also necessary to detect whether there is a preset expression in the input conditions of the preset configuration table, and to perform different operations based on different detection results.

[0096] Step e: If a preset expression exists and the input parameter matches the preset expression, then determine whether the target logic meets the preset detection conditions based on the preset configuration table.

[0097] If, after evaluation, a preset expression is found in the preset configuration table for the input condition, and the input parameter matches the preset expression, the input parameter condition evaluation is considered successful, and the next condition evaluation can proceed to determine whether the target logic meets the preset detection conditions based on the preset configuration table. If no preset expression exists, the target logic can be directly evaluated based on the preset configuration table to determine whether it meets the preset detection conditions.

[0098] In this embodiment, when the preset expressions in the input parameters and input conditions are matched, the target logic is determined based on the preset configuration table to ensure that the target logic meets the preset detection conditions, thereby ensuring the effective implementation of anomaly handling and detection.

[0099] Further, the step of determining whether the target logic meets the preset detection conditions based on the preset configuration table includes:

[0100] Step f: Check if there is a configuration count value for watch in the preset configuration table;

[0101] In this embodiment, when the input parameter matches the preset expression, the input parameter condition check is considered successful. At this point, an injection count check is required, which involves detecting whether a configuration count value exists in the preset configuration table's `watch` field. Different operations are performed based on different detection results. The configuration count value is the configuration value in the `return_content` field of the exception class in the preset configuration table.

[0102] Step g: If it exists and the configuration count value is greater than the injection count carried by the input parameter, then it is determined that the target logic meets the preset detection condition.

[0103] If the watchlist is found to have a configuration count value, and this count value is greater than the injection threshold carried by the input parameters, then the target logic can be determined to meet the preset detection conditions. However, if no configuration value exists, then the target logic does not meet the preset detection conditions.

[0104] It should be noted that in this embodiment, the determination of whether the target logic meets the preset detection conditions can be based on input parameter condition judgment and injection count judgment. When performing input parameter condition judgment, if the input condition field `input_condition` is not configured in the configuration table, the input parameter condition judgment is considered successful, meeting the conditions for abnormal injection. When the input condition field `input_condition` is present, the target logic input parameter value can be placed in the Ognl context, and the expression configured in `input_condition` is matched using the Ognl context. If the matching result is true (accurate), the input parameter condition judgment is considered successful; otherwise, it is considered unsuccessful. After the input parameter condition judgment is successful, the injection count judgment is also required. Only after the injection count judgment is successful is it determined that the target logic meets the preset detection conditions. Therefore, when the sandbox-mock module is loaded and started, an atomic counter is defined for each configuration, with an initial value of 0; if the `watch_count` field is not configured in the preset configuration table, the injection count judgment is considered successful. If the `watch_count` field in the preset configuration table is configured and its value is greater than the counter value, the injection attempt is considered successful and the counter is incremented by 1. If the `watch_count` field in the configuration table is configured and its value is less than or equal to the counter value, the injection attempt is considered unsuccessful.

[0105] In this embodiment, when the configured number of injections is greater than the number of injections carried by the input parameters, it is determined that the target logic meets the preset detection conditions, thereby ensuring the effective implementation of anomaly handling detection.

[0106] Furthermore, the steps for obtaining the preset configuration table and input parameters corresponding to the target logic include:

[0107] Step h: Determine the method body of the target logic, and determine the target listener based on the method body;

[0108] In this embodiment, it is necessary to determine whether the method body of the target logic is executed before or after execution. If the method body of the target logic is executed before execution, the event listener `beforeEvent` can be obtained and used as the target listener. However, if the method body of the target logic is executed after execution, the event listener `returnEvent` can be obtained and used as the target listener.

[0109] Step k: Obtain the preset configuration table and input parameters corresponding to the target logic based on the target listener.

[0110] Once the target listener is obtained, the input parameters for the execution of the target logic can be obtained directly through the target listener, and the preset configuration table corresponding to the target logic can be determined to obtain the various configuration information of the target logic in the preset configuration table.

[0111] In this embodiment, the target listener is determined based on the method body of the target logic, and the preset configuration table and input parameters corresponding to the target logic are determined based on this listener, thereby ensuring the normal operation of anomaly handling and detection.

[0112] Specifically, after the step of obtaining the preset configuration table and input parameters corresponding to the target logic based on the target listener, the process includes:

[0113] Step m: Obtain the historical configuration information in memory corresponding to the target logic;

[0114] In this embodiment, since the preset configuration table can be updated and changed in real time based on the operation of the target logic, the historical configuration information in memory corresponding to the target logic can be obtained first, so as to perform detection based on the historical configuration information. The historical configuration information can be existing configuration information in memory.

[0115] Step n: Obtain configuration information from the preset configuration table based on the target listener, and detect whether the configuration information matches the historical configuration information;

[0116] The target listener will retrieve the latest configuration information from the preset configuration table and check whether the configuration information matches the historical configuration information, and perform different operations based on different detection results.

[0117] Step x: If a match is found, then the step of detecting whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters is executed.

[0118] When the configuration information matches the historical matching information, the preset configuration table can be used as the preset configuration table for the target logic, while keeping the current target listener unchanged. That is, the target listener continuously reads the latest configuration from the exception injection rule configuration table and compares it with the previously read configuration (which is stored in memory). If a configuration exists in memory but not in the latest configuration, the target listener (i.e., the `beforeEvent` and `returnEvent` event listeners corresponding to the target logic) is unloaded. If a configuration is not in memory but exists in the latest configuration, the target logic's `beforeEvent` and `returnEvent` event listeners are added. If a configuration exists in both memory and the latest configuration, but their version numbers are inconsistent, the `beforeEvent` and `returnEvent` listeners are first unloaded, then the latest `beforeEvent` and `returnEvent` listeners are re-added, and the injection count counter is reset to 0. Then, the step of checking whether the target logic meets the preset detection conditions based on the preset configuration table and input parameters is executed.

[0119] In this embodiment, the target logic is only checked when the configuration information in the preset configuration table matches the historical configuration information, thereby ensuring the normal operation of anomaly handling detection.

[0120] Furthermore, it should be noted that the exception handling detection method adopted in this embodiment achieves zero intrusion, that is, it is based on JVM-sandbox technology and extends exception injection without modifying the original business system. Injection rules are dynamically configured in the database, and configurations are dynamically loaded, allowing testers to easily modify the configurations. Automated testing and regression testing are convenient, requiring only modifications to the configuration table, thus improving the flexibility of exception handling detection. It also allows for configuration of exception injection based on input parameters, enabling multiple tests to be performed independently, improving the isolation of exception handling detection, and supporting exception injection before or after method execution.

[0121] The present invention also provides an anomaly detection device, as described above. Figure 3 The anomaly handling and detection device includes:

[0122] The acquisition unit A10 is used to acquire the preset configuration table and input parameters corresponding to the target logic, and to detect whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters.

[0123] The detection unit A20 is used to detect whether there is an abnormal configuration in the preset configuration table if the condition is met.

[0124] Output unit A30 is used to construct an abnormal scenario based on the abnormal configuration if an abnormal configuration exists, obtain the target abnormality corresponding to the target logic according to the abnormal scenario, and output the target abnormality.

[0125] Optionally, the detection unit A20 is further configured to:

[0126] If no abnormal configuration is found, check if the mock return content in the preset configuration table contains a configuration content value;

[0127] If a configuration value exists, the return type of the target logic is obtained, and the configuration value is converted according to the return type to obtain the conversion result. The conversion result is then used as the return value of the target logic and output.

[0128] Optionally, the detection unit A20 is further configured to:

[0129] If the condition is met, then check whether the configuration field in the preset configuration table has a sleep time value;

[0130] If a sleep time value exists, the target logic is subjected to sleep processing based on the sleep time value, and after the sleep processing is completed, the system checks whether there is an abnormal configuration in the exception class of the preset configuration table.

[0131] Optionally, the acquisition unit A10 is further configured to:

[0132] Check whether the input conditions in the preset configuration table contain a preset expression;

[0133] If a preset expression exists and the input parameter matches the preset expression, then it is determined whether the target logic meets the preset detection conditions based on the preset configuration table.

[0134] Optionally, the acquisition unit A10 is further configured to:

[0135] Check if there is a configuration count value for watch in the preset configuration table;

[0136] If it exists, and the configuration count value is greater than the injection count carried by the input parameter, then the target logic is determined to meet the preset detection conditions.

[0137] Optionally, the acquisition unit A10 is further configured to:

[0138] Determine the method body of the target logic, and determine the target listener based on the method body;

[0139] Based on the target listener, obtain the preset configuration table and input parameters corresponding to the target logic.

[0140] Optionally, the acquisition unit A10 is further configured to:

[0141] Obtain the historical configuration information in memory corresponding to the target logic;

[0142] Based on the target listener, the configuration information in the preset configuration table is obtained, and it is detected whether the configuration information matches the historical configuration information;

[0143] If a match is found, then the step of detecting whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters is executed.

[0144] The methods executed by the above-mentioned program modules can be referred to in the various embodiments of the anomaly handling and detection method of the present invention, and will not be repeated here.

[0145] The present invention also provides a computer storage medium.

[0146] The present invention provides a computer storage medium storing an exception handling detection program, which, when executed by a processor, implements the steps of the exception handling detection method described above.

[0147] The method implemented when the exception handling detection program running on the processor is executed can be referred to in various embodiments of the exception handling detection method of the present invention, and will not be repeated here.

[0148] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0149] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0150] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0151] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. An anomaly detection method, characterized in that, The anomaly handling and detection method includes the following steps: Obtain the preset configuration table and input parameters corresponding to the target logic; wherein, the target logic refers to the target method to be executed; Check whether the input conditions in the preset configuration table contain a preset expression; If a preset expression exists and the input parameter matches the preset expression, then check whether there is a configuration count value for watch in the preset configuration table; If it exists, and the configuration count value is greater than the injection count carried by the input parameter, then the target logic is determined to meet the preset detection condition. If the target logic meets the preset detection conditions, then it is detected whether there is an exception configuration in the exception class of the preset configuration table; wherein, the exception configuration means that the exception class field exception_class in the preset configuration table is configured, and the configuration value does not start with "IMMEDIATELY:"; If an abnormal configuration exists, an abnormal scenario is constructed based on the abnormal configuration, the target exception corresponding to the target logic is obtained according to the abnormal scenario, and the target exception is output; wherein, obtaining the target exception corresponding to the target logic according to the abnormal scenario and outputting the target exception includes: obtaining the JVM class loader, and throwing an exception when an exception error code exception_code and an exception description exception_desc are input.

2. The anomaly handling and detection method as described in claim 1, characterized in that, After the step of detecting whether there is an abnormal configuration in the preset configuration table, the following steps are included: If no abnormal configuration is found, check if the mock return content in the preset configuration table contains a configuration content value; If a configuration value exists, the return type of the target logic is obtained, and the configuration value is converted according to the return type to obtain the conversion result. The conversion result is then used as the return value of the target logic and output.

3. The anomaly handling and detection method as described in claim 1, characterized in that, If satisfied, the step of checking whether there is an abnormal configuration in the abnormal class of the preset configuration table includes: If the condition is met, then check whether the configuration field in the preset configuration table has a sleep time value; If a sleep time value exists, the target logic is subjected to sleep processing based on the sleep time value, and after the sleep processing is completed, the system checks whether there is an abnormal configuration in the exception class of the preset configuration table.

4. The anomaly handling and detection method according to any one of claims 1-3, characterized in that, The steps of obtaining the preset configuration table and input parameters corresponding to the target logic include: Determine the method body of the target logic, and determine the target listener based on the method body; Based on the target listener, obtain the preset configuration table and input parameters corresponding to the target logic.

5. The anomaly handling and detection method as described in claim 4, characterized in that, After the step of obtaining the preset configuration table and input parameters corresponding to the target logic based on the target listener, the following steps are included: Obtain the historical configuration information in memory corresponding to the target logic; Based on the target listener, the configuration information in the preset configuration table is obtained, and it is detected whether the configuration information matches the historical configuration information; If a match is found, then the step of detecting whether the target logic meets the preset detection conditions based on the preset configuration table and the input parameters is executed.

6. An anomaly handling and detection device, characterized in that, The anomaly handling and detection device includes: The acquisition unit is used to acquire a preset configuration table and input parameters corresponding to the target logic; wherein, the target logic refers to the target method to be executed; detect whether there is a preset expression in the input conditions in the preset configuration table; if there is a preset expression, and the input parameters match the preset expression, then detect whether there is a configuration count value in the watch in the preset configuration table; if there is, and the configuration count value is greater than the injection count carried by the input parameters, then determine that the target logic satisfies the preset detection conditions; The detection unit is used to detect whether there is an exception configuration in the exception class of the preset configuration table if the target logic meets the preset detection conditions; wherein, the exception configuration refers to the exception class field exception_class in the preset configuration table being configured, and the configuration value does not start with "IMMEDIATELY:"; The output unit is used to construct an exception scenario based on the exception configuration if an exception configuration exists, obtain the target exception corresponding to the target logic according to the exception scenario, and output the target exception; wherein, obtaining the target exception corresponding to the target logic according to the exception scenario and outputting the target exception includes: obtaining the JVM class loader, and throwing the exception when an exception error code exception_code and exception description exception_desc are input.

7. An anomaly handling and detection device, characterized in that, The anomaly detection device includes: a memory, a processor, and an anomaly detection program stored in the memory and executable on the processor. When the anomaly detection program is executed by the processor, it implements the steps of the anomaly detection method as described in any one of claims 1 to 5.

8. A computer storage medium, characterized in that, The computer storage medium stores an anomaly handling detection program, which, when executed by a processor, implements the steps of the anomaly handling detection method as described in any one of claims 1 to 5.

Images