A method and system for closed-loop testing of full-link evidence in MNO asynchronous transaction graphs

Abstract

This invention provides a method and system for closed-loop testing of full-link evidence in an MNO asynchronous transaction graph, relating to the field of communication service testing technology. The method and system include: S1, acquiring a set of business objects from a communication card management system or a vehicle networking service system, wherein the set of business objects includes at least transactionId, postTransactionId, asynchronous request records, message queue messages, callback requests, service status records, and upstream notification records; S2, constructing an asynchronous transaction graph based on the set of business objects, wherein transactionId is used as the primary association key. By acquiring a set of business objects including transaction identifiers, asynchronous request records, message trajectories, status records, and notification behaviors, data scattered across different stages during business execution forms a unified association basis, avoiding the state fragmentation problem caused by a single record perspective, and enhancing the traceability of the entire asynchronous business process.

Description

Technical Field

[0001] This invention relates to the field of communication service testing technology, specifically to a closed-loop testing method and system for full-link evidence of MNO asynchronous transaction graphs. Background Technology

[0002] The field of communication service testing technology mainly involves technologies related to functional verification, link verification, interface verification, protocol verification, performance verification, and stability verification for mobile communication networks, operator business platforms, and vehicle-to-everything (V2X) communication platforms. As mobile network operator services gradually evolve towards distributed architectures, microservice architectures, and asynchronous message-driven architectures, communication service systems typically include multiple heterogeneous modules such as order systems, billing systems, real-name systems, message queue systems, callback systems, and third-party service platforms. These modules achieve business collaboration through asynchronous requests, message delivery, event notifications, and status callbacks.

[0003] Existing communication service testing processes typically revolve around verifying interface return results, log records, or local state changes. During business execution, a large number of cross-stage behaviors rely on manual serial analysis. When faced with business scenarios where asynchronous requests, message passing, state updates, and callback notifications are intertwined, it is easy to only verify the final state while ignoring the intermediate execution processes. For example, while an order status may show as successful, issues such as delayed notifications, duplicate message consumption, or abnormal status update order are difficult to identify in a timely manner. This can easily lead to hidden problems where the result appears normal but risks exist in the business process. Because business data is scattered across multiple storage locations and execution stages, the testing process typically relies on log retrieval, manual comparison, and experience-based judgment to analyze problems. Different personnel have different criteria for judging the causes of anomalies, resulting in low efficiency in locating problems in complex scenarios. Cross-link anomalies often require a long investigation period. At the same time, the existing verification process lacks unified constraints on the state change patterns of different business types. In complex asynchronous scenarios, insufficient test coverage, omissions of key execution stages, or coarse-grained anomaly identification can easily occur. For example, when the business status experiences a brief anomaly recovery, the final result may appear normal, but intermediate state deviations, message backlogs, or missing callbacks may still affect the stability of subsequent business operations, thereby increasing business quality risks and online fault investigation costs. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a closed-loop testing method and system for full-link evidence of MNO asynchronous transaction graphs. It solves the problem that existing communication service testing processes typically focus on verifying interface return results, log records, or local state changes. During business execution, a large number of cross-stage behaviors rely on manual serial analysis. When facing business scenarios where asynchronous requests, message passing, state updates, and callback notifications are intertwined, it is easy to only verify the final state while ignoring the intermediate execution process.

[0005] To achieve the above objectives, the present invention is implemented through the following technical solution: a closed-loop test method and system for full-link evidence of MNO asynchronous transaction graph, comprising the following steps: S1, obtaining a set of business objects in a communication card management system or vehicle network business system, wherein the set of business objects includes at least transactionId, postTransactionId, asynchronous request record, message queue message, callback request, business status record and upstream notification record; S2. Construct an asynchronous transaction graph based on the set of business objects, wherein transactionId is used as the main association key to establish association relationships between entry request nodes, asynchronous status nodes, message delivery nodes, callback nodes, business status nodes and notification nodes, and form a directed transaction graph with time constraints. S3. Generate a set of target evidence nodes based on the business type, and establish corresponding state transition rules, timing constraint rules, and anomaly rules; S4. During the asynchronous business execution process, according to the preset time window and retry strategy, collect multi-source evidence data from the asynchronous request table, message queue, business table, callback interface and notification mirror, and map the multi-source evidence data to the corresponding transaction graph node. S5. Calculate the evidence completeness score based on the target evidence node set and the actual collected evidence nodes; S6. Detect broken nodes that have not reached the target state along the node path of the transaction graph, and generate abnormal attribution labels according to the attribution rules; S7. Output structured test results including evidence completeness score, anomaly attribution results, breakpoint locations, and access control conclusions.

[0006] Preferably, the nodes in the asynchronous transaction graph include at least an entry node, an asynchronous status node, a message delivery node, a processor node, a business status node, and a notification node, and each node includes a status field, a timestamp field, and a source identifier field.

[0007] Preferably, in step S3, a target evidence node mapping relationship is established for different business types, wherein: The recharge service corresponds to at least the entry flow node, asynchronous table status node, message queue node, package table node, and notification node; The real-name registration service should correspond to at least the entry flow node, the asynchronous table status node, the real-name registration callback node, the KYC status node, and the notification node.

[0008] Preferably, the multi-source evidence collection in S4 includes: Poll the state transition information in the asynchronous request table; Monitor message delivery and consumption records in the message queue; Capture request and response messages in the callback interface; Query the final business status in the business table; Record the upstream notification mirror content.

[0009] Preferably, the evidence completeness score in S5 is calculated in the following manner: By assigning different weights to core evidence nodes, business status nodes, asynchronous nodes, and notification nodes, the matching degree between the actual collected evidence and the target evidence is calculated using a weighted average, and a comprehensive score is generated by combining the penalty coefficient for missing key evidence.

[0010] Preferably, the anomaly attribution in S6 includes: When the asynchronous table state fails to transition to the final state, it is attributed to a downstream callback exception. When there are delivery records in the message queue but no state change in the business table, the cause is attributed to abnormal processor consumption. When the business table status has been updated but the notification image is missing, the cause is attributed to a notification sending error.

[0011] Preferred options also include: Construct duplicate callback requests, delayed callback requests, and unknown pipeline callback requests to verify the idempotency of the system's callbacks and detect whether there are duplicate state updates or duplicate notifications.

[0012] Preferably, an MNO asynchronous transaction graph full-link evidence closed-loop testing system includes the following modules: a transaction modeling module, used to acquire a set of business objects and construct an asynchronous transaction graph; The rule generation module is used to generate a set of target evidence nodes and corresponding state rules and time sequence rules based on the business type. The evidence collection module is used to collect multi-source evidence from asynchronous tables, message queues, business tables, callback requests, and notification mirrors according to preset time windows and retry strategies. The integrity assessment module is used to calculate the evidence integrity score based on the target set of evidence nodes and the actual evidence nodes. The anomaly attribution module is used to detect broken nodes in the transaction graph and generate anomaly attribution labels; The access control output module is used to generate release, review, or blocking conclusions based on the evidence completeness score and the abnormal attribution results.

[0013] Preferably, the system further includes a group transaction aggregation module, which is used to aggregate and statistically analyze multiple sub-transactions based on groupTransId, and generate batch task completion results based on the number of successes, failures, and incomplete transactions.

[0014] Preferably, the system further includes an asset recirculation module, which is used to collect abnormal patterns, missing evidence types, timeout links, and high-frequency failure paths generated during the testing process into regression test assets, and dynamically adjust the priority of subsequent tests.

[0015] This invention provides a method and system for closed-loop testing of full-link evidence in MNO asynchronous transaction graphs. It has the following beneficial effects: This invention acquires a set of business objects, including transaction identifiers, asynchronous request records, message trajectories, status records, and notification behaviors, thus forming a unified foundation for data scattered across different stages of business execution. This avoids the state fragmentation caused by a single record perspective and enhances the traceability of the entire asynchronous business process. Combined with a directed transaction association structure with temporal constraints established around the transaction identifier, it enables a continuous path expression from the entry point to state changes, message flow, and result feedback. This allows for the location of anomalies along the business path, reducing the difficulty of troubleshooting state jumps, link breakpoints, and result distortions in asynchronous scenarios. Furthermore, it generates a set of target evidence nodes based on the business type and simultaneously establishes state change relationships, execution sequence relationships, and anomaly judgment criteria. This provides differentiated verification capabilities for different business scenarios, avoiding misjudgments or omissions when unified rules cover complex business scenarios, and improving the accuracy of test results in complex asynchronous transaction scenarios. With adaptability; during business execution, it continuously collects multi-source evidence data by combining preset time ranges and retry behaviors, and maps the collected results to the corresponding positions in the business execution path, so that the testing process shifts from static result verification to dynamic execution verification, enhancing the evidence coverage capability in scenarios of delayed processing, repeated notifications, and cross-link asynchronous collaboration; it forms a completeness evaluation by combining the matching relationship between target evidence and actual evidence, so that the test results are expanded from simple success or failure judgment to process credibility analysis, which is conducive to discovering hidden anomalies, partial execution deficiencies, and problems where the results are normal but the process has deviations; it identifies the positions that have not reached the expected state along the execution path and forms anomaly attribution results by combining business context, so that problem localization shifts from single-point fault judgment to path-level analysis, shortening the problem investigation cycle in complex asynchronous transaction scenarios, and forming a unified access control basis by combining structured output content, enhancing the consistency, interpretability, and cross-business scenario reusability of test results.

[0016] This invention, by acquiring business objects and constructing an asynchronous transaction graph, can clearly depict the transaction relationships and state transitions between heterogeneous modules, enabling visualized tracking of the entire business chain. It generates target evidence nodes and corresponding state and timing rules based on business type, providing clear measurement standards for key nodes and abnormal states during the transaction process, improving the accuracy of judging the integrity of business execution. It collects multi-source data according to preset time windows and retry strategies, including asynchronous tables, message queues, business tables, callback requests, and notification mirrors, achieving comprehensive coverage of the transaction chain and significantly reducing the risk of information omissions due to asynchronous processing and message delays. It combines target nodes with actual collected data to calculate completeness assessment. This system enables quantitative analysis of transaction integrity and anomalies, providing a reliable basis for subsequent anomaly identification. By detecting link breakpoints and generating anomaly attribution labels, it can quickly locate the source of the fault and the abnormal link, reducing troubleshooting time and improving business recovery efficiency. Based on integrity scores and anomaly attribution results, it outputs decisions on release, review, or blocking, achieving dynamic control and risk management of transactions, thereby ensuring the stability and reliability of business execution. The overall processing logic achieves closed-loop management of the transaction link through end-to-end transaction modeling, rule-driven data collection and verification, anomaly identification, and dynamic control, significantly improving the accuracy of business monitoring, the speed of anomaly detection, and processing efficiency. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the main steps of the present invention; Figure 2 This is a system block diagram of the present invention; Figure 3 This is a system flowchart of the present invention; Figure 4 This is a schematic diagram of the main process of the present invention; Figure 5 This is a supplementary schematic diagram of the system of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1: like Figure 1-5As shown, this embodiment of the invention provides a method and system for closed-loop testing of full-link evidence in MNO asynchronous transaction graph, including the following steps: S1, obtaining a set of business objects in a communication card management system or vehicle network business system, wherein the set of business objects includes at least transactionId, postTransactionId, asynchronous request records, message queue messages, callback requests, business status records and upstream notification records; First, the transaction serial number, subsequent transaction serial number, asynchronous request record number, message queue offset sequence number, callback address identifier, business status code, and notification record number are split into fields. During business processing, a log collection program reads user card replacement request data from the business gateway, and a script tool verifies the character length of the serial number in the request message. If the character length is within a preset range, it is considered a valid number. Then, a database retrieval tool queries the related records in the asynchronous request table, message cache table, and business status table. During the query process, index matching is performed according to the "mainstream serial number + time slice" method. For example, if a card replacement business request generates a request record in the first time slice, subsequent time slices... Message queue records and callback records are generated using the association expression R(i) = T(i) + Q(i) + C(i), where R(i) represents the i-th association result, T(i) represents the request log, Q(i) represents the message number, and C(i) represents the callback number. Each parameter is compared using a string hash mapping result. When the mapping difference is within a preset range, they are considered the same business object. Simultaneously, the status codes in the status records are parsed; status code values ​​within the normal range are retained, while those outside the range are marked as abnormal objects. Then, a log mirroring program captures notification records and calculates the difference between the notification trigger time and the business status update time. The time difference is then calculated using... Calculation, where Indicates the time offset. Indicates the notification time. This indicates the state update time. When the time offset is within the preset window range, the object aggregation is completed, and the corresponding business object set result is generated.

[0020] S2. Construct an asynchronous transaction graph based on the set of business objects, wherein transactionId is used as the main association key to establish association relationships between entry request nodes, asynchronous status nodes, message delivery nodes, callback nodes, business status nodes and notification nodes, and form a directed transaction graph with time constraints. First, the entry request node, state change node, message delivery node, callback receiving node, and notification node are structurally decomposed. After receiving the vehicle-to-everything (V2X) service activation, the main stream number and subsequent sub-stream numbers are read through a graph modeling program, and a node identifier set is established. Then, a node association matrix is ​​used to calculate the temporal relationship between each node. The matrix elements are obtained through... The graph is defined as follows: G(i,j) represents the time span between node i and node j, t(i) represents the time of node i's creation, and t(j) represents the time of node j's creation. A directed edge relationship is established when the time span is within a preset asynchronous window interval. For example, if a business request completes its request entry into the database in the previous time slice, sends the message in the next time slice, and receives a callback in the subsequent time slice, then a graph path is established in the order of request node → message node → callback node. Simultaneously, a log analysis program is used to check node status codes. If the status code is in the success range, the path continues downward; if the status code falls into the failure range, path construction is interrupted. During path generation, duplicate nodes also need to be screened using node weight coefficients. Calculate, where N(i) represents the number of node visits. This represents the total number of visits. When the weight of a node exceeds the preset limit, it is determined to be a duplicate node and is removed. Finally, a directed transaction relationship with time direction constraints is established based on the node generation order.

[0021] S3. Generate a set of target evidence nodes based on the business type, and establish corresponding state transition rules, timing constraint rules, and anomaly rules; First, the business category, target state nodes, state transition relationships, and exception rule parameters are categorized and read. In the communication card account opening business scenario, key nodes such as "request acceptance," "message sending," "status update," "callback completion," and "notification return" are extracted through the rule configuration program. A target node set is then established based on the business template, and subsequently, state transition expressions are used. The state is advanced, where S(n) represents the current state value and S(n-1) represents the previous state value. This represents the state change amount. When the state change amount is within the valid range, transitioning to the next state is allowed. For example, if a request's state changes from "Pending" to "Processing," and then further changes to "Completed," the transition sequence is considered valid. Simultaneously, time constraint rules are set using a time window formula. The calculation is performed, where T represents the allowed waiting time, w represents the base waiting time, and k represents the business complexity coefficient. A smaller complexity coefficient is used when the business belongs to a high-frequency short transaction scenario, and a larger complexity coefficient is used when the business belongs to a multi-level callback scenario. Then, the exception rule table is used to match missing states, duplicate states, and reverse order states. If the time order of a node is found to be inconsistent with the rule template, an exception label is marked, and the corresponding target evidence node and rule set result are formed.

[0022] S4. During the asynchronous business execution process, according to the preset time window and retry strategy, collect multi-source evidence data from the asynchronous request table, message queue, business table, callback interface and notification mirror, and map the multi-source evidence data to the corresponding transaction graph node. First, the asynchronous request table, message queue cache, business database, callback interface logs, and notification image cache are parsed. During business operation, a timed collection program performs polling operations according to a preset time window. The polling interval is divided according to the business frequency; a longer polling period is used when the number of requests per unit time is in a lower range, and a shorter polling period is used when the number of requests is in a higher range. Then, a retry counter is used to re-collect unsuccessfully acquired data. The number of retries is calculated using a formula. This indicates that C represents the allowed number of retries, n represents the base retry value, and p represents the business priority coefficient. The coefficient is increased when the business priority is high. In a real-world scenario, for example, if a vehicle-to-everything (V2X) activation service fails to retrieve the callback record on its first attempt, it will request the interface log again in the next time slice and read the callback response content. Then, a field mapping program will be used to map the collected data to graph nodes. The method generates mapping key values, where ID represents the business flow identifier and Time represents the node generation time. The mapping is completed when the generated key value matches the key value of the graph node. At the same time, the status field in the collected data is numerically converted. The status value is retained when it is in the normal status range and an abnormal status mark is recorded when it is in the abnormal status range, thus forming the multi-source evidence data result of the corresponding node.

[0023] S5. Calculate the evidence completeness score based on the target evidence node set and the actual collected evidence nodes; First, the number of target evidence nodes, the actual number of collected nodes, and the node validity parameters are broken down. After the business execution is completed, the target node set and the collected node set are read through a statistical program, and the node number, status code, and timestamp information are compared item by item using matching rules. For example, if an asynchronous business theoretically requires four types of evidence—request nodes, message nodes, callback nodes, and notification nodes—but only the first three types of nodes are actually obtained, then the missing nodes are marked as empty nodes. Subsequently, the completeness calculation expression is used. A scoring system is implemented, where P represents the completeness score, M represents the number of valid data collection nodes, N represents the number of target nodes, and K represents the node reliability coefficient. A higher reliability coefficient is used when a node originates from a database master record, and a lower reliability coefficient is used when a node originates from a cached image. Abnormal nodes are deducted, and the deduction value is determined by... Calculation, where This represents the impact value of a single abnormal node, where n represents the total number of nodes. When the deduction result exceeds the preset threshold range, the final score is reduced. In the vehicle network card opening scenario, if the notification node is missing and the callback node time is abnormal, the score is corrected proportionally, and the final evidence completeness result is generated.

[0024] S6. Detect broken nodes that have not reached the target state along the node path of the transaction graph, and generate abnormal attribution labels according to the attribution rules; First, the node paths, target state values, path relationships, and anomaly attribution rules are read. After the graph operation is complete, the path traversal program checks the state changes of each node in chronological order. If a node fails to enter the preset target state, it is recorded as a suspected breakpoint. For example, if a service has completed request reception and message sending but no callback record has been generated, the breakpoint is marked between the message node and the callback node. Subsequently, the path difference formula is used to... Deviation calculation is performed, where L(i) represents the deviation value of the i-th node, S(t) represents the target state value, and S(a) represents the actual state value. When the deviation value is within the abnormal range, the attribution process is initiated. Then, the abnormal rule table is called to analyze the source of the break. If the message node exists but the business state is not updated, it is determined to be a business processing abnormality; if the message node is missing, it is determined to be a message delivery abnormality. Simultaneously, node timeout is detected, and the timeout duration is determined by... Calculate, where ΔT represents the timeout duration. Indicates the end time. This indicates the start time. When the timeout duration exceeds the rule window, a timeout label is generated, and corresponding exception label results are generated based on the attribution rules.

[0025] S7. Output structured test results including evidence completeness score, anomaly attribution results, breakpoint locations, and access control conclusions.

[0026] First, the integrity score, anomaly attribution labels, breakpoint locations, and access control judgment parameters are read. After the test, the results are integrated to summarize the graph analysis data, and structured fields are generated based on the node status and score results. For example, the integrity score is mapped to a level range; when the score is in the high range, it is marked as a pass state, and when the score is in the low range, it is marked as an interception state. Then, the access control judgment expression is used. The results are judged, where J represents the access control judgment value, P represents the integrity score, E represents the number of anomalies, α represents the scoring weight coefficient, and β represents the anomaly deduction coefficient. Each coefficient is set based on historical business statistics. For example, when the proportion of complete link business in the historical sample is high, the scoring weight value is increased, and when the number of abnormal business increases, the deduction coefficient value is increased. In actual vehicle network business scenarios, if the integrity score of a certain business is in the normal range but there are multiple timeout anomalies, the access control result is corrected again using the deduction formula, and the path where the broken node is located, the anomaly label number, and the final judgment field are output to the structured test report result.

[0027] The nodes in the asynchronous transaction graph include at least an entry node, an asynchronous status node, a message delivery node, a processor node, a business status node, and a notification node. Each node includes a status field, a timestamp field, and a source identifier field.

[0028] When decomposing nodes based on the field relationships of various types of nodes in the asynchronous transaction chain, the source identifier field in the entry-side record is read first, and a first time sequence is formed according to the business acceptance time. Then, the status field in the asynchronous status record is extracted using a log collection tool. The entry-side transaction number and the asynchronous status number are compared character-wise. When the character matching length reaches a preset proportion range, a first association is established. The character matching proportion can be set between 80% and 95%. When the number of overlapping characters is lower than the lower limit of the range, it is marked as abnormal source data. Subsequently, the timestamp field in the message delivery record is called to calculate the time difference between the entry record time and the message sending time. The time difference calculation formula is as follows: ,in Indicates the message sending time. Indicates the entry record time, if If the data is within the preset buffer time interval, the corresponding node association is retained. If it exceeds the interval, it is transferred to the verification set. For example, if a recharge request generates a message delivery record within a few seconds after being recorded at the entry point, it is considered a valid message flow. Then, the processing status value in the processor node is read, and a status mapping is performed through the status transition table to convert the string status into a numerical status code, such as a value within the corresponding numerical range during processing. After establishing the correspondence, the result identifier in the business status node is read, and an association operation is performed between the processor node number and the business status node number. The association coefficient can be... ,in Indicates the number of valid fields. The target number of fields is represented by w, which represents the field weight coefficient. The weight coefficient is divided into different intervals according to the importance of the fields. For example, the time field has a higher weight than the source field. Finally, a complete asynchronous transaction graph is formed based on the sending records in the notification nodes, and the graph retains the status field, timestamp field, and source identifier field of each node.

[0029] In step S3, target evidence node mapping relationships are established for different business types, wherein: The recharge service corresponds to at least the entry flow node, asynchronous table status node, message queue node, package table node, and notification node; First, extract the transaction number, business source number, and creation time from the inbound transaction records, and sort them according to creation time to form the first transaction set. Then, read the status change records in the asynchronous status table, and perform a line-by-line matching based on the transaction number. When the matching success rate is within a preset ratio range, establish an asynchronous association relationship. The matching success rate can be expressed by the formula... The calculation is performed, where m represents the number of successfully matched records and n represents the total number of records to be matched. If P is lower than the lower limit of the set range, the corresponding record is transferred to the manual verification queue. For example, if an asynchronous status update record is generated shortly after a recharge order is generated, the two are considered to belong to the same transaction chain. Subsequently, the message delivery time, message number, and consumption status are extracted from the message queue, and the message delay value is calculated. The delay value formula is... ,in Indicates the message consumption time. This indicates the message delivery time. If the delay value is within a preset time interval, the current link is retained; otherwise, an abnormal message node is marked. Then, package change records in the package table are read, and a relationship is established between the user ID and the recharge transaction number. The business execution order is calculated based on the package update time. For example, if a package change record appears within an adjacent time interval after a successful recharge, the package table node is added to the current graph. Next, the notification sending status and notification time are extracted from the notification node, and a cross-comparison is performed using the sending number and the entry transaction number. The cross-comparison coefficient can be... Calculate, where 'a' represents the ID matching value and 'b' represents the time matching value. This represents the corresponding weight coefficient. The weight coefficient is divided into different ranges based on the stability of the field, ultimately forming a mapping relationship between the entry flow node, asynchronous table status node, message queue node, package table node, and notification node corresponding to the recharge business.

[0030] The real-name registration service should correspond to at least the entry flow node, the asynchronous table status node, the real-name registration callback node, the KYC status node, and the notification node.

[0031] First, extract the application number, user ID, and acceptance time from the entry transaction record, and form a sequential queue according to the acceptance time. Then, read the status change field from the asynchronous status table, and perform item-by-item character matching between the application number and the status number. When the character matching ratio is within a preset range, establish a first mapping relationship. The character matching ratio can be divided into different ranges based on the field length; for example, a higher matching ratio range is used when the field length is longer. Subsequently, read the callback time, callback status, and callback source from the real-name callback record, and calculate the callback delay value. The formula for the callback delay value is... ,in Indicates the time when the callback is generated. This indicates the entry processing time. When R is within a preset time range, the callback node is included in the current real-name authentication process. For example, if a real-name application is submitted and a callback is received from the real-name authentication platform within an adjacent time interval, the current callback is considered to belong to the corresponding real-name application. Then, the authentication result, status update time, and review number in the KYC status record are read, and a correlation is established between the review number and the real-name callback number. The correlation strength can be determined using... Calculation, where Indicates the degree of matching of the numbers. Indicates the proximity of time. The system represents the consistency of the status. Each parameter is assigned a value according to the preset scoring range. Then, the notification sending time and notification status in the notification node are read. The time difference between the notification time and the KYC status update time is calculated. When the time difference is within the set range, a notification association relationship is established. If it exceeds the range, it is transferred to the abnormal pending verification set. Finally, a corresponding mapping relationship is formed between the entry pipeline node, asynchronous table status node, real-name callback node, KYC status node and notification node.

[0032] The multi-source evidence collection in S4 includes: Poll the state transition information in the asynchronous request table; First, a state transition mapping table is established based on the order processing scenario. The request initiation state, processing state, and completion state are associated with a unique identifier field, a timestamp field, and a source node field, respectively. Then, change records in the state cache are read at a fixed polling cycle. In one embodiment, the state number can be read at a minute-level cycle. When the state number in two consecutive reads is inconsistent, the corresponding state change time is extracted to form a state transition sequence. Finally, the state transition interval formula is used... The time interval between adjacent states is calculated, where ΔT represents the migration interval value, Tn represents the timestamp of the current state, and Tn-1 represents the timestamp of the previous state. When a migration interval is within a preset time interval, it is marked as normal migration data. When the migration time exceeds a preset baseline interval, it is classified as delayed migration data. The preset baseline interval is generated based on the statistical results of historical request samples, for example, by extracting multiple historical request records and calculating the average migration time. Where μ represents the average migration time, Σ represents the summation sign, ti represents the time taken for the i-th state transition, and n represents the number of samples. A state determination threshold is then generated by multiplying the average value by a fluctuation coefficient. In specific calculations, the average migration time can be taken to be approximately several seconds, and the fluctuation coefficient can be taken to a value close to one, thus forming the corresponding migration determination range. Subsequently, the state change records are sorted and associated, and all state change nodes under the same request identifier are extracted. The state sequence completeness formula is then used to determine the threshold. Calculate the integrity rate, where K represents the state integrity rate, m represents the number of state nodes acquired, and M represents the preset total number of state nodes. When the integrity rate is within the preset ratio range, record the corresponding state transition information.

[0033] Monitor message delivery and consumption records in the message queue; First, the message sending identifier, delivery time, consumption time, and consumption node number are extracted in the message middleware environment, and a message chain correspondence is established. In a certain order synchronization scenario, the delivery and consumption logs in the message queue are read in real time by the listening component. The sending record and consumption record corresponding to the same message number are matched, and then the message delay calculation formula is applied. Message processing latency is calculated, where L represents the message latency value, Tc represents the consumption timestamp, and Ts represents the delivery timestamp. Messages with latency values ​​within a preset time range are classified as normal messages, while those exceeding a preset range are classified as abnormal messages. This preset time range is obtained through historical queue throughput statistics, for example, by selecting message processing samples from multiple time periods, calculating the average processing time, and then generating a dynamic threshold based on a message backlog coefficient. The message backlog coefficient is generated based on the ratio of queue length to the number of processing threads, calculated using the formula Q = N / P, where Q represents the backlog coefficient, N represents the number of messages to be processed in the queue, and P represents the number of processing threads. A lower Q range corresponds to a low-load state, while a higher Q range corresponds to a high-load state. In specific implementations, the low-load range can be set to a near-single-digit percentage, and the high-load range to a near-tens-digit percentage. Subsequently, consumption failure records are repeatedly statistically analyzed, and the abnormal proportion is calculated using the failure rate formula F = a / b, where F represents the failure rate, a represents the number of failed messages, and b represents the total number of messages. Finally, a record linking message delivery and consumption is formed.

[0034] Capture request and response messages in the callback interface; First, a message capture module is deployed at the callback interface. This module extracts the request number, request parameters, return code, and processing time fields from both the incoming request data packet and the returning response data packet. In a payment notification scenario, the system reads the order number and amount fields from the interface request and simultaneously records the status code in the response message. When a request message enters the interface, the system extracts the field length, field type, and field order according to message parsing rules, and then applies the field matching rate formula. Calculate message integrity, where R represents integrity rate, u represents the number of successfully matched fields, and v represents the number of standard fields. A message is considered valid when the integrity rate is within a preset range. Then, the response time formula is applied. The interface processing time is calculated, where S represents the interface timeout, Tr represents the response return time, and Tq represents the request reception time. The interface timeout threshold is generated based on historical interface access records. For example, the average timeout is calculated after extracting interface response data from multiple time periods, and a floating range is formed by combining it with the network fluctuation coefficient. The network fluctuation coefficient is generated by calculating the number of request packet retransmissions and the total number of transmissions. When the retransmission ratio is in a lower range, it corresponds to a stable network state, and when the retransmission ratio enters a higher range, it corresponds to a fluctuating state. Then, the returned status codes are classified and statistically analyzed, and the interface numbers that have consecutively abnormal status codes are recorded in the abnormal list. Finally, the association result of request messages and response messages is generated.

[0035] Query the final business status in the business table; First, based on the business number, the processing status field, update time field, and associated transaction field are extracted from the business data table, and the relationship between business status changes is established. In a logistics order processing scenario, by querying the order status number and fulfillment record number in the business table, all business statuses corresponding to the same order are sorted. Then, the status consistency formula is used. Calculate the business consistency rate, where C represents the consistency rate, x represents the number of matched states, and y represents the total number of states. A business state record is considered valid when the consistency rate is within a preset range. Then, the update time is read and calculated according to the time difference formula. The business processing time is calculated, where D represents the processing time, Te represents the end time, and Tb represents the start time. The processing time benchmark is formed based on historical business samples, such as taking the average of the processing cycles of multiple historical orders. Then, a dynamic benchmark range is generated by combining the business complexity coefficient. The business complexity coefficient is calculated based on the number of order-related subtasks and the number of standard tasks. When the complexity coefficient is in a lower range, it corresponds to a normal business document. When the complexity coefficient enters a higher range, it corresponds to a complex business document. Then, the final status field is encoded and verified, and the correspondence between the status number and the business result is checked according to the status code mapping table to finally form the business status query result.

[0036] Record the upstream notification mirror content.

[0037] First, a mirror acquisition module is deployed on the upstream notification channel to synchronously copy the request number, notification time, notification parameters, and signature field in the notification message. In a certain inventory synchronization scenario, after the upstream system sends an inventory change notification, the mirror module synchronously records the notification content and writes it to the mirror cache. Then, it extracts the inventory number, change quantity, and time fields according to the field parsing rules, and then applies the mirror consistency rate formula. The completeness of the notification is calculated, where G represents the mirror consistency rate, p represents the number of successfully mirrored fields, and q represents the total number of standard fields. A mirrored record is considered valid when the completeness falls within a preset range. Then, the data difference formula is used... The notification value deviation is calculated, where E represents the deviation value, A represents the quantity value in the upstream notification, and B represents the quantity value in the local record. When the deviation value is in a lower range, it corresponds to consistent data, and when the deviation value enters a higher range, it corresponds to abnormal data. The deviation range is obtained based on historical notification sample statistics. For example, the average deviation value is calculated for inventory synchronization records within multiple periods, and a deviation threshold is formed by combining it with the volatility coefficient. The volatility coefficient is generated based on the number of changes per unit time and the total number of notifications. Then, the mirrored content is archived according to the notification time order, and the number of duplicate notifications with the same notification number is counted, finally forming the notification mirrored record content.

[0038] The evidence completeness score in S5 is calculated as follows: By assigning different weights to core evidence nodes, business status nodes, asynchronous nodes, and notification nodes, the matching degree between the actual collected evidence and the target evidence is calculated using a weighted average, and a comprehensive score is generated by combining the penalty coefficient for missing key evidence.

[0039] Based on the evidence node classification and assignment rules, the core record items, status transition items, asynchronous interaction items, and notification record items in the business chain are layered and decomposed. First, the log collection program reads the corresponding field content from the order processing system, asynchronous scheduling system, and message middleware. Then, the business transaction number, status identifier code, timestamp, and node source identifier are extracted through the field mapping table. Each node is written into the scoring cache table according to its business priority level. Core nodes are assigned a weight range close to full, business status nodes are assigned a middle weight range, asynchronous nodes are assigned a low weight range, and notification nodes are assigned the lowest weight range. Subsequently, the matching program compares the number of nodes, field completeness rate, and time consistency rate in the target evidence set with those in the actual collection set. For example, if an order process is pre-defined to have multiple core nodes, multiple asynchronous nodes, and multiple notification nodes, and the system detects that some asynchronous nodes are missing, it first uses the field completeness rate formula... Calculate the single-node matching value, where This represents the matching rate of the i-th type of node. Indicates the actual number of fields collected. This indicates the number of target fields, and then the comprehensive weighted formula is applied. Calculate the completeness result, where This represents the weight parameters of each node, λ represents the missing penalty coefficient, q represents the number of missing key nodes, and the summation symbol ∑ represents the cumulative summation of all node types. In actual execution, the data processing program sets the weight of core nodes in the high range, asynchronous nodes in the medium-low range, and notification nodes in the low range. When a missing key business signature field is detected, the penalty coefficient is automatically increased. For example, after the number of missing business transaction fields increases, the system increases the penalty value according to the number of missing fields. Then, the scoring program outputs the comprehensive scoring result and writes it into the anomaly analysis table.

[0040] The anomaly attribution in S6 includes: When the asynchronous table state fails to transition to the final state, it is attributed to a downstream callback exception. Based on asynchronous state transition records, the state fields, callback reception time, and final state identifier in the asynchronous processing table are broken down item by item. First, the task scheduler periodically reads the processing state records from the asynchronous business table. Then, the state verification module compares the current state value with the target state code in the final state mapping table. The asynchronous state fields are then used to generate a state trajectory sequence in chronological order. When the system continuously detects that the state trajectory remains in an intermediate state range, it records the corresponding business transaction number, last update time, and callback source address. This is combined with a timeout threshold for state verification. The timeout threshold is generated based on the historical average callback time. Perform calculations. Indicates the timeout threshold. ∑ represents the historical callback time of the i-th time, k represents the number of statistical samples, β represents the floating coefficient, and the summation symbol ∑ represents the cumulative historical time. In actual execution, the monitoring program counts the callback time data in multiple business cycles and then generates a threshold range according to the offset ratio. When the current record continuously exceeds the range and the status field does not enter the final state number range, the system checks the HTTP status code, return time, and signature field in the callback receiving log through the log parsing program. For example, if the business status of a certain payment asynchronous process remains in the processing interval for a long time, and there is no successful record in the callback receiving log, the attribution module will classify the abnormal record into the downstream callback abnormal category and write it to the abnormal attribution result table simultaneously.

[0041] When there are delivery records in the message queue but no state change in the business table, the cause is attributed to abnormal processor consumption. Based on the relationship between message delivery records and business status change records, the delivery sequence, consumption time, and business table status fields in the message queue are broken down item by item. First, the message monitoring program reads the delivery number, message subject, consumer identifier, and consumption confirmation code from the message queue log. Then, the business status verification program retrieves the corresponding status change record in the business table based on the business sequence number and establishes a time-related sequence based on the status update time and message delivery time. When the system detects that there is a valid delivery record in the message queue but the business status field remains in the initial range, it first determines whether the consumer has completed the consumption action by checking the consumption confirmation field. Then, it calls the consumption log parsing module to read the exception stack, thread return code, and transaction commit identifier. For example, in a certain order processing flow, the message queue already has a successful delivery marker, but the business status field has not changed at all, and the consumption log has a transaction rollback record. In this case, the system calculates the exception level value based on the number of consumption failures and the duration of status dwell. The exception level adopts... The calculation is performed, where R represents the anomaly level value, a represents the number of consumption failures, b represents the state dwell time, c represents the failure count weight, d represents the dwell time weight, and z represents the normalization coefficient. Subsequently, the anomaly attribution program classifies the record into the processor consumption anomaly category and writes it into the consumption anomaly index table.

[0042] When the business table status has been updated but the notification image is missing, the cause is attributed to a notification sending error.

[0043] Based on the correspondence between business status update records and notification mirror records, the status change field in the business table, notification sending logs, and mirror storage records are broken down item by item. First, the status synchronization program reads the latest status number, update time, and operation source identifier from the business table. Then, the notification verification module retrieves the sending record in the notification sending system and the mirror identifier field in the mirror storage table based on the business transaction number. A correlation window is established between the business status update time and the notification sending time, and synchronization verification is performed based on the time deviation interval. This time deviation interval is generated based on historical notification sending time statistics. The calculation is performed, where ΔT represents the allowable time deviation value. denoted by , p represents the number of times the notification was sent, γ represents the offset correction amount, and the summation symbol ∑ represents the cumulative value of all historical sending times. In actual execution, the log program counts the sending times in multiple notification cycles and then generates an allowable deviation range based on the business scenario. When the status field of the business table has entered the completed state range, but the corresponding mirror number is not found in the mirror storage table, and the notification log contains a sending failure code or no return record, the system further checks the notification address, signature field, and number of retries. For example, if the status of a certain business process has been updated to the completed state, but the notification mirror table remains empty and the notification sending log contains timeout records, the attribution program will classify the abnormal record into the notification sending abnormal category and write it into the notification abnormal registration table.

[0044] Also includes: Construct duplicate callback requests, delayed callback requests, and unknown pipeline callback requests to verify the idempotency of the system's callbacks and detect whether there are duplicate state updates or duplicate notifications.

[0045] Based on the callback request processing records and serial number management content, the received historical callback records are disassembled and categorized according to the callback time identifier, request source identifier, serial number field, and status change field. Then, the log management tool is used to read the request data within the corresponding time interval. Multiple callback requests corresponding to the same serial number are arranged in chronological order of receipt time. For data groups with duplicate request identifiers, a callback count method is used for processing, where the callback count is denoted as […]. The total number of requests is recorded as The repetition rate is denoted as When a transaction number appears more than a preset interval within a preset time window, it is marked as a duplicate callback data group. In actual business scenarios, taking payment order callbacks as an example, if the same order number generates multiple status notifications in a short period of time, the order status field in the database is read, and the first status update time, current status value, and notification count parameters are extracted. Status identification is completed by comparing whether the status codes before and after are consistent. If the status code has not changed, the duplicate status writing behavior is recorded. For delayed callback requests, the time difference between the request generation time and the callback reception time is read, and the time difference parameter is set to... ,in Indicates the callback receiving time. This indicates the request sending time. When the time difference is within a preset delay interval, it is classified as a delayed callback request. In the example, if the normal callback time of a payment platform is within a short time interval, and a request returns after exceeding the preset time interval, it will be included in the delayed queue for processing. Simultaneously, the system reads the set of transaction numbers in the current transaction log table and performs a set matching operation on the newly received transaction numbers. Let the system's registered transaction set be... The current callback sequence number is ,when If the request is found to be an unknown transaction callback, the frequency of the unknown transaction within the specified time interval is then counted, and the number of status updates and notification pushes is recorded. By reading the sending record number in the message notification log, the number of notifications associated with the same transaction number is accumulated. If the accumulated notification value exceeds the preset range, the duplicate notification behavior is recorded. At the same time, the number of duplicate status updates is counted according to the update count in the status update record, and the association verification is completed according to the change time order in the status change table. Finally, the abnormal record result corresponding to the callback type is formed.

[0046] A closed-loop testing system for full-link evidence of MNO asynchronous transaction graph includes the following modules: a transaction modeling module, used to acquire a set of business objects and construct an asynchronous transaction graph; Based on the reading and association mapping of business object collections, the system first extracts the order number, user identifier, request serial number, message topic number, and callback identifier fields from asynchronous transactions through the log management platform. Then, it performs a unified field conversion on data from different sources, recording the order number field as... The user identifier field is denoted as The message log field is recorded as Subsequently, a node association table was established according to time sequence. Database query tools were used to read and associate message sending records, asynchronous status records, and notification records corresponding to the same order number, and the number of nodes in the same business chain was recorded as follows: The node association rate is denoted as ,in This indicates the number of successfully associated nodes. When the association rate is within a preset range, a corresponding business graph node is established. In a real-world scenario, taking payment transaction business as an example, after the system reads the order creation record, it continues to read payment notification data and callback notification data from the message queue, using a timestamp difference formula... Sort the time relationships between the nodes, where Indicates the time of the next node. This indicates the time of the previous node. When the time difference exceeds a preset interval, the corresponding node is marked as an abnormal delay node. Simultaneously, nodes are categorized according to the business object type. If a node belongs to an order node, notification node, or callback node, it is written to different association tables respectively. Then, the status values ​​of each node are read and a node relationship matrix is ​​generated. Let the node status value be... The state difference is When the state difference is not within the preset range, the state abnormal relationship is recorded. In the example, if the order status has been updated but the notification node status is still in the initial range, a broken edge relationship is formed in the graph. Then, a complete link structure is generated based on the time order, status order and transaction number order between nodes, and the corresponding asynchronous transaction association result is output.

[0047] The rule generation module is used to generate a set of target evidence nodes and corresponding state rules and time sequence rules based on the business type. Based on business type classification and rule mapping, the transaction category field, node identifier field, and status code field in the business configuration file are first read. A rule index table is then built according to the business category, and the business category is recorded as... The number of state rules is denoted as The number of time sequence rules is denoted as Then, the rule management tool reads the state transition sequence corresponding to different business categories. For example, the order payment business corresponds to the sequence of "creation, payment, notification, callback," and writes each state node into the rule set according to a preset sequence number. Let the state sequence number be... If the sequence number of a later state is less than that of a previous state, a state reversal anomaly is recorded. In a real-world scenario, when the payment completion state appears before the order creation state, a re-verification is performed based on the state timestamp. Subsequently, the time interval between each node is calculated, assuming the node interval is... ,in Indicates the time of the next node. This represents the time of the previous node. When the time interval is in the lower range, it is classified as normal time-series data. When the time interval exceeds the preset upper limit, a delay rule anomaly is recorded, and the rule weight parameter in the business table is read. Let the weight of the status rule be... The weight of the time sequence rule is The comprehensive rule value is denoted as ,in and Based on the historical anomaly proportion allocation, in the example, if the proportion of time-series anomalies in the historical anomalies is large, the weight value of the time-series rule is appropriately increased. Then, the target node set is numbered, and a rule mapping relationship is established according to the node order, finally generating the corresponding state rule and time sequence rule results.

[0048] The evidence collection module is used to collect multi-source evidence from asynchronous tables, message queues, business tables, callback requests, and notification mirrors according to preset time windows and retry strategies. Based on asynchronous data source reading and time window management, the data acquisition platform first connects to the asynchronous record table, message cache queue, business database, and callback log file. It then reads the transaction number, status value, timestamp, and notification number fields from each data source and establishes a unified collection index. The total amount of collected data is set to... The effective data volume is Efficiency is recorded as When the effectiveness rate is below a preset range, a data missing anomaly is recorded. Subsequently, the data is read in segments according to the time window parameter, where the time window width is set to... The window start time is The end time is ,satisfy In actual business scenarios, when the order callback time and the message notification time fall within the same time window, they are included in the same collection batch, and repeated collection is performed according to a preset number of retries. Let the number of retries be... The maximum retry threshold is ,when If the notification image data is not obtained on the first attempt, the notification log will be read again after a preset time interval. The fields of the two collection results will be compared, with a field consistency rate of 100%. ,in Indicates the number of consistent fields. This indicates the total number of fields. When the consistency rate is in a low range, the corresponding data is marked as an abnormal collection record. At the same time, the consumption offset in the message queue is read, and the data in different time periods is checked for order. If the offset order is not continuous, the queue discontinuity information is recorded. Then, the associated data in the asynchronous table, message queue, and notification mirror are archived in a unified manner according to the serial number, and the corresponding multi-source evidence data results are output.

[0049] The integrity assessment module is used to calculate the evidence integrity score based on the target set of evidence nodes and the actual evidence nodes. Based on the target node matching and scoring calculation, the target node numbers in the rule set and the actual collected node numbers are first read, and a node matching table is established. Let the total number of target nodes be denoted as . The actual number of nodes is denoted as The number of matched nodes is denoted as The score for completeness of evidence is recorded as follows: ,in This indicates the number of nodes that simultaneously satisfy both the state and time rules. In practical business scenarios, taking payment link detection as an example, if the target node includes order creation, payment confirmation, notification sending, and callback records, but notification nodes are missing during the actual data collection process, the completeness score is recalculated according to the proportion of missing nodes. Simultaneously, the weight parameters corresponding to each node are read, assuming the node weight is... Weighted score is recorded as ,in This represents the matching result of a single node. When a key node fails to match, its corresponding weight value is in a higher range. In the example, if the payment confirmation node is a key node, its weight value is higher than that of a regular notification node. Subsequently, a consistency comparison is performed on the node status values, assuming a consistency rate of 1%. ,in Indicates the number of consistent states. This indicates the total number of states. When the state consistency rate is below the preset lower limit, a state conflict anomaly is recorded. At the same time, it checks whether each node is generated within the specified range according to the time window. If the time offset value exceeds the preset threshold, time anomaly data is recorded. Based on the number of matching nodes, state consistency rate, and time offset result, a corresponding evidence completeness score is generated.

[0050] The anomaly attribution module is used to detect broken nodes in the transaction graph and generate anomaly attribution labels; Based on the node association relationships and abnormal path identification in the transaction graph, the node connection relationships, node status values, and time sequence records are first read. A link relationship table is then established based on the transaction number, assuming the number of link nodes is [number missing]. The number of normally connected nodes is The number of fracture nodes is denoted as Subsequently, log analysis tools were used to read the state change data before and after the fracture node, and the state difference of the node was calculated. Let the state offset be... ,in Indicates the state value of subsequent nodes. This represents the state value of the preceding node. When the state offset is not within the preset range, a state breakage exception is recorded. In actual business scenarios, if the order status has been updated to "completed" but the notification node has not appeared, the message queue consumption log and callback log are read, the data for the corresponding time period is re-associated, and the node interval is checked according to the time order. The time offset value is set to... When the time offset value exceeds the preset upper limit range, it is classified as a delayed break type. Then, historical anomaly tags from the anomaly sample library are read, and the anomaly similarity is set to... ,in Indicates the number of identical abnormal features. This indicates the total number of abnormal features. When the similarity is in a high range, the current broken node is classified into the corresponding abnormal type. In the example, if there are a large number of unconsumed messages in the historical anomalies, the current broken node is associated with a message consumption anomaly label. At the same time, the corresponding anomaly attribution label is generated based on the node missing position, the state anomaly position, and the time anomaly position, and the anomaly attribution result is output.

[0051] The access control output module is used to generate release, review, or blocking conclusions based on the evidence completeness score and the abnormal attribution results.

[0052] Based on the scoring results and the associated anomaly labels, the completeness score data in the evidence scoring table and the anomaly label data in the anomaly attribution table are first read. Then, an access control judgment set is established according to the serial number. Let the completeness score be denoted as... The number of abnormal numbers is recorded as The comprehensive judgment value is denoted as ,in This represents the scoring weighting coefficient. This represents the anomaly deduction coefficient. The weighting parameter is allocated based on the historical transaction anomaly ratio. When the number of anomalies is in a high range, the anomaly deduction coefficient value is in a wide range. In actual business scenarios, if a transaction link has multiple broken nodes and state conflict records, the corresponding anomaly tags are read and the number of anomalies is accumulated. At the same time, classification processing is performed according to the scoring range. When the score is in the preset high range and the number of anomalies is lower than the preset threshold, it is classified as normal. When the score is in the middle range, a manual review mark is recorded. When the score is lower than the preset lower limit range, a blocking mark is recorded. Then, a database query tool is called to read the historical access control judgment results and compare the current score with the historical average score. Let the historical average score be denoted as . The scoring deviation value is When the scoring deviation exceeds the preset range, the scoring fluctuation is recorded as abnormal. In the example, if the current transaction integrity score is significantly lower than the historical scores of similar transactions, the corresponding abnormal node is read and the correlation verification is re-executed. Then, the scoring result, abnormal label and judgment type are written into the access control result table, and the corresponding conclusion data is output.

[0053] The system also includes a group transaction aggregation module, which is used to aggregate and count multiple sub-transactions based on groupTransId, and generate batch task completion results based on the number of successes, failures, and incomplete transactions.

[0054] When establishing transaction merging relationships based on batch association identifiers, the log collection component first reads multiple transaction records under the same association number and constructs a transaction log set according to the transaction submission time, channel source identifier, account type identifier, and status return field. Then, in the data processing interface, field splitting operations are performed on each sub-record, extracting the response status value, duration value, and return code value from each record. The response status value is obtained by reading the interface receipt field, and the duration value is calculated using a formula. Perform the calculation, where Indicates the duration of the transaction. Indicates the end timestamp, The start timestamp is indicated. A duration exceeding a preset waiting interval is defined as the duration being in a higher range, while a duration within a normal range is defined as the duration being within a preset baseline interval. The waiting interval is determined based on the average duration of historical batch transactions and a volatility coefficient. The volatility coefficient is calculated using the discrete value of recent period duration. Subsequently, a status mapping table is used to categorize the returned codes. Sub-records in the normal completion code interval are included in the completion set, sub-records in the abnormal code interval are included in the failure set, and sub-records that have not received a receipt for a long time are included in the pending set. During the counting process, a cache counting tool is used to accumulate the number of records in different states, and a formula is used... Statistical analysis is performed, in the formula This indicates the total number of transactions in the current batch. Indicates the quantity completed. Indicates the number of failures. This indicates the number of pending transactions. For example, in a batch of transfer tasks, there are multiple sub-transaction records. Most of them return standard completion status codes, so they are accumulated into the completed set. Some records return account abnormal status codes, so they are accumulated into the failed set. The remaining records that did not return receipts and whose duration exceeded the waiting interval are accumulated into the pending set. Then, the proportion of each status is calculated. The completion proportion is calculated using a formula. The failure rate is calculated using the formula. The percentage of suspended items is calculated using the formula. The calculation is as follows: when the completion rate is in a high range, the corresponding rate range is defined as higher than the historical average rate; when the failure rate is in a high range, the corresponding rate range is defined as higher than the historical failure benchmark rate. The historical failure benchmark rate is obtained by reading the average failure rate of recent batches and adding a floating coefficient. The floating coefficient is determined by combining the failure fluctuation range and the transaction size coefficient. The transaction size coefficient is calculated by the ratio of the current batch transaction quantity to the historical average batch quantity. Finally, the aggregation component writes the quantity and rate of each status into the task result table to form a batch processing record.

[0055] The system also includes an asset recirculation module, which is used to collect abnormal patterns, missing evidence types, timeout links, and high-frequency failure paths generated during the testing process into regression test assets and dynamically adjust the priority of subsequent tests.

[0056] When establishing an abnormal path set based on test asset archiving relationships, the test recording component first reads the test execution logs from each round and constructs a test data set according to the abnormal identifier field, evidence type field, link duration field, and node return field. Then, in the rule processing interface, the abnormal records are split, extracting the abnormal trigger count, link wait time, and node failure count from each log entry. The abnormal trigger count is obtained by statistically analyzing the cumulative occurrence of similar abnormalities within a preset period, and the link wait time is calculated using a formula. Calculate, where Indicates link latency. Indicates the response timestamp. This represents the request timestamp. A link latency exceeding the historical average latency range is defined as being in a higher range, while a link latency within the normal range is defined as being close to the historical average latency range. The historical average latency is obtained by averaging recent link records. Subsequently, missing evidence types are categorized and statistically analyzed. Test records lacking screenshot, log, or receipt fields are marked as different missing categories, and a counting expression is used. Statistical analysis is performed, in the formula Indicates the total number of missing records. Indicates the first Number of missing records of a class This represents the total number of missing categories. In the process of identifying high-frequency failure paths, a link sequence is first constructed according to the node call order, and then the number of failures under the same path is counted. The failure frequency is expressed by the formula... Calculate, where Indicates the frequency of path failures. Indicates the number of times an exception is triggered. This represents the total number of path calls. When the failure frequency is in the prominent range, it is defined as exceeding the sum of the historical average failure rate and the fluctuation coefficient. The fluctuation coefficient is obtained by reading the standard deviation of the failure rate in the recent period. For example, if a test link has consecutive interface timeout records in multiple periods and lacks a complete log file, the system marks the link as an object to be archived in the abnormal path set and continues to read the return status values ​​of adjacent nodes. Nodes that continuously return abnormal codes are associated and accumulated. Then, priority parameters are generated according to the weight of the abnormal category. The weight parameters are calculated by combining the number of historical abnormal impacts and the recent trigger frequency. The impact weight is obtained by the proportion of abnormal associated records, and the trigger frequency weight is obtained by the density of abnormal occurrence periods. Finally, the order of subsequent test tasks is rearranged according to the priority parameters, and the corresponding abnormal records, link records, and missing records are written into the regression asset library to form test asset records.

[0057] Example 2: The system first establishes an object set O. Object set O is not a single interface parameter, but rather an evidence graph composed of transactionId, asynchronous request table, in-transit work orders, MQ messages, callback requests, business tables, and upstream notifications. The system then establishes a rule set R, which includes pre-rules, action rules, post-rules, exception rules, and backflow rules. Each test execution can be represented as generating an execution path from O and R, collecting an evidence set E from the execution path, and finally calculating a difference set D and a gate control conclusion G based on E. |Variable|Meaning|Source of Value|Technical Role| |—|—|—|—| |O|Set of Business Objects|Evidence Graph Composed of transactionId, Asynchronous Request Table, In-Transit Work Orders, MQ Messages, Callback Requests, Business Tables, and Upstream Notifications|Determines the Scope of Verification| |R|Set of Rules|Interface Contracts, State Transitions, Permissions, Asynchronous or File Verification Rules|Determines the Execution Path| |E|Set of Evidence|Response, Status, Callback, File, Report, and Log Index|Proves the Result of the Action| |D|Set of Differences|Snapshots or Reconciliation of Source Results Before and After Execution|Discovers Expected Changes and Prohibited Changes| |G|Access Control Conclusion|Completeness of Evidence, Risk Level, and Anomaly Attribution|Decides to Allow, Block, or Review| The variables mentioned above can be stored in different formats in different projects, but their technical meaning remains unchanged. O is used to determine which business objects to verify, R is used to determine what changes are allowed between objects, E is used to prove whether the changes actually occurred, D is used to identify side effects beyond the expected changes, and G is used to translate the verification results into release, blocking, review, or regression strategies.

[0058] (1) During parameterized implementation, the instantiation method of object collection O is as follows: the system reads the record with the transactionId in the TblMnoAsyncRequest table as an asynchronous node, reads the lock record with the same transactionId in the in-transit work order table as a work order node, extracts the corresponding msgId from the RocketMQ sending log as a message node, and extracts the callback content from the inbound request log of NotifyController as a callback node. Each node object contains four standard fields: primary key, status enumeration, timestamp, and source identifier.

[0059] (2) During parameterized implementation, the rule set R is instantiated as follows: The system queries the rule configuration table based on the requestType field to obtain the target evidence node list, the expected state value of each node, the timing constraints between nodes (such as the callback time must be later than the entry time), and the timeout threshold for this business type. The rules are stored in JSON Schema and support loading different configurations according to the environment (Mock / SIT / UAT / PRD).

[0060] (3) When implementing parameterization, the evidence set E is stored as follows: each collected evidence is stored in a Redis Hash structure (short-term) and a MySQL evidence archive table (long-term) with transactionId as the key. The Hash fields include entry_evidence, async_evidence, mq_evidence, callback_evidence, biz_evidence and notify_evidence. Each field stores a JSON snapshot of the node.

[0061] (4) During parameterized implementation, the access control conclusion G is generated as follows: the system calculates the evidence completeness Q and compares it with the access control threshold. Q≥90 indicates PASS (automatic release), 70≤Q<90 indicates REVIEW (manual review), and Q<70 indicates BLOCK (block release). Simultaneously, if there are hard anomalies such as idempotency violations or work order residues, BLOCK is output regardless of the Q value. The access control conclusion is written to the pipeline Gate API in JSON format.

[0062] Example 3: Taking "Package order waiting for CMP completion" as an example: After sending a recharge request, the system obtains the transactionId and immediately confirms in the asynchronous table that the record has been created and its status is WAITING. The system then enters waiting mode, polling the asynchronous table at 5-second intervals. When the CMP callback arrives, the asynchronous table status transitions to SUCCESS. The system then checks whether RocketMQ has delivered the recharge processing message, whether the processor has added a record with the corresponding productId to the package table, and whether the TSP notification contains the correct order result. If the package table has a record but the notification is missing, the system attributes it to "TSP notification assembly or sending error".

[0063] Taking "Duplicate Reporting Idempotency Verification" as an example: The system first completes a binding transaction normally (the entire chain from entry to notification is successful), recording a complete snapshot of the business table at this point. Then, the system uses the callback simulation module to send a successful callback with the same transactionId to the NotifyController again, waits for 1 second, and then re-captures a snapshot of the business table. The system performs a field-level diff between the two snapshots. If any changed fields exist (such as changes in updateTime or overwritten status), it is marked as an idempotency violation, and a list of changed fields is output.

[0064] Taking "Insufficient Evidence After MQ Delivery Failure" as an example: The system injects an MQ sending exception (such as simulating Broker unreachability) into the Mock environment, then executes the binding request and triggers the CMP callback normally. After the callback arrives, the asynchronous table is updated to SUCCESS, but due to the MQ delivery failure, the processor will not consume the message, and the vehicle-card relationship table will not change. The system detects the missing MQ node and the missing business table node in the graph, and outputs the attribution label "MQ delivery failure caused the processor not to trigger," rather than the general "binding failure."

[0065] Taking "Batch Sub-Transaction Aggregation Completed" as an example: The system sends a batch request containing 10 recharges and obtains the groupTransId. The system queries all sub-transaction records by groupTransId and finds 8 SUCCESS and 2 FAIL. The system performs a single-transaction attribution process for the 2 FAIL sub-transactions: the first was rejected by the entry point because the ICCID does not exist (entry node REJECTED), and the second was suspended due to CMP callback timeout (asynchronous table WAITING timeout). Finally, the system outputs an 80% batch completion rate, independent attributions for the two failures, and suggested supplementary data.

[0066] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A closed-loop test method for end-to-end evidence of MNO asynchronous transaction graphs, characterized in that, Includes the following steps: S1. Obtain a set of business objects from the communication card management system or the vehicle network business system. The set of business objects includes at least transactionId, postTransactionId, asynchronous request records, message queue messages, callback requests, business status records, and upstream notification records. S2. Construct an asynchronous transaction graph based on the set of business objects, wherein transactionId is used as the main association key to establish association relationships between entry request nodes, asynchronous status nodes, message delivery nodes, callback nodes, business status nodes and notification nodes, and form a directed transaction graph with time constraints. S3. Generate a set of target evidence nodes based on the business type, and establish corresponding state transition rules, timing constraint rules, and anomaly rules; S4. During the asynchronous business execution process, according to the preset time window and retry strategy, collect multi-source evidence data from the asynchronous request table, message queue, business table, callback interface and notification mirror, and map the multi-source evidence data to the corresponding transaction graph node. S5. Calculate the evidence completeness score based on the target evidence node set and the actual collected evidence nodes; S6. Detect broken nodes that have not reached the target state along the node path of the transaction graph, and generate abnormal attribution labels according to the attribution rules; S7. Output structured test results including evidence completeness score, anomaly attribution results, breakpoint locations, and access control conclusions.

2. The method for closed-loop testing of full-link evidence in MNO asynchronous transaction graphs according to claim 1, characterized in that: The nodes in the asynchronous transaction graph include at least an entry node, an asynchronous status node, a message delivery node, a processor node, a business status node, and a notification node. Each node includes a status field, a timestamp field, and a source identifier field.

3. The method for closed-loop testing of full-link evidence in MNO asynchronous transaction graphs according to claim 1, characterized in that: In step S3, target evidence node mapping relationships are established for different business types, wherein: The recharge service corresponds to at least the entry flow node, asynchronous table status node, message queue node, package table node, and notification node; The real-name registration service should correspond to at least the entry flow node, the asynchronous table status node, the real-name registration callback node, the KYC status node, and the notification node.

4. The method for closed-loop testing of full-link evidence in MNO asynchronous transaction graphs according to claim 1, characterized in that: The multi-source evidence collection in S4 includes: Poll the state transition information in the asynchronous request table; Monitor message delivery and consumption records in the message queue; Capture request and response messages in the callback interface; Query the final business status in the business table; Record the upstream notification mirror content.

5. The method for closed-loop testing of full-link evidence in MNO asynchronous transaction graphs according to claim 1, characterized in that: The evidence completeness score in S5 is calculated as follows: By assigning different weights to core evidence nodes, business status nodes, asynchronous nodes, and notification nodes, the matching degree between the actual collected evidence and the target evidence is calculated using a weighted average, and a comprehensive score is generated by combining the penalty coefficient for missing key evidence.

6. The method for closed-loop testing of full-link evidence in MNO asynchronous transaction graphs according to claim 1, characterized in that: The anomaly attribution in S6 includes: When the asynchronous table state fails to transition to the final state, it is attributed to a downstream callback exception. When there are delivery records in the message queue but no state change in the business table, the cause is attributed to abnormal processor consumption. When the business table status has been updated but the notification image is missing, the cause is attributed to a notification sending error.

7. The method for closed-loop testing of full-link evidence in MNO asynchronous transaction graphs according to claim 1, characterized in that: Also includes: Construct duplicate callback requests, delayed callback requests, and unknown pipeline callback requests to verify the idempotency of the system's callbacks and detect whether there are duplicate state updates or duplicate notifications.

8. A closed-loop testing system for full-link evidence of MNO asynchronous transaction graphs, characterized in that, It includes the following modules: a transaction modeling module, used to obtain a collection of business objects and construct an asynchronous transaction graph; The rule generation module is used to generate a set of target evidence nodes and corresponding state rules and time sequence rules based on the business type. The evidence collection module is used to collect multi-source evidence from asynchronous tables, message queues, business tables, callback requests, and notification mirrors according to preset time windows and retry strategies. The integrity assessment module is used to calculate the evidence integrity score based on the target set of evidence nodes and the actual evidence nodes. The anomaly attribution module is used to detect broken nodes in the transaction graph and generate anomaly attribution labels; The access control output module is used to generate release, review, or blocking conclusions based on the evidence completeness score and the abnormal attribution results.

9. The MNO asynchronous transaction graph full-link evidence closed-loop testing system according to claim 7, characterized in that: The system also includes a group transaction aggregation module, which is used to aggregate and count multiple sub-transactions based on groupTransId, and generate batch task completion results based on the number of successes, failures, and incomplete transactions.

10. The MNO asynchronous transaction graph full-link evidence closed-loop testing system according to claim 7, characterized in that: The system also includes an asset recirculation module, which is used to collect abnormal patterns, missing evidence types, timeout links, and high-frequency failure paths generated during the testing process into regression test assets and dynamically adjust the priority of subsequent tests.

Images