Multi-type test data processing method and device based on distributed computing

Abstract

The embodiment of the invention discloses a multi-type test data processing method and device based on distributed computing, and the method comprises the steps: capturing a native test data stream at each test execution node, packaging the native test data stream into a multi-type test data unit, and storing the multi-type test data unit into a local streaming data cache region to generate a node test data time sequence, generating a node internal test data flow path graph based on the time interval and the type conversion relation between the data units; all node internal maps are sent to a distributed coordination control system for cross-node association analysis, a test data cross-node flow association network is generated, and test execution nodes are divided into test task execution node groups according to the network; selecting a core node to construct a test data aggregation view in the group, extracting a test data unit chain corresponding to a process test transaction crossing multiple nodes according to the dependency relationship of the test data aggregation view, distributing a globally unique transaction tracking identifier for the test data unit chain, and reinjecting the transaction tracking identifier to a streaming data cache region of the corresponding node.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method and device for processing multi-type test data based on distributed computing. Background Technology

[0002] In the development and testing of large-scale distributed systems and cloud computing platforms, tasks such as performance testing, stress testing, and functional verification usually require scheduling multiple test execution nodes to work together. During the execution of test tasks, these test execution nodes will continuously generate massive amounts of native test data streams, including but not limited to application logs, performance monitoring metrics, API call records, database operation statements, and custom test result outputs.

[0003] In existing technologies, the processing of the aforementioned test data typically employs a centralized log collection scheme. For example, this involves deploying a log collection agent on each node to periodically or in real-time push locally generated log files to a centralized log storage system such as Elasticsearch or a distributed file system. Another common approach is to use streaming data processing frameworks, such as Apache Kafka combined with Flink or Spark Streaming, to connect data generated by each node as messages to a unified data pipeline for subsequent offline or real-time analysis. This enables centralized storage of massive amounts of test data and basic keyword retrieval or metric aggregation. Furthermore, some test management platforms manually embed tracking points in test scripts to generate a unique request identifier for each test request and record its processing logs on different service nodes. This request identifier is then used as a key for log aggregation, enabling call chain tracing at the individual request level. Summary of the Invention

[0004] This application provides a method and device for processing multiple types of test data based on distributed computing.

[0005] This application provides, in one aspect, a method for processing multi-type test data based on distributed computing, applied to computer equipment, the method comprising: At each test execution node, capture the raw test data stream generated during the execution of the test task, encapsulate the raw test data stream into multi-type test data units carrying node source tags and test type tags, and store the multi-type test data units in a local streaming data buffer to generate a node test data time series with a continuous time span; Based on the time intervals and type conversion relationships between multiple types of test data units in the time series of the node test data, a test data flow path map is generated for each test execution node; Send the test data flow path graph within all nodes to the distributed coordination and control system for cross-node correlation analysis, and generate a test data cross-node flow correlation network containing directed edges for test data transmission; Based on the cross-node flow association network of the test data, the test execution nodes are divided into test task execution node groups, and a core test execution node is selected from each test task execution node group to construct a test data aggregation view within the group; Based on the dependencies in the test data aggregation view within the group, extract the test data unit chain corresponding to the process test transaction that spans multiple nodes, assign a globally unique transaction tracking identifier to the test data unit chain, and inject it back into the streaming data cache of the corresponding test execution node.

[0006] One embodiment of this application provides a computer device, including: A processor; a storage device having a computer program stored thereon; a network interface for providing network communication functions; when the computer program is executed by the processor, the processor enables the processor to implement any of the aforementioned distributed computing-based multi-type test data processing methods.

[0007] One embodiment of this application provides a readable storage medium on which a program or instruction is stored, and when the program or instruction is executed by a processor, it implements the steps of the multi-type test data processing method based on distributed computing.

[0008] This application constructs a complete technical chain from raw data capture to global transaction identifier back-injection, achieving a deep deconstruction and explicit representation of cross-node data flow logic in distributed testing scenarios. First, multiple types of test data units carrying node source and test type labels are generated locally on each test execution node, forming a continuous time series as a structured data foundation with spatiotemporal and type attributes. Then, based on the time intervals and type conversion relationships between data units in the time series, an internal test data flow path graph is generated, completing the abstract modeling of the data processing logic within a single node. All internal node graphs are aggregated into a distributed coordination and control system for cross-node correlation analysis. By matching the type codes of the start and end nodes in different node graphs, a cross-node test data flow correlation network containing directed edges for test data transmission is generated, achieving global topology reconstruction of the data transmission path between multiple nodes. Based on this flow association network, the test execution nodes are divided into test task execution node groups, and core nodes are selected to build a test data aggregation view within the group. At the group level, the spatiotemporal alignment and dependency visualization of cross-node data are realized. Finally, based on the dependency relationship in the aggregation view, the test data unit chain corresponding to the process test transaction that spans multiple nodes is extracted and a globally unique transaction tracking identifier is assigned and injected back to the cache area of ​​each node. A data footprint index that runs through all participating nodes is established for each distributed transaction.

[0009] Therefore, this application constructs a layer-by-layer abstraction and reverse mapping mechanism from the original data stream to the transaction-level tracking identifier. It transforms the originally isolated, heterogeneous, and disordered multi-type test data in the distributed environment into an ordered data structure with clear node paths, type conversion logic, and transaction ownership relationships through the construction and correlation analysis of multi-level graphs. This improves the technical difficulties of tracing cross-node data lineage and ensuring transaction integrity in distributed testing scenarios, enhances the observability and diagnosability of the testing process of complex distributed systems, and solves the technical problem of serious lag or even absence in the construction of data lineage, making it difficult to achieve integrity analysis and anomaly localization of test transactions. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a multi-type test data processing method based on distributed computing, as provided in an embodiment of this application.

[0012] Figure 2 This is a schematic diagram of the basic structure of a computer device provided in an embodiment of this application.

[0013] Figure 3 This is a functional block diagram of a multi-type test data processing device based on distributed computing, provided in an embodiment of this application.

[0014] Figure 4 This is a schematic diagram of a multi-type test data processing and interaction environment based on distributed computing, provided in an embodiment of this application. Detailed Implementation

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

[0016] Please see Figure 1 , Figure 1 This is a flowchart of a multi-type test data processing method based on distributed computing provided in an embodiment of this application. The method can be executed by a computer device or by a computer device and a server. The method may include steps 110-150.

[0017] Step 110: Capture the native test data stream generated during the execution of the test task at each test execution node, encapsulate the native test data stream into multi-type test data units carrying node source tags and test type tags, and store the multi-type test data units in the local streaming data buffer to generate a node test data time series with a continuous time span.

[0018] In this embodiment, a distributed performance testing platform of a large cloud computing data center is used as an example. This platform comprises dozens of physical servers or container instances as independent test execution nodes, all uniformly scheduled by an upper-layer distributed coordination and control system (e.g., a management service built on Zookeeper or Kubernetes). First, on each test execution node, this embodiment needs to capture all raw data generated during the execution of specific test tasks (e.g., concurrent simulated user access, stress testing, interface function verification, etc.). To achieve this, this embodiment deploys a resident test task execution agent within each test execution node. This agent runs as a daemon process and is deeply integrated with the operating system's kernel event mechanism.

[0019] Step 111: Install a test task execution agent on each test execution node in the distributed computing environment. Receive test task start instructions from the distributed coordination and control system through the test task execution agent. Create a test task execution process instance in the local operating system process according to the task parameter information carried in the test task start instructions.

[0020] Specifically, after receiving the test task orchestration instruction from the computer equipment, the distributed coordination and control system parses out the list of test execution nodes that need to participate and the specific test scripts or binary programs that need to be run on each node. For one of the test execution nodes, Node_A, the coordination and control system sends it a test task start instruction conforming to a standard protocol (such as gRPC or HTTP / 2). The request body payload of this instruction contains a JSON-formatted task parameter information object, such as a task identifier (TaskID) field with the value "LoadTest_20231027_001", which is globally unique throughout the distributed system; a Uniform Resource Locator (URL) field for the test script, pointing to the test package stored in a distributed file system (such as HDFS or Ceph), for example, with the value "hdfs: / / test-cluster / scripts / user-login-simulator.jar"; and key-value pairs such as JVM startup parameters, environment variables, number of concurrent threads, and runtime.

[0021] Upon receiving the instruction, the test task execution agent on test execution node Node_A first performs integrity verification and signature verification to ensure the instruction's legitimate origin and lack of tampering. After successful verification, the agent parses the task parameter information and then creates a new child process in the local operating system kernel using the fork and execve system calls with the specified task parameters (e.g., setting the heap memory size to 2GB and setting the environment variable TEST_MODE=STRESS). This child process becomes the test task execution process instance. The agent records the mapping relationship between the process identifier (PID) of this process instance (e.g., PID 12345) and its corresponding task identifier "LoadTest_20231027_001," storing this information in the agent's internal process management hash table.

[0022] Step 112: During the execution of the test task execution process instance, the test task execution agent intercepts the data write operation of the test task execution process instance to the local file system and captures the original test data content in the memory buffer corresponding to the data write operation.

[0023] During the execution of a test task execution process instance, it continuously generates test results, logs, performance metrics, and other data. This data is typically written to a log file on the local disk using standard C library functions (such as `fwrite` and `printf`) or Java's I / O streams. This specification's embodiments monitor the system calls of the test task execution process instance at the kernel level using Linux's `ptrace` mechanism or more efficient technologies like `fanotify` and `eBPF`. Specifically, the test task execution agent pre-mounts a probe for the `write` series of system calls in `eBPF`. When the test task execution process instance (PID 12345) calls the `write` function to write the contents of a memory buffer to a file descriptor (e.g., file descriptor 3 corresponds to " / var / log / test.log"), the `eBPF` probe is triggered. This probe captures the parameters of this system call, including the starting address pointer `buf_ptr` of the user-space memory buffer and the length of the data to be written `data_len` (e.g., 1024 bytes). The probe then passes this information to the user-space test task execution agent through an `eBPF` map structure. The agent then uses the process_vm_readv system call to safely copy the original test data (i.e. the binary data of this write operation) from the address space of the test task execution process instance to the agent's own memory buffer, based on the obtained process PID12345, memory address buf_ptr, and data length data_len. This achieves seamless capture of the original test data without modifying the test task's code.

[0024] Step 113: Parse the task identifier corresponding to the test task currently being executed by the test task execution process instance from the original test data content, and obtain the node network address of the test execution node where the test task execution agent program is located as the node source label.

[0025] After capturing the raw test data, the agent needs to attach context information to it. Since multiple test task process instances may run simultaneously on a single test execution node, it's crucial to determine which task the captured data belongs to. The agent retrieves the corresponding task identifier "LoadTest_20231027_001" based on the PID 12345 of the process that triggered the data capture, using a previously maintained hash table mapping process PIDs to task identifiers. Simultaneously, the agent reads the node's local network configuration, obtaining the Internet Protocol address (IP address) of the primary network interface (e.g., eth0), such as "XXX.XXX.X.XXX". This IIP address string is then encapsulated into a standard node source tag object with the format {"key":"node_ip", "value":"XXX.XXX.X.XXX"}. In containerized deployment scenarios, the node source tag can also be the Pod name or container ID.

[0026] Step 114: Read the test data type identifier field contained in the original test data content generated by the test task execution process instance, and convert the test data type identifier field into a unified test type classification code as a test type label.

[0027] The raw test data itself typically contains information identifying its type. For example, a typical test log line might begin with "[ERROR]", or a performance metric might be prefixed with "metric:". After obtaining the raw data, the agent performs initial streaming parsing. It matches the type identifier in the data using a set of configurable regular expression rules. For example, the rule might be defined as follows: if the raw data matches the regular expression "^[0-9]{4}-[0-9]{2}-[0-9]{2}.*\[ERROR\].*", it is determined to be an error log type, mapped to the unified test type classification code "LOG_ERR". If it matches "metric:(.*)", it is determined to be a performance metric type, mapped to "PERF_METRIC". If it matches "^\{.*\"result\":\"pass\".*\}$", it is determined to be a functional test result, mapped to "FUNC_RESULT". In this embodiment of the specification, for example, the captured raw test data content is a piece of performance data in JSON format, such as the string '{"timestamp":1698403200,"metric":"cpu_usage","value":75.5}'. When the matching rule matches the "metric:" pattern, the agent program converts it into a unified test type classification code "PERF_METRIC" as the test type label for the data unit.

[0028] Step 115: Arrange the captured raw test data content in the order of its generation time. Combine and encapsulate the raw test data content captured at each time point with the corresponding task identifier, node source label and test type label to generate the data encapsulation header corresponding to the raw test data content. The resulting data payload unit containing the data encapsulation header and the raw test data content is used as a multi-type test data unit.

[0029] The computer device control agent encapsulates the collected information in a structured manner, constructing a data encapsulation header for each captured raw test data content. This header is encoded using a compact binary format or an efficient serialization protocol (such as Protocol Buffers or MessagePack). The header structure contains several predefined fields: first, a Magic Number field, fixed at 4 bytes (0x9ABCDEF0), used to quickly identify data unit boundaries; then, a version number field, occupying 1 byte, with an initial value of 0x01; next, a total packet length field, occupying 4 bytes, used to describe the total number of bytes including the header and payload. Then, the task identifier field (e.g., "LoadTest_20231027_001", using variable-length string encoding), the node source label field (e.g., "XXX.XXX.X.XXX", also variable-length encoding), and the test type label field (e.g., "PERF_METRIC", represented by the predefined enumerated integer 0x03 to save space) are filled in sequentially. The packet header also contains a generation timestamp accurate to microseconds. This timestamp is taken from the high-precision time obtained by calling clock_gettime(CLOCK_REALTIME) when the agent program captures data; for example, the timestamp value is 1698403200.123456 seconds. The agent program concatenates the calculated packet header data and the original test data content (i.e., the payload) together to form a complete binary data block, which is the multi-type test data unit described in the embodiments of this specification.

[0030] Step 116: Maintain a multi-type test data unit sending queue in the test task execution agent program, and push the generated multi-type test data units into the multi-type test data unit sending queue in chronological order.

[0031] To smooth the data generation and subsequent processing speed and avoid blocking of the agent program due to untimely downstream processing, the computer device implements a lock-free concurrent circular queue (RingBuffer) as the sending queue within the agent program. Each slot in the queue can store a pointer to a complete multi-type test data unit memory block. After a data unit is encapsulated in step 115, the agent program attempts to place the pointer of the data unit into the tail of the queue using a CAS (Compare-And-Swap) operation. If the queue is full, the agent program will wait or discard old data according to a preset strategy (e.g., discard the oldest data and record the discard log). In this way, all generated multi-type test data units are temporarily stored in this sending queue strictly in the order of their generation time, waiting to be retrieved by the consuming thread for further processing. For example, a high-concurrency performance test may generate tens of thousands of data points per second, and all of these data will be pushed into this queue in an orderly manner.

[0032] Step 120: Based on the time intervals and type conversion relationships between multiple types of test data units in the time series of the node test data, generate a node internal test data flow path map corresponding to each test execution node.

[0033] After data is stored in the cache and formed into a sequence, the computer device needs to analyze the data flow patterns within a single node, examining the chronological order of the data and the evolution of their types. For example, in a user login test process, data of type "request sent," type "database query," and type "result returned" may be generated sequentially. In other words, the embodiments of this specification need to automatically extract the path map of this type of evolution from the chaotic time series.

[0034] Step 121: Parse the time series of node test data corresponding to each test execution node. Starting from the beginning of the node test data time series, traverse each multi-type test data unit in sequence to obtain the generation timestamp information, test type label and task identifier in the data encapsulation header corresponding to each multi-type test data unit.

[0035] At each test execution node, the local streaming data buffer stores the node test data time series with a continuous time span generated in step 110. This series is an ordered list, and each element in the list is a multi-type test data unit. This step scans this series using a separate local analysis thread. Starting from the beginning index 0 of the series, each multi-type test data unit is read sequentially. For each unit, its data encapsulation header is parsed first, extracting three key pieces of information: first, the timestamp generated, for example, the timestamp T_ts parsed from the header of unit_A is 1698403200.123456; second, the test type label, for example, the type label Type_A parsed from unit_A is "PERF_METRIC"; and third, the task identifier, for example, the task identifier Task_ID parsed from unit_A is "LoadTest_20231027_001". The analysis thread stores the above information, along with the unit's position index or unique ID in the series, in a temporary analysis data table in the form of structured metadata.

[0036] Step 122: Calculate the time interval between adjacent multi-type test data units based on the recorded generation timestamp information, and mark adjacent multi-type test data units with a time interval less than the preset adjacent time threshold as test data unit pairs with a continuous generation relationship.

[0037] After acquiring the metadata for each data unit, this step begins analyzing temporal correlation. The analysis thread traverses the metadata list generated in step 121, calculating the difference in timestamps between the i-th and (i+1)-th data units: Delta_T_i = T_ts_(i+1) - T_ts_i. For example, if the timestamp of Unit_A is t=1.000 seconds and the timestamp of Unit_B is t=1.003 seconds, then Delta_T_AB is 0.003 seconds. A preset adjacency threshold, Thresh_adjacent, is used. This threshold can be dynamically adjusted according to the type of test task. For example, it can be set to 10 milliseconds for high-throughput performance testing and 100 milliseconds for functional testing. If Delta_T_AB is less than Thresh_adjacent, Unit_A and Unit_B are considered to be temporally adjacent, forming a test data unit pair with a continuous generation relationship. For two units with a time interval greater than the threshold, it is considered that there may be a time discontinuity between them, and they do not belong to the same batch of continuous data streams. The analysis thread adds a flag field, such as "is_adjacent":true, to the metadata of Unit_A and Unit_B.

[0038] Step 123: Identify the conversion pattern between the test type label of the previous multi-type test data unit and the test type label of the next multi-type test data unit in a test data unit pair with a continuous generation relationship, and determine the type conversion path of the test data type evolving sequentially during the execution of the same test task.

[0039] After identifying unit pairs with continuous generation relationships, this step further focuses on the type conversions within these unit pairs. For each unit pair (Unit_X, Unit_Y) marked as true, the analysis thread extracts the type label Type_X for Unit_X and the type label Type_Y for Unit_Y. This type conversion relationship is recorded as a directed conversion pattern (Type_X->Type_Y). For example, in a unit pair, if the type label for Unit_X is "REQ_SEND" (request sent) and the type label for Unit_Y is "DB_QUERY" (database query), then a conversion pattern "REQ_SEND"->"DB_QUERY" is recorded. The analysis thread will then count the various conversion patterns appearing in all unit pairs and their frequencies.

[0040] However, adjacent conversions alone are insufficient to form a complete path; they need to be chained together with task identifiers. For a series of units with the same Task_ID, arranging them according to their timestamp order yields a series of type conversions within that task. For example, "REQ_SEND"->"DB_QUERY"->"RESP_RECV"->"FUNC_RESULT". This ordered sequence of type conversions constitutes a type conversion path where the test data type evolves sequentially.

[0041] Step 124: Based on the order of the timestamps of all the test data units of the same task identifier, connect the test data units of the same task identifier into branches of the data flow path within the task according to the timestamp order.

[0042] This step involves constructing the flow path for each task instance. For the task identifier "LoadTest_20231027_001", the analysis thread filters all units with this task identifier from the metadata table in step 121 and sorts them by timestamp T_ts in ascending order. For example, the sorted result is: Unit_1 (Type: REQ_SEND), Unit_2 (Type: DB_QUERY), Unit_3 (Type: DB_QUERY), Unit_4 (Type: RESP_RECV), Unit_5 (Type: FUNC_RESULT). The analysis thread connects these five units sequentially to form a directed chain: Unit_1->Unit_2->Unit_3->Unit_4->Unit_5. This directed chain is the data flow path branch within the node for this task. This branch not only contains type conversion information but also the sequential relationship between units, ensuring that even two consecutive units of the same type (such as Unit_2 and Unit_3 both being DB_QUERY) are fully preserved.

[0043] Step 125: Merge branches with the same test type conversion pattern in all internal data flow path branches of all tasks to obtain a directed graph structure with test type labels as nodes and type conversion relationships as directed edges, which serves as the internal test data flow path graph of the node.

[0044] After generating the branch paths for all tasks, this step abstracts and merges these branches to form a general flow graph at the node level. The analysis thread initializes an empty directed graph Graph_node, where the nodes are test type labels and the edges are type conversion relationships. It traverses each task's internal data flow path branch. For example, when traversing the branch "LoadTest_20231027_001" mentioned above, starting from Unit_1 (REQ_SEND), it checks if the node "REQ_SEND" already exists in Graph_node. If not, it creates the node. Then, it examines the transition from Unit_1 to Unit_2, checking if there is a directed edge in the graph pointing from "REQ_SEND" to "DB_QUERY". If not, it creates the edge and sets a weight counter for it, initially set to 1; if it already exists, it increments the edge's weight counter by 1. Next, process the transformation from Unit_2 to Unit_3, creating or updating self-loop edges in the graph pointing from "DB_QUERY" to "DB_QUERY", representing multiple consecutive operations of the same type. Continue processing the transformations from Unit_3 to Unit_4 and from Unit_4 to Unit_5.

[0045] After all task branches have been processed, Graph_node evolves into a weighted directed graph, where nodes represent all the test types that have appeared, and the weights of the edges represent the frequency of that transformation pattern in the historical data. This weighted directed graph is a graph of the test data flow path within the node, which abstracts the typical internal data flow pattern on the test execution node.

[0046] Step 126: Traverse all task identifiers corresponding to the multi-type test data units in the node test data time series, extract the starting multi-type test data unit and ending multi-type test data unit corresponding to each task identifier, and mark the start and end position nodes of the flow path corresponding to each task identifier in the test data flow path graph inside the node.

[0047] To associate specific task instances with the abstract graph, this step labels the start and end information of each task on the final graph. The computer device, through an analysis thread, iterates through all task identifiers again, identifying the earliest timestamp (start unit) and the latest timestamp (end unit) for each task ID. Then, in the graph_node, the test type node of the start unit is located, and an attribute, such as "start_of_task:[Task_ID1, Task_ID2, ...]", is appended to this node, recording the list of tasks starting with this type. Similarly, the attribute "end_of_task:[Task_ID1, Task_ID2, ...]" is appended to the test type node of the end unit. For example, for the task "LoadTest_20231027_001", it is recorded as one of the start nodes in the "REQ_SEND" node of the graph, and as one of the end nodes in the "FUNC_RESULT" node. Therefore, the internal test data flow path graph of the node not only describes the general rules of type conversion, but also indicates the common transaction start and end points.

[0048] Step 130: Send the test data flow path graph of all nodes to the distributed coordination and control system for cross-node association analysis, and generate a test data cross-node flow association network containing directed edges for test data transmission.

[0049] The flow graph within a single node describes the evolution of data within that node. However, in distributed testing, a complete test transaction often involves multiple nodes. For example, node A might simulate a user request, then send the task of processing the request to node B for computation, and node B would then return the result to node A. Therefore, it is necessary to aggregate the internal graphs of all nodes and perform cross-node correlation analysis to construct a global data flow network.

[0050] Step 131: Receive the internal test data flow path graphs sent by all test execution nodes through the distributed coordination and control system, assign a corresponding node identifier to each internal test data flow path graph, and store the received internal test data flow path graphs in the central graph database.

[0051] In detail, the distributed coordination and control system acts as the central hub, possessing a data interface for receiving graphs. Each test execution node (e.g., Node_A, Node_B), after completing the computation of its internal graphs Graph_A and Graph_B, uploads them to the coordination and control system via HTTP / 2 or gRPC streaming. Upon receiving the graphs, the coordination and control system appends a source identifier to each graph, namely the node identifier Node_ID that sent the graph. For example, Node_ID_A is "XXX.XXX.X.XXX", and Node_ID_B is "YYY.YYY.Y.YYY". The coordination and control system then persists the graph data with node labels to a central graph database. This database can be a graph database (e.g., Neo4j or JanusGraph) for efficient graph traversal and association queries. Each node's internal graph is stored as an independent subgraph in the database and associated with the root node through its node identifier attribute.

[0052] Step 132: Extract the set of test type labels contained in the internal test data flow path graph of all nodes from the central graph database, perform global unified encoding on each test type label appearing in the set of test type labels, and establish a mapping relationship table between test type labels and global unified encoding.

[0053] Because developers at different nodes may use different label strings for the same test type (e.g., "DB_QUERY" for node A may be equivalent to "DATABASE_ACCESS" for node B), a unified language must be established before cross-node associations can be performed. The computer device initiates a globally unified encoding generation process through a coordinated control system. This process traverses all subgraphs in the central graph database, extracting the original test type label strings for all nodes in each subgraph, forming a global string set S_global. To ensure the uniqueness and consistency of the global encoding, the embodiments in this specification implement precise mapping relationship construction through the following sub-steps.

[0054] Step 1321: Start the global unified coding generation process through the distributed coordination and control system. The global unified coding generation process sequentially accesses the internal test data flow path map of each node stored in the central graph database.

[0055] After receiving a signal that all nodes have completed uploading their graphs, or after the set time window has closed, the coordination and control system triggers a global unified encoding generation process. This process runs as an independent transaction. It first queries all stored internal graph records of the nodes from the central graph database, sorts them according to the node identifier, and then performs in-depth analysis on each graph in turn.

[0056] Step 1322: For the internal test data flow path graph of the currently accessed node, parse all the nodes contained in the internal test data flow path graph of the node. Each node corresponds to a test type label, and extract the original string of the test type label of each node.

[0057] For the graph currently being processed, such as Graph_C from Node_C, the process parses the graph structure of Graph_C and obtains the attributes of all vertices in the graph. Each vertex represents a test type, and the process reads the field storing the test type label from the vertex attributes to obtain its raw string value, such as reading the string "REDIS_CACHE_HIT" from a vertex in Graph_C.

[0058] Step 1323: Add the extracted original string of the test type label to the global test type label summary set, and check whether there is already a string record in the global test type label summary set that is exactly the same as the original string of the current test type label. If there is no string record in the global test type label summary set that is exactly the same as the original string of the current test type label, then insert the original string of the current test type label as a new entry into the global test type label summary set.

[0059] The process maintains a global hash set H_global to store all discovered, unique test type label raw strings. For each raw string extracted from Graph_C, such as "REDIS_CACHE_HIT", the process uses it as the key to look up in H_global. If the string does not exist in H_global, it indicates a newly emerging test type, and the process inserts the string into H_global. If it already exists, it is ignored, and the process continues to the next one. For example, if "DB_QUERY" already exists in the graph of Node_A, and "DATABASE_ACCESS" exists in the graph of Node_B, these two strings will be inserted into H_global as two different entries because the string literals are different.

[0060] Step 1324: After completing the traversal of the test data flow path graph within all nodes, obtain the total number of original strings of test type labels contained in the global test type label summary set, and determine the encoding bit length of the global unified encoding based on the total number.

[0061] Once the graphs of all nodes have been processed, H_global contains the original strings of all distinct test type labels that have appeared throughout the distributed system. Let the size of H_global be N (e.g., N = 150). Based on the value of N, we can determine how many bits of integer are needed to uniquely identify all the aforementioned labels. For example, N = 150, which is less than 2^8 (256), so a 1-byte (8-bit) unsigned integer can be used for encoding. If N is greater than 256 but less than 65536, then 2 bytes (16 bits) are needed for encoding. Determining the number of bits is to improve efficiency by using fixed-length binary encoding to replace variable-length strings during data transmission and storage.

[0062] Step 1325: According to the insertion order of the original strings of the test type labels in the global test type label summary set, assign a globally unified code to each original string of the test type labels, which is an integer sequence that increases sequentially from the initial code value.

[0063] The computer device iterates through H_global via processes. Since H_global is unordered during insertion, to assign a specific code to each string, the process sorts the strings in H_global, for example, in ascending lexicographical order. Then, starting from 0 or 1 (in this embodiment, it starts from 1, reserving 0 for null values ​​or unknown type codes), an incrementing integer is assigned to each sorted string sequentially. For example, the first sorted string is "API_CALL", assigned code GCode=1; the second string is "ASYNC_TASK", assigned code GCode=2; and the 150th string is "ZK_WATCH", assigned code GCode=150.

[0064] Step 1326: Establish a key-value pair mapping relationship with the original string of the test type label as the key and the assigned global unified code as the value, and store the key-value pair mapping relationship as a mapping relationship table between the test type label and the global unified code.

[0065] Finally, the one-to-one correspondence described above is persisted, resulting in a mapping table. Each record in the table contains two fields: raw_type_string (e.g., "API_CALL") and global_type_code (e.g., 1). This table is stored in the metadata database of the coordination and control system and is broadcast or distributed to all test execution nodes so that all nodes can use a unified encoding to replace verbose strings when reporting and processing data, thus standardizing the data format. For example, when a subsequent node reports data, it can replace the test type label field from the string "API_CALL" with the integer 1.

[0066] Step 133: Based on the mapping relationship table, replace all test type labels in the internal test data flow path graph of each node with the corresponding global unified code to obtain the unified code internal test data flow path graph of the node.

[0067] The computer-controlled equipment coordination system uses the newly generated mapping table to update all the original node graphs stored in the central graph database. For each node's internal graph, the system traverses all its vertices, reads the original string of the test type label on the vertex, then looks up the corresponding globally unified code in the mapping table, and writes this code as the new attribute value to the vertex, or replaces the original string label. After this step, the original Graph_A (vertex label is the string "DB_QUERY") is transformed into the uniformly encoded Graph_A' (vertex label is the integer 2). The vertex labels in all graphs are now unified into a global encoding space.

[0068] Step 134: Traverse the complete flow path corresponding to each task identifier in the internal test data flow path graph of all unified-encoded nodes, and extract the global unified code corresponding to the end position node of each complete flow path as the code of the output test type to be matched.

[0069] This step involves the core analysis of cross-node association, namely, finding clues to the flow of data between different nodes. Specifically, starting from the output end of a node, the computer device, through a coordinated control system, traverses the internal graph of each uniformly coded node. For each complete flow path corresponding to a task identifier recorded in the graph (i.e., the task branch in step 124), the system finds the last vertex of that path, i.e., the end position node marked in step 126. The global uniform code GCode_end of that node is read. For example, in the uniformly coded graph of Node_A, the complete flow path of task "T001" ends at the node with a global code of 2. Therefore, GCode_end=2 is considered as the data type code that might be passed out externally after the task on Node_A is completed, i.e., the output test type code to be matched.

[0070] Step 135: In the test data flow path graphs of other nodes besides the node to which the current node belongs, search for whether there is a complete flow path corresponding to the task identifier whose globally unified code is the same as the code of the output test type to be matched.

[0071] The computer equipment instructs the coordination and control system to search the unified coding graphs of all other nodes (Node_B, Node_C, ...) using the output test type code GCode_end=2. The specific search objective is to find the complete flow path corresponding to the task identifier whose global unified code is also 2 for the starting node (i.e., the starting node marked in step 126) in the graphs of other nodes. For example, in the unified coding graph of Node_B, there exists a task "T003" whose starting node's global code is also exactly 2. This constitutes a strong hint: the output data type (code 2) at the end of task "T001" on Node_A is exactly the data type (code 2) that task "T003" on Node_B needs to process at the beginning, and there may be a data transfer relationship between the two.

[0072] Step 136: If a complete flow path is found where the global unified code corresponding to the starting position node is the same as the code of the output test type to be matched, then a directed connection edge is established from the node to which the test data flow path graph belongs within the current node to the node to which the complete flow path belongs, and the directed connection edge is added to the test data cross-node flow association network.

[0073] Based on the findings in step 135, the coordinated control system infers the existence of a data flow edge from Node_A to Node_B. To formally record this association, the system adds a directed edge to the global test data cross-node flow association network (initially an empty graph). The source node of this edge is Node_A (represented by the node identifier "XXX.XXX.X.XXX"), and the destination node is Node_B (represented by the node identifier "YYY.YYY.Y.YYY"). Attributes can also be attached to this edge, such as encoding the associated data type as 2, and the associated task pair ("T001" from Node_A, "T003" from Node_B). By traversing all nodes, the end nodes of all tasks, and the start nodes, steps 134-136 are repeatedly executed, ultimately forming a potentially very complex network composed of nodes (test execution nodes) and directed edges (data flow relationships), namely the test data cross-node flow association network. This network reveals the macroscopic topology of the test data flow across nodes throughout the distributed system.

[0074] Step 137: If no matching complete flow path is found, mark the end node of the test data flow path graph inside the current node as a cross-node flow breakpoint, and add a cross-node flow breakpoint mark to the node to which the test data flow path graph inside the current node belongs in the test data cross-node flow association network.

[0075] If no starting task matching the end code of a task on Node_A can be found in any other node, it indicates that the final data generated by that task may not have been processed by tasks on any other node, meaning the data flow is interrupted. The coordinated control system will not ignore this situation but will mark this end point node on Node_A (e.g., the node with global code 5) as a "cross-node flow breakpoint" in the global network. Simultaneously, in the test data cross-node flow association network, an attribute is added to Node_A itself, such as "sink_nodes:[GCode_5, GCode_7]", to record which output types terminated their flow at this node. This breakpoint information is valuable for identifying the endpoint of the data processing flow or analyzing data loss.

[0076] Step 140: Based on the cross-node flow association network of the test data, divide the test execution nodes into test task execution node groups, and select the core test execution node from each test task execution node group to construct a test data aggregation view within the group.

[0077] After constructing a global, cross-node flow and connection network, this network needs to be structured and analyzed to group closely connected nodes into the same group for finer-grained data aggregation and analysis. This is similar to discovering community structure in a social network.

[0078] In this embodiment of the application, step 140 includes the technical solutions described in steps 141 and 142: Step 141: Based on the cross-node flow association network of the test data, divide the test execution nodes into test task execution node groups; Step 142: Select the core test execution node from each test task execution node group to build a clustered view of test data within the group.

[0079] In detail, step 141 describes dividing the test execution nodes into test task execution node groups based on the cross-node flow association network of the test data, which is achieved through steps 1411-1415.

[0080] Step 1411: Parse the graph structure of the cross-node flow association network of the test data, obtain all node identifiers and directed connection edges between all nodes contained in the cross-node flow association network of the test data, with each directed connection edge pointing from the source node to the target node.

[0081] The coordinated control system first loads the previously constructed test data cross-node flow association network from the database. This network is a directed graph G_global. Parsing the graph structure of G_global yields a set of nodes V, where each element is a node identifier; for example, v1 represents "XXX.XXX.X.XXX" and v2 represents "YYY.YYY.Y.YYY". Simultaneously, a set of edges E is obtained, where each edge is an ordered pair (e_source, e_target). For example, if an edge points from v1 to v2, it indicates that data flows from node v1 to node v2.

[0082] Step 1412: Initialize an empty set of node groups. Select a node identifier from the test data cross-node flow association network that has not yet been assigned to any node group as a seed node. Create a new node group and add the seed node to the new node group.

[0083] To perform group partitioning, a breadth-first search algorithm based on graph connectivity is used. First, an empty group set `Groups=[]` is created. Then, an unvisited node is randomly selected from `V`, for example, `v1` is chosen as the seed node. A new group `Group_1` is created, `v1` is added to `Group_1`, and `v1` is marked as visited.

[0084] Step 1413: Starting from the seed node, perform a breadth-first traversal along the direction of the directed connection edges in the cross-node flow association network of the test data, and add all node identifiers that can be reached from the seed node through the directed connection edges to the new node group; simultaneously, starting from the seed node, perform a breadth-first traversal along the opposite direction of the directed connection edges in the cross-node flow association network of the test data, and add all node identifiers that can be reached from the seed node through the directed connection edges to the new node group.

[0085] This step is crucial for grouping. For group_1, starting from seed node v1, a breadth-first traversal is performed in two directions. First, a forward traversal: starting from v1, all direct downstream nodes (e.g., v2) are found along all outgoing edges (i.e., data flows out of v1); then, starting from v2, the search continues along its outgoing edges until no further downstream nodes can be found. All nodes found in this way, such as v2, v5, and v7, are added to group_1. Second, a reverse traversal: starting from v1, all direct upstream nodes (e.g., v4) are found along all incoming edges (i.e., data flows into v1); then, starting from v4, the search continues along its incoming edges until no further upstream nodes can be found. All nodes found through the reverse traversal, such as v4 and v9, are also added to group_1. In essence, this bidirectional traversal ensures that all nodes with direct or indirect data flow to v1 (regardless of the data flow direction) are grouped into the same group, forming a large, interconnected group.

[0086] Step 1414: Mark all node identifiers in the new node group as assigned, and repeat the steps of selecting unassigned node identifiers as new seed nodes and creating new node groups until all node identifiers in the test data cross-node flow association network are assigned to the corresponding node groups.

[0087] After constructing Group_1, all nodes (v1, v2, v4, v5, v7, v9) are marked as assigned. Then, from the remaining nodes in V (e.g., v3, v6, v8), an unmarked node is selected as the new seed, such as v3, to create a new group, Group_2, and the bidirectional breadth-first traversal in step 143 is repeated. This continues until all nodes in V are assigned to a group. Finally, the entire node set V is divided into several disjoint node groups, such as Group_1, Group_2, and Group_3.

[0088] Step 1415: For each node group, calculate the ratio of the number of directed connection edges within the node group to the maximum number of directed connection edges of all nodes in the node group as the internal connection density of the group. For a node group with an internal connection density lower than the preset density threshold, split the group into multiple subgroups. The splitting method is to remove the node identifier with the least number of connection edges from the group and check whether the remaining node identifiers form a connected component. Each connected component is used as an independent node group.

[0089] The initially divided groups may be too large in scale and have loose internal connections, which is not conducive to the construction of the aggregation view. Therefore, this step performs refined processing on the groups. For a group Group_k, for example, it contains M nodes. The actual number of directed edges existing between the above nodes in G_global is E_actual. The maximum number of directed edges that these M nodes may form (i.e., the number of edges in a complete directed graph) is M*(M - 1). Calculate the internal connection density of the group Density_k = E_actual / (M*(M - 1)). Preset a density threshold Thresh_density, for example, 0.3. If Density_k < Thresh_density, it is considered that the internal connection of the group is not tight enough and may contain relatively independent substructures. At this time, split the group. The splitting algorithm uses a heuristic node removal method: iteratively find the node with the least number of connection edges (i.e., the sum of the in-degree and out-degree of the node) in the current group and temporarily remove it from the group. After each node is removed, check whether the induced subgraph of the remaining nodes in the graph G_global splits into multiple connected components. Once multiple connected components appear, each connected component is used as a new and independent node group, and the previously removed nodes are grouped separately or merged nearby according to their connection relationships. In this way, each test task execution node group finally formed has a high data interaction density internally, providing a structurally reasonable unit for the selection of core nodes and the construction of the view.

[0090] Specifically, selecting core test execution nodes from each test task execution node group to construct an internal test data aggregation view as recorded in step 142 is achieved through steps 1421 - 1426.

[0091] Step 1421: For each test task execution node group, calculate the out-degree value and in-degree value of each test execution node in the test data cross-node flow association network within the group, and select the test execution node with the largest sum of the out-degree value and in-degree value as the core test execution node corresponding to the group.

[0092] After grouping, each group needs to select a core node as the center for data aggregation. For one group, `Group`, it contains nodes {v1, v2, v4, v5}. The coordination and control system queries `G_global` to calculate the out-degree (the sum of directed edges pointing to nodes outside or within the group) and in-degree (the sum of directed edges pointed to by nodes outside or within the group) of each node. For example, for node v1, its out-degree is 5 and in-degree is 3, so the sum `Degree_sum_v1` = 8; for node v2, its out-degree is 4 and in-degree is 2, so the sum is 6; for v4, its out-degree is 1 and in-degree is 7, so the sum is 8; for v5, its out-degree is 2 and in-degree is 1, so the sum is 3. The sums for v1 and v4 are both 8, which is the maximum. If there is a tie, the out-degree or in-degree can be further compared, or a random selection can be made. For example, v1 is ultimately selected as the core test execution node for this group. The selection principle for core nodes is that they have the highest hub status in the entire network (especially within the group) and are most suitable for undertaking the functions of data aggregation and relay.

[0093] Step 1422: The test execution node selected as the core test execution node sends a test data time series synchronization request to other test execution nodes in the same group through the distributed coordination and control system. The test data time series synchronization request includes the start point and end point of the time range to be synchronized.

[0094] Once core node v1 is selected, the distributed coordination and control system issues an instruction to v1, notifying it to become the core of the group and initiating the data aggregation process. Upon receiving the instruction, the agent program on v1 constructs a synchronization request. This request aims to retrieve data generated by other nodes (v2, v4, v5) within a specific time window. The request includes a time range, for example, a start point Start_ts of 1698403200 seconds and an end point End_ts of 1698403500 seconds. This time window typically covers the execution period of the test task that needs to be analyzed or processed. v1 reliably forwards this request to v2, v4, and v5 through the coordination and control system.

[0095] Step 1423: After receiving the test data time series synchronization request, other test execution nodes in the same group read the node test data time series segments located between the start point and the end point of the time range from their respective streaming data buffers, encapsulate the read node test data time series segments into a synchronization response data packet, and send it back to the core test execution node.

[0096] Upon receiving the synchronization request, the agent on node v2 parses the time range [1698403200, 1698403500]. Then, it accesses the local streaming data buffer (circular buffer) and, based on the timestamp index or by traversing storage slots, selects all multi-type test data units whose timestamps fall within this time range. These units are then organized chronologically to form a time series segment, Segment_v2. The agent encapsulates Segment_v2 into a synchronization response packet, which contains the source node identifier v2 and the sequence segment itself. Similarly, v4 and v5 each generate Segment_v4 and Segment_v5, respectively, and send them back to the core node v1. The data packets are compressed using a compression algorithm (such as Snappy or LZ4) to reduce network transmission overhead.

[0097] Step 1424: Receive synchronization response data packets returned by all other test execution nodes in the same group through the core test execution node, and parse out the corresponding node test data time series segment and the node identifier of the test execution node to which each node test data time series segment belongs from each synchronization response data packet.

[0098] Core node v1 continuously listens for responses from v2, v4, and v5. Upon receiving a data packet, v1 first decompresses it, then deserializes it to obtain the time-series segment and the source node identifier. v1 also prepares its own local node test data time-series segment, Segment_v1, for the same time window. At this point, v1 possesses complete data from all nodes within the group for the specific time window.

[0099] Step 1425: Using the starting point of the time range as the alignment reference, the core test execution node aligns and arranges its own node test data time series segments with the node test data time series segments of all other received test execution nodes in parallel according to the timestamp, generating a group-wide test data aggregation view containing multiple rows of data sequences.

[0100] The core node v1 now needs to integrate the collected sequences. It aligns them based on timestamps. A two-dimensional data structure is created with timestamps as row indices and node identifiers as column names. Starting from Start_ts=1698403200, the entire time window is traversed in very small steps (e.g., 1 millisecond) or based on the actual timestamp of the data unit. For each time point t, v1 checks whether there are data units in Segment_v1, Segment_v2, Segment_v4, and Segment_v5 that produce timestamps approximately equal to t. If any node has data at time point t, a summary or storage pointer for that data unit is entered into the corresponding column; otherwise, an empty value is entered. This ultimately forms a time-axis aligned view View_Group. For example, one row of the view might display: timestamp t=1698403200.123, node v1 has data unit A1, node v2 has data unit B1, node v4 has no data, and node v5 has no data. The next line shows t=1698403200.456, node v1 has no data, node v2 has data B2, node v4 has data C1, and node v5 has no data. This view intuitively shows the data generation on different nodes at the same time dimension.

[0101] Step 1426: In the test data aggregation view within the group, identify multiple types of test data units with the same task identifier in the time series segments of node test data of different test execution nodes through the core test execution node, and draw intra-group dependency connection lines between the multiple types of test data units.

[0102] After constructing the aligned view, this step further explores task relationships across nodes. v1 scans each non-empty data unit in the View_Group, parsing the task identifier in its data encapsulation header. For example, in v1's sequence fragment, there is a unit Unit_A with a task identifier of TaskX. v1 continues to search the view for data units with the same task identifier TaskX on other nodes (v2, v4, v5). For example, in v2's sequence fragment, Unit_B is found, also with the task identifier TaskX. Based on their chronological order on the timeline (Unit_A first, Unit_B second) and their type conversion relationship (the ending type of Unit_A may match the starting type of Unit_B via step 136), v1 infers a dependency relationship between Unit_A and Unit_B. Then, v1 draws a directed line on the converged view View_Group, from the row and column where Unit_A is located to the row and column where Unit_B is located. In this way, v1 connects all data units that belong to the same cross-node transaction and are scattered on different nodes within the group with dependency lines, so that the originally isolated data points are re-associated in the business logic. This draws a view of dependency lines, which is the final form of the test data aggregation view within the group, providing a visual basis for understanding the complex multi-node data flow within the group.

[0103] Step 150: Extract the test data unit chain corresponding to the process test transaction that spans multiple nodes based on the dependency relationship in the test data aggregation view within the group, assign a globally unique transaction tracking identifier to the test data unit chain and inject it back into the streaming data cache area of ​​the corresponding test execution node.

[0104] After generating a converged view containing dependency connections, the computer device needs to extract complete transaction chains from the above relationships and assign them globally unique labels so that end-to-end transaction tracing can be performed based on the labels, similar to the concepts of Trace and Span in distributed tracing. However, the embodiments in this specification are implemented at the test data level.

[0105] Step 151: Scan all the intra-group dependency lines drawn in the intra-group test data aggregation view through the core test execution node. Starting from the multi-type test data unit corresponding to the starting end of the intra-group dependency line of each test task execution node, trace and traverse along the direction of the intra-group dependency line.

[0106] The computer initiates a graph traversal algorithm via the core node v1, operating on the dependency connections in the converged view. These connections and the data units they connect form a directed acyclic graph (DAG). v1 first identifies all data units without incoming edges (i.e., no other connections point to them); these units represent the starting points of potential transaction chains. One of these starting points is chosen, for example, unit Start_A on v1, and a depth-first traversal begins. Along each outgoing edge from Start_A, the algorithm moves to a unit on the next node (e.g., Unit_B on v2), and continues moving from Unit_B along its outgoing edges.

[0107] Step 152: During the tracing process, record the dependency relationship connection within the group and the multi-type test data units corresponding to both ends of the connection each time, and connect the multi-type test data units in sequence according to the tracing order to form an initial test data unit chain.

[0108] During the traversal, the algorithm records the paths traversed. Each time a connection is traversed, the data unit at the target end of that connection is added to the record list of the current path. For example, starting from Start_A, traversing connection L1 to Unit_B, the record list is [Start_A, Unit_B]; then starting from Unit_B, traversing connection L2 to Unit_C, the record list is updated to [Start_A, Unit_B, Unit_C]. This list, arranged in the order of traversal, constitutes an initial chain of test data units.

[0109] Step 153: Determine whether there are still intra-group dependency connections pointing to other intra-group dependency connections on other test execution nodes for the currently tracked multi-type test data units. If so, continue tracing along the newly discovered intra-group dependency connections and add the newly tracked multi-type test data units to the end of the initial test data unit chain.

[0110] Upon reaching Unit_C, check the outgoing edges of Unit_C. If Unit_C still has outgoing edges pointing to another node, Unit_D, continue tracing, add Unit_D to the chain, and the chain becomes [Start_A, Unit_B, Unit_C, Unit_D]. This process is repeated until the current unit no longer has any outgoing edges.

[0111] Step 154: If the currently tracked multi-type test data units do not have intra-group dependency connections pointing to other multi-type test data units, stop tracking and determine the currently obtained initial test data unit chain as a complete test data unit chain corresponding to a process test transaction that spans multiple test execution nodes.

[0112] When traversing to one of the units, Unit_Z, and finding that it has no outgoing edges, it indicates that this branch has reached its end. At this point, all the data units along the path from the starting point Start_A to the ending point Unit_Z constitute a complete chain of test data units corresponding to a multi-node process test transaction. For example, the final chain Chain_001 = [Start_A(onv1), Unit_B(onv2), Unit_C(onv2), Unit_Z(onv5)] represents the complete footprint of data generated by one test transaction (such as a complete user login process) across different nodes.

[0113] Step 155: Generate a globally unique transaction trace identifier for each determined test data unit chain through the core test execution node. The globally unique transaction trace identifier is composed of the node identifier of the core test execution node, the generation timestamp, and the incrementing sequence number.

[0114] To uniquely identify and trace this transaction chain within massive amounts of data, core node v1 generates a globally unique transaction trace identifier, TraceID. This identifier's generation strategy combines several pieces of information to ensure its global uniqueness. First, it includes the core node's identifier, such as "v1_XXX.XXX.X.XXX". Second, it includes a high-precision timestamp used to generate the identifier, such as "1698403600123" (represented in milliseconds by the current Unix timestamp). Finally, it includes a monotonically increasing sequence number on that node; for example, "00001" for the first chain generated that day. These three parts are concatenated using a specific separator (such as an underscore) to obtain TraceID="v1_XXX.XXX.X.XXX_1698403600123_00001". Since the combination of timestamps and sequence numbers is extremely unlikely to repeat across different core nodes, and the node identifier ensures namespace isolation, this TraceID is globally unique throughout the distributed system.

[0115] Step 156: Append the generated globally unique transaction trace identifier to the data encapsulation header of each multi-type test data unit contained in the test data unit chain.

[0116] After obtaining the TraceID, the final step is to write it back to the data itself. Core node v1, based on the records in Chain_001, knows that the chain contains Start_A on v1, Unit_B and Unit_C on v2, and Unit_Z on v5. v1 constructs an injection instruction and sends it to node v1 itself (processing local units), v2, and v5 respectively. The instruction contains the identifier of the unit to be injected (e.g., located by the unit's storage address or unique ID in the streaming buffer) and the TraceID value to be appended, "v1_XXX.XXX.X.XXX_1698403600123_00001". Upon receiving the instruction, the agent programs on each node locate the specified multi-type test data unit, find the reserved field or expandable area in its data encapsulation header, and write the TraceID. After this step, the data units that originally belonged to the same distributed transaction and were scattered in the cache areas of various nodes all have the same TraceID. This TraceID is like an invisible thread that connects them together and serves as the direct index key for global transaction tracing.

[0117] In an optional embodiment, after step 150, the method further includes: Step 161: Receive the global transaction tracing instruction issued to the node group for each test task, parse the target time window boundary carried in the global transaction tracing instruction, and locate the local multi-type test data unit set within the corresponding time interval in the node test data time series stored in the local streaming data buffer according to the target time window boundary.

[0118] After completing the data back-injection, this specification also provides a method for post-event tracing based on TraceID. When it is necessary to investigate a distributed test transaction that occurred within a specific time period, such as a time window T_start=1698403200 to T_end=1698403500, a global transaction tracing instruction can be issued to all node groups (or a specified group) through the coordination and control system. After receiving the instruction, the agent program on one of the test execution nodes (e.g., Node_D) parses out the target time window boundary. Then, Node_D accesses its local streaming data buffer, traverses all storage slots in the circular buffer, and filters out all multi-type test data units whose timestamps fall within this time window [1698403200, 1698403500], forming a local multi-type test data unit set Set_D_local.

[0119] Step 162: Extract all test data units to be traced that carry the globally unique transaction tracking identifier from the local multi-type test data unit set, and send a data unit tracing request according to the node source tag parsed from the data encapsulation header of the test data unit to be traced.

[0120] Node_D iterates through Set_D_local, and for each data unit, parses its data encapsulation header to check if it contains a TraceID field. If it does, for example, if a TraceID value of "v1_XXX.XXX.X.XXX_1698403600123_00001" is parsed, the unit is marked as a test data unit to be traced, and this TraceID is recorded. Then, Node_D doesn't just process local data; it needs to collect data from other nodes with the same TraceID. To do this, Node_D constructs a data unit tracing request, the core information of which is this TraceID. Node_D sends the request to the distributed coordination and control system, requesting the system to help address or broadcast it to all other nodes.

[0121] Step 163: Receive associated test data units with the same globally unique transaction trace identifiers read from the corresponding local streaming data buffer in response to the data unit traceability request; arrange all collected test data units with the same globally unique transaction trace identifiers in a global time sequence according to the order in which the timestamps were generated; and generate a cross-node complete test data timeline corresponding to each globally unique transaction trace identifier.

[0122] The distributed coordination and control system broadcasts the trace request to all other test execution nodes (or precisely locates nodes that may contain the TraceID through metadata indexing). Other nodes, such as Node_E, upon receiving the request, search their local streaming data buffer for all data units containing the TraceID "v1_XXX.XXX.X.XXX_1698403600123_00001", and package these units back to the request initiator Node_D (or directly to the coordination and control system for aggregation). Node_D (or the coordination and control system) ultimately collects all test data units carrying the same TraceID from Node_D itself, Node_E, and other nodes. Then, using the timestamps of each unit's creation as the sorting key, all units are globally sorted. The sorted list is an ordered list, for example: Unit_A(t=1698403200.100, onNode_D), Unit_B(t=1698403200.500, onNode_E), Unit_C(t=1698403200.700, onNode_F)... This list is the timeline of the complete cross-node test data corresponding to the TraceID, which accurately restores the time series and spatial distribution of the data generated when the test transaction is executed in a distributed environment.

[0123] Step 164: Compare the time interval between adjacent test data units in the cross-node complete test data timeline with a preset process interruption threshold. If there is an abnormal time interval exceeding the process interruption threshold, mark the process interruption position in the cross-node complete test data timeline, encapsulate the cross-node complete test data timeline marked with the process interruption position into a global transaction traceability result data packet and send it back.

[0124] After constructing the complete timeline, this embodiment further analyzes whether the transaction execution is smooth. The time interval between two adjacent units on the timeline is calculated; for example, the interval between Unit_A and Unit_B is Delta_AB = 0.4 seconds, and the interval between Unit_B and Unit_C is Delta_BC = 0.2 seconds. A process interruption threshold, Thresh_break, is preset, for example, 5 seconds. This threshold can be configured according to the business's tolerance for latency. If one of the intervals, such as the interval between Unit_X and Unit_Y, Delta_XY, reaches 6 seconds, exceeding Thresh_break, it is considered that a process interruption or long wait occurred between Unit_X and Unit_Y, which may indicate a performance bottleneck or error. The system inserts a "process interruption" marker between Unit_X and Unit_Y on the generated timeline and records the interruption duration as 6 seconds. Finally, this timeline, containing a list of data units and possible interruption markers, is encapsulated into a global transaction traceability result data packet and returned to the client initiating the traceability through the coordination and control system. Users can clearly see the complete trajectory of the entire transaction and any anomalies that occur through this data packet.

[0125] In an optional embodiment, after step 150, the method further includes: Step 171: Scan the time series of node test data stored in all streaming data buffers within each test task execution node group, identify all completed trace test data units carrying the globally unique transaction tracing identifier, and draw the spatiotemporal distribution trajectory of the data unit corresponding to each globally unique transaction tracing identifier in the test data aggregation view within the group according to the test type label and generation timestamp information corresponding to each completed trace test data unit.

[0126] In addition to passive tracing, this specification also provides a method for proactively analyzing abnormal processes. After an offline analysis cycle ends, or during real-time processing, the system can initiate analysis of test transactions that have been traced. The coordinated control system or a designated core node (such as v1) scans the streaming data buffers of all nodes (including itself) within its group, filtering out all data units that already carry a TraceID (i.e., data that has been traced). For each TraceID, such as TraceID_Alpha, the system collects all units it contains. Then, these points are plotted in a two-dimensional spatiotemporal coordinate system: the horizontal axis represents the timestamp, and the vertical axis represents the node identifier. Each unit corresponds to a point in the coordinate system based on its timestamp and the node it belongs to. All points belonging to TraceID_Alpha are connected in chronological order to generate the spatiotemporal distribution trajectory of the transaction's data units, which visually demonstrates the path the transaction travels between different nodes over time.

[0127] Step 172: Analyze the jump patterns of adjacent test data units between different test execution nodes in the spatiotemporal distribution trajectory of the data units corresponding to the same globally unique transaction tracking identifier, and generate the cross-node execution path sequence corresponding to the globally unique transaction tracking identifier according to the order of appearance of the test execution nodes in the jump patterns.

[0128] From the spatiotemporal distribution trajectory, the node-level execution path can be further extracted. For the trajectory of TraceID_Alpha, the system analyzes the points where nodes change. For example, the trajectory shows: time t1, node v1; time t2, node v1; time t3, node v2; time t4, node v3; time t5, node v3; time t6, node v4. By ignoring consecutive stops on the same node, the order of node changes is extracted: v1->v2->v3->v4. This node sequence is the cross-node execution path sequence Path_Alpha=[v1, v2, v3, v4] corresponding to TraceID_Alpha, which describes the route of the test transaction in the distributed system.

[0129] Step 173: Compare the path similarity between the cross-node execution path sequence and the preset baseline process path template. If the path similarity between the cross-node execution path sequence and the baseline process path template is lower than the preset similarity threshold, it is determined that the process test transaction corresponding to the globally unique transaction tracking identifier has a path execution deviation. The globally unique transaction tracking identifier with path execution deviation and its corresponding cross-node execution path sequence are marked as abnormal transaction records. The node identifier of the test execution node involved in the abnormal transaction record is associated and encapsulated with the timestamp of the generation of the multi-type test data unit corresponding to the occurrence of the abnormality, and a transaction execution deviation alarm data unit is generated and sent.

[0130] The system has a pre-defined baseline process path template. For example, a normal user login transaction is expected to initiate a request at node v1, then proceed to node v2 for authentication, and finally to node v3 for logging. Its template path is Template_Login=[v1, v2, v3]. Now, the actual path Path_Alpha=[v1, v2, v3, v4] is compared with Template_Login. Path similarity can be calculated using various algorithms, such as the Longest Common Subsequence (LCS). The LCS of Path_Alpha and Template_Login is [v1, v2, v3], with a length of 3. The template length is 3, and the actual path length is 4. A simple similarity score can be defined as LCS length / max(actual path length, template path length) = 3 / 4 = 0.75. A preset similarity threshold, Thresh_sim, is set, for example, 0.9. Since 0.75 < 0.9, the system determines that the transaction TraceID_Alpha has a path execution deviation (it traversed an extra node v4). Therefore, the system records TraceID_Alpha and its actual path Path_Alpha as an abnormal transaction record. Simultaneously, to accurately pinpoint the location of the anomaly, the system identifies the node and timing of the deviation within the path, specifically the first occurrence of node v4 that does not match the template, and the timestamp t4 of the data unit generated when entering v4. Finally, the above information (abnormal transaction record, involved node v4, and abnormal timestamp t4) is encapsulated into a transaction execution deviation alarm data unit and sent to the monitoring center or operations personnel via message queue or direct push for timely intervention and investigation. In this way, the embodiment in this specification achieves automated abnormal behavior detection and alarming for distributed testing processes.

[0131] Please see Figure 2The figure is a schematic diagram of the basic structure of a computer device 200 provided in an embodiment of this application. The computer device 200 includes: a processor 201; a storage device 202 on which a computer program 2020 is stored; and a network interface 203 for providing network communication functions. When the computer program 2020 is executed by the processor 201, the processor 201 implements any of the multi-type test data processing methods based on distributed computing.

[0132] Please see Figure 3 This application provides a functional block diagram of a multi-type test data processing device based on distributed computing. The multi-type test data processing device based on distributed computing includes: The test data encapsulation module is used to capture the native test data stream generated during the execution of the test task at each test execution node, encapsulate the native test data stream into multi-type test data units carrying node source tags and test type tags, and store the multi-type test data units in the local streaming data buffer to generate a node test data time series with a continuous time span. The path graph generation module is used to generate a path graph of the internal test data flow of each test execution node based on the time interval and type conversion relationship between multiple types of test data units in the time series of the node test data. The cross-node association analysis module is used to send the test data flow path graph within all nodes to the distributed coordination and control system for cross-node association analysis, generating a test data cross-node flow association network containing directed edges for test data transmission. The convergence view construction module is used to divide the test execution nodes into test task execution node groups based on the cross-node flow association network of the test data, and select the core test execution node from each test task execution node group to construct a convergence view of the test data within the group; The chain identifier allocation module is used to extract the test data unit chain corresponding to the process test transaction that spans multiple nodes according to the dependency relationship in the test data aggregation view within the group, assign a globally unique transaction tracking identifier to the test data unit chain and inject it back to the streaming data cache area of ​​the corresponding test execution node.

[0133] Please refer to the following: Figure 4This application constructs a complete technical chain from raw data capture to global transaction identifier back-injection, achieving a deep deconstruction and explicit representation of cross-node data flow logic in distributed testing scenarios. First, multiple types of test data units carrying node source and test type labels are generated locally on each test execution node, forming a continuous time series as a structured data foundation with spatiotemporal and type attributes. Then, based on the time intervals and type conversion relationships between data units in the time series, an internal test data flow path graph is generated, completing the abstract modeling of the data processing logic within a single node. All internal node graphs are aggregated into a distributed coordination and control system for cross-node correlation analysis. By matching the type codes of the start and end nodes in different node graphs, a cross-node test data flow correlation network containing directed edges for test data transmission is generated, achieving global topology reconstruction of the data transmission path between multiple nodes. Based on this flow association network, the test execution nodes are divided into test task execution node groups, and core nodes are selected to build a test data aggregation view within the group. At the group level, the spatiotemporal alignment and dependency visualization of cross-node data are realized. Finally, based on the dependency relationship in the aggregation view, the test data unit chain corresponding to the process test transaction that spans multiple nodes is extracted and a globally unique transaction tracking identifier is assigned and injected back to the cache area of ​​each node. A data footprint index that runs through all participating nodes is established for each distributed transaction.

[0134] Therefore, this application constructs a layer-by-layer abstraction and reverse mapping mechanism from the original data stream to the transaction-level tracking identifier. It transforms the originally isolated, heterogeneous, and disordered multi-type test data in the distributed environment into an ordered data structure with clear node paths, type conversion logic, and transaction ownership relationships through the construction and correlation analysis of multi-level graphs. This improves the technical difficulties of tracing cross-node data lineage and ensuring transaction integrity in distributed testing scenarios, enhances the observability and diagnosability of the testing process of complex distributed systems, and solves the technical problem of serious lag or even absence in the construction of data lineage, making it difficult to achieve integrity analysis and anomaly localization of test transactions.

[0135] It is understood that those skilled in the art, based on the above content, can fully and clearly implement the technical solutions of the embodiments in this specification based on existing technology and common knowledge. At the data acquisition and local processing level, using a proxy program to intercept system calls via eBPF or ptrace mechanisms to capture raw test data non-intrusively is a mature technology for achieving high-performance observability in the Linux environment. The stable interface provided by the kernel ensures the security of cross-process memory data reading. Using a lock-free circular queue as a send buffer to smooth the difference between data production and consumption rates is also a standard practice in high-throughput data acquisition scenarios. When constructing the data flow path graph within a node, correlation analysis is performed based on the timestamp and type label of the data unit. Even if there are microsecond-level time precision differences or inconsistent type label strings, those skilled in the art can ensure the accuracy of the analysis by dynamically adjusting the time threshold, configuring regular expression rules, or introducing a correlation strategy based on event sequence numbers rather than absolute time. All of these techniques are conventional methods that can be flexibly configured according to actual conditions.

[0136] At the level of cross-node data integration and global graph construction, uniformly mapping test type labels uploaded by different nodes, which may use different strings to express the same meaning, to a global code is a fundamental method to solve the semantic heterogeneity problem. This can be achieved through manual configuration or automatic matching algorithms based on string similarity. Node grouping based on the connectivity of directed graphs is a standard breadth-first search algorithm in graph computing. The splitting strategy used for sparsely connected groups is essentially an iteratively verifiable graph cut simplification method. Those skilled in the art can adjust the splitting threshold and strategy according to the actual network topology to achieve the desired clustering effect. When aggregating data within a group at core nodes, aligning multi-source data based on timestamps is a routine operation in time-series data processing. Even if there are slight deviations in the clocks of different nodes, this can be overcome through network time protocol synchronization or the introduction of tolerance windows.

[0137] At the transaction tracing and anomaly analysis level, assigning globally unique tracking identifiers to cross-node data chains and injecting them back into the caches of each node is highly consistent with the implementation principles of distributed tracing systems. The identifier generation strategy, combining node identifiers, timestamps, and sequence numbers, ensures global uniqueness and is a common industry solution. Cross-node data backtracking based on this identifier, and marking process interruption locations by calculating the time interval between adjacent data units, can effectively pinpoint performance bottlenecks. By comparing the parsed cross-node execution paths with preset templates and employing classic algorithms such as the longest common subsequence, combined with configurable similarity thresholds, automated anomaly detection can be achieved. Regarding the potential issue of cached data overwriting leading to tracing failures, those skilled in the art can ensure data availability by adjusting cache retention strategies or introducing persistent storage; these technical decisions are all within the scope of existing knowledge and can be effectively implemented.

[0138] Based on the above, a readable storage medium is provided, on which a program or instructions are stored, and when the program or instructions are executed by a processor, the steps of the above method are implemented.

[0139] Furthermore, it should be noted that this application also provides a computer program product, which may include a computer program that can be stored in a computer-readable storage medium. The processor of a computer device reads the computer program from the computer-readable storage medium, and the processor can execute the computer program, causing the computer device to perform the aforementioned... Figure 1 The methods described in the corresponding embodiments are already known, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program product embodiments related to this application, please refer to the description of the method embodiments of this application.

[0140] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.

Claims

1. A method for processing multi-type test data based on distributed computing, characterized in that, The method includes: At each test execution node, capture the raw test data stream generated during the execution of the test task, encapsulate the raw test data stream into multi-type test data units carrying node source tags and test type tags, and store the multi-type test data units in a local streaming data buffer to generate a node test data time series with a continuous time span; Based on the time intervals and type conversion relationships between multiple types of test data units in the time series of the node test data, a test data flow path map is generated for each test execution node; Send the test data flow path graph within all nodes to the distributed coordination and control system for cross-node correlation analysis, and generate a test data cross-node flow correlation network containing directed edges for test data transmission; Based on the cross-node flow association network of the test data, the test execution nodes are divided into test task execution node groups, and a core test execution node is selected from each test task execution node group to construct a test data aggregation view within the group; Based on the dependencies in the test data aggregation view within the group, extract the test data unit chain corresponding to the process test transaction that spans multiple nodes, assign a globally unique transaction tracking identifier to the test data unit chain, and inject it back into the streaming data cache of the corresponding test execution node.

2. The method according to claim 1, characterized in that, The process involves capturing the raw test data stream generated during the execution of test tasks at each test execution node, and encapsulating the raw test data stream into multi-type test data units carrying node source tags and test type tags, including: A test task execution agent is installed on each test execution node in the distributed computing environment. The test task execution agent receives the test task start command issued by the distributed coordination and control system and creates a test task execution process instance in the local operating system process according to the task parameter information carried in the test task start command. During the execution of the test task execution process instance, the test task execution agent program intercepts the data write operations that the test task execution process instance writes to the local file system, and captures the original test data content in the memory buffer corresponding to the data write operation. The task identifier corresponding to the test task currently being executed by the test task execution process instance is parsed from the original test data content, and the node network address of the test execution node where the test task execution agent program is located is obtained as the node source tag; Read the test data type identifier field contained in the original test data content generated by the test task execution process instance, and convert the test data type identifier field into a unified test type classification code as a test type label; The captured raw test data content is arranged in the order of its generation time. The raw test data content captured at each time point is combined and encapsulated with the corresponding task identifier, node source label and test type label to generate the data encapsulation packet header corresponding to the raw test data content. The resulting data payload unit containing the data encapsulation packet header and the raw test data content is used as a multi-type test data unit. The test task execution agent maintains a multi-type test data unit sending queue, and the generated multi-type test data units are pushed into the multi-type test data unit sending queue in chronological order.

3. The method according to claim 1, characterized in that, The step of storing the multi-type test data units into a local streaming data buffer to generate a node test data time series with a continuous time span includes: In the local memory space of each test execution node, a circular buffer of a set capacity is allocated as a streaming data cache area, and an independent cache writing thread and cache reading thread are configured for the streaming data cache area. The cache writing thread continuously monitors the multi-type test data unit sending queue in the test task execution agent program. When it detects that there are multi-type test data units to be processed in the multi-type test data unit sending queue, the multi-type test data unit is taken out from the head of the multi-type test data unit sending queue. Parse the data encapsulation header of the extracted multi-type test data units, extract the generation timestamp information contained in the data encapsulation header, calculate the write position index of the multi-type test data units in the circular buffer based on the generation timestamp information, and write the multi-type test data units into the corresponding storage slots of the circular buffer according to the write position index. The cache read thread scans all storage slots in the circular buffer at set time intervals, reads the written multi-type test data units from each storage slot, and arranges the read multi-type test data units into a linear sequence according to the write position index corresponding to the storage slot in ascending order. The difference between the timestamps generated by adjacent test data units of multiple types in the linear sequence is calculated. If the difference between the timestamps exceeds the preset time discontinuity threshold, an empty data unit identifier is inserted between the adjacent test data units of multiple types. The original test data content corresponding to each multi-type test data unit in the linear sequence after time fault gap filling is serialized and encoded to generate a node test data time series with a continuous time span for each test execution node.

4. The method according to claim 1, characterized in that, The step of generating an internal test data flow path graph for each test execution node based on the time intervals and type conversion relationships between multiple types of test data units in the time series of the node test data includes: Parse the time series of node test data corresponding to each test execution node, and traverse each multi-type test data unit sequentially from the starting position of the node test data time series to obtain the generation timestamp information, test type label and task identifier in the data encapsulation header corresponding to each multi-type test data unit; The time interval between adjacent multi-type test data units is calculated based on the recorded generation timestamp information. Adjacent multi-type test data units with a time interval less than a preset adjacent time threshold are marked as test data unit pairs with a continuous generation relationship. Identify the conversion pattern between the test type label of the previous multi-type test data unit and the test type label of the next multi-type test data unit in a test data unit pair with a continuous generation relationship, and determine the type conversion path of the test data type evolving sequentially during the execution of the same test task; Based on the order of the timestamps of all the test data units of the same task identifier, the test data units of the same task identifier are connected in the order of the timestamps to form the internal data flow path branches of the task. Merge branches with the same test type conversion pattern in all task internal data flow path branches to obtain a directed graph structure with test type label as node and type conversion relationship as directed edge, which serves as the test data flow path graph inside the node; Traverse all task identifiers corresponding to the multi-type test data units in the time series of node test data, extract the starting and ending multi-type test data units corresponding to each task identifier, and mark the start and end position nodes of the flow path corresponding to each task identifier in the test data flow path graph inside the node.

5. The method according to claim 1, characterized in that, The step of sending the test data flow path graph within all nodes to the distributed coordination and control system for cross-node association analysis generates a test data cross-node flow association network containing directed edges for test data transmission, including: The distributed coordination and control system receives the internal test data flow path graphs sent by all test execution nodes, assigns a corresponding node identifier to each internal test data flow path graph, and stores the received internal test data flow path graphs in the central graph database. Extract the set of test type labels contained in the internal test data flow path graph of all nodes from the central graph database, perform global unified encoding on each test type label appearing in the set of test type labels, and establish a mapping relationship table between test type labels and global unified encoding; Based on the mapping table, replace all test type labels in the internal test data flow path graph of each node with the corresponding global unified code to obtain the unified code internal test data flow path graph of the node. Traverse the complete flow path corresponding to each task identifier in the internal test data flow path graph of all unified encoded nodes, extract the global unified code corresponding to the end position node of each complete flow path, and use it as the output test type code to be matched. In the test data flow path graphs of other nodes besides the node to which the current node belongs, search for whether there is a complete flow path corresponding to the task identifier whose global unified code is the same as the code of the output test type to be matched, which is the same as the code of the starting position node. If a complete flow path is found where the global unified code corresponding to the starting position node is the same as the code of the output test type to be matched, then a directed connection edge is established from the node to which the test data flow path graph belongs within the current node to the node to which the complete flow path belongs, and the directed connection edge is added to the test data cross-node flow association network. If no matching complete flow path is found, the end node of the test data flow path graph inside the current node is marked as a cross-node flow breakpoint, and a cross-node flow breakpoint mark is added to the node to which the test data flow path graph inside the current node belongs in the test data cross-node flow association network.

6. The method according to claim 5, characterized in that, The process involves extracting a set of test type labels from the central graph database, including the test data flow path graph within all nodes; performing a globally unified encoding on each test type label appearing in the set; and establishing a mapping table between test type labels and the globally unified encoding. This includes: A global unified coding generation process is initiated through a distributed coordination and control system. The global unified coding generation process sequentially accesses the internal test data flow path graph of each node stored in the central graph database. For the test data flow path graph inside the currently accessed node, parse all the nodes contained in the test data flow path graph inside the node. Each node corresponds to a test type label, and extract the original string of the test type label for each node. Add the extracted original string of the test type label to the global test type label summary set, and check whether there is already a string record in the global test type label summary set that is exactly the same as the original string of the current test type label. If there is no string record in the global test type label summary set that is exactly the same as the original string of the current test type label, then insert the original string of the current test type label as a new entry into the global test type label summary set. After traversing the test data flow path graph within all nodes, obtain the total number of original strings of test type labels contained in the global test type label summary set, and determine the encoding bit length of the global unified encoding based on the total number. Based on the insertion order of the original strings of the test type labels in the global test type label summary set, each original string of the test type label is assigned a globally unified code that increments sequentially from the initial code value. Establish a key-value pair mapping relationship with the original string of the test type label as the key and the assigned global unified code as the value, and store the key-value pair mapping relationship as a mapping relationship table between the test type label and the global unified code.

7. The method according to claim 1, characterized in that, The test execution nodes are divided into test task execution node groups based on the cross-node flow association network of the test data, including: The graph structure of the cross-node flow association network of the test data is parsed to obtain all node identifiers and directed connection edges between all nodes contained in the cross-node flow association network of the test data, with each directed connection edge pointing from the source node to the target node. Initialize an empty set of node groups, select a node identifier from the test data cross-node flow association network that has not yet been assigned to any node group as a seed node, create a new node group and add the seed node to the new node group; Starting from the seed node, a breadth-first traversal is performed along the direction of the directed connection edges in the cross-node flow association network of the test data, and all node identifiers that can be reached from the seed node through the directed connection edges are added to the new node group; simultaneously, starting from the seed node, a breadth-first traversal is performed in the opposite direction along the directed connection edges in the cross-node flow association network of the test data, and all node identifiers that can be reached from the seed node through the directed connection edges are added to the new node group. Mark all node identifiers in the new node group as assigned, and repeat the steps of selecting unassigned node identifiers as new seed nodes and creating new node groups until all node identifiers in the test data cross-node flow association network are assigned to the corresponding node groups. For each node group, the ratio of the number of directed edges within the node group to the maximum number of directed edges in all nodes of the node group is used as the connection density within the group. For node groups whose connection density is lower than a preset density threshold, the node group is split into multiple subgroups. The splitting method is to remove the node identifier with the fewest connected edges from the node group and check whether the remaining node identifiers form a connected component. Each connected component is treated as an independent node group.

8. The method according to claim 1 or 7, characterized in that, The step of selecting core test execution nodes from each test task execution node group to construct a clustered view of test data within the group includes: For each test task execution node group, calculate the out-degree and in-degree values ​​of each test execution node in the cross-node flow association network of test data, and select the test execution node with the largest sum of out-degree and in-degree values ​​as the core test execution node corresponding to the group. The selected test execution node sends a test data time series synchronization request to other test execution nodes in the same group through the distributed coordination and control system. The test data time series synchronization request includes the start point and end point of the time range to be synchronized. After receiving the test data time series synchronization request, other test execution nodes in the same group read the node test data time series fragments located between the start point and the end point of the time range from their respective streaming data buffers, encapsulate the read node test data time series fragments into a synchronization response data packet and send it back to the core test execution node; The core test execution node receives synchronization response data packets returned by other test execution nodes in the same group, and parses out the corresponding node test data time series segment and the node identifier of the test execution node to which each node test data time series segment belongs from each synchronization response data packet. Using the starting point of the time range as the alignment reference, the core test execution node aligns and arranges its own node test data time series segments with the node test data time series segments of all other received test execution nodes in parallel according to the timestamp, generating a group test data aggregation view containing multiple rows of data sequences. In the test data aggregation view within the group, multiple types of test data units with the same task identifier are identified in the time series segments of node test data of different test execution nodes through the core test execution node, and intra-group dependency relationship lines are drawn between the multiple types of test data units.

9. The method according to any one of claims 1-7, characterized in that, The step of extracting test data unit chains corresponding to process test transactions spanning multiple nodes based on dependencies in the aggregated view of test data within the group, and assigning globally unique transaction tracking identifiers to the test data unit chains, includes: The core test execution node scans all the intra-group dependency relationship lines drawn in the intra-group test data aggregation view. Starting from the multi-type test data unit corresponding to the beginning of the intra-group dependency relationship line of each test task execution node, the node traces and traverses along the direction of the intra-group dependency relationship line. During the traversal process, the dependency relationship connection within the group and the multi-type test data units corresponding to both ends of the connection are recorded each time, and the multi-type test data units are connected sequentially according to the traversal order to form an initial test data unit chain. Determine whether there are still intra-group dependency connections pointing to other intra-group dependency connections on other test execution nodes for the currently tracked multi-type test data units. If so, continue tracing along the newly discovered intra-group dependency connections and add the newly tracked multi-type test data units to the end of the initial test data unit chain. If the currently tracked multi-type test data units do not have intra-group dependency connections pointing to other multi-type test data units, then stop tracking and determine the currently obtained initial test data unit chain as a complete test data unit chain corresponding to a process test transaction that spans multiple test execution nodes; The core test execution node generates a globally unique transaction trace identifier for each defined chain of test data units. The globally unique transaction trace identifier is composed of the node identifier of the core test execution node, the generation timestamp, and the incrementing sequence number. The generated globally unique transaction tracking identifier is appended to the data encapsulation header of each multi-type test data unit contained in the test data unit chain.

10. A computer device, characterized in that, include: A processor; a storage device having a computer program stored thereon; a network interface for providing network communication functions; when the computer program is executed by the processor, the processor enables the processor to implement the multi-type test data processing method based on distributed computing as described in any one of claims 1-9.

Images