A test data processing method and device, electronic equipment and storage medium

Abstract

This disclosure discloses a test data processing method, apparatus, electronic device, and storage medium, comprising: in response to a test trigger event, creating a data acquisition session corresponding to a test task, wherein the test task corresponds to at least one test case; during the data acquisition session, selectively acquiring screen stream data of the target application's running process based on preset application identification information; acquiring interactive event data, application status data, and client log data of the target application's running process in parallel; associating the screen stream data, interactive event data, application status data, and client log data with a unified timestamp to establish a time-series associated data set; and based on the time-series associated data set, in response to a data backtracking request, acquiring target screen stream data, target interactive event data, target application status data, and target client log data corresponding to the target timestamp. The embodiments of this disclosure effectively reduce retrieval computation overhead and response latency, improving the overall testing efficiency of the application.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and specifically to a test data processing method, apparatus, electronic device, and storage medium. Background Technology

[0002] In related technologies, testing game applications typically requires the use of separate screen recording tools, log collection tools, and system monitoring tools to obtain application runtime screenshots, client logs, and hardware performance parameters. Because these various data types are collected independently by different tools and stored in a dispersed manner, with varying data formats and storage structures and a lack of effective correlation and indexing mechanisms, the test data is fragmented in the backend storage. When it is necessary to locate specific defect scenarios, the backend system must traverse massive amounts of scattered data for manual comparison, significantly increasing retrieval computational overhead and response latency. Simultaneously, the test terminal consumes significant processor resources and memory space when maintaining multiple data acquisition tasks in parallel. These technical shortcomings make it difficult to meet the demands of high-frequency automated testing in terms of overall test data management efficiency and defect location accuracy. Summary of the Invention

[0003] This disclosure provides a test data processing method, apparatus, electronic device, and storage medium, which effectively reduces retrieval computation overhead and response latency; significantly improves the positioning accuracy and overall management efficiency of test data, thereby effectively improving the overall testing efficiency of applications and meeting the needs of high-frequency automated testing.

[0004] It significantly reduces the consumption of time and manpower, enables quick and accurate retrieval of test data corresponding to different timestamps, significantly improves the positioning accuracy of test data, and thus effectively improves the overall testing efficiency of the application.

[0005] In a first aspect, embodiments of this disclosure provide a test data processing method, including: In response to a test trigger event, a data collection session corresponding to a test task is created, wherein the test task corresponds to at least one test case; During the acquisition session, screen stream data of the target application's running process is selectively acquired based on preset application identification information; The system collects interaction event data, application status data, and client log data during the operation of the target application in parallel. Associate the video stream data, the interaction event data, the application status data, and the client log data with a unified timestamp to establish a time-series associated data set; Based on the aforementioned time-series associated data set, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are obtained.

[0006] Secondly, embodiments of this disclosure provide a test data processing apparatus, comprising: A response unit is used to create a collection session corresponding to a test task in response to a test trigger event, wherein the test task corresponds to at least one test case; The first acquisition unit is used to selectively acquire screen stream data of the target application running process based on preset application identification information during the acquisition session; The second acquisition unit is used to collect interactive event data, application status data, and client log data in parallel during the operation of the target application. The processing unit is used to associate unified timestamps with the video stream data, the interaction event data, the application status data, and the client log data respectively, and establish a time-series associated data set; The acquisition unit is used to acquire, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp, based on the time-series associated data set.

[0007] Thirdly, embodiments of this disclosure also provide an electronic device, including a memory storing a plurality of instructions; a processor loading instructions from the memory to execute the steps of any of the test data processing methods provided in embodiments of this disclosure.

[0008] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to perform the steps of any of the test data processing methods provided in embodiments of this disclosure.

[0009] Fifthly, embodiments of this disclosure also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in any of the test data processing methods provided in embodiments of this disclosure.

[0010] The solution adopted in this disclosure allows for the association of collected video stream data, interaction event data, application status data, and client log data with a unified timestamp during testing of a target application. This establishes a time-series associated data set, enabling testers to quickly find the desired test data from a massive amount of test data based on the target timestamp when locating specific defect scenarios. This eliminates the need for manual retrieval and filtering by testers, significantly reducing time and manpower consumption and effectively minimizing retrieval computational overhead and response latency. Furthermore, it enables rapid and accurate retrieval of test data corresponding to different timestamps, significantly improving the location accuracy and overall management efficiency of test data, thereby effectively enhancing the overall testing efficiency of the application and meeting the needs of high-frequency automated testing. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram of a test data processing system provided in the embodiments of this disclosure; Figure 2 This is a schematic flowchart of one embodiment of the test data processing method provided in this disclosure. Figure 3 This is a connection diagram of the processing nodes of the test data processing system provided in the embodiments of this disclosure; Figure 4 This is an interaction timing diagram of the test data provided in the embodiments of this disclosure; Figure 5 This is a schematic diagram of the timeline control provided in the embodiments of this disclosure; Figure 6 This is a schematic diagram of the structure of the test data processing device provided in the embodiments of this disclosure; Figure 7 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0013] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure. Furthermore, in the description of the embodiments of this disclosure, the terms "first," "second," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance. Therefore, features defined with "first" or "second" may explicitly or implicitly include one or more features. In the description of the embodiments of this disclosure, "multiple" means two or more, unless otherwise explicitly specified.

[0014] This disclosure provides a test data processing method, apparatus, electronic device, and computer-readable storage medium. Specifically, this embodiment will be described from the perspective of a test data processing apparatus, which can be integrated into an electronic device. That is, the test data processing method of this disclosure can be executed by an electronic device. Optionally, the electronic device may include a terminal device. The terminal device may be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, or personal computer (PC), etc.

[0015] The test data processing method provided in this disclosure can be applied to interactive systems, such as terminal devices and servers. The terminal can be a device that includes both receiving and transmitting hardware, i.e., a device with receiving and transmitting hardware capable of performing bidirectional communication over a bidirectional communication link. The terminal device and the server can communicate bidirectionally via a network.

[0016] Optionally, the server can be a standalone server, or a server network or server cluster, including but not limited to computers, network hosts, single network servers, multiple network server sets, or cloud servers composed of multiple servers. Cloud servers consist of a large number of computers or network servers based on cloud computing.

[0017] In one embodiment of this disclosure, the test data processing method can run on a local terminal device or a server. When the game interaction method runs on a server, the method can be implemented and executed based on a cloud interaction system, wherein the cloud interaction system includes a server and a client device.

[0018] Please see Figure 1 , Figure 1This is a schematic diagram of a test data processing system provided in this embodiment. The system may include at least one terminal, at least one server, at least one database, and a network. A user's terminal can connect to different servers via the network. A terminal is any device with computing hardware capable of supporting and executing software products corresponding to model generation. Furthermore, when the system includes multiple terminals, multiple servers, and multiple networks, different terminals can connect to each other through different networks and servers. The network can be a wireless network or a wired network, such as a wireless local area network (WLAN), local area network (LAN), cellular network, 2G network, 3G network, 4G network, 5G network, etc. Additionally, different terminals can also connect to other terminals or servers using their own Bluetooth networks or hotspot networks. For example, multiple users can connect online through different terminals via appropriate networks and synchronize with each other to support multi-user access. Furthermore, the system may include multiple databases coupled to different servers, and can continuously store information related to the operating environment in the databases while different users are using the system online.

[0019] The following detailed description is provided in conjunction with the accompanying drawings. In this embodiment, the execution subject is a terminal device as an example. It should be noted that the order of description in the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the accompanying drawings.

[0020] Please see Figure 2 , Figure 2 This is a schematic flowchart of one embodiment of the test data processing method provided in this disclosure. The specific flow of the test data processing method can be as follows: steps 101 to 105, wherein: Step 101: In response to the test trigger event, create a data acquisition session corresponding to the test task, wherein the test task corresponds to at least one test case.

[0021] In this embodiment of the disclosure, the use case platform can initiate a recording operation and send the task identifier of the test task to the acquisition terminal to create an acquisition session and bind the corresponding task identifier of the test task; or, the user can select a test task and manage the corresponding task identifier of the test task for the target application through the graphical user interface of the acquisition terminal to create an acquisition session and bind the corresponding task identifier of the test task.

[0022] Furthermore, while creating a data collection session, multiple test cases and their structured step information contained in the test task can be associated within the session. The structured step information serves to display the detailed execution of the test cases during subsequent backtracking and review, specifically including strict functional points, test points, preconditions, operation steps, expected results, and test results.

[0023] Specifically, during the collection session, test data generated when the target application performs test tasks can be collected. The types of test data include one or more of the following: video type, interaction event type, test case type, application state type, and log type. In the actual testing process, one or more of the above types of data can be collected as needed.

[0024] Among them, video type data (such as video stream data) refers to the video stream of the application window during the operation of the target application under test; interaction event type data (such as interaction event data) includes various interactive behavior information such as mouse operations, keyboard input, and screen touches generated when testers perform operations; test case type data corresponds to the metadata related to the current test task and the test cases called; application running status type data (such as application status data) includes application running performance indicators such as target application version information, test deployment environment information, CPU utilization, memory usage, and screen frame rate; log type data (such as client log data) refers to the local running logs generated by the client under test. The collection system reads the client's local log files in real time and divides the log content into time slices based on a time base, providing a data foundation for subsequent log retrieval and associated indexing. All types of test data are assigned a globally unified timestamp when collected and generated, thereby achieving alignment of different types of data in the time dimension, and constructing a unified timeline based on a unified time base, which facilitates subsequent defect location, data backtracking, and scenario reproduction.

[0025] Step 102: During the acquisition session, selectively acquire screen stream data of the target application's running process based on preset application identification information.

[0026] Specifically, the video stream data can be the real-time video stream displayed in the application window of the target application during the entire process of test running based on the test task. The system can completely capture the visual information of the entire process, such as the rendered screen in the application window, the interface jump in the window, the animation display, the abnormal pop-up, the screen lag, and the display abnormality, through the screen recording module of the terminal device. It can completely retain the entire display state of the application interface during the test, which can be used for subsequent defect screen backtracking and operation process screen restoration.

[0027] In one embodiment, the step "selectively collecting screen stream data of the target application's running process based on preset application identification information during the collection session" includes: Based on the preset application identification information, determine the running window of the target application from at least one running application; The output screen of the running window of the target application is recorded to generate the screen stream data.

[0028] Specifically, the step "determining the running window of the target application from at least one running application based on the preset application identifier information" includes: The target process identifier and / or target window identifier of the target application are matched based on preset application identifier information; If the preset application identifier information contains a process identifier that matches the target process identifier and / or a window identifier that corresponds to the target window identifier, then the running window of the target application is determined.

[0029] In one specific embodiment, a graphical user interface is provided by a terminal device, which displays running windows of multiple applications. Specifically, the test task is executed through the target application, and the application screen displayed in the running window of the target application is recorded based on preset application identification information. In response to the target application finishing the test task, a target video is generated based on the recorded application screen and used as the screen stream data of the target application's running process.

[0030] In this embodiment of the disclosure, testers can trigger test events for a target application. The terminal device responds to the test events for the target application by executing test tasks through the target application and matching based on a preset whitelist of applications under test (i.e., preset application identification information) and the target process identifier and / or target window identifier of the target application. The whitelist of applications under test includes multiple process names and window names. If there is a process name in the whitelist that matches the target process name and / or a window name that corresponds to the target window name, then only the target application window is recorded. Other screen content displayed on the graphical user interface will not be recorded, thus preventing privacy content from entering the data link from the source.

[0031] Optionally, the acquisition end can support pausing or resuming the acquisition of video data. During the pause, only video acquisition can be stopped, and the pause time interval can be recorded in the timeline. Specifically, the method further includes: During the acquisition session, in response to a pause trigger event, a pause operation is performed to stop the acquisition of the video stream data, while maintaining the acquisition of the interaction event data, the application status data, and the client log data; Pause intervals are recorded in the timeline information of the time-series associated data set. The pause intervals are used to identify the time sequence of the interaction event data, the application status data, and the log data during the pause operation.

[0032] In one specific embodiment, during the continuous operation of the data collection session, the client (or the data collection terminal) monitors preset pause trigger events in real time. These pause trigger events include, but are not limited to, scenarios such as: user manually triggering a data collection pause command, application switching to background operation, screen turning off, application silent operation time reaching a preset threshold, and device entering low power mode, which are non-user operation and non-application core operation scenarios.

[0033] Furthermore, when any pause trigger event is detected, the client immediately performs a targeted pause operation. The specific execution logic is as follows: stop the real-time acquisition, encoding and caching of video stream data, terminate the capture process of all video frames and visual streaming media data, and no longer add video stream data to the current time-series associated data set.

[0034] Meanwhile, the client can continuously maintain the full collection process of core related data, without interruption or pause in the collection, parsing, and storage of interactive event data, application status data, and client log data. Even during the entire period when video stream collection is paused, it continues to capture sporadic user interactions, changes in application running status, system running logs, and anomaly information in real time, ensuring uninterrupted and complete collection of core business data, operational data, and fault data.

[0035] For example, when a user temporarily switches to the phone's home screen while using the target application (the application is running in the background and triggers a pause event), the system immediately stops collecting the screen video stream of the application to avoid invalid background screen data consuming device storage and computing power; however, it continues to collect core data such as changes in background memory usage, background log errors, and background permission verification status to ensure that any abnormalities in the application's background operation can be traced throughout the entire process.

[0036] While performing the aforementioned pause operation, the client records the pause interval corresponding to this pause operation in real time based on the global timeline information of the current acquisition session. Specifically, the generation time of the pause trigger event is used as the pause start timestamp, and the time when a subsequent recovery trigger event is detected (such as the application returning to the foreground, the screen turning on, the user resuming acquisition, the device exiting low-power mode, etc.) is used as the pause end timestamp. The start and end timestamps together constitute a complete pause interval. This pause interval is uniquely associated with the timeline information of the current time-series associated data set, forming a unique time-series marker for the pause interval. The core function of this pause interval is to accurately identify the time-series attribution relationship of various types of data during the pause operation. Specifically, in the time-series associated data set, interaction event data, application status data, and client log data within the time range of this pause interval are all marked as associated data corresponding to the pause period of screen acquisition.

[0037] Furthermore, when a pause-to-resume trigger event is detected, the pause state is immediately exited, the video stream data acquisition process is restarted, and the full-dimensional data synchronous acquisition mode is restored. After the video stream data acquisition is resumed, the newly added video stream data and related data continue to be time-series marked based on the global timeline, seamlessly connecting with the acquisition data before and after the pause interval. In the final generated time-series related data set, the full-dimensional time-series data of the normal acquisition interval and the refined time-series data of the pause interval are completely retained. The time-series marking of the pause interval on the timeline completes the unified time-series regularization of all data, realizing the data fusion and summarization under different acquisition states. By explicitly recording the pause interval in the unified timeline, even if the video stream stops acquiring during the pause, the interactive events, application status samples, and client log entries continuously recorded during that period can still be accurately assigned to the corresponding time-series positions during subsequent backtracking. This effectively avoids timeline breaks and data misalignments caused by missing video, ensuring the integrity and consistency of the data chain during the reproduction of abnormal scenarios.

[0038] Optionally, the step "selectively collecting screen stream data of the target application's running process based on preset application identification information during the collection session" includes: In response to the target application running on a mobile device, and the mobile device rendering the application screen in the screen projection window of the terminal device through the screen projection channel, a screen recording operation is performed on the screen projection window based on the preset application identification information, so as to serve as the screen stream data of the target application running process.

[0039] Optionally, in addition to supporting direct recording to trigger the creation of a capture session and the binding of task identifiers, for Android / iOS testing, it also supports screen mirroring to a computer (Personal Computer, PC) via data cable to form a screen mirroring window. The PC then acts as the capture end to record the screen mirroring window to obtain video stream data. By migrating the screen mirroring recording task to the PC, this embodiment fully utilizes the PC's stronger CPU and disk write performance, effectively avoiding the processor overload, memory spikes, and frame rate drops caused by simultaneously rendering the application under test and encoding video on the mobile terminal. This significantly improves the stability of the mobile testing process and the quality of video capture.

[0040] Step 103: Collect interactive event data, application status data, and client log data in parallel during the operation of the target application.

[0041] For example, the interaction event data corresponds to all user interaction behaviors generated when testers perform test operations on the target application, specifically including various human-computer interaction events such as mouse clicks, mouse drags, keyboard key inputs, device screen touch swipes, and command triggers. At the same time, it records the trigger time, operation location, operation type, and operation sequence of each interaction behavior, completely restoring the tester's real operation trajectory and test case execution steps.

[0042] For example, the test case type data consists of the task metadata and test case metadata corresponding to this test, including basic information such as test task number, test environment information, test case ID, test case execution steps, expected results, test case execution status, and test case belonging module. This data is used to associate the test process with the test task and to achieve source matching between defects and corresponding test cases.

[0043] For example, application status data refers to the underlying running status information of the target application during testing. It includes application version information, device hardware and software environment information, system underlying running parameters, and real-time performance indicators such as CPU utilization, memory usage, video memory usage, screen rendering frame rate, and thread scheduling status. This data is used to monitor the stability of application operation and analyze the underlying causes of defects such as stuttering, crashes, and excessive resource consumption.

[0044] For example, the client log data consists of local system logs, business operation logs, exception error logs, and crash stack information generated by the client corresponding to the target application during operation. The collection end reads the log files stored locally on the client in real time, divides and organizes the massive log content into time slices according to a unified time base, and completes the construction of log entry index by combining global timestamps, so that each log segment and each error message can be matched to the accurate collection time, which facilitates the rapid retrieval of defect-related log content in the future.

[0045] Furthermore, all the aforementioned different types of test data are assigned a globally unified timestamp at the moment of collection and generation. The system constructs a continuous and ordered unified timeline based on this unified timestamp, aligning various heterogeneous data according to their chronological order, and building a multi-dimensional data index based on timestamps, task identifiers, and test case identifiers. When testers subsequently locate any time point, the system can quickly retrieve video footage, interaction records, application running status parameters, and log information for the corresponding time period based on the timestamp and index information, enabling accurate reproduction of defect scenarios and synchronous backtracking of multi-dimensional data.

[0046] Step 104: Associate the video stream data, the interaction event data, the application status data, and the client log data with a unified timestamp to establish a time-series associated data set.

[0047] In one embodiment, the acquisition end (or client) immediately reads the timestamp of a local unified clock for each frame of video stream data acquired, each user interaction event captured, each application running status update, and each client log entry generated, and attaches a millisecond-level unified timestamp to each of the four types of heterogeneous data. All video stream data, interaction event data, application status data, and client log data carrying unified timestamps are stored in a local structured data cache in chronological order according to their timestamps. This local structured cache dataset constitutes the time-series associated data set in this embodiment. This data set has a complete global timeline, and all data dimensions share the same time-series benchmark.

[0048] In another embodiment, during the session, the client independently collects video stream data, interaction event data, application status data, and client log data. Each piece of raw data is assigned an initial timestamp using the client's local clock, and these four types of heterogeneous data are uploaded to the cloud server in real time with their timestamps. The cloud server uses a globally unified time-series reference clock to perform clock deviation calibration, time-series deduplication, and sorting and reorganization on the timestamps of the raw data uploaded by all terminals. The video stream data, interaction event data, application status data, and client log data, after unified time-series calibration, are then correlated and aggregated to form a globally unified structured dataset in the cloud. This aggregated structured dataset is the time-series correlated data set in this embodiment.

[0049] Specifically, the timestamp can be the moment the data is collected, recording the collection time simultaneously. For example, if application logs and mouse clicks are collected at 00:01, then 00:01-client log data and 00:01-mouse data (i.e., interaction event data) will be recorded; if no application logs are written at 00:02, then no log data will be recorded.

[0050] Furthermore, in this embodiment, after collecting various types of test data (such as video stream data, interaction event data, application status data, and client log data) and adding a globally unified timestamp, the system can construct a mapping relationship between the timestamp and multiple types of test data to establish a time-series associated data set. The mapping relationship uses the globally unified timestamp as the unique association key, and each independent timestamp corresponds to at least two or more types of test data captured at that collection time, thus forming a time-centric data association mapping set.

[0051] Specifically, the data structure of the mapping relationship includes a primary key field and auxiliary data fields. The primary key field is a globally unified timestamp, and the auxiliary data fields are any combination of video stream data, interaction event data, application status data, client log data, and test case metadata collected synchronously at the corresponding timestamp. For heterogeneous test data collected at the same time, the system no longer stores them independently and separately, but instead achieves unified binding through this mapping relationship. That is, under the same timestamp node, the system synchronously associates the application window video frames (i.e., video stream data), real-time interactive operation events (i.e., interaction event data), performance running status parameters such as CPU and memory frame rates (i.e., application status data), client running log entries (i.e., client log data), and / or currently executed test case information at the corresponding time.

[0052] For example, when a globally unified timestamp T1 is marked as the data acquisition time, the mapping set corresponding to that timestamp may specifically include: (1) Stream data: The video frame of the interface of the application under test at time T1; (2) Interaction event data: User interaction behavior information such as mouse clicks and touch swipes that occur at time T1; (3) Application status data: CPU usage, memory usage, frame rate and other running performance indicators of the application at time T1; (4) Client log data: runtime log information and exception stack fragments generated by the client at time T1.

[0053] In one embodiment, after establishing the time-series associated data set, a mapping relationship is also established between the structured step information and the time-series associated data set. The structured step information is a set of executable test cases corresponding to the test task. Each test case is strictly constructed according to a fixed structured dimension, specifically including functional points, test points, preconditions, operation steps, expected results, and test results, achieving standardized, structured, and quantifiable description of the actions performed during testing.

[0054] In this embodiment of the disclosure, after completing the unified timestamp binding of data such as screen stream data, interaction event data, application status data, and client log data to form a time-series associated data set, the structured step information of the test cases and the time-series associated data set can be mapped one-to-one to achieve bidirectional binding between the structured step information and the data during testing. During data backtracking, the data in the corresponding time period can be quickly located through the structured step information of the test cases, and the corresponding test action can be determined by tracing the data back to the corresponding structured test step information.

[0055] Specifically, for each standardized test case's corresponding structured step information, the start and end times of the test case's execution during the test can be obtained, forming a unique execution time interval for that structured step information. The start time is the moment when the tester or automated script triggers the structured step information, and the end time is the moment when the structured step information completes execution and moves to the next structured step information. Each structured test step corresponds to an execution time interval.

[0056] Furthermore, based on a unified global timestamp, the constructed time-series associated data set is traversed to filter out all data falling within the execution time interval of the current structured step information. This data specifically includes all screen stream data, user interaction event data, application status data, and customer single log data within the time period of the structured step information. Then, a mapping relationship is established between the structured step information and the data within the corresponding time period. This allows all time-series associated data within the execution time interval to be found using the structured step information of each test case as an index. This enables precise retrieval of all runtime data generated during the execution of a test step. In addition, the global timestamp of the time-series associated data can be used as an index to match the corresponding structured test steps, allowing any piece of data to be traced back to the corresponding test action, test objective, and test scenario.

[0057] In one embodiment, after the step of "associating the video stream data, the interaction event data, the application state data, and the client log data with a unified timestamp to establish a time-series associated data set", the method further includes: Based on the time-series associated data set, at least one test case corresponding to the test task, the video stream data, the interaction event data, the application status data, and the client log data are stored in the target database.

[0058] In this embodiment, after completing the collection of multiple types of test data, the addition of a globally unified timestamp, and the construction of the mapping relationship between timestamps and multiple types of test data, the system combines the target test cases corresponding to the target test task being executed this time with the completed timestamp mapping relationship (i.e., the time-series associated data set) to perform a unified database storage operation. This process stores the target test case-related metadata, the time-series test data corresponding to the entire test process, and the mapping relationship into the target database, thereby achieving integrated persistent storage of test tasks, test cases, time-series data, and mapping relationships.

[0059] Furthermore, the step "based on the time-series associated data set, in response to a data backtracking request, acquiring the target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp" includes: Based on the time-series associated data set, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are obtained from the target database.

[0060] Specifically, users can trigger a data backtracking request through the backtracking platform. Based on the time-series associated data set, in response to the data backtracking request, the platform retrieves target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp from the target database and displays them to the user through the backtracking platform.

[0061] In another embodiment, the method further includes: Based on the aforementioned time-series associated data set, in response to analysis events for test tasks, target test cases, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are retrieved from the target database. The target model analyzes the target test cases, the target screen stream data, the target interaction event data, the target application status data, and the target client log data according to the analysis logic of at least one data analysis type, in order to generate target analysis information corresponding to each data analysis type.

[0062] The data analysis type includes at least one of the following: Quality monitoring and analysis, wherein the quality monitoring and analysis is used to detect abnormal behavior during the operation of the target application based on the target screen stream data and / or the target interaction event data; Efficiency analysis, which is used to identify execution time hotspots and / or path redundancy based on the execution time interval and / or operation path overlap of adjacent task nodes; Quality improvement analysis is used to identify visual or behavioral anomalies during the operation of the target application based on the target video stream data.

[0063] In this embodiment of the disclosure, based on a unified timeline and multiple types of test data, the target model can be used to generate analysis reports corresponding to quality supervision type, efficiency analysis type, and / or quality improvement type, and output corresponding evidence references (such as corresponding time points, video clips, video screenshots, log fragments, etc.), confidence level, and risk level.

[0064] The target model can be an Artificial Intelligence (AI) model. An AI model refers to a computer program and technical architecture that simulates human intelligence and is built based on algorithms and data training. It possesses the ability to learn, reason, make decisions, or generate data autonomously. It is used to extract features, recognize patterns, and optimize parameters from input test data to output results that meet preset goals, such as outputting analysis reports corresponding to quality supervision, efficiency analysis, and quality improvement types. AI models can be categorized into general-purpose large models (such as large language models). General-purpose large models have cross-domain adaptability and support multi-task processing, such as text generation, image recognition, and logical reasoning. Their architectures are often based on Transformer Neural Networks (TNNs) and Mixture of Experts (MoE) models.

[0065] Furthermore, to ensure the accuracy of AI model analysis and system performance, the test data can be preprocessed before inputting various types of test data into the AI ​​model; the step of analyzing the target video stream data by the target model according to the analysis logic of at least one data analysis type also includes: The target video stream data is preprocessed based on preset processing logic, and the preprocessing includes: Based on the time interval or task execution node, the target video stream data is processed into video segments to obtain multiple video clips; And / or, perform image change detection on the target image stream data to identify static image intervals; The target model is used to analyze the processed target image stream data.

[0066] Specifically, the preset processing logic can include a first preset processing logic and a second preset processing logic. The first preset processing logic can be a long video segmentation processing logic. Since a complete test screen recording is usually long, directly inputting it into a large language model (LLM) that supports multimodal processing would lead to an explosion in the number of semantic tokens, exceeding the model context limit. Therefore, the system will segment the long video into multiple short video segments according to the time interval or test case execution node (for example, segmenting by fixed time interval, with a fixed time interval as a segment unit and video keyframes as boundaries; or segmenting by test case steps, generating video segments by test case step boundaries or state transition events). These segments are then input into the multimodal LLM for inference in batches, and finally the analysis results of each segment are summarized. The second preset processing logic can be a screen change detection logic based on the perceptual hash algorithm. When detecting static or idle screen moments, the system adopts a second-level video frame extraction strategy. For the extracted adjacent video frames, the perceptual hash algorithm (pHash) is used to calculate image fingerprints and compare similarity. If the similarity of the inter-frame perceptual hash values ​​exceeds a set threshold for several consecutive seconds, the image is determined to be unchanged. This processing method significantly saves computing power and improves detection efficiency compared to having a large model directly analyze long videos.

[0067] Step 105: Based on the time-series associated data set, in response to the data backtracking request, obtain the target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp.

[0068] Specifically, users can trigger a data backtracking request through the backtracking platform. Based on the time-series associated data set, in response to the data backtracking request, the platform retrieves target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp from the target database and displays them to the user through the backtracking platform.

[0069] In one specific embodiment, the step "in response to the data backtracking request, acquiring the target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp" includes: Provide a timeline control in the backtracking interface; In response to an operation on the timeline control, a target timestamp is determined; Based on the aforementioned time-series associated data set, the target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are synchronously acquired and displayed.

[0070] In this embodiment, based on the aforementioned time-series associated data set, all test data are linked across types using timestamps, and a unified timeline is used to achieve full-data time-series arrangement. Furthermore, users can drag the time progress bar (i.e., the timeline control) to any time node (i.e., timestamp), or directly click on a marked key interactive event node or defect marker on the timeline, and the system will automatically jump to the target timestamp corresponding to that event. After determining the target timestamp, the system only needs to retrieve the target timestamp corresponding to that time node to retrieve all types of test data bound to that target timestamp at once through the mapping relationship of the time-series associated data set, achieving synchronized display of video footage, operation trajectory, running status, and log information, thereby quickly reproducing the complete scene when the defect occurred.

[0071] Specifically, the step "synchronously acquiring and displaying the target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp" includes: The backtracking interface synchronously provides a main view, a use case view, a log view, and a status view; The main view displays the target screen stream data and corresponding interaction event markers; the use case view displays structured step information associated with the target use case; the log view displays the target client log data; and the status view displays the target application status data. This embodiment of the disclosure, by simultaneously presenting the above four types of time-aligned data in a single backtracking interface, eliminates the need for testers to frequently switch between screen recording players, log analysis tools, and performance monitoring platforms for manual comparison. This allows for a complete panoramic reconstruction of the defect's occurrence within a single screen, significantly reducing manual troubleshooting costs and shortening the time required for problem localization.

[0072] Based on the above description, the following examples will further illustrate the test data processing method disclosed herein. Please refer to them for details. Figure 3 , Figure 4 and Figure 5 , Figure 3 This is a connection diagram of the processing nodes of the test data processing system provided in this embodiment of the disclosure. Figure 4 This is an interaction timing diagram of the test data provided in the embodiments of this disclosure; Figure 5This is a schematic diagram of the timeline control provided in this embodiment. The data processing system includes a data acquisition terminal, a server, a backtracking platform, and an AI analysis service. Both the server and the AI ​​analysis service are located on an intranet. The data acquisition terminal can include a personal computer (PC) test machine, an Android device, and / or an iOS device. The data acquisition terminal is responsible for tasks such as creating task sessions, binding task / use case data, recording target application windows, collecting events, reading logs, caching data, and uploading data. The server (intranet) is responsible for receiving uploads, structured storage, index building, permission verification, backtracking retrieval interfaces, and AI task orchestration. The backtracking platform (World Wide Web, Web) provides retrieval, playback, multi-view synchronization, data export, and AI report display. The AI ​​analysis service (intranet) is responsible for AI model inference and outputs structured analysis results and evidence citations. Specific embodiments of the test data processing method provided in this embodiment are as follows: (1) The acquisition terminal can create and bind task sessions. The acquisition terminal supports two paths for creating and binding task sessions. The first path is triggered by the use case platform. When the user clicks "Start Recording / Start Execution", the use case platform generates a task identifier (Identity Document, ID) and sends it to the acquisition terminal. The acquisition terminal creates a session and binds the task ID, and at the same time pulls the list of use cases and structured step information contained in the task. The second path is triggered by the acquisition terminal. The user selects the task belonging to him / her on the acquisition terminal and clicks "Start Recording". The acquisition terminal creates a session and binds the selected task ID. Similarly, it pulls the use case and step information. The acquisition terminal supports pause / resume. During the pause, video acquisition and event acquisition can be stopped, or only video acquisition can be stopped, and the pause interval is recorded in the timeline.

[0073] The acquisition terminal can also capture the screen of the target application window. The acquisition terminal maintains a whitelist of the application under test. The whitelist can include one or a combination of the following matching conditions: process name matching and window name matching. The acquisition terminal only captures the screen of the matched target window. Non-target windows are not captured directly, thus avoiding privacy content from entering the data link from the source.

[0074] Multi-source data collection includes video capture, interaction event capture, test case data capture, client log capture, and application status capture. Specifically, video capture involves recording the target application window and generating video files or segments (e.g., segmented by time period). Interaction event capture involves collecting mouse clicks, movements, keyboard presses, and touch events (for mobile screen mirroring scenarios, it involves collecting reported events from the mobile device). Test case data capture involves recording the time point when the executor clicks on each test case entry in the test case management interface and its marked status (e.g., "pass," "fail"), so that it can be located through test case entries during backtracking. Client log capture involves the collection terminal reading local log files according to configuration and recording the timestamps of log lines for quick location during backtracking. Application status capture involves collecting version number, environment information, and performance metrics (CPU / memory / FPS / network, etc., specific metrics are configurable and expandable).

[0075] At the end of the session, the acquisition end packages all the collected data and uploads it to the intranet server; for large videos, segmented upload and breakpoint resume can be used, and the session state is written back after the upload is completed.

[0076] (2) In this embodiment, a unified timestamp (second-level) is used as the primary key to strongly bind all heterogeneous data. First, test data can be tagged. At the acquisition end, the system maintains a unified session clock. Whether it is a continuous video stream (recorded by frame rate), discrete interactive events (mouse clicks, keyboard input), periodic hardware status sampling (CPU / memory), or asynchronously written local logs, when they are collected and recorded, they will be appended with an absolute or relative second-level timestamp of the current session. Then, index building can be performed. After the server receives the packaged data, it builds a multi-dimensional index database with the timestamp as the axis to support efficient point lookup and range retrieval based on timestamp. Finally, data synchronization can be achieved. In the backtracking platform, when the user drags the progress bar or positions it to a specific time point \(t\), the front end will send a query to the server. The server will instantly pull up all the corresponding data based on the timestamp \(t\): including the video frame at \(t\), the operation cases before and after \(t\), the log lines at \(t\), and hardware interaction data. In addition, when the user initiates a range backtracking request, the server responds to the request to query the target range \([t1, t2]\) by synchronously obtaining the continuous video segments, batch interaction events, and log context of that range, thereby achieving perfect synchronization of multiple views.

[0077] (3) Regarding the backtracking platform, the backtracking platform can support functions such as retrieval, multi-view synchronous playback, AI analysis display, and access control. Regarding the retrieval function, it can be searched by project, task, session, and / or test case dimensions, and supports filtering data display by time range, executor, and test case tag. Regarding the multi-view synchronous playback function, the main view can be displayed through the graphical user interface. The main view is used to display the screen recording of the target application window, click / input event markers, etc. The test case view can be displayed through the graphical user interface to display structured test case information, including test case description, execution status, executor, execution time, etc. The log view can be displayed through the graphical user interface to display log fragments that are linked with the timeline. The status view can be displayed through the graphical user interface to display performance index curves / sampling points. The timeline can be displayed through the graphical user interface to display second-level scales and supports drag-and-drop navigation. Regarding the AI ​​analysis display function, it can display the result data of AI model analysis. Regarding the access control function, it can perform project-level isolation, allowing other testers to only view the content uploaded by themselves; project test members can view the content of this project.

[0078] (4) In this embodiment of the present disclosure, test data can be analyzed using an AI model to obtain an analysis report. Specifically, the AI ​​model can take a unified timeline and multi-source test data as input, output structured results, and provide evidence citations, confidence levels, and risk levels.

[0079] 1) Optionally, embodiments of this disclosure also provide a data preprocessing and input mechanism for AI model analysis. To ensure the accuracy of AI model analysis and system performance, the system performs the following preprocessing before inputting multi-source test data into the AI ​​model: Long video segmentation: Since complete test screen recordings are usually quite long, directly inputting them into a multimodal Large Language Model (LLM) would result in an explosion in the number of tokens, exceeding the model context limit. Therefore, the system segments long videos into multiple short video segments (e.g., segments based on test case steps) according to time intervals or test case execution nodes, inputs them into the multimodal LLM for inference in batches, and finally summarizes the analysis results of each segment.

[0080] pHash-based scene change detection: During idle time detection such as when the scene is still, the system employs a second-level video frame extraction strategy. For each extracted adjacent video frame, an image fingerprint is calculated using the Perceptual Hash (pHash) algorithm, and the similarity is compared. If the pHash similarity between frames over several consecutive seconds is higher than a set threshold, the scene is determined to be unchanged. Compared to having a large model directly analyze long videos, this approach significantly saves computational costs and improves detection efficiency.

[0081] 2) To improve the efficiency of reviewing target applications, the AI ​​model analysis corresponding to the quality monitoring type can be performed as follows: Idle time detection; the judgment criteria are that the system adopts batch analysis mode to automatically detect abnormal behavior in the target test data, and identifies abnormal behavior in the testing process through the following three core dimensions: The detection principle for static scenes is based on the above-mentioned second-level frame capture + pHash algorithm to identify continuous static scenes. The judgment criteria is to record an anomaly when the screen does not change significantly for more than a set threshold. The application scenario is to effectively identify situations where the screen remains on the same interface for a long time without any operation progress.

[0082] No keyboard and mouse input; Detection principle: Real-time monitoring of keyboard and mouse input events; Judgment criteria: When there is no continuous keyboard and mouse operation for more than a set threshold, an anomaly is recorded; Application scenario: Identifying periods when testers leave their work positions or are distracted.

[0083] Application not in the foreground; Detection principle: Monitor the window focus state of the game client; Judgment criteria: Record the anomaly when the application under test loses foreground focus for more than a set threshold; Application scenario: Identify behaviors such as switching to other applications or performing non-test-related operations during the test.

[0084] Finally, the system can output information such as total duration, number and percentage of idle time, the longest time period of the Top N, and jump links (time points). All of the above thresholds can be configured.

[0085] Test process summary; summarizing long video content to improve review efficiency. Main outputs include an overview summary and a detailed summary of the following: Overview and summary: The overall process can be described as "The tester successfully completed the game login, lobby function check, and exit process."; the time consumption can be described as "The main time consumption was in the initial resource loading (2 minutes and 15 seconds) and the matchmaking wait before entering the battle (1 minute and 50 seconds)."; the execution standard judgment can be described as "The execution process was in accordance with the standards, with no redundant operations."; the problem feedback summary can be described as "10 test cases failed, accounting for 10%."

[0086] A detailed summary of the test process can be presented in tabular form. The AI ​​model analysis focuses on action recognition, result determination, time consumption analysis, and anomaly detection. Output fields include: step number, time point, action performed (AI recognition), game response / result (AI determination), time consumption, status, key screenshots / video clips, and AI annotations and analysis (e.g., bottleneck indication of long initial loading time).

[0087] 3) Regarding the testing of key functionalities, to address the difficulty of full-scale analysis, the system supports intelligent analysis of key test points at the P0 / P1 level (or user-specified points). The system identifies video segments based on test case execution time points and uses AI to provide analysis results in conjunction with test case descriptions. The output results are as follows: Test point: Test point description.

[0088] AI judgment result: core conclusion, such as fully consistent / partially consistent / significantly inconsistent / cannot be determined.

[0089] Confidence level: The degree to which the AI ​​is confident in its judgment.

[0090] Judgment criteria: A list of key factual evidence supporting the conclusion, directly cited from the video analysis results.

[0091] Risk level: Simplified to high / medium / low / none based on the degree of "non-compliance".

[0092] Recommendation: Follow-up recommendations based on the implementation status.

[0093] Output example: { "Test point": "XXXXXXXX", AI Judgment Result: "Partially Conforms" Confidence level: 0.90 "Judgment basis": [ "The video detected XXXXX, which meets the trigger condition." "XXXXX detected", "XXXXX" ], Risk Level: Medium Recommendation: "The test execution was incomplete, missing key operational steps." } 4) Efficiency analysis can be conducted from two dimensions: execution level and use case level. The aim is to identify system performance bottlenecks, user operation issues, and unreasonable use case design. At the execution level, time-consuming hotspot analysis is performed, analyzing both system performance and user operation to identify potential system performance bottlenecks or user unfamiliarity with operations. The basic process is as follows: The actual execution time of each test case is calculated by the execution time interval between adjacent test cases or test steps. Combining the test case content and execution process, AI provides a judgment result. Output: Similar to a code time-consuming heatmap, showing the distribution of test case test point time consumption. For each specific test point, the following content is displayed: Test point description: The specific content of the current test point; Test time consumption: The actual execution time of this test point; AI judgment result: Core conclusions, such as reasonable time consumption / excessive time consumption / needs to be judged in conjunction with the context. Judgment criteria: System response: Whether there are stutters or delays in interface loading, animation playback, data requests, etc. Operation density and rhythm: In the video, whether the frequency of effective operations (such as clicking, dragging, input) per unit time is too low, and whether there are unreasonable idle intervals between operations. Behavioral patterns: Whether there are behaviors unrelated to the test purpose (such as repeatedly switching screens, staying on non-critical interfaces for a long time). Risk level: High / Medium / Low. AI suggestions: Optimization suggestions given for the causes of time consumption.

[0094] Output example: { Test point description: "XXXXXX". Test duration: 15.8 seconds AI's assessment result: "Taking too long" "Judgment basis": [ "XXXX lasted for 12 seconds, far exceeding the acceptable range (it should usually be <5 seconds)." "XXXX, abnormal time consumption here." "XXXX" ], Risk Level: High AI suggestion: "This may indicate a performance bottleneck in resource loading or a stream processing issue. We recommend submitting a performance bug report for investigation first." } 5) Redundancy path identification can be performed at the use case level, combining the execution path to determine if there is room for optimization in the use case order, structure, etc. The basic process is as follows: By analyzing screen recordings of continuously executed test cases, the AI ​​will reconstruct the operation path, identifying the complete operation path of each test case in the game (such as which buttons were clicked, which interfaces were visited, and what data was entered). It will compare the operation paths of consecutive test cases to find common, reusable operation segments. Redundancy types will be identified, such as: Pre-repetition, where test case B starts by repeating operations already performed in test case A (e.g., test case A has logged in, and test case B starts by performing the login again); Path backtracking, where after executing test case A, it doesn't stay in A's final state but completely exits, requiring re-entry when executing test case B (e.g., test case A tests the "Settings" module, then completely exits to the homepage, requiring test case B to re-enter "Settings"); Inefficient order, where the execution order of test cases does not conform to the "shortest path" principle. For example, it would be better to test all functions of module A first, then module B, but the actual order involves repeatedly jumping between modules A and B.

[0095] The output may include: The analysis unit specifies a set of consecutive test cases (such as test case A -> test case B) or a test sequence to be analyzed.

[0096] The AI ​​judgment results include core conclusions, indicating the type of redundancy (redundancy exists - preceding duplication / redundancy exists - path backtracking / redundancy exists - inefficient sequence / efficient path - no significant redundancy).

[0097] The criteria for judgment include a detailed description of the discovered redundancy patterns, specific areas for optimization (such as expected time savings), and a preliminary judgment on the cause of redundancy (whether it is a use case design problem, a script problem, or a problem with the habits of the executors).

[0098] The risk level is divided into high / medium / low based on the degree to which redundancy affects test efficiency.

[0099] AI suggestions include providing specific, actionable optimization solutions, such as modifying test case design, adjusting execution order, optimizing automation scripts, or providing guidance to testers.

[0100] Output example: { "Analysis Scenario": "Two test cases: the first test case and the second test case." Analysis Unit: "First Test Case -> Second Test Case", AI Judgment Result: "Redundancy Exists - Pre-existing Duplicate", "Judgment basis": [ Redundant path description: When the first test case ends, XXXXXX, "Optimization potential: The two use cases can be seamlessly integrated." "Attribution analysis: This redundancy is not system-mandated, but rather due to the test case design or execution script failing to consider state inheritance." ], Risk Level: Medium AI Recommendation: "Optimize the design of test case sets, grouping test cases that share the same pre-state for execution. Or modify the test scripts to avoid unnecessary state resets." } 6) For quality improvement-related issues, missed bug identification can be performed. First, by analyzing test execution recordings, potential defects that testers may have overlooked or failed to report can be proactively identified. These defects usually have obvious visual or behavioral anomalies, but may be missed due to reasons such as unclear test case coverage or tester negligence. The results are then output, as follows: Detection type: The type of defect identified, such as UI misalignment, texture abnormality, performance / animation stuttering, abnormal physical effects, audio-visual desynchronization, etc.

[0101] AI assessment results: Core conclusions include finding suspected defects / not finding obvious defects.

[0102] Severity: Classified according to the impact of the defect on user experience (high / medium / low).

[0103] Location / Scope: The specific screen location or affected area where the defect occurs.

[0104] Defect Description: Clearly and specifically describe the defect phenomenon.

[0105] Triggering context: The specific operation or condition under which the defect occurs, which is the key to subsequent reproduction.

[0106] Evidence reference: Points to the specific time point in the video when the defect occurred, which facilitates manual review.

[0107] AI suggestions: Guide testers on how to report the defect, including suggestions on defect type, severity level, and steps to reproduce it.

[0108] In summary, the embodiments of this disclosure provide a test data processing method that, when testing a target application, associates collected video stream data, interaction event data, application status data, and client log data with a unified timestamp to establish a time-series associated data set. This allows testers to quickly find the desired test data from massive amounts of test data based on the target timestamp when locating specific defect scenarios, eliminating the need for manual retrieval and filtering by testers, significantly reducing time and manpower consumption, and effectively reducing retrieval computation overhead and response latency. Simultaneously, it enables rapid and accurate retrieval of test data corresponding to different timestamps, significantly improving the location accuracy and overall management efficiency of test data, thereby effectively improving the overall testing efficiency of the application and meeting the needs of high-frequency automated testing.

[0109] This embodiment also provides a test data processing device, which can be integrated into a terminal device. For example, such as Figure 6 As shown, the test data processing device may include: The response unit 201 is used to create a collection session corresponding to the test task in response to a test trigger event, wherein the test task corresponds to at least one test case; The first acquisition unit 202 is used to selectively acquire screen stream data of the target application running process based on preset application identification information during the acquisition session; The second acquisition unit 203 is used to collect interactive event data, application status data and client log data in parallel during the operation of the target application; Processing unit 204 is used to associate unified timestamps with the video stream data, the interaction event data, the application status data and the client log data respectively, and establish a time-series associated data set; The acquisition unit 205 is used to acquire, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp, based on the time-series associated data set.

[0110] In some embodiments, the test data processing apparatus includes: The first response subunit is configured to, during the acquisition session, respond to a pause trigger event, perform a pause operation to stop the acquisition of the video stream data, and maintain the acquisition of the interaction event data, the application status data, and the client log data; A recording subunit is used to record pause intervals in the timeline information of the time-series associated data set. The pause intervals are used to identify the time sequence of the interaction event data, the application status data, and the log data during the pause operation.

[0111] In some embodiments, the test data processing apparatus includes: The first recording subunit is configured to, in response to the target application running on a mobile device and the mobile device rendering the application screen in the screen projection window of the terminal device through a screen projection channel, perform a screen recording operation on the screen projection window based on the preset application identification information, so as to serve as the screen stream data of the target application running process.

[0112] In some embodiments, the test data processing apparatus includes: The first processing subunit is used to provide timeline controls in the backtracking interface; The first determining subunit is used to determine the target timestamp in response to an operation on the time axis control; The first display subunit is used to synchronously acquire and display the target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp based on the time-series associated data set.

[0113] In some embodiments, the test data processing apparatus includes: The second display subunit is used to synchronously provide the main view, use case view, log view and status view in the backtracking interface; The main view is used to display the target screen stream data and the corresponding interactive event markers; the use case view is used to display the structured step information associated with the target use case; the log view is used to display the target client log data; and the status view is used to display the target application status data.

[0114] In some embodiments, the test data processing apparatus includes: The storage subunit is used to store at least one test case corresponding to the test task, the screen stream data, the interaction event data, the application status data, and the client log data into the target database based on the time-series associated data set.

[0115] In some embodiments, the test data processing apparatus includes: The acquisition subunit is used to acquire, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp from the target database based on the time-series associated data set.

[0116] In some embodiments, the test data processing apparatus includes: The first analysis subunit is used to analyze the target test cases, the target screen stream data, the target interaction event data, the target application status data, and the target client log data according to the analysis logic of at least one data analysis type through the target model, so as to generate target analysis information corresponding to each of the data analysis types.

[0117] In some embodiments, the data analysis type includes at least one of the following: Quality monitoring and analysis, wherein the quality monitoring and analysis is used to detect abnormal behavior during the operation of the target application based on the target screen stream data and / or the target interaction event data; Efficiency analysis, which is used to identify execution time hotspots and / or path redundancy based on the execution time interval and / or operation path overlap of adjacent task nodes; Quality improvement analysis is used to identify visual or behavioral anomalies during the operation of the target application based on the target video stream data.

[0118] In some embodiments, the test data processing apparatus includes: The second processing subunit is used to preprocess the target video stream data based on preset processing logic, the preprocessing including: Based on the time interval or task execution node, the target video stream data is processed into video segments to obtain multiple video clips; And / or, perform image change detection on the target image stream data to identify static image intervals; The second analysis subunit is used to analyze the processed target image stream data using the target model.

[0119] In some embodiments, the test data processing apparatus includes: The second determining subunit is used to determine the running window of the target application from at least one running application based on the preset application identification information; The second recording subunit is used to record the output screen of the running window of the target application to generate the screen stream data.

[0120] In some embodiments, the test data processing apparatus includes: The matching subunit is used to match the target process identifier and / or target window identifier of the target application based on preset application identifier information; The third determining subunit is used to determine the running window of the target application if there is a process identifier that matches the target process identifier and / or a window identifier that corresponds to the target window identifier in the preset application identifier information.

[0121] This disclosure provides a test data processing device that, when testing a target application, associates collected video stream data, interaction event data, application status data, and client log data with a unified timestamp to establish a time-series associated data set. This allows testers to quickly find the desired test data from a massive amount of test data based on the target timestamp when locating specific defect scenarios, eliminating the need for manual retrieval and filtering. This significantly reduces time and manpower consumption, effectively minimizing retrieval computational overhead and response latency. Simultaneously, it enables rapid and accurate retrieval of test data corresponding to different timestamps, significantly improving the location accuracy and overall management efficiency of test data, thereby effectively enhancing the overall testing efficiency of the application and meeting the needs of high-frequency automated testing.

[0122] Accordingly, this disclosure also provides an electronic device, which can be a terminal, such as a smartphone, tablet computer, laptop computer, touch screen, game console, personal computer (PC), personal digital assistant (PDA), or other terminal device. Alternatively, the electronic device can be a server.

[0123] like Figure 7 As shown, Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. The electronic device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored in the memory 302 and executable on the processor. The processor 301 and the memory 302 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0124] The processor 301 is the control center of the electronic device 300. It connects various parts of the electronic device 300 via various interfaces and lines. By running or loading software programs and / or units stored in the memory 302, and by calling data stored in the memory 302, it executes various functions and processes data of the electronic device 300, thereby providing overall monitoring of the electronic device 300. The processor 301 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this disclosure.

[0125] In this embodiment of the disclosure, the processor 301 in the electronic device 300 loads the instructions corresponding to the processes of one or more applications into the memory 302 according to the following steps, and the processor 301 runs the applications stored in the memory 302 to realize various functions, such as: In response to a test trigger event, a data collection session corresponding to a test task is created, wherein the test task corresponds to at least one test case; During the acquisition session, screen stream data of the target application's running process is selectively acquired based on preset application identification information; The system collects interaction event data, application status data, and client log data during the operation of the target application in parallel. Associate the video stream data, the interaction event data, the application status data, and the client log data with a unified timestamp to establish a time-series associated data set; Based on the aforementioned time-series associated data set, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are obtained.

[0126] The electronic device provided in this disclosure can associate the collected video stream data, interaction event data, application status data, and client log data with a unified timestamp when testing a target application, establishing a time-series associated data set. This allows testers to quickly find the desired test data from a massive amount of test data based on the target timestamp when locating specific defect scenarios, eliminating the need for manual retrieval and filtering by testers. This significantly reduces time and manpower consumption, effectively reducing retrieval computation overhead and response latency. Simultaneously, it can quickly and accurately find test data corresponding to different timestamps, significantly improving the location accuracy and overall management efficiency of test data, thereby effectively improving the overall testing efficiency of the application and meeting the needs of high-frequency automated testing.

[0127] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0128] Optional, such as Figure 7 As shown, the electronic device 300 also includes: a touch display screen 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the touch display screen 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 7 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0129] The touch display screen 303 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 303 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 301. It can also receive and execute commands from the processor 301. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 301 to determine the type of touch event. Subsequently, the processor 301 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 303 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 303 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 303 can also be used as part of the input unit 306 to achieve input functions.

[0130] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0131] Audio circuitry 305 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and then processed by processor 301 before being transmitted via radio frequency circuitry 304 to, for example, another electronic device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and electronic devices.

[0132] The input unit 306 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0133] Power supply 307 is used to supply power to various components of electronic device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0134] although Figure 7 As not shown in the diagram, the electronic device 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0135] 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 in other embodiments.

[0136] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0137] Therefore, embodiments of this disclosure provide a computer-readable storage medium storing a plurality of computer programs, which can be loaded by a processor to execute any of the test data processing methods provided in embodiments of this disclosure. The computer program can execute the steps of the following test data processing method: In response to a test trigger event, a data collection session corresponding to a test task is created, wherein the test task corresponds to at least one test case; During the acquisition session, screen stream data of the target application's running process is selectively acquired based on preset application identification information; The system collects interaction event data, application status data, and client log data during the operation of the target application in parallel. Associate the video stream data, the interaction event data, the application status data, and the client log data with a unified timestamp to establish a time-series associated data set; Based on the aforementioned time-series associated data set, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are obtained.

[0138] Because the computer program stored in this storage medium can associate the collected screen stream data, interaction event data, application status data, and client log data with a unified timestamp when testing the target application, it can establish a time-series associated data set. This allows testers to quickly match and find the test data they want to view in massive amounts of test data based on the target timestamp when they need to locate specific defect scenarios, eliminating the need for testers to manually search and filter, greatly reducing time and manpower consumption, and effectively reducing retrieval computation overhead and response latency. At the same time, it can quickly and accurately find test data corresponding to different timestamps, significantly improving the location accuracy of test data and overall management efficiency, thereby effectively improving the overall testing efficiency of the application and meeting the needs of high-frequency automated testing.

[0139] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0140] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0141] Since the computer program stored in the computer-readable storage medium can execute any of the test data processing methods provided in the embodiments of this disclosure, the beneficial effects that any of the test data processing methods provided in the embodiments of this disclosure can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0142] According to one aspect of this disclosure, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0143] In the above embodiments of the test data processing apparatus, computer-readable storage medium, electronic device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes and beneficial effects of the test data processing apparatus, computer-readable storage medium, computer program product, electronic device, and their corresponding units described above can be referred to the description of the test data processing method in the above embodiments, and will not be repeated here.

[0144] The foregoing has provided a detailed description of a test data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product provided by the embodiments of this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the embodiments above are only for the purpose of helping to understand the methods and core ideas of this disclosure. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this disclosure. Therefore, the content of this specification should not be construed as a limitation of this disclosure.

Claims

1. A test data processing method, characterized in that, include: In response to a test trigger event, a data collection session corresponding to a test task is created, wherein the test task corresponds to at least one test case; During the acquisition session, screen stream data of the target application's running process is selectively acquired based on preset application identification information; The system collects interaction event data, application status data, and client log data during the operation of the target application in parallel. Associate the video stream data, the interaction event data, the application status data, and the client log data with a unified timestamp to establish a time-series associated data set; Based on the aforementioned time-series associated data set, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are obtained.

2. The method according to claim 1, characterized in that, The method further includes: During the acquisition session, in response to a pause trigger event, a pause operation is performed to stop the acquisition of the video stream data, while maintaining the acquisition of the interaction event data, the application status data, and the client log data; Pause intervals are recorded in the timeline information of the time-series associated data set. The pause intervals are used to identify the time sequence of the interaction event data, the application status data, and the log data during the pause operation.

3. The method according to claim 1, characterized in that, During the data collection session, selectively collecting video stream data of the target application's runtime process based on preset application identification information includes: In response to the target application running on a mobile device, and the mobile device rendering the application screen in the screen projection window of the terminal device through the screen projection channel, a screen recording operation is performed on the screen projection window based on the preset application identification information, so as to serve as the screen stream data of the target application running process.

4. The method according to claim 1, characterized in that, The process of responding to a data backtracking request and acquiring target video stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp includes: Provide a timeline control in the backtracking interface; In response to an operation on the timeline control, a target timestamp is determined; Based on the aforementioned time-series associated data set, the target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are synchronously acquired and displayed.

5. The method according to claim 4, characterized in that, The process of synchronously acquiring and displaying the target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp includes: The backtracking interface synchronously provides a main view, a use case view, a log view, and a status view; The main view is used to display the target screen stream data and the corresponding interactive event markers; the use case view is used to display the structured step information associated with the target use case; the log view is used to display the target client log data; and the status view is used to display the target application status data.

6. The method according to claim 1, characterized in that, After associating the video stream data, the interaction event data, the application status data, and the client log data with unified timestamps to establish a time-series associated data set, the method further includes: Based on the time-series associated data set, at least one test case corresponding to the test task, the video stream data, the interaction event data, the application status data, and the client log data are stored in the target database.

7. The method according to claim 6, characterized in that, Based on the time-series correlated data set, in response to a data backtracking request, the system acquires target video stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp, including: Based on the time-series associated data set, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp are obtained from the target database.

8. The method according to claim 1, characterized in that, The method further includes: The target model analyzes the target test cases, the target screen stream data, the target interaction event data, the target application status data, and the target client log data according to the analysis logic of at least one data analysis type, in order to generate target analysis information corresponding to each data analysis type.

9. The method according to claim 8, characterized in that, The data analysis type includes at least one of the following: Quality monitoring and analysis, wherein the quality monitoring and analysis is used to detect abnormal behavior during the operation of the target application based on the target screen stream data and / or the target interaction event data; Efficiency analysis, which is used to identify execution time hotspots and / or path redundancy based on the execution time interval and / or operation path overlap of adjacent task nodes; Quality improvement analysis is used to identify visual or behavioral anomalies during the operation of the target application based on the target video stream data.

10. The method according to claim 8, characterized in that, The steps of analyzing the target video stream data using a target model based on analysis logic of at least one data analysis type include: The target video stream data is preprocessed based on preset processing logic, and the preprocessing includes: Based on the time interval or task execution node, the target video stream data is processed into video segments to obtain multiple video clips; And / or, perform image change detection on the target image stream data to identify static image intervals; The target model is used to analyze the processed target image stream data.

11. The method according to claim 1, characterized in that, During the data collection session, selectively collecting video stream data of the target application's runtime process based on preset application identification information includes: Based on the preset application identification information, determine the running window of the target application from at least one running application; The output screen of the running window of the target application is recorded to generate the screen stream data.

12. The method according to claim 11, characterized in that, The step of determining the running window of the target application from at least one running application based on the preset application identifier information includes: The target process identifier and / or target window identifier of the target application are matched based on preset application identifier information; If the preset application identifier information contains a process identifier that matches the target process identifier and / or a window identifier that corresponds to the target window identifier, then the running window of the target application is determined.

13. A test data processing device, characterized in that, include: A response unit is used to create a data acquisition session corresponding to a test task in response to a test trigger event, wherein the test task corresponds to at least one test case; The first acquisition unit is used to selectively acquire screen stream data of the target application running process based on preset application identification information during the acquisition session; The second acquisition unit is used to collect interactive event data, application status data, and client log data in parallel during the operation of the target application. The processing unit is used to associate unified timestamps with the video stream data, the interaction event data, the application status data, and the client log data respectively, and establish a time-series associated data set; The acquisition unit is used to acquire, in response to a data backtracking request, target screen stream data, target interaction event data, target application status data, and target client log data corresponding to the target timestamp, based on the time-series associated data set.

14. An electronic device, characterized in that, The device includes a processor and a memory, the memory storing multiple instructions; the processor loads instructions from the memory to perform the steps of the test data processing method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the test data processing method as described in any one of claims 1 to 12.

Images