Method and terminal for data abnormal mounting

Abstract

The application provides a data abnormal mounting processing method and a terminal. The method comprises the following steps: constructing a data abnormal type library for detecting running data; capturing running time data generated by a service in real time; performing classification matching analysis on the captured running time data based on the abnormal data types in the data abnormal type library; and generating corresponding abnormal mounting processing operations based on the analysis results. The application realizes active discovery, accurate identification and automatic disposal of various data abnormalities in the running process by constructing a structured abnormal type library and capturing real-time data and performing intelligent classification analysis at the source of service execution, solves the problems of lag, incomplete coverage and dependence on manual response of traditional detection methods, and improves the efficiency of operation and maintenance and the system security.

Description

Technical Field

[0001] This invention relates to the technical field of abnormal data processing, and in particular to a method and terminal for abnormal data loading. Background Technology

[0002] In current system execution, most automated mounting tools rely on preset exception rules, making it difficult to systematically identify various complex data anomalies generated during system runtime, such as interface state anomalies, logical sequence anomalies, performance feedback anomalies, and business data anomalies. Because both normal and abnormal data are generated simultaneously during system execution, related technologies cannot perform refined data classification and real-time analysis immediately, making it difficult to promptly warn or address deep-seated data-level issues. This results in insufficient testing depth, impacting product quality and security. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a method and terminal for abnormal data mounting, so as to realize real-time detection and automated processing of various data anomalies during runtime.

[0004] A method for abnormal data mounting, the method comprising: Build a library for detecting data anomaly types in runtime data; Capture runtime data generated by business operations in real time; Based on the abnormal data types in the data anomaly type library, the captured runtime data is classified and matched for analysis. Based on the analysis results, corresponding abnormal mounting handling operations are generated.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A terminal for handling abnormal data mounting includes a memory, a processor, and a computer program stored in the memory and running on the processor. When the processor executes the computer program, it performs the following steps: Build a library for detecting data anomaly types in runtime data; Capture runtime data generated by business operations in real time; Based on the abnormal data types in the data anomaly type library, the captured runtime data is classified and matched for analysis. Based on the analysis results, corresponding abnormal mounting handling operations are generated.

[0006] The beneficial effects of this invention are as follows: By constructing a data anomaly type library and capturing runtime data in real time at the execution mount point, and through the systematic definition and classification of anomaly data types, accurate identification and real-time monitoring of various data anomalies during system operation are achieved; based on predefined anomaly data types, the captured data is automatically classified and matched for analysis, and corresponding anomaly handling operations are generated and executed in real time according to the analysis results. Through real-time data capture and analysis, potential logical vulnerabilities, interface anomalies, and performance errors can be discovered and responded to in the first instance; through the automatic triggering of anomaly handling operations, the response efficiency and automation level of operation and maintenance are effectively improved. While ensuring the comprehensiveness and accuracy of data anomaly detection, the stability and security of the system are improved, the cost of manual testing is reduced, and the real-time performance and automation of anomaly handling data are enhanced. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a method for handling abnormal data mounting according to an embodiment of the present invention; Figure 2 A flowchart illustrating the steps involved in detecting runtime data anomalies in games, as provided in this embodiment of the invention. Figure 3 A flowchart for anomaly detection in interface interaction scenarios provided in an embodiment of the present invention; Figure 4 A flowchart for anomaly detection of the logical sequence of a business process provided in an embodiment of the present invention; Figure 5 A flowchart for anomaly detection in business operation performance feedback provided in an embodiment of the present invention; Figure 6 A flowchart for anomaly detection of business logic and data structure compliance provided in an embodiment of the present invention; Figure 7 A flowchart for anomaly detection of system boundaries and data type compatibility provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a terminal for processing abnormal data mounting provided in an embodiment of the present invention; Label Explanation: 1. A terminal for handling abnormal data mounting; 2. A processor; 3. A memory. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] Please refer to Figure 1 A method for handling abnormal data mounting includes steps 110 to 140.

[0010] Step 110: Construct a data anomaly type library for detecting runtime data. For example, create a structured anomaly type library for detecting runtime data. Each anomaly data type is configured with corresponding detection logic rules and feature parameters, and an index relationship is established for persistent storage, forming a scalable and maintainable data anomaly type library.

[0011] Step 120: Capture runtime data generated by business operations in real time. For example, in a test scenario, when the test agent initiates a business instruction, the system deploys a lightweight probe on the mounting end of the business logic execution. This probe synchronously intercepts and copies the complete request context, forming structured runtime data, providing raw input for subsequent real-time analysis.

[0012] Step 130: Based on the abnormal data types in the data anomaly type library, perform classification and matching analysis on the captured runtime data. For example, the analysis engine performs classification and matching analysis on the runtime data, determines one or more possible associated abnormal data types according to preset mapping rules, and the system calls the dedicated detection logic for the corresponding abnormal data type in the data anomaly type library for detection.

[0013] Step 140: Based on the analysis results, generate the corresponding abnormal mounting handling operation. For example, based on the above analysis results, the system generates the abnormal mounting handling operation corresponding to the analysis results.

[0014] As described above, the beneficial effects of this invention are as follows: By constructing a structured anomaly type library, scattered anomaly detection experience is transformed into a systematic and reusable detection data anomaly type library, improving the coverage and professional depth of anomaly identification. By deploying real-time probes at the business execution mounting end, source capture and immediate analysis of runtime data are achieved, shortening anomaly response latency. With the help of a data anomaly type-based classification and matching analysis mechanism, the system can call dedicated detection logic for different anomaly scenarios, realizing the transformation from general rule matching to intelligent triage and judgment, improving detection accuracy and efficiency. Through the automated generation and execution of anomaly handling operations, a complete closed loop from monitoring and analysis to rapid handling is constructed, effectively reducing the cost of manual intervention and improving the automation level and security assurance capabilities of system operation and maintenance.

[0015] Further, step 110 includes step 111.

[0016] Step 111: Associate and store the abnormal data types with their corresponding detection logic to form a data anomaly type library. For example, the system configures dedicated detection logic units for abnormal data types. These units include components such as feature extraction algorithms, rule matching engines, threshold judgment modules, and test scripts. The system establishes a "normal type - detection logic" mapping table to strongly associate and store the two, enabling each abnormal data type to quickly locate and call its corresponding analysis program during detection.

[0017] As described above, by structurally associating and storing abnormal data types with detection logic, a scalable and maintainable abnormal data type library is constructed. This design enables the system to flexibly respond to new types of anomalies and achieve efficient and accurate analysis through modular detection logic, providing a reliable technical foundation for automated anomaly handling.

[0018] Further, step 110 includes steps 112 to 115.

[0019] Step 112: Create a UI exception data type for detecting the interaction state of the interface. For example, the system defines an "Interface Exception Data Type" specifically for monitoring the interaction state of the user interface. This type includes specific exception subclasses such as UI response timeout detection, UI element state verification, and UI rendering integrity verification.

[0020] Step 113: Create a logic exception data type for detecting the execution order and results of logic. For example, the system defines a "logic exception data type" to monitor the integrity of the execution logic of the business process. This type includes subclasses such as timing logic verification, result consistency detection, and state machine compliance checks.

[0021] Step 114: Create a performance anomaly data type for detecting discrepancies in business operation performance. For example, the system defines a "performance anomaly data type" to monitor the visual and data performance of operation feedback. This type includes subclasses such as operation feedback delay detection, visual performance consistency verification, and data synchronization status verification.

[0022] Step 115: Associate and store interface exception data types with interface detection logic, logical exception data types with logical detection logic, and performance exception data types with business detection logic, forming a data exception type library. For example, the system establishes a mapping relationship between "exception type - detection logic" through configuration files or database tables: interface exception types are associated with interface detection logic, which includes: interface automated test scripts and image recognition algorithms; logical exception types are associated with business detection logic, which includes the business process verification engine and time series analysis module; performance exception types are associated with business detection logic, which includes: operation feedback monitors and data synchronization verifiers. These associations are stored in the type library with an extensible structure, supporting dynamic loading and hot updates.

[0023] As described above, by refining the definition of core anomaly data types and establishing a precise mapping between type and logic, a highly targeted anomaly detection system has been constructed. This classification and association mechanism ensures that different types of anomalies can invoke the most suitable detection method. By designing detection logic specifically for anomalies in different dimensions such as interface, logic, and presentation, the limitations of traditional single detection methods in complex anomaly scenarios are avoided. This division of labor and collaboration mechanism enables all types of anomalies to be efficiently identified within the most appropriate detection framework. This improves the accuracy of anomaly detection and the adaptability of the system, providing a clear technical path for subsequent intelligent analysis.

[0024] Further, step 130 includes steps 131 to 133.

[0025] Step 131: Determine the data to be matched based on the relevant business environment in the runtime data. For example, in a test scenario, the analysis engine first parses the business context of the runtime data, including key dimensions such as the currently executing game function module, operation type, and execution stage. Based on these environmental characteristics, the system extracts key data segments that are strongly related to the current business from the raw runtime data as the data to be matched, ensuring that subsequent analysis only targets core data with clear business meaning and avoids interference from irrelevant data.

[0026] Step 132: Match the data to be matched against the abnormal data types stored in the data anomaly type library. For example, based on the business environment identified by the system, a set of potentially relevant abnormal data types is selected from the data anomaly type library, and the detection logic corresponding to each anomaly type is called to match the data to be matched.

[0027] Step 133: Determine whether there are data anomalies based on the matching and comparison results. For example, the system combines the output results of various anomaly detection logics to make a joint judgment to determine whether there are data anomalies. In the case of multiple anomalies coexisting, the system can establish an anomaly correlation graph to analyze the causal relationships between anomalies.

[0028] As described above, by constructing an intelligent analysis chain that moves from business environment awareness to anomaly type matching and finally to multi-dimensional rule-based judgment, a highly efficient mechanism for accurately locating anomalies from massive runtime data has been achieved. Firstly, by extracting key data features based on dynamic business scenarios, the performance overhead of full-scale scanning in traditional methods is avoided. Secondly, through intelligent mapping of the anomaly type library, the most relevant detection strategies are matched for different business scenarios, improving the targeting and effectiveness of anomaly identification. Finally, through cross-validation and joint judgment of multi-dimensional detection logic, the false alarm rate is effectively reduced and the credibility of anomaly diagnosis is enhanced. This layered and progressive analysis architecture not only optimizes system resource allocation but also makes the anomaly detection process highly interpretable and traceable, providing a high-quality data foundation for subsequent automated repair, root cause analysis, and system self-optimization.

[0029] Further, step 132 includes steps 1321 and 1322.

[0030] Step 1321: When the abnormal data type matching the data to be matched is a logical abnormal data type, the actual business logic in the runtime data is compared with the preset expected business logic. For example, in a game item purchase scenario, the logic detection module will extract the actual execution sequence from the runtime data: the player initiates a purchase request, the system payment interface is called, the inventory quantity is deducted, and the item is issued and the transaction is completed. The system will compare the triggering conditions, execution order, state transitions, and result outputs of each step in turn to see if they are consistent with the preset expected business logic. The preset logic includes strictly defined rules, such as "the item cannot be delivered before payment is successful" and "the transaction should fail when inventory is insufficient." The detection module will perform timing verification, state compliance checks, and data consistency comparisons on key nodes to ensure the complete execution of the business logic.

[0031] Step 1322: When the abnormal data type to be matched is an abnormal data type, the actual business performance in the runtime data is compared with the preset expected business performance. For example, in the same item purchase scenario, the performance detection module will simultaneously monitor the visual feedback and data update status of the client interface. Actual business performance includes: changes in the state of the purchase button, a pop-up message indicating a successful transaction, animations updating the quantity of items in the inventory, and real-time updates of the currency balance. The system will compare the collected interface screenshots, control states, data change events, etc., with the preset expected performance library to check whether the visual feedback conforms to the interaction specifications, whether the data updates are synchronized in a timely manner, and whether the animation effects are fully presented. The preset expected performance includes detailed interaction protocols and visual standards to ensure timely feedback and data accuracy for user operations.

[0032] Step 133 includes steps 1331 and 1332.

[0033] Step 1331: If there is a discrepancy between the actual business logic and the expected business logic, a logical data anomaly is determined. For example, when the system detects situations such as "shipping goods without calling the payment interface" or "not updating the database after inventory deduction" in the actual execution sequence, it determines that there is a logical data anomaly. Such anomalies usually correspond to violations of business rules or breaks in the execution chain. The system will record the anomaly type as "process sequence violation" or "state synchronization failure," mark the scope of impact as a business integrity risk, and trigger the corresponding alarm and repair process.

[0034] Step 1332: If the actual interface performance differs from the expected interface performance, an anomaly in performance data is identified. For example, if the system detects that a purchase success notification does not pop up after a successful transaction, the inventory quantity update is delayed beyond a set threshold, or the item icon displays abnormally, the system determines this as an anomaly in performance data. Such anomalies directly affect user experience and data consistency. The system will record the anomaly type as "missing interface feedback" or "data synchronization delay" and generate an alarm notification of the corresponding level according to the preset severity level, driving interface optimization or data synchronization mechanism repair.

[0035] As described above, by independently and collaboratively detecting and judging logical data anomalies and performance data anomalies, a dual quality assurance system covering business rules and user experience has been constructed. Precise verification at the logical level ensures the accuracy and security of core business processes, while meticulous monitoring at the performance level ensures the timeliness and integrity of user interactions. This bidirectional, parallel detection mechanism can comprehensively identify anomalies across the entire chain, from underlying logic to front-end presentation, providing multi-dimensional technical support for quality assurance of complex systems.

[0036] Furthermore, step 130, which involves classifying and matching the captured runtime data, also includes steps 134 to 137.

[0037] Step 134: When analyzing based on abnormal business data types, parse the business process corresponding to the runtime data and obtain the preset data types of key business elements in the business process. For example, in the game item trading process, the system first parses the key business elements in the transaction request, including: transaction amount, item ID, transaction status, and timestamp. The system obtains the strict data type definitions and value range constraints of these elements from the business configuration library, such as the transaction amount must be a positive integer and the item ID must conform to specific encoding rules. This step establishes a benchmark reference system for business data specifications.

[0038] Step 135: Compare the actual data types of key business elements in the runtime data with the preset data types. For example, in the item trading scenario, the detection module will verify one by one: whether the transaction amount is an integer rather than a floating-point number, whether the item ID is a valid string rather than a number, and whether the transaction status is a predefined enumeration value rather than an arbitrary string. Any type mismatch or format violation will be recorded as a potential exception and classified according to the severity according to preset rules.

[0039] Step 136: When analyzing based on generic abnormal data types, replace the original data type of the target business data in the runtime data with at least one extended data type to generate test data. For example, in item purchase testing, the system will select key business parameters for data type transformation testing: the "purchase quantity" field, which should originally be an integer, will be replaced sequentially with various abnormal data types such as floating-point numbers, very large integers, negative numbers, and special characters. Each transformation will generate an independent extended data type, keeping other business parameters unchanged, only modifying the data type and numerical expression of the target field.

[0040] Step 137: Execute the business process based on runtime data containing test data and monitor its performance. For example, the system will inject various types of abnormal data types of test data into the business process sequentially: when using floating-point numbers as the purchase quantity, monitor whether the system performs reasonable type conversion or returns an error message; when using excessively large integers, monitor whether the numerical overflow protection mechanism is triggered; when using negative numbers, monitor whether illegal input is intercepted and a clear error feedback is given; when using strings, monitor whether the type validation mechanism is effective.

[0041] As described above, a dual verification system covering data specification compliance and system boundary robustness is constructed through rigorous validation of abnormal business data types and proactive testing of generic abnormal data types. The former ensures the accuracy and security of business data in normal processes, while the latter tests the system's fault tolerance and security protection level under extreme conditions by proactively constructing abnormal data. This combined detection strategy can both prevent risks from regular data anomalies and proactively discover potential system vulnerabilities, providing multi-layered quality assurance for building stable and reliable business systems.

[0042] Further, step 120 includes step 121.

[0043] Step 121: Capture the input data, process data, and output data associated with the business execution request as runtime data. For example, in a game item purchase scenario, when the test program initiates a purchase request, the mounted probe will synchronously capture the complete data stream: input data includes request parameters such as user ID, item ID, purchase quantity, and payment method; process data includes intermediate processing information such as server-side verification results, inventory query status, payment interface call records, and database transaction logs; output data includes result information such as the final transaction result, item distribution record, interface feedback content, and client status update.

[0044] As described above, a traceable and reproducible runtime monitoring system has been constructed by collecting key data nodes covering the entire request, processing, and response chain. This holographic data capture mechanism not only ensures the integrity and accuracy of anomaly analysis but also provides a solid data foundation for post-event problem localization, performance optimization, and process improvement, achieving a precise mapping capability from apparent anomalies to root causes.

[0045] Further, step 140 includes steps 141 and 142.

[0046] Step 141: If the analysis results indicate an anomaly, acquire the anomaly data and record its detailed information. For example, when the system detects an anomaly in the item purchase process, it will automatically capture the complete anomaly context: including the time of the anomaly, the user account and game character information involved, the anomaly business scenario, the specific anomaly type, a snapshot of the system state when the anomaly was triggered, an assessment of the anomaly's impact scope, and the trajectory of key data changes before and after the anomaly. This information is persistently stored in the anomaly database in a structured format, supporting multi-dimensional queries and statistical analysis.

[0047] Step 142: Based on the anomaly data and pre-defined policy rules, generate and send anomaly alert information including detailed information. For example, the system automatically matches pre-defined handling strategies based on the anomaly type and severity level: for high-risk anomalies, push alerts in real time to the game operation and maintenance monitoring dashboard and the mobile terminals of on-duty personnel, with alert content including anomaly summary, impact assessment, suggested handling solutions, and original data links; simultaneously, automatically create high-priority issue work orders and assign them to the corresponding development teams; for medium- and low-risk anomalies, generate daily reports summarized to the quality management platform and trigger automated repair scripts to attempt self-healing of common problems. All alert information includes a complete access point for anomaly details, ensuring that personnel can quickly locate the root cause of the problem.

[0048] As described above, a structured collection and hierarchical response mechanism for anomaly information enables an intelligent closed loop from anomaly detection to processing and response. This not only shortens the time window from anomaly discovery to handling, but also accumulates valuable data assets for problem analysis, accountability, and system optimization through standardized event logging and strategy execution, thereby improving system maintainability and operational efficiency.

[0049] Furthermore, step 140 is followed by steps 143 and 144.

[0050] Step 143: Archive and store the data anomaly detection process, analysis results, and handling operations. For example, after completing the handling of an item transaction anomaly, the system will automatically generate a complete event archive containing the following dimensions: anomaly triggering environment, anomaly detection timeline, detection method details, analysis depth report, handling measures record, and handling result verification. This archive is stored in the case knowledge base in structured JSON format, with a unique event ID and associated with relevant system logs.

[0051] Step 144: Based on the archived data, update the abnormal data types in the data anomaly type library. For example, when the case library accumulates to a certain size, the system initiates a periodic knowledge extraction process: for frequently occurring similar anomaly patterns, the system automatically extracts their common features and suggests adding a new subtype, "Inventory Synchronization Anomaly"; for false alarm cases in existing detection rules, the system automatically adjusts the threshold parameters of the corresponding detection logic; for newly emerging anomalies that are successfully repaired, the system adds their feature patterns to the detection rule library for the corresponding anomaly type.

[0052] As described above, constructing a complete closed loop for anomaly handling archiving and knowledge evolution enables continuous self-optimization of the detection system. The system follows a virtuous cycle mechanism from detection and handling to learning and optimization: each anomaly handling is transformed into a structured case, becoming systematic knowledge; based on historical data analysis, detection rules and threshold parameters are automatically optimized; and closed-loop feedback continuously improves recognition accuracy and handling efficiency. This transforms scattered experience into reusable detection wisdom, driving the transformation of quality assurance from passive response to proactive prevention. It enables the system to adapt to business changes and technological iterations, providing sustainable and intelligent technical support for the long-term stable operation of complex software systems.

[0053] The data anomaly handling method described above is applicable to various software systems that require automated monitoring and anomaly detection of runtime data, especially in scenarios such as game testing and online transaction systems where data consistency, business logic integrity, and real-time user interaction requirements are high. The following detailed implementation method will illustrate this.

[0054] Please refer to Figure 2 This application can apply the above solution to runtime data anomaly detection scenarios in games, including the following steps: S1. Create a data anomaly type library. Upon system startup, the system first establishes the knowledge base for anomaly detection. Based on testing requirements, the system can selectively predefine and configure various data types, such as interface anomalies, logical anomalies, and performance anomalies, and associate corresponding detection logic and rules with each type, completing the initialization of the core rule base. (Equivalent to step 110)

[0055] S2. Real-time capture of runtime data and matching of exception handling types: When the program executes business instructions, the complete request-response data stream is captured in real time at the business execution endpoint. Subsequently, the analysis engine, based on the business characteristics of the captured data, enters a decision-making chain, sequentially determining "Does UI exception handling need to be handled?", "Does logic exception handling need to be handled?", and "Does performance exception handling need to be handled?". Based on the path of the judgment result, one or more exception data types to be applied in this analysis are determined, such as UI exception data types, logic exception data types, and performance exception data types. This is equivalent to steps 120 and 130.

[0056] S3. Perform classification and matching analysis and complete the process. Based on the determined abnormal data type, the analysis engine calls the corresponding dedicated detection logic in the data abnormality type library to perform in-depth analysis of runtime data. For example, UI status verification is performed for interface abnormalities, step sequence verification is performed for logical abnormalities, and feedback consistency comparison is performed for performance abnormalities. After the analysis is completed, the process ends. If an abnormality is detected, the system will automatically trigger recording, alarm, and other processing operations in this node or related subsequent logic. This is equivalent to steps 130 and 140.

[0057] Through the above application examples, this solution realizes an anomaly mounting and processing flow from the construction of an anomaly type library, real-time data capture, and intelligent classification analysis. It effectively solves the problems of delayed anomaly detection, incomplete coverage, and reliance on manual intervention during system operation. While improving efficiency and system reliability, it enhances the automation and intelligence level of quality assurance.

[0058] Please refer to Figure 3 The following describes in detail the application examples of configuring data types for interface anomalies in this application. Anomaly detection for interface interaction scenarios includes the following steps: S21. Initialize the interface anomaly detection process and check the interface data type. When the system starts the interface anomaly detection task, it first determines the interface elements to be detected and their data types, such as window type, control state, response timeout threshold, etc., and loads the corresponding interface anomaly detection rule base. This is equivalent to step 110.

[0059] S22. Real-time acquisition of interface status data and execution of anomaly detection: During business execution, the system captures runtime data of the interface layer in real time through the mounted probe, including window state, control attributes, event response time, etc. Then, it enters the core judgment chain: checking whether the interface data is abnormal: comparing the collected actual interface data, such as whether the window is visible and whether controls are disabled, with the preset normal state. If the data is abnormal, the abnormal interface behavior is recorded and further analysis is performed; if the data is normal, the system proceeds to verify the interface function response. Then, the system actively triggers an interface refresh command to monitor whether the interface has the expected response, such as redrawing completion and status update. If there is no response, it is determined to be an interface unresponsiveness anomaly, and the process ends; if there is a response, the system proceeds to check data changes. This is equivalent to steps 120 and 130.

[0060] S23. Based on the interface responding, further verify whether the relevant business data is updated synchronously, such as whether the amount is deducted after a successful purchase and whether the quantity of items increases. If the data does not change, it is determined that the data synchronization is abnormal; if the data changes normally, the process ends normally.

[0061] S24. Based on the results of the above judgment chain, the system automatically generates an interface anomaly detection report, recording the anomaly type, such as data anomaly, no response, data asynchrony, etc., the occurrence context, and a detailed snapshot. For detected anomalies, an alarm notification is triggered, a screenshot is archived, or an automatic recovery operation is attempted according to a preset strategy. This step integrates a complete closed loop of anomaly judgment, recording, and response handling. It is equivalent to step 140.

[0062] Through the above embodiments, this solution achieves multi-dimensional automated detection of interface anomalies, from status monitoring and interaction verification to data synchronization checks. This method, through hierarchical judgment logic, can accurately distinguish between different types of interface anomalies such as interface freezing, response delays, and data asynchrony. It effectively solves the problems of traditional interface testing, such as reliance on manual observation, high false negative rates, and difficulty in root cause localization, significantly improving the automation level and detection accuracy of interface layer quality assurance.

[0063] Please refer to Figure 4 The following describes in detail an application example of configuring data types for logical exceptions in this application. The exception detection for the logical sequence of business processes includes the following steps: S31. When the system starts the logic anomaly detection task, it first configures the logic expectation settings for the business process under test, including defining the execution step order, the expected input and output of each step, and the dependencies between steps. This is equivalent to step 110.

[0064] S32. During system execution, runtime data of the business logic is captured in real time through the mounted probe, including key information such as the actual execution status of each step, parameter passing, and result return. Then, a logic matching and verification process is initiated to determine whether the data type matches the expected settings. If they match, subsequent operations are executed according to the preset step sequence; if they do not match, the corresponding backup or termination process is executed based on the exception type. This is equivalent to the preliminary matching analysis in steps 120 and 130.

[0065] S33. Step-by-step execution and result recording verification: The system executes operations sequentially according to the steps of the business process. Perform step one and record its return result to verify whether it matches the expected output of step one; Perform step two and record its return result, verifying whether it matches the expected output of step two and maintains logical consistency with the result of step one; Perform step three and record the returned results to verify whether the final output of the entire business process meets the overall expectations.

[0066] The execution result of each step will be compared with the preset expected result in real time, which is equivalent to the in-depth analysis of the logical abnormal data type in step 130.

[0067] S34. Generate a logic anomaly detection report and trigger handling operations: Based on the comparison between the execution results of each step and the expected settings, the system automatically generates a logic anomaly detection report. If logic anomalies such as disordered step order, inconsistent results, or violated dependencies are found, the system will record the anomaly type, such as timing anomaly, result anomaly, dependency anomaly, etc., the location of occurrence, and detailed context information. For detected logic anomalies, corresponding handling is triggered according to preset strategies: such as interrupting the business process, rolling back the transaction state, sending an alarm notification, or attempting logic repair. This is equivalent to step 140.

[0068] Through the above embodiments, this solution achieves fully automated detection of business process logic anomalies, from expected configuration and real-time execution monitoring to result consistency verification. This method, through strict step sequence control and result comparison mechanisms, can accurately identify various types of logic anomalies such as timing errors, inconsistent results, and missing dependencies. It effectively solves the problem that traditional logic testing relies on static analysis and struggles to cover dynamic execution paths, thus improving the automation level and error location accuracy of business logic layer quality assurance.

[0069] Please refer to Figure 5 The following is a detailed application example of configuring detection logic for abnormal performance data in this application. The abnormal detection for business operation performance feedback includes the following steps: S41. Identify abnormal data types and initialize the detection process: When the system starts the abnormal behavior detection task, it first identifies the data type to be detected, such as interface feedback, data update response, etc. This step is equivalent to step 110.

[0070] S42. Configure expected performance and collect actual performance data. The system determines whether expected performance has been preset. If so, it records the preset expected performance characteristics, such as Performance 1 and Performance 2. If not, it directly proceeds to collect actual performance data. During business execution, the system captures the current result performance in real time through the mounted probe, including the actual status data of Performance 1 and Performance 2. The expected configuration in this step is equivalent to the rule predefinition process, while the actual data collection is equivalent to step 120.

[0071] S43. Performance Comparison and Difference Analysis: The system compares the recorded actual performance with the expected performance to determine if there are any differences. If differences exist, a difference analysis report is output, detailing the specific content and degree of deviation of the performance inconsistencies. If no differences exist, a verification pass conclusion is output. This comparison analysis process is equivalent to the deep matching analysis of abnormal data types in step 130.

[0072] S44. Generate a detection report and complete the processing flow: Based on the difference analysis results, the system automatically generates a performance anomaly detection report. For detected performance differences, the system will record the anomaly type, such as missing interface feedback, data update delay, the degree of difference, and the context of occurrence. Corresponding processing operations will be triggered according to preset strategies, such as interface redrawing instructions, data synchronization compensation, or alarm notifications. This is equivalent to generating and executing the anomaly handling operation in step 140.

[0073] Through the above embodiments, a fully automated detection process for abnormal data is achieved, encompassing type identification, expected / actual performance collection, comparative analysis, and result output and processing. This method, through a precise comparison mechanism between preset expectations and real-time performance, effectively identifies performance-level issues such as abnormal interface feedback and data synchronization delays, thereby improving the system's quality assurance capabilities in user interaction and data consistency.

[0074] Please refer to Figure 6 The following describes a specific application example of the business anomaly data type detection logic in this application. The anomaly detection for business logic and data structure compliance includes the following steps: S51. When the system initiates a business anomaly detection task, it first obtains the type information of the business process to be detected, including metadata such as business function modules, operation types, and associated data interfaces. Then, it determines whether the business type is abnormal. This step identifies whether there are any anomalies such as type definition errors, interface mismatches, or unauthorized functions by comparing the characteristics of the business type with the preset legal business type library. This is equivalent to step 110.

[0075] S52. If the business type is normal, the system enters the normal business process; if the business type is abnormal, the exception handling process is initiated. The system first sets the business data type and defines the type constraint rules for key business elements, such as field type, value range, and format specifications, and then determines whether the data type setting is successful. This is equivalent to collecting business configuration data in step 120 and performing a preliminary analysis of the compliance of the business data type in step 130.

[0076] S53. If the data type setting is successful, the system performs abnormal data type handling, including recording exception details, triggering alarm notifications, attempting automatic repair, or implementing security isolation measures. If the setting fails, the business type is reset, and the system returns to the starting point of the detection process for iterative processing. For normal business type paths, the system executes the normal business process. This is equivalent to the in-depth analysis of abnormal data types in step 130 and the exception handling operations in step 140.

[0077] S54. Regardless of whether exception handling or normal procedures are executed, the system will eventually terminate the detection task and generate a corresponding status report, recording information such as the business type detection results, exception handling measures, or normal execution confirmation. This step completes the closed loop from detection to analysis and final handling, equivalent to the final execution and result archiving of step 140.

[0078] Through the above embodiments, the entire process of detecting abnormal business data types—from type acquisition and verification, data configuration and status judgment, exception handling or normal execution, to result report generation—is automated. This method, through a dual mechanism of business type compliance verification and data type constraint control, can effectively identify problems such as business logic anomalies, data structure violations, and configuration errors, thereby improving the system's security and stability at both the business and data layers.

[0079] Please refer to Figure 7 The following describes in detail an application example of configuring detection logic for generic abnormal data types in this application. The abnormal detection for system boundaries and data type compatibility includes the following steps: S61. When the system starts the generic type exception detection task, it first identifies the generic type exception scenario to be detected and determines the data type boundary conditions and compatibility requirements to be verified. This is equivalent to step 110.

[0080] S62. The system determines whether data type expansion is needed. If so, it performs a data type expansion operation, expanding the target data from its original type, such as INT, to various boundary or unconventional types, such as HEX / String / float. If not, it directly enters the data return waiting state. This is equivalent to the preliminary analysis of data type expansion requirements in steps 120 and 130.

[0081] S63. After performing the extension operation, the system enters a waiting state to monitor whether the extended data type returns successfully. If the extended data is successfully obtained, the actual performance of the extended data type is recorded, such as performance one and performance two, to verify the system's ability to handle non-standard data types. If the acquisition fails, default type data is filled in as an alternative. This is equivalent to the deep matching analysis of generic abnormal data types in step 130.

[0082] S64. Regardless of whether the extended data type is successfully acquired, the system will eventually terminate the detection process and generate a detection report based on the actual execution. For successful extended data type processing, the system compatibility verification result is recorded; for failures, system boundary constraint information is recorded. This is equivalent to step 140.

[0083] Through the above embodiments, this solution achieves fully automated detection of generic abnormal data types, from scenario identification, extended requirement judgment, data acquisition and verification to result recording. By proactively constructing unconventional data types and monitoring system responses, this method can effectively identify data type compatibility issues, boundary condition vulnerabilities, and fault tolerance mechanism defects, thereby improving the system's robustness and security capabilities at the data processing level.

[0084] Please refer to Figure 8 A terminal 1 for handling abnormal data mounting includes a memory 3, a processor 2, and a computer program stored on the memory 3 and running on the processor 2. When the processor 2 executes the computer program, it implements each step of the above-mentioned method for handling abnormal data mounting.

[0085] In summary, this invention provides a method and terminal for handling abnormal data mounting. This method constructs a structured exception type library covering multiple dimensions such as interface, logic, presentation, business logic, and generic types, enabling real-time capture and intelligent analysis of runtime data at the mounting end of business execution.

[0086] The system can automatically adapt corresponding detection strategies based on different anomaly scenarios. For various types of problems commonly encountered in the system, such as UI interaction anomalies, business logic anomalies, and operational performance anomalies, it accurately matches predefined anomaly data types with detection logic to achieve multi-dimensional coverage and refined diagnosis of anomalies. During anomaly analysis, the system automatically selects the applicable anomaly type based on the business characteristics of runtime data and calls the corresponding detection rules for deep matching analysis, thereby accurately identifying the anomaly type and locating the root cause of the anomaly.

[0087] Simultaneously, a dynamic response and knowledge evolution mechanism for anomaly handling has been established. The system automatically triggers corresponding handling operations based on anomaly analysis results, including anomaly logging, alarm notifications, automatic repair, and process intervention, achieving real-time and automated anomaly response. Regarding feature processing, the system employs differentiated analysis strategies for different types of anomalies. For example, logical anomalies focus on the sequence of steps and consistency of results; performance anomalies focus on interface feedback and data synchronization status; and business anomalies verify data structure compliance. Based on the varying degrees of impact of each anomaly type on the system, a tiered response strategy can be implemented to optimize resource allocation and processing priorities.

[0088] Furthermore, throughout the entire anomaly handling process, the system constructs a self-evolving closed loop from case archiving to knowledge optimization. By continuously accumulating anomaly handling cases and extracting feature patterns, the system can dynamically update the anomaly data type library and optimize detection logic and threshold parameters, thereby continuously improving the accuracy and coverage of anomaly detection. This system is suitable for various scenarios with high requirements for system stability and data consistency, such as game testing, online transactions, and real-time communication. By constructing an intelligent anomaly handling system, it effectively improves the quality assurance capabilities and operational automation level of the software system.

[0089] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for handling abnormal data mounting, characterized in that, include: Build a library for detecting data anomaly types in runtime data; Capture runtime data generated by business operations in real time; Based on the abnormal data types in the data anomaly type library, the captured runtime data is classified and matched for analysis. Based on the analysis results, corresponding abnormal mounting handling operations are generated.

2. The method for handling abnormal data mounting according to claim 1, characterized in that, The construction of the data anomaly type library for detecting runtime data includes: Anomaly data types are associated with their corresponding detection logic and stored to form a data anomaly type library.

3. The method for handling abnormal data mounting according to claim 1, characterized in that, The construction of the data anomaly type library for detecting runtime data includes: Create a data type for detecting UI exceptions in the user interface interaction state; Create a logical exception data type for detecting the logical execution order and results; Create a data type for detecting performance anomalies that vary in business operations. The interface anomaly data type is associated with the interface detection logic, the logic anomaly data type is associated with the logic detection logic, and the performance anomaly data type is associated with the business detection logic, thus forming a data anomaly type library.

4. The method for handling abnormal data mounting according to claim 1, characterized in that, The step of classifying and matching the captured runtime data based on the abnormal data types in the data anomaly type library includes: Based on the associated business environment in the runtime data, determine the data to be matched; The data to be matched is compared with the abnormal data types stored in the data anomaly type library; Based on the matching and comparison results, determine whether there are any data anomalies.

5. The method for handling abnormal data mounting according to claim 4, characterized in that, The step of matching and comparing the data to be matched with the abnormal data types stored in the data anomaly type library includes: When the abnormal data type that matches the data to be matched is a logical abnormal data type, the actual business logic in the runtime data is compared with the preset expected business logic. When the abnormal data type to be matched is an abnormal data type, the actual business performance in the runtime data is compared with the preset expected business performance. The step of determining whether there are data anomalies based on the matching comparison results includes: If the actual business logic differs from the expected business logic, then it is determined that there is a logical data anomaly. If the actual interface performance differs from the expected interface performance, then it is determined that there is an anomaly in the performance data.

6. The method for handling abnormal data mounting according to claim 1, characterized in that, The classification and matching analysis of the captured runtime data further includes: When analyzing based on the data type of business exception, the business process corresponding to the runtime data is parsed to obtain the preset data type of the key business elements in the business process; The actual data type of the key business element in the runtime data is compared with the preset data type; When performing analysis based on generic exception data types, the original data type of the target business data in the runtime data is replaced with at least one extended data type to generate test data. The business process is executed based on runtime data containing the test data, and the performance of the business process is monitored.

7. The method for handling abnormal data mounting according to claim 1, characterized in that, The runtime data generated by the real-time capture service includes: The input data, process data, and output data associated with the business execution request are captured and used as the runtime data.

8. The method for handling abnormal data mounting according to claim 1, characterized in that, The process of generating corresponding abnormal mounting handling operations based on the analysis results includes: If the analysis result indicates an anomaly, then acquire the anomaly data and record the detailed information of the anomaly data; Based on the abnormal data and the preset policy rules, an abnormal alarm message including the detailed information is generated and sent.

9. The method for handling abnormal data mounting according to claim 1, characterized in that, After generating the corresponding abnormal mounting handling operation based on the analysis results, the process also includes: Archive and store the data anomaly detection process, analysis results, and processing operations; Based on the archived data, update the abnormal data types in the data anomaly type library.

10. A terminal for handling abnormal data mounting, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement each step of the data abnormal mounting processing method according to any one of claims 1 to 9.

Images