Fault simulation method and device based on code probe, equipment and medium

Abstract

The invention relates to the technical field of software testing, can be applied to business system platforms of financial science and technology, medical treatment and health and the like, and discloses a fault simulation method, device and equipment based on a code probe and a medium. Constructing a corresponding fault logic code according to the payment data link; injecting the fault logic code into the to-be-tested fault object to obtain a target fault object; performing payment fault simulation on the target fault object according to a preset payment fault simulation condition and the fault logic code to obtain fault response data corresponding to the target fault object; and performing fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report of the target fault object. According to the invention, full-link intelligent fault simulation can be realized and the verification reliability of each transaction of the target system can be improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to a fault simulation method, device, equipment and medium based on a code probe. Background Art

[0002] In the healthcare and fintech sectors, the demand for payment consistency assurance based on distributed transactions is growing, but existing technologies still have obvious shortcomings in the comprehensiveness of payment link failure simulation and test effectiveness.

[0003] For example, in the healthcare sector, target users expect real-time, accurate payment result feedback during health product flash sales. Current payment verification systems only support simple simulation scenarios such as "single-system anomalies" and "basic network jitter," and are unable to build complex testing environments for multi-system cascading failures. When encountering anomalies in the interaction between the payment gateway and inventory system, the testing tools lack a full-link state synchronization mechanism, requiring manual construction of multi-system failure scenarios, significantly reducing the coverage of failure and anomaly testing.

[0004] For example, in the fintech sector, existing payment testing frameworks rely solely on fixed threshold triggers for exception injection. When simulating an inconsistent payment status due to exchange rate conversion delays, the system struggles to dynamically generate abnormal data flows across time zones and multiple currencies, resulting in insufficient realism in the test scenario and inaccurate payment status reconciliation.

[0005] Existing link fault testing technologies primarily rely on discrete fault injection architectures, for example, constructing fault test cases by presetting independent dimensions such as "interface timeouts" and "database anomalies." While this approach can accomplish basic verification, it lacks the ability to generate coordinated faults across multiple nodes at the link control layer. Furthermore, at the fault-tolerance verification layer, it is difficult to trace the root cause of anomalies using transaction logs, leading to potential test blind spots and verification distortion. Therefore, implementing full-link intelligent fault simulation and improving the reliability of transaction verification across the target system are pressing challenges. Summary of the Invention

[0006] The present invention provides a fault simulation method, device, equipment and medium based on a code probe, the main purpose of which is to solve the problems of incomplete link fault simulation and low reliability.

[0007] In a first aspect, to achieve the above-mentioned purpose, the present invention provides a fault simulation method based on a code probe, comprising:

[0008] Obtaining the payment data link of the fault object to be tested, and constructing a corresponding fault logic code according to the payment data link;

[0009] Injecting the fault logic code into the fault object to be tested to obtain a target fault object;

[0010] Performing payment fault simulation on the target fault object according to the preset payment fault simulation conditions and the fault logic code to obtain fault response data corresponding to the target fault object;

[0011] Performing a fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report for the target fault object.

[0012] In a second aspect, the present invention further provides a fault simulation device based on a code probe, comprising:

[0013] A code construction module is used to obtain the payment data link of the fault object to be tested and construct a corresponding fault logic code according to the payment data link;

[0014] A code injection module, configured to inject the fault logic code into the fault object to be tested to obtain a target fault object;

[0015] a fault simulation module, configured to perform payment fault simulation on the target fault object according to preset payment fault simulation conditions and the fault logic code, and obtain fault response data corresponding to the target fault object;

[0016] The fault analysis module is configured to perform fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report of the target fault object.

[0017] In a third aspect, the present invention further provides an electronic device, comprising:

[0018] at least one processor; and,

[0019] a memory communicatively connected to the at least one processor; wherein,

[0020] The memory stores a computer program that can be executed by the at least one processor. The computer program is executed by the at least one processor so that the at least one processor can perform the above-mentioned fault simulation method based on a code probe.

[0021] In a fourth aspect, the present invention further provides a computer-readable storage medium, wherein at least one computer program is stored in the computer-readable storage medium, and the at least one computer program is executed by a processor in an electronic device to implement the above-mentioned code probe-based fault simulation method.

[0022] By constructing a payment data link, the present invention can completely restore the data flow of each link in the payment process. When a payment fails or is abnormal, the fault logic code can automatically analyze the abnormal node based on the link data, significantly shortening the troubleshooting time; by dynamically and accurately injecting the fault logic code, it can simulate real fault scenarios in complex systems such as the payment link, effectively improving the stability and reliability of the payment link, and reducing the risk of link failure; by pre-setting payment fault simulation conditions and fault logic codes, payment fault simulation operations are carried out on the target fault object, which can simulate various payment abnormalities, enhance the system's fault tolerance and recovery mechanism under real fault scenarios, and provide a more accurate basis for the optimization of the preset system; cleaning, labeling and aggregation calculation of massive fault response data greatly shortens data processing time, improves analysis efficiency, and reduces human analysis errors. By automatically generating reports, it ensures that the content format is standardized and the information is comprehensive, which is convenient for subsequent reference and decision-making, realizes the standardization and repeatability of the fault analysis process, and facilitates horizontal comparative analysis of different fault objects. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0024] Figure 1 A schematic diagram of an application environment of a fault simulation method based on a code probe according to an embodiment of the present invention;

[0025] Figure 2 A schematic flow chart of a fault simulation method based on a code probe provided in one embodiment of the present invention;

[0026] Figure 3 A schematic diagram of a process of injecting the fault logic code into the fault object to be tested provided by an embodiment of the present invention;

[0027] Figure 4 A schematic diagram of a module of a fault simulation device based on a code probe provided by an embodiment of the present invention;

[0028] Figure 5 A schematic structural diagram of an electronic device for implementing a fault simulation method based on a code probe provided by an embodiment of the present invention;

[0029] Figure 6 Another structural diagram of an electronic device for implementing a fault simulation method based on a code probe provided by an embodiment of the present invention.

[0030] The purpose, features and advantages of the present invention will be further described with reference to the accompanying drawings and in conjunction with the embodiments. DETAILED DESCRIPTION

[0031] In order to enable those skilled in the art to better understand the technical solutions of the present disclosure, and to fully understand and implement how the present disclosure applies technical means to solve technical problems and achieve the corresponding technical effects, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of the embodiments. The embodiments of the present disclosure and the various features in the embodiments can be combined with each other without conflict, and the technical solutions formed are all within the scope of protection of the present disclosure. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work should fall within the scope of protection of the present disclosure.

[0032] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, apparatus, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0033] The embodiment of the present application provides a fault simulation method based on a code probe, and the execution subject of the fault simulation method based on a code probe includes but is not limited to at least one of the electronic devices such as a server and a terminal that can be configured to execute the device provided by the embodiment of the present application. In other words, the fault simulation method based on a code probe can be executed by software or hardware installed on a terminal device or a server device. The server includes but is not limited to: a single server, a server cluster, a cloud server or a cloud server cluster, etc. The server can be an independent server, or it can be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0034] The present invention provides a fault simulation method based on code probe, which can be applied in Figure 1 In this application environment, the client communicates with the server over the network. The server obtains data links from the client and, by building payment data links, can fully restore the data flow of each link in the payment process. When a payment fails or an anomaly occurs, the fault logic code automatically analyzes the abnormal node based on the link data, significantly shortening the troubleshooting time. By dynamically and accurately injecting fault logic code, it can simulate real-world failure scenarios in complex systems such as payment links, effectively improving the stability and reliability of payment links and reducing the risk of link failures. By pre-setting payment failure simulation conditions and fault logic code, payment failure simulation operations are performed on the target fault object, simulating various payment anomalies, enhancing the system's fault tolerance and recovery mechanisms in real-world failure scenarios, and providing a more accurate basis for optimizing the preset system. Massive fault response data is cleaned, annotated, and aggregated, significantly shortening data processing time, improving analysis efficiency, and reducing human analysis errors. Automated report generation ensures standardized content formatting and comprehensive information, facilitating subsequent review and decision-making, standardizing and repeating the fault analysis process, and facilitating horizontal comparative analysis of different fault objects. Finally, the target fault analysis report is output and fed back to the client. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablet computers, and portable wearable devices. The server can be implemented as an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0035] Reference Figure 2 FIG. 1 is a flow chart of a fault simulation method based on a code probe according to an embodiment of the present invention. In this embodiment, the fault simulation method based on a code probe includes:

[0036] S1. Obtain the payment data link of the fault object to be tested, and construct a corresponding fault logic code according to the payment data link.

[0037] In an embodiment of the present invention, the payment data link refers to the complete data processing path from the target user initiating a payment request to the complete funds settlement in a payment business scenario, including the request entry layer, business logic layer, funds channel layer, data persistence layer, and status feedback layer.

[0038] Among them, the request entry layer refers to the nodes such as payment gateway and API interface that receive payment requests from target users; the business logic layer refers to core processing modules such as transaction routing and order inventory calculation; the capital channel layer refers to the data interaction link with banks and third-party payment platforms; the data persistence layer refers to transaction record storage, reconciliation logs, etc.; the status feedback layer refers to the notification link that returns the payment results to the fault object to be tested.

[0039] In an embodiment of the present invention, the fault object to be tested may be a business system, a payment system, etc., and the fault logic code may be the logic code corresponding to insufficient inventory, interface timeout, or payment failure, and may be written using a specific programming language or technology stack such as Python, Java, JavaScript, etc.

[0040] In an embodiment of the present invention, the payment data link can be obtained through distributed link tracing technology, the entire link call can be connected in series through the TraceID global identifier, a probe can be implanted in the preset payment system, and a data link log can be automatically generated.

[0041] For example, in the medical and health business scenario, the medical payment data link mainly includes core businesses such as medical insurance settlement, patient self-payment, commercial insurance direct payment, and drug / consumables procurement payment. When obtaining the payment data link, it is necessary to be compatible with the medical insurance protocol (such as HL7 / FHIR), patient privacy protection (HIPAA / GDPR), and multi-system heterogeneous docking (hospital HIS, LIS, PACS). The present invention can use an HL7 parser (such as HAPI FHIR) to capture the medical insurance transaction message to parse the medical insurance interface protocol, thereby obtaining key fields such as medical insurance settlement order number, diagnosis code, etc., and then connect the payment system and payment gateway log in series through the patient ID to obtain the medical payment data link. The medical payment link can be patient mobile terminal → hospital registration system (initiate payment) → medical insurance center interface (cost decomposition) → UnionPay / third-party payment (self-paid part) → HIS system (order status synchronization) → electronic invoice system.

[0042] For example, in the field of financial technology business, the financial payment data link mainly includes core businesses such as cross-border payment, real-time clearing, and digital currency trading. The financial payment link can be obtained as a real-time transaction flow mirror. For example, cross-border payment can deploy traffic replication equipment in the financial payment system, and align the transaction flows of multiple data centers through nanosecond timestamps to obtain a financial payment link. The financial payment link can be user APP → risk control engine (anti-money laundering verification) → exchange rate calculation service → blockchain node (digital currency conversion) → agent bank channel → SWIFT network → overseas receiving bank → fund status callback.

[0043] In an embodiment of the present invention, constructing a corresponding fault logic code according to the payment data link includes:

[0044] Constructing a data link topology graph based on the payment data link, performing data parsing on the data link topology graph to obtain node information and edge correspondence of the data link topology graph;

[0045] Constructing a target syntax tree according to the correspondence between the node information and the edges;

[0046] The target syntax tree is converted into fault logic code.

[0047] In detail, based on the specific structure of the payment data link, the various components in the payment process, such as the payment interface, payment gateway, database, third-party payment platform, etc., are abstracted as nodes in the graph, and the interactive relationships between them, such as data transmission and state transition, are abstracted as edges in the graph. Through data modeling technology, the actual payment link is converted into a visual and structured data link topology diagram, which intuitively displays the dependency and interaction sequence between the various components in the payment process, providing a basis for subsequent analysis and processing.

[0048] Specifically, the present invention performs a depth-first or breadth-first traversal on the data link topology graph (such as using a DFS or BFS algorithm), extracting detailed information of each node in the graph such as node type, function description, input and output parameters, etc., as well as the corresponding relationship between edges between nodes such as edge type, direction, weight, etc.

[0049] In detail, the target syntax tree is a tree structure used to represent the syntax structure of the program code, wherein the starting point of the data link topology diagram can be selected as the root node of the target syntax tree, and each node is added to the target syntax tree as a child node of its parent node according to the correspondence of the edges. At the same time, necessary attributes such as node type, state transition rules, etc. are assigned to each node, and the logical relationship between nodes such as conditional judgment, loop structure, etc. is defined to facilitate subsequent code generation and logical analysis.

[0050] Among them, based on the constructed target syntax tree, code generation technology is used to convert it into executable fault logic code. By using template engines such as Jinja2 and Handlebars, specific code implementation can be generated through predefined code templates and node information in the target syntax tree.

[0051] In detail, the target syntax tree is traversed, each node is visited, and code template matching is performed according to the type and attributes of the node to select a suitable code template, and the specific information in the node is filled into the code template to generate a specific code fragment. All the generated code fragments are spliced ​​together according to the structure of the target syntax tree to form a complete fault logic code. The fault logic code can represent the simulated implementation of the specific fault in the fault object to be tested.

[0052] In an embodiment of the present invention, performing data parsing on the data link topology graph to obtain node information and edge correspondence of the data link topology graph includes:

[0053] Traversing all units with preset flag bits in the data link topology diagram;

[0054] Parsing the unit according to the attribute edge value of the unit to obtain a parsing result;

[0055] The node information and the corresponding relationship of the edges of the data link topology graph are determined according to the analysis result.

[0056] In detail, a graph traversal algorithm and flag bit screening may be used to perform unit traversal, wherein the graph traversal algorithm is used to access each node or edge in the graph structure, including depth-first search (DFS) and breadth-first search (BFS).

[0057] The depth-first search (DFS) refers to starting from a starting node and visiting nodes as deeply as possible along a path until it is impossible to go further and then backtracking to the previous node to continue visiting other unvisited paths.

[0058] The breadth-first search (BFS) refers to starting from a starting node and visiting all adjacent nodes layer by layer until the entire graph is traversed.

[0059] Specifically, in the data link topology diagram, each node or edge is assigned one or more flags to identify its specific attributes or status, such as "visited", "pending", "critical node", etc. Through pre-defined flags such as binary bits, enumeration values, etc., it is possible to quickly identify the units that need to be parsed, such as nodes or edges.

[0060] In detail, attribute values ​​can be extracted from the original data of the unit through predefined parsing rules such as regular expressions, key-value pair mapping, etc. The attribute edge values ​​include numerical edge values ​​and symbolic edge values. The numerical edge values ​​include the weight of the edge, the load value of the node, etc., and the symbolic edge values ​​include the type of edge (unidirectional / bidirectional), the status of the node (activated / inactivated), etc.

[0061] Among them, if the attribute edge value of the unit is 1, the node source value corresponding to the unit is obtained as the starting node identity of the edge corresponding to the unit, and the node target value corresponding to the unit is obtained as the target node identity of the edge corresponding to the unit.

[0062] If the attribute edge value of the unit is not 1, the identity identification value of the unit is obtained as the node identity identification value corresponding to the unit, and the attribute value of the unit is obtained as the judgment logic or root cause value within the node corresponding to the unit. According to the type value of the unit, the node type corresponding to the unit is determined according to the shape, thereby obtaining the node information of the data link topology diagram and the corresponding relationship of the edges.

[0063] The fault logic code in the present invention can be a fault code corresponding to fault objects such as insufficient inventory, interface timeout, payment failure, etc. If the fault object is insufficient inventory, the fault logic code can set the inventory module to 0 or a negative number to implement the conditional judgment of insufficient inventory; if the fault object is interface timeout, the fault logic code can replace a certain interface and let it sleep for a specific timeout period, thereby simulating the interface timeout situation; if the fault object is payment failure, the fault logic code can simulate the payment failure scenario by directly returning the failure code.

[0064] In an embodiment of the present invention, by constructing a payment data link, the data flow of each link in the payment process can be completely restored. When a payment fails or is abnormal, the fault logic code can automatically analyze the abnormal node based on the link data, significantly shortening the troubleshooting time.

[0065] S2. Inject the fault logic code into the fault object to be tested to obtain a target fault object.

[0066] In an embodiment of the present invention, by dynamically injecting the constructed fault logic code into the operating environment of the fault object to be tested, such as an API interface, a service module or a message queue, a real fault scenario in the payment link can be simulated.

[0067] The target fault object may be a fault type such as insufficient inventory, interface timeout, payment failure, etc.

[0068] like Figure 3 As shown, in the embodiment of the present invention, injecting the fault logic code into the fault object to be tested to obtain a target fault object includes:

[0069] Obtaining call information of an internal function in the fault logic code, and counting the number of calls of the internal function according to the call information;

[0070] Perform function screening on the internal function according to the number of calls to obtain a target function;

[0071] Performing a position structure analysis on the fault object to be tested according to the objective function to obtain a target injection position of the fault object to be tested;

[0072] Setting a detection point at the target injection position according to a preset function probe;

[0073] The fault logic code is injected into the fault object to be tested at the detection point to obtain a target fault object.

[0074] Specifically, static analysis such as AST abstract syntax tree parsing or dynamic instrumentation such as the bytecode enhancement framework ASM can be used to extract the call information of all internal functions in the fault logic code, such as function name, parameters, return value type, etc. Based on the call information, the triggering frequency of each function in the fault scenario can be counted. For example, when the payment callback fails, the retryPayment() function is called 3 times. A threshold is set according to the number of calls (for example, a function with a call count ≥ 2 is a high-frequency function), and the function that has the greatest impact on the fault trigger is screened out to obtain the target function.

[0075] The location structure analysis described in the present invention refers to performing code structure analysis on the fault object to be tested to generate a function call chain diagram, and combining the context dependency of the target function, such as dependency on the database connection pool and third-party payment SDK, to determine its execution node in the chain.

[0076] Among them, runtime tracing technologies such as Java's Instrumentation API or Python's sys.settrace() can be used to monitor the execution path of the target function in real time, obtain the specific call stack location, ensure that the injection point is on the trigger path of the fault logic, and avoid injecting invalid locations.

[0077] Specifically, a general probe interface can be defined to record input parameters before function execution and capture return values ​​and exception information after execution. Bytecode enhancement technologies such as ASM and ByteBuddy can be used to insert probe code at the target injection location to trigger fault logic at the detection point and simulate abnormal fault scenarios.

[0078] For example, in a medical information system, processes such as patient appointment registration and examination report inquiry involve the interaction of multiple service modules. In order to ensure that the system can run stably and accurately diagnose problems when a failure occurs, the system needs to be tested by fault injection.

[0079] Among them, common failure scenarios in medical appointment systems are simulated, such as database connection timeouts and patient information query interface return errors. For example, a fault logic code is constructed. When the patient information query interface is called, an error code (such as 500) is simulated to be returned, indicating an internal server error. Static analysis techniques (such as AST abstract syntax tree parsing) can be used to analyze the fault logic code and extract the call information of the internal functions, including function name, parameters, return value type, etc. Assume that in the fault logic code, the queryPatientInfo() function is frequently called. By counting the number of calls, it is found that its call count reaches the threshold and is determined as the target function.

[0080] Specifically, in the appointment registration process, the target function depends on the database connection pool and the patient information database. Its execution node in the appointment registration link is determined to be the appointment information query module. Runtime tracing technology is used to monitor the execution path of the target function in real time, obtain the specific call stack location, ensure that the injection point is on the trigger path of the fault logic, and use bytecode enhancement technology to insert probe code at the target injection position to trigger the fault logic at the detection point, simulate the fault scenario where the patient information query interface returns an error, and inject the constructed fault logic code into the medical appointment system to be tested at the detection point to obtain the target fault object.

[0081] At this time, when the medical appointment system calls the patient information query interface, it will simulate the return error according to the fault logic code to test the system's response and processing capabilities under such fault conditions.

[0082] In the embodiments of the present invention, by dynamically and accurately injecting fault logic code, it is possible to simulate real fault scenarios in complex systems such as payment links, effectively improve the stability and reliability of payment links, reduce the risk of link failures, and at the same time reduce debugging time and improve development efficiency.

[0083] S3. Perform payment fault simulation on the target fault object according to the preset payment fault simulation conditions and the fault logic code to obtain fault response data corresponding to the target fault object.

[0084] In an embodiment of the present invention, based on preset payment fault simulation conditions and fault logic codes, a payment fault simulation operation is performed on a target fault object, and by simulating various abnormal conditions, response data fed back by the target fault object for these faults is obtained.

[0085] In an embodiment of the present invention, fault scenarios can be simulated in parallel or a single fault scenario can be simulated. If the target fault object is insufficient inventory, only insufficient inventory can be configured, and fault scenarios such as interface timeout and payment failure are not configured, thereby testing the fault tolerance and recovery mechanism of the preset system when inventory is insufficient.

[0086] For example, in the fintech business scenario, insurance business involves a large number of payment operations, such as premium payment when customers purchase insurance products, compensation payment when insurance claims are settled, etc. In order to ensure the stability and security of the insurance payment system, it is necessary to simulate payment failures of the target fault object (such as the insurance payment system).

[0087] Among them, a variety of fault simulation conditions can be set, such as payment channel failure (simulating problems in the bank payment channel resulting in payment failure), insurance premium calculation error (simulating an error in the system when calculating the insurance premium, resulting in incorrect payment amount), customer account freeze (simulating the customer's bank account being frozen and unable to complete payment), etc.

[0088] In detail, the fault logic code can be bound to the preset payment fault simulation conditions through the configuration file. For example, the fault logic code of the payment channel failure can be associated with the "payment channel failure" condition. When the insurance payment system is running, the rule engine monitors the various data in the payment process in real time. Once a preset condition is met, the corresponding fault logic code is triggered to execute.

[0089] When a fault simulation condition is triggered, the corresponding fault logic code is injected into the insurance payment system's operating environment for execution according to the conditional trigger execution chain. For example, when a customer account freeze is detected, the fault logic code simulating the customer account freeze is executed, returning the corresponding error information. Pre-set monitoring probes deployed in the insurance payment system can collect key metrics of the payment process, such as payment response time, payment success rate, and error type. When a metric is detected to be outside the normal range (such as a sudden drop in payment success rate), corresponding fault response data is generated, including the fault type (such as customer account freeze).

[0090] In an embodiment of the present invention, performing payment fault simulation on the target fault object according to the preset payment fault simulation condition and the fault logic code to obtain fault response data corresponding to the target fault object includes:

[0091] Establishing a dynamic mapping relationship between the fault logic code and a preset payment fault simulation condition, and generating a condition-triggered execution link based on the mapping relationship;

[0092] Performing code execution on the target fault object according to the condition-triggered execution link and the fault logic code to obtain a code execution result;

[0093] The code execution result is monitored according to a preset monitoring probe to obtain fault response data corresponding to the target fault object.

[0094] In detail, the preset payment fault simulation conditions are bound to the corresponding fault logic code through a configuration file or database. For example, a condition is set to "payment timeout is greater than 5 seconds", and it is associated with the code segment that simulates the payment timeout fault. Then, the mapping relationship is read using rule engine technology to build a conditional triggered execution link.

[0095] Among them, when the payment system is running, the rule engine will monitor various data in the payment process (such as payment time, payment amount, etc.) in real time. Once a preset condition is met, the corresponding fault logic code will be triggered to execute.

[0096] In detail, according to the condition-triggered execution link, when a certain fault simulation condition is triggered, the corresponding fault logic code is executed in the running environment of the target fault object. An isolated execution environment can be created for the fault logic code through sandbox technology to ensure that its execution process does not interfere with the normal business logic of the target object, and prevent the fault logic code from causing problems such as preset system crashes or data leakage. The fault logic code is executed in the sandbox to simulate the occurrence of payment failures, such as returning a payment timeout error message.

[0097] In detail, logging technology can be used to record key information during code execution. Logging technology can capture every step of code execution, input and output data, exception information, etc., providing data support for subsequent analysis and monitoring.

[0098] Among them, during the execution of the fault logic code, the logging technology records in detail the code's execution path, input parameters, output results and other information. For example, when the payment timeout fault simulation code is executed, the initiation time of the payment request, the timeout time, the returned error code and other information are recorded. The preset monitoring probe collects log information in real time and analyzes it according to the defined monitoring indicators. When it is found that a certain indicator exceeds the normal range (such as a sudden increase in the error rate), the monitoring probe will generate corresponding fault response data, including fault type, fault occurrence time, impact range and other information.

[0099] For example, in the medical and health scenario, there are various payment-related business processes, such as patients making online appointments and paying fees, purchasing medicines online, etc. In order to ensure the stability and reliability of the medical payment system under various failure conditions, it is necessary to simulate payment failures on the target failure object (such as the payment system module).

[0100] Among them, a variety of fault simulation conditions can be set, such as payment interface timeout (simulating network delays that cause payment requests to fail to respond in a timely manner), abnormal payment amount (simulating users entering incorrect amounts or the system calculating incorrect amounts), insufficient balance in medical insurance accounts (simulating insufficient funds in patients' medical insurance accounts to complete payment), etc.

[0101] Specifically, the fault logic code of the payment interface timeout is associated with the "payment interface timeout" condition. When the payment system is running, the rule engine monitors the data in the payment process in real time. Once a preset condition is met, the corresponding fault logic code is triggered to execute. According to the test requirements, you can choose to simulate multiple fault scenarios in parallel, such as simulating payment interface timeout and insufficient medical insurance account balance at the same time to test the system's fault tolerance in complex fault situations; you can also simulate a single fault scenario, such as only simulating insufficient medical insurance account balance, and focus on testing the system's processing mechanism under this fault.

[0102] Specifically, when a fault simulation condition is triggered, the corresponding fault logic code is injected into the runtime environment of the target fault object (payment system module) according to the conditional trigger execution chain. For example, when insufficient medical insurance account balance is detected, the fault logic code simulating insufficient medical insurance account balance is executed, and the corresponding error information is returned. Pre-set monitoring probes are deployed in the payment system to monitor the code execution results in real time. The monitoring probes can collect key metrics of the payment process, such as payment response time, payment success rate, and error type. When a metric is found to be out of the normal range (such as a sudden drop in payment success rate), corresponding fault response data is generated, including the insufficient medical insurance account balance, the time of failure, and the scope of impact (such as the number of affected users and the payment orders involved).

[0103] In an embodiment of the present invention, by presetting payment fault simulation conditions and fault logic codes, payment fault simulation operations are carried out on the target fault object, which can simulate various payment abnormalities, enhance the system's fault tolerance and recovery mechanism under real fault scenarios, and effectively improve the overall stability and reliability of the preset system. The fault tolerance can be comprehensively evaluated through fault response data, providing a more accurate basis for the optimization of the preset system.

[0104] S4. Perform fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report of the target fault object.

[0105] In an embodiment of the present invention, by analyzing the fault response data of the target fault object, extracting key information and performing data statistical processing, a fault analysis report of the target fault object is generated, which can quickly locate the cause of the fault, evaluate the scope of the fault impact, and provide a basis for subsequent fault repair and optimization.

[0106] In an embodiment of the present invention, performing fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report for the target fault object includes:

[0107] Performing data cleaning on the fault response data to obtain target response data;

[0108] Performing data statistics on the target response data to obtain fault analysis indicators;

[0109] Obtain a fault analysis report template corresponding to the target fault object, import the fault analysis indicators into the fault analysis report template, and generate a target fault analysis report.

[0110] In detail, the data cleaning includes missing value processing, outlier detection processing and data format conversion. The missing value processing refers to the situation where some fields may be missing in the fault response data. It can be done by deleting records containing missing values ​​or using statistics such as mean, median, mode, etc. to fill them in. The outlier detection processing refers to observations that are significantly different from most data. It may be due to data entry errors, equipment failures, etc. Statistical methods such as the standard deviation method can be used to treat data that is more than a certain multiple of the standard deviation away from the mean as outliers. Machine learning-based methods such as the isolation forest algorithm can also be used to automatically detect abnormal points in the data. The detected outliers can be corrected or deleted according to the specific situation.

[0111] The fault analysis indicators include the fault occurrence rate (the number of faults occurring per unit time), the average fault recovery time (the average time required from the occurrence of a fault to the system returning to normal operation), the number of users affected by the fault (the number of users affected by each fault), etc.

[0112] In detail, according to the type of target fault object, the purpose and requirements of the fault analysis, a suitable template is selected from the predefined fault analysis report template library, which contains a variety of report templates of different types and styles, such as templates for overall system fault analysis, templates for specific module fault analysis, etc.

[0113] Among them, the fault analysis indicators obtained by statistics are filled in according to the predefined format and position in the template. During the filling process, the data needs to be properly formatted, such as retaining a certain number of decimal places for numerical data, converting date and time data into a specific display format, etc. At the same time, according to the requirements of the template, necessary charts such as bar charts, line charts, pie charts, etc. can be added to intuitively display the fault analysis results.

[0114] Specifically, a report generation tool or programming language can be used to convert the template filled with data into a final fault analysis report. The target fault analysis report can be output in multiple formats, such as PDF, Word, HTML, etc., for easy viewing, printing, etc.

[0115] In the embodiment of the present invention, performing data statistics on the target response data to obtain the fault analysis index includes:

[0116] Annotating the target response data according to a preset fault classification dimension, and classifying the annotated data according to the fault type to obtain annotated response data;

[0117] Calibrate the labeled response data to correct any possible labeling deviations or errors;

[0118] Perform multi-level aggregation calculations on the corrected labeled response data to obtain fault analysis indicators.

[0119] Among them, the classification dimensions include fault type, fault location, fault impact range, etc. The fault type includes network failure, database failure, code logic error, etc. The fault location includes front-end page, back-end server, database, etc. The fault impact range includes local impact, global impact, etc.

[0120] The multi-level aggregation calculation refers to the process of summarizing and calculating the labeled response data according to different levels. The multi-level aggregation calculation can aggregate the data from multiple different angles and levels to obtain fault analysis indicators of different granularities.

[0121] In detail, the data labeling is to add corresponding classification labels to each target response data. Machine learning algorithms such as decision trees, support vector machines, neural networks, etc. can be used to train the target response data so that it can automatically learn the rules of fault classification and classify and label new data so that the data can be statistically analyzed according to different dimensions in the future. For example, for the target response data of an e-commerce payment system, if it is labeled according to the fault type, then a payment failure record caused by network delay may be labeled as "network failure"; if it is labeled according to the fault impact range, a payment failure record that affects all users may be labeled as "global impact".

[0122] Specifically, SQL statements can be used to perform first-level aggregation based on fault type to calculate indicators such as the number of occurrences and average response time of each fault type; then, second-level aggregation can be performed based on the fault impact range to analyze the distribution of faults with different impact ranges in each fault type, thereby obtaining various fault analysis indicators.

[0123] In the embodiment of the present invention, massive fault response data is cleaned, labeled and aggregated, which greatly shortens the data processing time, improves analysis efficiency, and reduces human analysis errors. At the same time, through automatic report generation, the content format is ensured to be standardized and the information is comprehensive, which is convenient for subsequent review and decision-making, realizes the standardization and repeatability of the fault analysis process, and facilitates horizontal comparative analysis of different fault objects.

[0124] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0125] like Figure 4 FIG. 1 is a functional module diagram of a fault simulation device based on a code probe provided by an embodiment of the present invention.

[0126] In an embodiment of the present disclosure, a fault simulation device based on a code probe is provided, and the fault simulation device based on a code probe corresponds one-to-one to the fault simulation method based on a code probe in the above embodiment. Figure 5 As shown, the fault simulation device 100 based on a code probe can be installed in an electronic device. According to the functions to be implemented, the fault simulation device 100 based on a code probe includes a code construction module 101, a code injection module 102, a fault simulation module 103, and a fault analysis module 104. The functional modules are described in detail as follows:

[0127] The code construction module 101 is used to obtain the payment data link of the fault object to be tested and construct the corresponding fault logic code according to the payment data link;

[0128] A code injection module 102 is configured to inject the fault logic code into the fault object to be tested to obtain a target fault object;

[0129] The fault simulation module 103 is configured to perform a payment fault simulation on the target fault object according to preset payment fault simulation conditions and the fault logic code, and obtain fault response data corresponding to the target fault object;

[0130] The fault analysis module 104 is configured to perform fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report of the target fault object.

[0131] In one embodiment, when executing the construction of the corresponding fault logic code according to the payment data link, the code construction module 101 is used to:

[0132] Constructing a data link topology graph based on the payment data link, performing data parsing on the data link topology graph to obtain node information and edge correspondence of the data link topology graph;

[0133] Constructing a target syntax tree according to the correspondence between the node information and the edges;

[0134] The target syntax tree is converted into fault logic code.

[0135] In one embodiment, when the code construction module 101 performs data parsing on the data link topology graph to obtain the node information and edge correspondence of the data link topology graph, it is configured to:

[0136] Traversing all units with preset flag bits in the data link topology diagram;

[0137] Parsing the unit according to the attribute edge value of the unit to obtain a parsing result;

[0138] The node information and the corresponding relationship of the edges of the data link topology graph are determined according to the analysis result.

[0139] In one embodiment, when injecting the fault logic code into the fault object to be tested to obtain a target fault object, the code injection module 102 is configured to:

[0140] Obtaining call information of an internal function in the fault logic code, and counting the number of calls of the internal function according to the call information;

[0141] Perform function screening on the internal function according to the number of calls to obtain a target function;

[0142] Performing a position structure analysis on the fault object to be tested according to the objective function to obtain a target injection position of the fault object to be tested;

[0143] Setting a detection point at the target injection position according to a preset function probe;

[0144] The fault logic code is injected into the fault object to be tested at the detection point to obtain a target fault object.

[0145] In one embodiment, the fault simulation module 103 performs payment fault simulation on the target fault object according to the preset payment fault simulation conditions and the fault logic code, and obtains fault response data corresponding to the target fault object, including:

[0146] Establishing a dynamic mapping relationship between the fault logic code and a preset payment fault simulation condition, and generating a condition-triggered execution link based on the mapping relationship;

[0147] Performing code execution on the target fault object according to the condition-triggered execution link and the fault logic code to obtain a code execution result;

[0148] The code execution result is monitored according to a preset monitoring probe to obtain fault response data corresponding to the target fault object.

[0149] In one embodiment, when performing fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report of the target fault object, the fault analysis module 104 is configured to:

[0150] Performing data cleaning on the fault response data to obtain target response data;

[0151] Performing data statistics on the target response data to obtain fault analysis indicators;

[0152] Obtain a fault analysis report template corresponding to the target fault object, import the fault analysis indicators into the fault analysis report template, and generate a target fault analysis report.

[0153] In one embodiment, when performing data statistics on the target response data to obtain the fault analysis index, the fault analysis module 104 is configured to:

[0154] Annotating the target response data according to a preset fault classification dimension, and classifying the annotated data according to the fault type to obtain annotated response data;

[0155] Calibrate the labeled response data to correct any possible labeling deviations or errors;

[0156] Perform multi-level aggregation calculations on the corrected labeled response data to obtain fault analysis indicators.

[0157] In the present invention, the specific definition of a fault simulation device based on a code probe can be found in the definition of a fault simulation method based on a code probe above, and will not be repeated here. Each module in the above-mentioned fault simulation device based on a code probe can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0158] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, it realizes the functions or steps on the server side of a fault simulation method based on a code probe.

[0159] In one embodiment, a computer device is provided. The computer device may be a client, and its internal structure diagram may be as follows: Figure 6As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps on the client side of a fault simulation method based on a code probe.

[0160] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0161] Obtaining the payment data link of the fault object to be tested, and constructing a corresponding fault logic code according to the payment data link;

[0162] Injecting the fault logic code into the fault object to be tested to obtain a target fault object;

[0163] Performing payment fault simulation on the target fault object according to the preset payment fault simulation conditions and the fault logic code to obtain fault response data corresponding to the target fault object;

[0164] Performing a fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report for the target fault object.

[0165] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and apparatuses can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For example, the module division is merely a logical function division, and actual implementation may employ other division methods.

[0166] In addition, the functional modules in various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or hardware plus software functional modules.

[0167] Therefore, the embodiments should be considered in all respects as illustrative and non-restrictive, and the scope of the invention is defined by the appended claims rather than the foregoing description, and all changes that come within the meaning and range of equivalents of the claims are intended to be embraced therein. Any reference to a figure in a claim should not be construed as limiting the claim to which it relates.

[0168] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0169] In some implementations of this embodiment, a computer-readable storage medium is provided, on which a computer program is stored, characterized in that when the computer program is executed by a processor, the steps of the method described in the above embodiment are implemented.

[0170] The readable storage medium of the present invention stores a computer program, which, when executed by a processor of an electronic device, can implement:

[0171] Obtaining the payment data link of the fault object to be tested, and constructing a corresponding fault logic code according to the payment data link;

[0172] Injecting the fault logic code into the fault object to be tested to obtain a target fault object;

[0173] Performing payment fault simulation on the target fault object according to the preset payment fault simulation conditions and the fault logic code to obtain fault response data corresponding to the target fault object;

[0174] Performing a fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report for the target fault object.

[0175] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the client side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0176] The computer-readable storage medium may also store at least one computer-executable program / instruction, such as a computer-readable instruction. Computer-readable storage media include, but are not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Computer-readable storage media may include, for example, read-only memory (ROM), a hard disk, a flash memory, etc. For example, a non-transitory computer-readable storage medium may be connected to a computing device such as a computer, and then, when the computing device executes the computer-readable instructions stored on the computer-readable storage medium, the various methods described above may be performed.

[0177] In addition, the computer device may also include (but is not limited to) a data bus, an input / output (I / O) bus, a display, and input / output devices (eg, keyboard, mouse, speaker, etc.).

[0178] The processor can communicate with external devices via an I / O bus via a wired or wireless network.

[0179] In one embodiment, the at least one computer executable instruction may also be compiled into or constitute a software product / computer program product, wherein one or more computer executable instructions are executed by a processor to perform the various functions and / or method steps in the embodiments described in the present technology.

[0180] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0181] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0182] In the embodiments provided in the present disclosure, it should be understood that the disclosed devices and methods may also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram may represent a module, a program segment or a part of a code, and the above-mentioned module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box may also occur in an order different from that marked in the accompanying drawings. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, may be implemented with a dedicated hardware-based system that performs the specified function or action, or may be implemented with a combination of dedicated hardware and computer instructions.

[0183] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

[0184] It should be noted that if software tools or components other than those of our company appear in the embodiments of this application, they are only used for illustration and do not represent actual use.

Claims

1. A fault simulation method based on code probe, characterized in that: The method comprises: Obtaining the payment data link of the fault object to be tested, and constructing a corresponding fault logic code according to the payment data link; Injecting the fault logic code into the fault object to be tested to obtain a target fault object; Performing payment fault simulation on the target fault object according to the preset payment fault simulation conditions and the fault logic code to obtain fault response data corresponding to the target fault object; Performing a fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report for the target fault object.

2. The fault simulation method based on code probe according to claim 1, characterized in that: The constructing of a corresponding fault logic code according to the payment data link includes: Constructing a data link topology graph based on the payment data link, performing data parsing on the data link topology graph to obtain node information and edge correspondence of the data link topology graph; Constructing a target syntax tree according to the correspondence between the node information and the edges; The target syntax tree is converted into fault logic code.

3. The fault simulation method based on code probe according to claim 2, characterized in that: The performing data parsing on the data link topology graph to obtain node information and edge correspondence of the data link topology graph includes: Traversing all units with preset flag bits in the data link topology diagram; Parsing the unit according to the attribute edge value of the unit to obtain a parsing result; The node information and the corresponding relationship of the edges of the data link topology graph are determined according to the analysis result.

4. The fault simulation method based on code probe according to claim 1, characterized in that: The step of injecting the fault logic code into the fault object to be tested to obtain a target fault object includes: Obtaining call information of an internal function in the fault logic code, and counting the number of calls of the internal function according to the call information; Perform function screening on the internal function according to the number of calls to obtain a target function; Performing a position structure analysis on the fault object to be tested according to the objective function to obtain a target injection position of the fault object to be tested; Setting a detection point at the target injection position according to a preset function probe; The fault logic code is injected into the fault object to be tested at the detection point to obtain a target fault object.

5. The fault simulation method based on code probe according to claim 1, characterized in that: The performing payment fault simulation on the target fault object according to the preset payment fault simulation condition and the fault logic code to obtain fault response data corresponding to the target fault object includes: Establishing a dynamic mapping relationship between the fault logic code and a preset payment fault simulation condition, and generating a condition-triggered execution link based on the mapping relationship; Performing code execution on the target fault object according to the condition-triggered execution link and the fault logic code to obtain a code execution result; The code execution result is monitored according to a preset monitoring probe to obtain fault response data corresponding to the target fault object.

6. The fault simulation method based on code probe according to claim 1, characterized in that: The performing fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report of the target fault object includes: Performing data cleaning on the fault response data to obtain target response data; Performing data statistics on the target response data to obtain fault analysis indicators; Obtain a fault analysis report template corresponding to the target fault object, import the fault analysis indicators into the fault analysis report template, and generate a target fault analysis report.

7. The fault simulation method based on code probe according to claim 6, characterized in that: The performing of data statistics on the target response data to obtain fault analysis indicators includes: Annotating the target response data according to a preset fault classification dimension, and classifying the annotated data according to the fault type to obtain annotated response data; Calibrate the labeled response data to correct any possible labeling deviations or errors; Perform multi-level aggregation calculations on the corrected labeled response data to obtain fault analysis indicators.

8. A fault simulation device based on a code probe, characterized in that: The device comprises: A code construction module is used to obtain the payment data link of the fault object to be tested and construct a corresponding fault logic code according to the payment data link; A code injection module, configured to inject the fault logic code into the fault object to be tested to obtain a target fault object; a fault simulation module, configured to perform payment fault simulation on the target fault object according to preset payment fault simulation conditions and the fault logic code, and obtain fault response data corresponding to the target fault object; The fault analysis module is configured to perform fault analysis on the target fault object according to the fault response data to obtain a target fault analysis report of the target fault object.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to perform a fault simulation method based on a code probe as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the fault simulation method based on a code probe according to any one of claims 1 to 7 is implemented.

Images