Test data management method and device, storage medium and terminal

Abstract

This specification discloses a method, apparatus, storage medium, and terminal for managing test data. First, atomic operation data during test case execution is automatically captured by various applications and centrally collected to a verification platform, ensuring comprehensive and automated data acquisition and providing a complete data source for subsequent processing. Second, the raw data is aggregated according to multiple dimensions to generate structured aggregated data, integrating fragmented information and facilitating testers to quickly locate anomalies or verify expected results, significantly improving verification efficiency. Finally, the system responds to query requests specified by the front-end user, quickly retrieving matching data from the pre-aggregated dataset and returning it in a visual format. This interactive design enables precise and flexible information acquisition, greatly simplifying the operation process. This automated verification solution provides reliable technical support for software test quality management.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and terminal for managing test data. Background Technology

[0002] In software quality assurance, omissions in the verification of test results are particularly common. The root cause is that test data in modern distributed systems is scattered across multiple platforms (such as tracing tools, database management platforms, log terminals, etc.). Therefore, testers need to frequently switch between multiple systems to manually acquire and summarize information in order to complete a single verification, resulting in a high degree of reliance on human experience throughout the entire process.

[0003] This model results in significant problems such as low verification efficiency and poor consistency, and is also prone to omissions or misjudgments. Therefore, there is an urgent need for a method to organize test data to solve the aforementioned problems of poor verification quality and low efficiency of test results. Summary of the Invention

[0004] This specification provides a method, apparatus, storage medium, and terminal for managing test data, which can solve the technical problems of poor quality and low efficiency in the verification of test results in related technologies.

[0005] Firstly, embodiments of this specification provide a method for managing test data, the method comprising: Obtain raw process data collected by multiple applications during the execution of test cases. The raw process data includes atomic operation data executed by the test cases on each application. The original process data above is aggregated according to multiple data dimensions to obtain the aggregated data of the test cases under each data dimension. The data dimensions above include at least the request link dimension or the test case dimension. In response to a user's request to view data for a specific data dimension, the system locates the target aggregated data for that data dimension and returns it to the user for display.

[0006] In one possible implementation, the above-mentioned aggregation of the original process data according to multiple data dimensions to obtain the aggregated data of the test cases under each data dimension includes: aggregating the original process data according to the unique tracking identifier to obtain the link aggregated data under the request link dimension; and aggregating the link aggregated data according to the test case identifier to obtain the test case aggregated data under the test case dimension.

[0007] In one possible implementation, the above-mentioned response to a user's data viewing request for a target data dimension, and the search for target aggregate data for that target data dimension, includes: parsing the target data dimension and the corresponding target identifier value carried in the data viewing request; if the target data dimension is the request link dimension, then searching for target aggregate data that matches the target identifier value from the link aggregate data; if the target data dimension is the test case dimension, then searching for target aggregate data that matches the target identifier value from the test case aggregate data.

[0008] In one possible implementation, the above-mentioned acquisition of raw process data collected by multiple applications during the execution of test cases includes: receiving raw process data dynamically collected by software development kits embedded in each application during the execution of test cases; wherein the raw process data includes at least one atomic operation data among remote procedure calls, message passing, and database operations triggered by the test cases during execution.

[0009] In one possible implementation, the above-mentioned aggregation of the original process data according to multiple data dimensions includes: performing a merging operation and / or a deduplication operation on the original process data according to multiple data dimensions to generate aggregated data.

[0010] In one possible implementation, the above-mentioned merging operation is performed on database operation data to merge multiple operations on the same database record into final state data; the above-mentioned deduplication operation is performed on at least one of remote procedure call data and message data to filter duplicate call or message records.

[0011] In one possible implementation, the data dimension mentioned above also includes an interface dimension, where the aggregated data under the interface dimension is the original process data itself.

[0012] Secondly, embodiments of this specification provide a test data management device, the device comprising: The process data acquisition module is used to acquire raw process data collected by multiple applications during the execution of test cases. The raw process data includes atomic operation data executed by the test cases on each application. The dimension data aggregation module is used to aggregate the above-mentioned original process data according to multiple data dimensions to obtain the aggregated data of the above-mentioned test cases under each data dimension. The above-mentioned data dimensions include at least the request link dimension or the test case dimension. The user request response module is used to respond to user requests to view data for a target data dimension, find the target aggregated data for the target data dimension, and return the target aggregated data to the user for display.

[0013] Thirdly, embodiments of this specification provide a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of the method described above.

[0014] Fourthly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method described above.

[0015] Fifthly, embodiments of this specification provide a terminal including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is adapted to be loaded by the processor and to execute the steps of the method described above.

[0016] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This specification provides a method for managing test data. It acquires raw process data collected from multiple applications during test case execution. This raw process data includes atomic operation data executed by test cases on each application. The raw process data is aggregated according to multiple data dimensions to obtain aggregated data for each test case across these dimensions. These data dimensions include at least a request chain dimension or a test case dimension. In response to a user's request to view data for a target data dimension, the target aggregated data for that dimension is located and returned to the user for display. First, atomic operation data from multiple applications during test case execution is acquired and centrally collected on a test verification platform. This design avoids testers manually retrieving data from multiple platforms one by one, laying the data foundation for subsequent automated processing. By automatically capturing this raw process data during test execution, comprehensive and automated collection of test process data is achieved, ensuring no critical operational information is missed. Simultaneously, because atomic operation data is collected, the finest-grained original details are preserved, providing a rich data source for subsequent multi-dimensional aggregation, thus supporting verification needs at different granularities. Next, the original process data is aggregated according to multiple data dimensions to obtain aggregated data for test cases under each data dimension. This step integrates scattered data into structured link aggregated data and test case aggregated data. Through multi-dimensional aggregation operations, testers can easily view the integrated data of any dimension, thereby quickly locating anomalies or verifying expected results, significantly improving verification efficiency. Finally, users can specify the required data dimensions through the front-end interface. In response to user requests to view data for the target data dimension, the system quickly retrieves matching data from the pre-aggregated dataset and presents it to the user in a visual form. This interactive design closely integrates data display with user intent, achieving flexible and accurate information acquisition. Users do not need to switch between multiple platforms or manually associate data, greatly simplifying the operation process. At the same time, since the aggregated data is pre-calculated, the response speed is fast, and the user experience is smooth. This automated test result verification scheme effectively overcomes the shortcomings of low efficiency and easy omissions in manual verification, providing reliable technical support for software test quality management. Attached Figure Description

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

[0018] Figure 1 An exemplary system architecture diagram of a test data management method provided in the embodiments of this specification; Figure 2 A flowchart illustrating a test data management method provided in the embodiments of this specification; Figure 3 This is a schematic diagram of a test data aggregation process provided in an embodiment of this specification; Figure 4 This is a schematic diagram illustrating the execution logic of a merging operation provided in an embodiment of this specification; Figure 5 A schematic diagram illustrating the execution logic of a deduplication operation provided in an embodiment of this specification; Figure 6 A flowchart illustrating a test data management method provided in the embodiments of this specification; Figure 7 A structural block diagram of a test data management device provided in the embodiments of this specification; Figure 8 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Detailed Implementation

[0019] To make the features and advantages of the embodiments of this specification more apparent and understandable, the technical solutions of the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the embodiments of this specification.

[0020] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those in this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments in this specification as detailed in the appended claims. Furthermore, in the description of the embodiments in this specification, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, in the description of the embodiments in this specification, "multiple" refers to two or more.

[0021] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0022] In a software quality assurance system, the purpose of testing is to ensure that the software system behaves as required under expected scenarios. Therefore, test coverage risk is always one of the key concerns of testing activities. Test coverage risk essentially refers to the possibility of omissions in the testing process, that is, functional points, service paths, system components, or data states that should be covered by testing are not fully executed and verified. Typical coverage blind spots include scenario omissions (no corresponding test cases designed), link omissions (a link in the call chain is not monitored), application omissions (a service is not included in the test), branch omissions (code logic branches are not covered), and verification omissions (the results after execution are not fully checked).

[0023] Among these issues, omissions in validation are particularly insidious and common. The root cause of these omissions lies in the high complexity of the testing and verification process and its deep reliance on manual operations. Modern software systems are mostly distributed architectures; a single test request may span multiple microservices, databases, message queues, and caching components. The resulting process data is scattered across different platforms. For example, call chain information needs to be reconstructed using tracing tools (such as cloud maps), database changes require logging into metadata management platforms (such as ODCs), log records need to be retrieved by accessing terminal login platforms (such as shells), and interface return values ​​and middleware status may rely on other specialized tools. To complete a full test case validation, testers have to frequently switch between multiple systems, manually performing data retrieval, format conversion, logical correlation, and expectation comparison. This entire process is not only time-consuming and labor-intensive, but also difficult to guarantee in terms of continuity and comprehensiveness due to information fragmentation. Each switch may introduce operational delays or context interruptions, and each manual judgment is limited by personal experience and attentional boundaries, ultimately leading to omissions or misjudgments in the validation results.

[0024] While existing technologies offer partial support in their respective fields (such as visualization of link tracing, database change auditing, and log aggregation analysis), they are isolated and fail to achieve a closed-loop verification process covering the entire workflow. They still require manual piecing together of scattered information, essentially relying on repetitive manual labor for core quality assurance. This leads to multiple negative consequences: First, the testing cycle is artificially lengthened, especially during regression testing or large-scale test case execution, where the verification process becomes a bottleneck, extending the overall delivery cycle. Second, verification quality is unstable, relying on the experience of testers, making it easy for defects to hide until they negatively impact the production environment. Finally, the assessment of coverage effectiveness lacks data support, making it difficult for teams to quantify the adequacy of testing, leading to the continuous accumulation of coverage blind spots and potential quality risks. Therefore, this specification provides a test data management method to address the aforementioned technical problems of poor verification quality and low efficiency in test results.

[0025] Please see Figure 1 , Figure 1 This is an exemplary system architecture diagram of a test data management method provided in the embodiments of this specification.

[0026] like Figure 1 As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 serves as the medium for providing a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired or wireless communication links, such as wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables, and wireless communication links including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, or microwave communication links, etc.

[0027] Terminal 101 can interact with server 103 via network 102 to receive messages from or send messages to server 103. Alternatively, terminal 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. Terminal 101 can be hardware or software. When terminal 101 is hardware, it can be various electronic devices, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal 101 is software, it can be installed in the aforementioned electronic devices and can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0028] In the embodiments of this specification, terminal 101 first acquires raw process data collected by multiple applications during the execution of test cases. The raw process data includes atomic operation data executed by the test cases on each application. Then, terminal 101 aggregates the raw process data according to multiple data dimensions to obtain aggregated data of the test cases under each data dimension. The data dimensions include at least the request link dimension or the test case dimension. When the user has an interactive intent, terminal 101 responds to the user's data viewing request for the target data dimension, finds the target aggregated data for the target data dimension, and returns the target aggregated data to the user terminal for display.

[0029] Server 103 can be a server that provides various services. It should be noted that server 103 can be hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0030] Alternatively, the system architecture may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification. That is, the method provided in the embodiments of this specification can be applied to a system structure that only includes terminal 101. The embodiments of this specification do not limit this.

[0031] It should be understood that Figure 1 The number of terminals, networks, and servers shown is only illustrative; the number can be any number of terminals, networks, and servers depending on the implementation requirements.

[0032] Please see Figure 2 , Figure 2 This is a flowchart illustrating a test data management method provided in an embodiment of this specification. The execution entity in this embodiment can be a terminal performing test data management, a processor within the terminal performing the test data management method, or a test data management service within the terminal performing the test data management method. For ease of description, the following example uses a processor within a terminal as the execution entity to illustrate the specific execution process of the test data management method.

[0033] like Figure 2 As shown, the methods for managing test data can include at least: S202. Obtain raw process data collected by multiple applications during the execution of test cases. The raw process data includes atomic operation data executed by the test cases on each application.

[0034] Optionally, in distributed system testing scenarios, the execution of a test case often involves complex interactions between multiple microservice applications. Each application generates a series of fine-grained operation records. Obtaining raw process data collected from multiple applications during test case execution helps provide a rich data source for subsequent multi-dimensional aggregation, thereby supporting verification needs at different granularities. In traditional technical approaches, testers often need to manually retrieve data from multiple platforms one by one, which is time-consuming and labor-intensive. Therefore, in order to efficiently and comprehensively capture these scattered process data, the embodiments in this specification achieve automated collection by using software development kits (SDKs) pre-embedded in each application.

[0035] Specifically, please refer to Figure 3 , Figure 3 This is a schematic diagram illustrating a test data aggregation process provided in an embodiment of this specification. For example... Figure 3 As shown, this software development kit utilizes aspect-oriented programming (AOP) technology to dynamically embed data acquisition logic into key application methods (such as Remote Procedure Call (RPC) entry points, database (DB) access layers, message producers and consumers, etc.). When test cases (such as...) are executed, the data acquisition logic is dynamically embedded into these methods. Figure 3When test cases a, b, c, and d) are executed, the SDK can identify and intercept the triggered key operation points, including but not limited to the initiation and reception of remote procedure calls, the publication and consumption of message queues (MSGs), the creation, deletion, modification, and querying of databases, and the read and write access of caches. It encapsulates the operation type, call parameters, return result, execution time, status code, exception information, globally unique trace ID (traceId), and the context information of the current application (such as application name, IP address, and timestamp) into a raw process data record. These records are reported in real time by each application for centralized aggregation.

[0036] Optionally, this mechanism enables the system to achieve comprehensive and automated observation of the test execution process without intruding on service code or affecting the normal operation of the application. The collected raw process data retains the finest granular operational details, providing a complete data source for subsequent multi-dimensional aggregation analysis, while avoiding the tedious process of manually switching and searching between multiple platforms, thus improving the accessibility and completeness of test data from the source.

[0037] S204. Aggregate the original process data according to multiple data dimensions to obtain the aggregated data of test cases under each data dimension. The data dimensions include at least the request link dimension or the test case dimension.

[0038] Optionally, while the raw process data collected in the above steps is comprehensive, it is still temporarily in a scattered and fragmented state. For example, the same test case may generate hundreds of operation records from dozens of applications. These records are intertwined in time and scattered in space, making it difficult to form an overall understanding of the test results by directly viewing them. Therefore, the embodiments of this specification aggregate the raw process data in multiple dimensions to transform it into a semantically structured view.

[0039] For a detailed implementation guide, please refer to [link / reference needed]. Figure 3The system provides a non-real-time, batch-based aggregation solution, which is more suitable for scenarios where timeliness requirements are not high but data integrity and processing stability need to be ensured. In this mode, the collected raw process data is first persistently stored in a centralized database and will not trigger aggregation calculation immediately. The system maintains a lifecycle state for each test case. When any of the following conditions are met, the system will automatically trigger a batch aggregation task for that test case: (1) the test case execution end instruction is received, indicating that the current test case execution has been completed; (2) the preset timeout threshold is reached, which is used to handle the situation where the end instruction is not received due to an exception. After the aggregation task is started, the system queries the database in batch mode for all raw process data generated by the test case within the time window; then, the aggregation logic is executed in the aggregation calculation engine (such as Spark SQL or traditional MapReduce) to obtain the aggregated data. Specifically, based on the globally unique trace ID (traceId) in distributed tracing technology, request chain data aggregation is achieved. This aggregated data not only includes the call relationships and order between nodes but also summarizes the operation details, time distribution, and exception information for each node, allowing testers to intuitively trace the entire lifecycle of a request. The test case dimension represents a higher level of aggregation: a test case may initiate multiple test requests (e.g., in concurrent scenarios) or contain multiple dependencies between steps. In one feasible implementation, the system performs secondary aggregation on all aggregated data belonging to the same test case using the test case ID, merging the execution results of multiple requests to generate test case aggregated data. This data presents the final state set of all related operations after the test case is executed, such as the final database changes, a summary of responses from all external interfaces, and a comprehensive judgment of whether the overall execution passed. Since the data processing time may be much longer than the data generation time, offline batch processing is generally used.

[0040] Understandably, under this non-real-time aggregation mechanism, since the data is pre-persisted, the aggregation task can be executed multiple times or backtracked, facilitating the re-analysis of historical use case data and the reproduction of problems. Furthermore, batch processing consumes computing resources in a concentrated manner, allowing it to be scheduled to run during off-peak hours to avoid competing for resources with online services.

[0041] In another feasible implementation, besides streaming aggregation, the system also provides a scheme that uses a streaming processing framework (such as Apache Flink) as the aggregation engine to continuously consume the raw process data stream and perform real-time or near-real-time aggregation calculations according to preset data dimensions. In this scheme, the aggregation engine executes the same aggregation logic as the non-streaming mode, that is, it aggregates and generates link aggregation data based on unique trace identifiers. When the same test request traverses various applications, the aggregation engine, based on the trace identifiers, strings together the atomic operations scattered across the applications to reconstruct the complete call chain topology, generating link aggregation data. Then, it performs secondary aggregation on the link data according to the test case identifiers to generate test case data. Through the complementary design of streaming real-time aggregation and offline batch processing aggregation modes, the embodiments in this specification can flexibly adapt to diverse testing scenarios: for routine testing verification requiring immediate feedback, the real-time aggregation mode provides fast-response data insights; for large-scale regression testing or historical data analysis, the offline batch processing mode ensures the integrity of data processing and the economy of resource utilization. Both modes can achieve the transformation from atomic operations to structured aggregated data, providing a high-quality, multi-time-sensitive data foundation for subsequent test result verification.

[0042] Optionally, during the aggregation process, the system also performs differentiated processing logic for different types of data. This means performing merging and / or deduplication operations on the original process data according to multiple data dimensions to generate aggregated data, ensuring the accuracy and validity of the aggregation results. For details, please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram illustrating the execution logic of a merging operation provided in an embodiment of this specification, such as... Figure 4 As shown, for database operation-related data, the system primarily performs merge operations. In actual test execution, the same transaction operation may trigger multiple insert, delete, and modify operations on the same database record (e.g., insert first, then update, then query). Simply listing these operations would increase the testers' understanding burden. Therefore, the system uses the database primary key or unique index as a basis to group multiple operations on the same record, then tracks and merges them, restoring the record to its final state after the entire test case execution. For example, during the execution of a test case, three "insert-update-update" operations were performed on the record with ID 1001 in the user table. After merging, only the final field values ​​of the record are presented, which is completely consistent with the final state data seen by the testers when directly querying the database. Through the merge operation, the system eliminates redundant display of intermediate process states, making the test results more concise and clear.

[0043] On the other hand, please see Figure 5 , Figure 5 This is a schematic diagram illustrating the execution logic of a deduplication operation provided in an embodiment of this specification, such as... Figure 5As shown, the system may perform deduplication on remote procedure call (RPC) data and message data. In a distributed testing environment, due to network retries, timeout retransmissions, and middleware duplicate deliveries, a single transaction operation may generate multiple duplicate call records or message records. If these duplicate data are not filtered, redundant entries will appear in the aggregated data, interfering with testers' judgment of the number of results and even leading to misjudgments of the execution logic. Therefore, the system performs real-time deduplication on the data during the aggregation process based on the unique identifier of the remote procedure call or message (such as request ID, message ID) and key fields (such as idempotent keys). When multiple records are identified corresponding to the same original request or message, only the first successful record is retained or merged into a single valid record according to transaction rules; the remaining redundant copies are filtered out. For example, if a remote call is retried three times by the client due to network jitter, but is actually only successfully processed once on the target server, the deduplication operation will merge these three original records into a single successful call record, restoring the true execution of the service. By performing differentiated aggregation processing based on data types, the system not only transforms scattered atomic operations into structured aggregated data, but also completes data cleaning and information extraction during the aggregation process. This effectively avoids data redundancy and interference caused by the instability of the test environment. The resulting request link aggregation data and test case aggregation data not only retain the necessary details but also eliminate irrelevant noise information, providing a high-quality data foundation for subsequent test result verification.

[0044] S206. In response to the user's request to view data for the target data dimension, locate the target aggregated data for the target data dimension and return the target aggregated data to the user for display.

[0045] Optionally, after completing multi-dimensional aggregation, the system also provides convenient query and display capabilities to meet the data viewing needs of testers in different scenarios. This embodiment of the specification achieves on-demand data acquisition and visualization through a unified interactive interface.

[0046] Specifically, when a user triggers a data viewing request on the front-end page, they need to specify the desired target data dimension (such as the request link dimension or test case dimension) and the corresponding target identifier value (such as the trace identifier or test case identifier). After the request is submitted to the server, the system first parses the request parameters to determine the target dimension and identifier for the query. If the target dimension is the request link dimension, the system quickly retrieves matching link aggregation data from the pre-built link aggregation dataset using the trace identifier as the key; if the target dimension is the test case dimension, the system queries the corresponding test case aggregation data from the test case aggregation dataset using the test case identifier as the condition. Since the aggregated data has been pre-calculated and indexed, the query process can be completed within milliseconds, ensuring real-time interaction.

[0047] Furthermore, after retrieving the target aggregated data, the system encapsulates it into a structured response format and returns it to the front end. The front-end presentation layer uses differentiated visualization components based on the data type and content. For example, for data at the request link level, the system can display the call relationships and node details of each application in the form of a link topology diagram, supporting expansion to view the list of atomic operations. For data at the test case level, the system displays the final status, key metrics, and included link list of the test cases in the form of overview cards or tables, supporting drill-down to view link details. This multi-layered display design allows testers to quickly drill down from macroscopic test case results to microscopic link details or atomic operations according to their needs, without manually linking data across multiple platforms. Through this interactive design, testers can obtain complete test results for the required dimensions with just one query, greatly simplifying the operation process. At the same time, the unified visualization interface helps reduce the bias of manual interpretation, improves the accuracy and consistency of test result verification, and ultimately provides efficient and intuitive technical support for the test verification process.

[0048] This specification provides a method for managing test data. The method involves acquiring raw process data collected by multiple applications during test case execution. This raw process data includes atomic operation data executed by test cases on each application. The raw process data is then aggregated according to multiple data dimensions to obtain aggregated data for each test case across these dimensions. These data dimensions include at least a request chain dimension or a test case dimension. In response to a user's request to view data for a specific data dimension, the method locates the target aggregated data for that dimension and returns it to the user for display. First, atomic operation data from multiple applications during test case execution is acquired and centrally collected on a test verification platform. This design avoids testers manually retrieving data from multiple platforms, laying the data foundation for subsequent automated processing. By automatically capturing this raw process data during test execution, comprehensive and automated collection of test process data is achieved, ensuring no critical operational information is missed. Simultaneously, because atomic operation data is collected, the finest-grained original details are preserved, providing a rich data source for subsequent multi-dimensional aggregation, thus supporting verification needs at different granularities. Next, the original process data is aggregated according to multiple data dimensions to obtain aggregated data for test cases under each data dimension. This step integrates scattered data into structured link aggregated data and test case aggregated data. Through multi-dimensional aggregation operations, testers can easily view the integrated data of any dimension, thereby quickly locating anomalies or verifying expected results, significantly improving verification efficiency. Finally, users can specify the required data dimensions through the front-end interface. In response to user requests to view data for the target data dimension, the system quickly retrieves matching data from the pre-aggregated dataset and presents it to the user in a visual form. This interactive design closely integrates data display with user intent, achieving flexible and accurate information acquisition. Users do not need to switch between multiple platforms or manually associate data, greatly simplifying the operation process. At the same time, since the aggregated data is pre-calculated, the response speed is fast, and the user experience is smooth. This automated test result verification scheme effectively overcomes the shortcomings of low efficiency and easy omissions in manual verification, providing reliable technical support for software test quality management.

[0049] Please see Figure 6 , Figure 6 This is a flowchart illustrating a test data management method provided in an embodiment of this specification.

[0050] like Figure 6 As shown, the methods for managing test data can include at least: S602. Obtain raw process data collected by multiple applications during the execution of test cases. The raw process data includes atomic operation data executed by the test cases on each application.

[0051] For details regarding step S602, please refer to the description in step S202; it will not be repeated here.

[0052] S604. Aggregate the original process data based on the unique tracking identifier to obtain the link aggregation data under the request link dimension.

[0053] Optionally, after completing the centralized collection of raw process data, the system needs to further restructure these dispersed atomic operations to restore the complete execution path of the test request in the distributed system. This step focuses on data aggregation at the request link level, and its core basis is the unique tracking identifier widely used in distributed tracing technology. This identifier, as global context information carried by the request as it traverses each application node, can associate all atomic operation records generated by the same test request.

[0054] In its implementation, the aggregation engine consumes raw process data streams from message middleware or data bus as continuously running stream processing tasks. For each data record, the system first extracts its unique tracking identifier and uses this identifier as a grouping key to aggregate all records belonging to the same request into the same processing window or state partition. Within the window, the system reconstructs the topology of the raw process data based on the call sequence and nesting relationships between application nodes. For example, by analyzing the call direction (client-initiated or server-received), upstream and downstream application names, and timestamp information for each record, the system can draw a complete call chain from the entry application to the end service and mark the specific atomic operations that occur at each node, such as remote procedure calls, database access, message sending and receiving, etc. The final generated data structure is the link aggregation data. The system presents a full-link view of the request in tree or graph form, where each node aggregates all the operation details of the corresponding application in the request process.

[0055] For further information, please refer to [link / reference]. Figure 3This specification also clarifies the data definition at the interface dimension, where aggregated data is the original process data itself. This design meets the needs of testers to examine the finest-grained data. In some complex troubleshooting scenarios, testers may need to view the original records of each atomic operation, including precise input parameters, return values, exception stacks, and millisecond-level timestamps. Therefore, the system stores and indexes the original process data as an independent view at the interface dimension, supporting retrieval by interface name, application name, time range, and other conditions. The interface dimension data retains its original form at the time of collection, providing a data source for in-depth debugging and refined analysis. Through this step, the system transforms fragmented atomic operations into a structured chain view, enabling testers to intuitively trace the complete execution trajectory of a request. Simultaneously, retaining the original data at the interface dimension balances the dual needs of macro-level overview and micro-level investigation, laying a solid data foundation for subsequent multi-dimensional queries and verification.

[0056] S606. Aggregate the link aggregation data according to the test case identifier to obtain test case aggregation data under the test case dimension.

[0057] Optionally, while the request chain dimension recreates the execution details of a single request, in actual testing activities, a test case often involves multiple request calls, such as multiple parallel requests in a concurrent scenario or multiple steps in a transaction process. To evaluate the execution results of test cases at a higher level, this step performs secondary aggregation based on the chain aggregation data to construct a unified view of the test case dimension.

[0058] Specifically, the system uses test case identifiers as the grouping criterion, aggregating all link aggregation data belonging to the same test case together. Test case identifiers are typically generated by the testing platform when a test case is initiated and transmitted to each application node with the request, ultimately being appended as metadata to the original process data. After generating the link aggregation data, the aggregation engine stores it in a data warehouse or analytical database with multidimensional analysis capabilities and establishes an index with the test case identifier as the partition key. When test case aggregation data needs to be generated, the system retrieves all associated link aggregation data based on the test case identifier and then performs a series of merging and integration operations. The merging operation primarily targets the merging of homogeneous data across links. For example, a test case may contain multiple requests to write data to the same database table; the test case aggregation data will merge the final effects of all these write operations, presenting the final state of the database table, rather than a simple list of multiple independent records. For remote procedure calls and message-type data, the system performs cross-link deduplication based on the unique identifier of the request, ensuring that the same transaction operation is counted only once in multiple requests. In addition, the system also tracks the overall execution status of test cases, including key metrics such as total number of requests, number of successes, number of failures, average execution time, and anomaly distribution, and generates a comprehensive judgment on whether a test case passes or fails. The aggregated test case data includes summary information on all relevant links, while also retaining entry points for drilling down to specific link details. This allows testers to obtain a complete overview of test case execution in a single aggregated view without having to manually switch and piece together information between multiple link views.

[0059] S608. Parse the target data dimension and the corresponding target identifier value carried in the data viewing request.

[0060] Optionally, when a user initiates a data viewing request through the front-end interface, the system needs to accurately understand the user's query intent and convert the interface operation into executable data retrieval instructions. Therefore, in the embodiments of this specification, the system will first parse and validate the request parameters.

[0061] Specifically, users can select the desired data dimension, such as "request link dimension" or "test case dimension," via typing, dropdown menus, or tabs on the front-end page, and enter the target identifier value, such as trace identifier or test case identifier, in the corresponding input box. The front-end encapsulates the user's selection and input into a structured request message and sends it to the server via HTTP or RPC protocol. Upon receiving the request, the server first verifies its validity and completeness, including checking whether the target data dimension is within the system's supported dimension list and whether the target identifier value conforms to the format requirements and is not empty. If the verification passes, the system further extracts the target dimension identifier (such as "link" or "case") and the target identifier value (such as the specific trace ID or test case ID), using them as input parameters for subsequent data retrieval. This parsing process ensures the accuracy and efficiency of subsequent data retrieval, avoiding query failures or data corruption due to incorrect parameters.

[0062] S610. If the target data dimension is the request link dimension, then search for the target aggregate data that matches the target identifier value from the link aggregate data; if the target data dimension is the test case dimension, then search for the target aggregate data that matches the target identifier value from the test case aggregate data.

[0063] Optionally, based on the query parameters parsed above, the system further performs corresponding data retrieval operations. Considering the differences in storage structure between link aggregation data and use case aggregation data, the system will also select the corresponding data source and retrieval strategy according to the target dimension.

[0064] In one feasible implementation, when the target dimension is the request link dimension, the system uses the trace identifier as the query key to search for matching records in a cache or index database that specifically stores link aggregation data. Link aggregation data is typically stored in key-value pairs, where the key is the trace identifier and the value is a structured object containing the call topology, node operation details, and metadata. The system achieves millisecond-level queries using hash indexes or distributed key-value stores (such as Redis or HBase). If the corresponding link aggregation data is found, the system loads it into memory, ready to return it to the front end; if not found, it returns an empty result or a prompt message. When the target dimension is the test case dimension, the system uses the test case identifier as the query condition to retrieve data from a relational database or analytical data warehouse that stores test case aggregation data. Test case aggregation data may contain multiple related link aggregation data references, as well as test case-level summary statistics. The system executes a database query to retrieve records matching the test case identifier, possibly along with a list of associated link identifiers, to support drill-down operations on the front end. The retrieval process also needs to ensure low latency, typically optimized through indexing and table partitioning strategies. For requests to view data at the interface level, the system directly retrieves data from the raw process data storage by interface identifier and time range, returning a list of unaggregated raw records. Through this data query mechanism, the system can accurately obtain the required data based on the user-specified dimensions, avoiding the performance overhead of full data scanning and ensuring the real-time performance and accuracy of the query.

[0065] S612. Return the target aggregated data to the user terminal for display.

[0066] Optionally, after successfully retrieving the target aggregated data, the system will also present it to the user in a visual format to assist testers in verifying the results in an intuitive and easy-to-understand way. In one feasible implementation, the server serializes the queried aggregated data into a unified response format, such as JSON or Protocol Buffers, and returns it to the front end via the network. After receiving the data, the front end calls the corresponding visualization component for rendering based on the dimension of the data source. For data at the request chain dimension, the front end uses a topology graph component to display the application's call relationship in the form of nodes and connections. The nodes can be expanded to display a list of all atomic operations of the application, including operation type, time consumption, status, and other information. Users can view details by hovering the mouse or clicking, and the call process can be played back on a timeline. For data at the test case dimension, the front end displays summary information of the test cases in the form of dashboards or cards, such as test case name, execution time, total number of requests, number of successes, failure rate, anomaly distribution, and other key indicators. Below, a list of related chains is listed, with each chain displaying the tracking identifier, entry application, total time consumption, and result status in summary form, and providing a "View Details" button, which allows users to jump to the complete view of that chain. The data at the interface level is displayed in tabular form as the original process records, supporting pagination, sorting, and keyword filtering.

[0067] Furthermore, the front-end integrates interactive query functionality, allowing users to directly initiate new dimension queries or drill-down operations on the results page. For example, clicking on a link identifier from the test case aggregation data automatically triggers a detailed data request for that link, enabling step-by-step exploration. The entire display interface adopts a unified visual style and interaction logic. Testers do not need to manually piece together information across multiple platforms; they can complete comprehensive data verification from test case-level overviews to link-level details within a unified interactive interface, significantly improving the efficiency and accuracy of test result verification. At the same time, the visual presentation lowers the barrier to data understanding, helps reduce the bias of manual interpretation, and provides strong support for the prevention and control of test coverage risks.

[0068] This specification provides a method for managing test data. First, at the data acquisition level, atomic operation data from various applications is automatically collected using a software development kit (SDK), replacing tedious manual operations and achieving comprehensive coverage of test process data. Furthermore, it provides a complete and reliable data source for subsequent multi-dimensional aggregation and in-depth analysis, fundamentally improving the observability of test data. At the data processing level, a multi-dimensional aggregation mechanism is constructed. Link aggregation based on unique tracking identifiers can restore atomic operations scattered across various applications into a complete call chain topology, allowing testers to intuitively trace the entire lifecycle of a request. Secondary aggregation based on test case identifiers integrates multiple related links into a unified view at the test case dimension, presenting the overall result of test case execution. The interface dimension retains the original data, balancing the dual needs of macro-level overview and micro-level exploration. This hierarchical aggregation design transforms fragmented information into a structured view with clear transaction semantics, significantly reducing the burden on testers. At the user interaction level, on-demand query and visualization capabilities are provided. Testers only need to specify the target dimension and identifier value to quickly obtain the corresponding aggregated data without switching between multiple platforms or manual association. The visual presentation method further enhances the intuitiveness and accuracy of result interpretation. In summary, the embodiments in this specification, through automated data collection, multi-dimensional aggregation, and visual interaction, significantly improve the efficiency and accuracy of test result verification, effectively prevent the risk of verification omissions, and provide efficient and reliable technical support for software test quality management.

[0069] Please see Figure 7 , Figure 7 This is a structural block diagram of a test data management device provided in an embodiment of this specification. Figure 7 As shown, the test data management device 700 includes: The process data acquisition module 710 is used to acquire raw process data collected by multiple applications during the execution of test cases. The raw process data includes atomic operation data executed by the test cases on each application. The dimension data aggregation module 720 is used to aggregate the original process data according to multiple data dimensions to obtain the aggregated data of test cases under each data dimension. The data dimensions include at least the request link dimension or the test case dimension. The user request response module 730 is used to respond to a user's request to view data for a target data dimension, find the target aggregated data for the target data dimension, and return the target aggregated data to the user for display.

[0070] Optionally, the dimension data aggregation module 720 is also used to aggregate the original process data according to the unique tracking identifier to obtain link aggregation data under the request link dimension; and to aggregate the link aggregation data according to the test case identifier to obtain test case aggregation data under the test case dimension.

[0071] Optionally, the user request response module 730 is also used to parse the target data dimension and the corresponding target identifier value carried in the data viewing request; if the target data dimension is the request link dimension, then the target aggregate data that matches the target identifier value is searched from the link aggregate data; if the target data dimension is the test case dimension, then the target aggregate data that matches the target identifier value is searched from the test case aggregate data.

[0072] Optionally, the process data acquisition module 710 is also used to receive raw process data dynamically acquired by the software development kits embedded in each application during the execution of test cases; wherein, the raw process data includes at least one atomic operation data among remote procedure calls, message passing, and database operations triggered during the execution of test cases.

[0073] Optionally, the dimension data aggregation module 720 is also used to perform merging and / or deduplication operations on the original process data according to multiple data dimensions to generate aggregated data.

[0074] Optionally, the merge operation is performed on database operation data to merge multiple operations on the same database record into final state data; the deduplication operation is performed on at least one of remote procedure call data and message data to filter duplicate call or message records.

[0075] Optionally, the data dimension also includes the interface dimension, where the aggregated data under the interface dimension is the original process data itself.

[0076] This specification provides a test data management device, comprising: a process data acquisition module for acquiring raw process data collected by multiple applications during test case execution, including atomic operation data of test cases executed on each application; a dimension data aggregation module for aggregating the raw process data according to multiple data dimensions to obtain aggregated data of test cases under each data dimension, where the data dimensions include at least request chain dimensions or test case dimensions; and a user request response module for responding to user requests to view data for a target data dimension, finding the target aggregated data for the target data dimension, and returning the target aggregated data to the user for display. First, atomic operation data from multiple applications during test case execution is acquired and centrally collected in a test verification platform. This design avoids testers manually retrieving data from multiple platforms one by one, laying the data foundation for subsequent automated processing. By automatically capturing this raw process data during test execution, comprehensive and automated collection of test process data is achieved, ensuring no critical operational information is missed. Simultaneously, because atomic operation data is collected, the finest-grained original details are preserved, providing a rich data source for subsequent multi-dimensional aggregation, thereby supporting verification requirements at different granularities. Next, the original process data is aggregated according to multiple data dimensions to obtain aggregated data for test cases under each data dimension. This step integrates scattered data into structured link aggregated data and test case aggregated data. Through multi-dimensional aggregation operations, testers can easily view the integrated data of any dimension, thereby quickly locating anomalies or verifying expected results, significantly improving verification efficiency. Finally, users can specify the required data dimensions through the front-end interface. In response to user requests to view data for the target data dimension, the system quickly retrieves matching data from the pre-aggregated dataset and presents it to the user in a visual form. This interactive design closely integrates data display with user intent, achieving flexible and accurate information acquisition. Users do not need to switch between multiple platforms or manually associate data, greatly simplifying the operation process. At the same time, since the aggregated data is pre-calculated, the response speed is fast, and the user experience is smooth. This automated test result verification scheme effectively overcomes the shortcomings of low efficiency and easy omissions in manual verification, providing reliable technical support for software test quality management.

[0077] This specification provides a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of any of the methods described above.

[0078] This specification also provides a computer storage medium that can store multiple instructions adapted for loading by a processor and executing the steps of any of the methods described in the above embodiments.

[0079] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Figure 8 As shown, terminal 101 may include: at least one terminal processor 801, at least one network interface 804, user interface 803, memory 805, and at least one communication bus 802.

[0080] The communication bus 802 is used to enable communication between these components.

[0081] The user interface 803 may include a display screen and a camera. Optionally, the user interface 803 may also include a standard wired interface and a wireless interface.

[0082] The network interface 804 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0083] The terminal processor 801 may include one or more processing cores. The terminal processor 801 connects to various parts within the terminal 101 using various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 805, and by calling data stored in the memory 805. Optionally, the terminal processor 801 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The terminal processor 801 may integrate one or more of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the terminal processor 801.

[0084] The memory 805 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 805 may include a non-transitory computer-readable storage medium. The memory 805 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 805 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 805 may also be at least one storage device located remotely from the aforementioned terminal processor 801. Figure 8 As shown, the memory 805, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a test data management program.

[0085] exist Figure 8 In the terminal 101 shown, the user interface 803 is mainly used to provide an input interface for the user and to obtain the user's input data; while the terminal processor 801 can be used to call the management program for test data stored in the memory 805 and specifically perform the following operations: Obtain raw process data collected by multiple applications during the execution of test cases. The raw process data includes atomic operation data executed by the test cases on each application. The original process data is aggregated according to multiple data dimensions to obtain aggregated data of test cases under each data dimension. The data dimensions include at least the request link dimension or the test case dimension. In response to a user's request to view data for a specific data dimension, the system locates the target aggregated data for that data dimension and returns it to the user for display.

[0086] In some embodiments, when the terminal processor 801 performs the following steps to aggregate the original process data according to multiple data dimensions to obtain aggregated test case data under each data dimension: aggregate the original process data according to the unique tracking identifier to obtain link aggregated data under the request link dimension; aggregate the link aggregated data according to the test case identifier to obtain test case aggregated data under the test case dimension.

[0087] In some embodiments, when the terminal processor 801 executes a response to a user's data viewing request for a target data dimension and searches for target aggregate data for that target data dimension, it specifically performs the following steps: parsing the target data dimension and the corresponding target identifier value carried in the data viewing request; if the target data dimension is a request link dimension, then searching for target aggregate data that matches the target identifier value from the link aggregate data; if the target data dimension is a test case dimension, then searching for target aggregate data that matches the target identifier value from the test case aggregate data.

[0088] In some embodiments, when the terminal processor 801 executes the process of acquiring raw process data collected by multiple applications during the execution of test cases, it specifically performs the following steps: receiving raw process data dynamically collected by the software development kits embedded in each application during the execution of test cases; wherein, the raw process data includes at least one atomic operation data among remote procedure calls, message passing, and database operations triggered during the execution of test cases.

[0089] In some embodiments, when the terminal processor 801 performs aggregation of the original process data according to multiple data dimensions, it specifically performs the following steps: performing a merging operation and / or deduplication operation on the original process data according to multiple data dimensions to generate aggregated data.

[0090] In some embodiments, the merge operation is performed on database operation data to merge multiple operations on the same database record into final state data; the deduplication operation is performed on at least one of remote procedure call data and message data to filter duplicate call or message records.

[0091] In some embodiments, the data dimension also includes the interface dimension, where the aggregated data under the interface dimension is the original process data itself.

[0092] In the several embodiments provided in this specification, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0093] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0094] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0095] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0096] Furthermore, it should be noted that all information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the test cases and atomic operation data involved in this specification were obtained under full authorization.

[0097] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0098] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0099] The above is a description of a test data management method, apparatus, storage medium, and terminal provided in the embodiments of this specification. For those skilled in the art, based on the ideas of the embodiments of this specification, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this specification.

Claims

1. A method of managing test data, characterized by, The method includes: Obtain raw process data collected by multiple applications during the execution of test cases, the raw process data including atomic operation data executed by the test cases on each application; The original process data is aggregated according to multiple data dimensions to obtain the aggregated data of the test cases under each data dimension. The data dimensions include at least the request link dimension or the test case dimension. In response to a user's request to view data for a specific data dimension, the system locates the target aggregated data for that data dimension and returns the target aggregated data to the user for display.

2. The method of claim 1, wherein, The aggregation of the original process data according to multiple data dimensions to obtain the aggregated data of the test cases under each data dimension includes: The original process data is aggregated based on the unique tracking identifier to obtain the link aggregation data under the request link dimension; The link aggregation data is aggregated based on the test case identifier to obtain test case aggregation data under the test case dimension.

3. The method of claim 2, wherein, The step of responding to a user's data viewing request for a target data dimension and searching for the target aggregated data for that target data dimension includes: Parse the target data dimension and corresponding target identifier value carried in the data viewing request; If the target data dimension is the request link dimension, then search for target aggregate data that matches the target identifier value from the link aggregate data; If the target data dimension is the test case dimension, then search for target aggregate data that matches the target identifier value from the test case aggregate data.

4. The method according to any one of claims 1 to 3, characterized in that, The acquisition of raw process data collected by multiple applications during test case execution includes: Receive raw process data dynamically collected by the software development kits embedded in each application during the execution of test cases; The original process data includes at least one atomic operation data from remote procedure calls, message passing, and database operations triggered during the execution of the test cases.

5. The method of claim 1, wherein, The aggregation of the original process data according to multiple data dimensions includes: Merging and / or deduplication operations are performed on the original process data according to multiple data dimensions to generate aggregated data.

6. The method of claim 5, wherein, The merging operation is performed on database operation data to merge multiple operations on the same database record into final state data; the deduplication operation is performed on at least one of remote procedure call data and message data to filter duplicate call or message records.

7. The method of claim 1, wherein, The data dimension also includes the interface dimension, and the aggregated data under the interface dimension is the original process data itself.

8. A management apparatus of test data, characterized by, The device includes: The process data acquisition module is used to acquire raw process data collected by multiple applications during the execution of test cases. The raw process data includes atomic operation data executed by the test cases on each application. The dimension data aggregation module is used to aggregate the original process data according to multiple data dimensions to obtain the aggregated data of the test cases under each data dimension. The data dimensions include at least the request link dimension or the test case dimension. The user request response module is used to respond to a user's data viewing request for a target data dimension, locate the target aggregated data for the target data dimension, and return the target aggregated data to the user for display.

9. A computer program product comprising instructions, characterized in that, When the computer program product is run on a computer or processor, it causes the computer or processor to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the steps of the method as described in any one of claims 1 to 7.

11. A terminal, characterized by comprising: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any one of claims 1 to 7.

Images