Test data processing method and related equipment

Abstract

The invention discloses a test data processing method and related equipment, and relates to the technical field of vehicle testing, and the method comprises the steps: carrying out the video recording based on a target vehicle-mounted camera corresponding to a preset test task, and obtaining video cache data; performing file segmentation processing on the video cache data to obtain a plurality of video segmentation files; uploading the plurality of video segment files to a cloud to obtain a plurality of video access links corresponding to the plurality of video segment files; and carrying out association processing on the plurality of video access links and the multi-dimensional test data corresponding to the preset test task to form a test data set corresponding to the preset task. According to the method, the vehicle-mounted video is continuously recorded and managed in a segmented manner, the video is uploaded to the cloud in a segmented manner, the access link is generated, and the access link is associated with the multi-dimensional test data, so that complete acquisition, stable storage, convenient access and unified management of the data in the test process are realized, and the data continuity, traceability and analysis efficiency of the test task can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle testing, and more particularly, to a test data processing method and related equipment. BACKGROUND

[0002] With the continuous improvement of intelligent networked vehicles, automatic driving testing and the complexity of vehicle electronic systems, the role of test terminals in vehicle road testing, function verification and stability testing is becoming increasingly important. Among them, the video recording in the test process as the key environmental perception information has irreplaceable value for problem reproduction, fault positioning, behavior analysis and test result verification. Through the video data collected by the vehicle-mounted camera, the test personnel can intuitively obtain the external environment, traffic conditions and device status of the vehicle in the specific task execution process, which is of great significance for improving test reliability and analysis accuracy.

[0003] However, in the related art, the video recording mode of the test terminal still generally relies on the traditional mode of local continuous recording and local storage. However, this kind of mode has obvious shortcomings in long-period, multi-task and cross-environment vehicle testing scenarios. First, long-time video continuous recording will quickly consume local storage space, and the video is easy to be interrupted due to insufficient space, making it difficult to guarantee the whole process recording of the test process. At the same time, the long video files that are not effectively managed have large volume, which not only has high storage risk, but also is not conducive to subsequent transmission, viewing and processing. Especially in vehicle testing scenarios that require multi-source information fusion analysis, the existing technology often has low data utilization rate and poor search efficiency, and cannot form a complete data link. That is, the related art has the technical problems of poor completeness of the test process and low problem positioning efficiency. SUMMARY

[0004] A series of simplified concepts are introduced in the summary part of the present application, which will be further described in detail in the specific embodiment part. The summary part of the present application does not mean to try to limit the key features and necessary technical features of the claimed technical solutions, and even less means to determine the protection scope of the claimed technical solutions.

[0005] The test data processing method and related equipment provided by the present application can realize complete collection, stable storage, convenient access and unified management of test process data by continuously recording and segmenting vehicle-mounted video, uploading video segments to the cloud and generating access links, and associating them with multi-dimensional test data, which can improve the data continuity, traceability and analysis efficiency of test tasks.

[0006] In a first aspect, this application provides a test data processing method applied to a test terminal, comprising: recording video based on a target vehicle-mounted camera corresponding to a preset test task to obtain video cache data; performing file segmentation processing on the video cache data to obtain multiple video segment files; uploading the multiple video segment files to the cloud to obtain multiple video access links corresponding to the multiple video segment files; and associating the multiple video access links with multidimensional test data corresponding to the preset test task to form a test data set corresponding to the preset task.

[0007] In some implementations, the step of segmenting the video cache data to obtain multiple video segment files includes: when the duration of the video cache data is detected to reach a preset duration threshold, segmenting the video cache data based on a preset duration to obtain the multiple video segment files; and / or, when the file size of the video cache data is detected to reach a preset memory threshold, segmenting the video cache data based on a preset file size to obtain the multiple video segment files; and / or, when a preset event is detected, segmenting the video cache data based on the start and end nodes of the preset event to obtain the multiple video segment files.

[0008] In some implementations, uploading the plurality of video segment files to the cloud includes: when the current network status of the test terminal is detected to meet preset transmission conditions, starting an upload task for the plurality of video segment files via a background asynchronous thread; during the execution of the upload task, if the current network status is detected to not meet the preset transmission conditions, pausing the upload task and recording the breakpoint information of the uploaded data segments; during the pause of the upload task, if the current network status is detected to meet the preset transmission conditions, performing a breakpoint resume operation on the video segment files that have not been uploaded based on the breakpoint information; and when any video segment file is detected to have been successfully uploaded to the cloud, receiving a success response signal returned by the cloud for the successfully uploaded target video segment file, wherein the success response signal includes the video access link of the target video segment file.

[0009] In some embodiments, the test data processing method further includes: upon receiving the successful response signal, releasing the memory space occupied by the target video segment file stored locally.

[0010] In some implementations, associating the plurality of video access links with multidimensional test data corresponding to the preset test task to form a test data set corresponding to the preset task includes: establishing a first association relationship based on the task identifiers of the plurality of video access links and the preset test task; establishing a second association relationship based on the task identifiers and the multidimensional test data, wherein the multidimensional test data is various signal data from the vehicle data bus, including vehicle bus signals, vehicle status signals, and alarm log signals; and generating a structured test data set based on the first association relationship and the second association relationship.

[0011] In some implementations, before recording video based on a target vehicle-mounted camera corresponding to a preset test task and obtaining video cache data, the test data processing method further includes: upon receiving a start command for the preset test task, sending a device registration request to the cloud to bind the device identifier of the target vehicle-mounted camera to the task identifier of the preset test task; and upon receiving a binding success confirmation signal returned by the cloud, initializing the target vehicle-mounted camera device object based on preset recording parameters, wherein the preset recording parameters include resolution and frame rate.

[0012] In some implementations, the test data processing method further includes: generating a segment index file based on the metadata of the plurality of video segment files, wherein the metadata includes the start timestamp, end timestamp, file size, associated preset event type, and corresponding video access link of the video segment file; and returning the video access link corresponding to the search request based on the segment index file when a search request for the preset test task is received.

[0013] Secondly, this application also provides a test data processing device applied to a test terminal, comprising: a video acquisition unit for recording video based on a target vehicle-mounted camera corresponding to a preset test task to obtain video cache data; a video segmentation unit for performing file segmentation processing on the video cache data to obtain multiple video segment files; a video upload unit for uploading the multiple video segment files to the cloud to obtain multiple video access links corresponding to the multiple video segment files; and a data integration unit for associating the multiple video access links with multi-dimensional test data corresponding to the preset test task to form a test data set corresponding to the preset task.

[0014] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to implement the steps of the test data processing method described in the first aspect when executing a computer program stored in the memory.

[0015] Fourthly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the test data processing method described in the first aspect.

[0016] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, they implement the steps of the test data processing method provided in the embodiments of this application.

[0017] In summary, this application, by performing video recording based on the target vehicle-mounted camera, can continuously acquire video cache data during the pre-set test task, achieving a complete record of the test scenario and helping to ensure the data continuity and traceability of the test process. Segmenting the video cache data avoids storage and transmission difficulties caused by excessively large single video files, improves file storage stability, and facilitates subsequent uploading, saving, and access. By uploading multiple video segment files to the cloud and obtaining corresponding access links, remote storage and online access to video data can be achieved, reducing local storage pressure and improving data accessibility, viewability, and access efficiency. Associating the multiple video access links generated by the upload with multi-dimensional test data related to the pre-set test task can form a complete test data set, enabling video recordings and other test information (such as time points, task parameters, and other collected data) to form a unified data structure, which is more conducive to the analysis, comparison, and problem localization of test results. In summary, the test data processing method provided in this application achieves complete data collection, stable storage, convenient access, and unified management of test process data by continuously recording and segmenting in-vehicle videos, uploading video segments to the cloud and generating access links, and associating them with multidimensional test data. This improves the data continuity, traceability, and analysis efficiency of test tasks. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating a test data processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the composition structure of a test data processing device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0020] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0021] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0022] Figure 1 This is a schematic flowchart illustrating a test data processing method provided in an embodiment of this application. For example, see [link to example]. Figure 1 The test data processing method provided in this application embodiment is applied to a test terminal. The test terminal is a hardware device or software system deployed in a vehicle test scenario, which has data acquisition, processing, and transmission functions. It is the core carrier for executing the test data processing method and can interact with in-vehicle equipment and cloud services. The test data processing method may include the following steps 101 to 104: Step 101: Record video based on the target vehicle camera corresponding to the preset test task to obtain video cache data.

[0023] In some examples, the preset test task is a predefined task instruction containing specific test requirements based on the vehicle test target before the test is executed. It serves as the basis for the test terminal to perform video recording and data processing. Testers can input task information through the test terminal's human-machine interface or cloud management platform, generate a unique task identifier, and store it in the test terminal. For example, the preset test task may include a 48-hour high-speed stability stress test, a 7-day continuous urban road condition cycle test, and a braking performance test on a specific road section. The target vehicle camera is a vehicle image acquisition device that is pre-associated with the preset test task and is used to collect video data related to the vehicle's surrounding environment and vehicle status during the test. It is the direct source of video data. Testers can install an appropriate camera at a designated location on the vehicle according to the collection requirements of the preset test task and establish a communication connection with the camera through the test terminal to complete the device association configuration. This may include a high-definition driving camera installed inside the vehicle's windshield, a wide-angle camera deployed on the side of the vehicle to collect lane-changing scenarios, and a cockpit camera facing the vehicle's interior to record driving operations. The video recording process involves the test terminal controlling the target vehicle-mounted camera to initiate image acquisition according to preset parameters, converting the dynamic scene during the test into a continuous video data stream. This is the core operation for acquiring test video data. Video cache data consists of the raw video data stream recorded by the target vehicle-mounted camera, which is temporarily stored on the local storage medium after being received by the test terminal. This data forms the basis for subsequent file processing and cloud uploads. The test terminal can receive real-time video data streams transmitted from the target vehicle-mounted camera and write them to the local storage module in real time according to a preset cache format. Examples include raw video files stored in H.264 encoding format, unsegmented continuous video data streams containing timestamp information, and high-definition raw video data blocks stored on the test terminal's local hard drive.

[0024] By implementing step 101, video recording is performed based on the target vehicle-mounted camera corresponding to the preset test task. Video cache data can be continuously acquired during the execution of the test task, so that the real situation at the test site can be completely recorded. This ensures the continuity and traceability of test process information and provides reliable video evidence for subsequent test result analysis and problem localization.

[0025] Step 102: Perform file segmentation on the video cache data to obtain multiple video segment files.

[0026] In some examples, segmentation processing is a process performed by the test terminal to split the acquired video cache data into multiple independent data segments according to preset unified rules. The purpose is to avoid problems such as storage pressure, transmission failure, and management inconvenience caused by the excessive size of a single video file, and to facilitate subsequent cloud uploads and data association. The segmentation processing logic can be built into the test terminal and automatically triggered to perform the segmentation operation during or after the generation of video cache data. For example, this includes splitting 10 hours of continuously recorded video cache data into multiple segments of uniform duration, or splitting a large-capacity original video data stream according to a fixed data volume standard, ensuring that each segment meets the preset storage and transmission requirements. Multiple video segment files are multiple video files with independent file identifiers and complete data structures formed after the video cache data has been segmented. Each file contains complete video information for a certain time period during the test and serves as the basic unit for subsequent cloud uploads and association with other test data. After the video cache data segmentation processing logic is completed, the test terminal can automatically generate and store the files in a specified local directory. Each file corresponds to a unique filename or identifier. For example, this could include 24 hourly video files obtained by segmenting 24 hours of continuously recorded video cache data, or multiple video files formed by splitting 10GB of video cache data into fixed-size segments. Each file retains the core attributes of the original video, such as image quality and frame rate.

[0027] By implementing step 102, the video cache data is processed by file segmentation, which can divide the original video, which is long and large in size, into multiple independent video segment files. This can not only avoid the storage and transmission difficulties caused by the large size of a single file, but also improve the security and stability of the data, and make subsequent video uploading, management and access more convenient and efficient.

[0028] Step 103: Upload multiple video segment files to the cloud to obtain multiple video access links corresponding to the multiple video segment files.

[0029] In some examples, the cloud may include a remote cloud computing platform (CCP) with large-scale data storage, management, and access service capabilities. This platform is the core carrier for storing video segment files and providing data access services. It supports remote access and data interaction from multiple terminals. Test terminals can establish a secure connection with the designated cloud platform through pre-configured network communication parameters, and obtain storage and access permissions after authentication. Multiple video access links are unique remote access addresses assigned to each video segment file by the cloud after successful reception and storage. These addresses allow authorized terminals to access the corresponding video segment files over the network and are key entry points for subsequent data association and video viewing. Multiple video access links can be generated automatically by the cloud after each video segment file is uploaded to the cloud and storage is confirmed. The cloud then automatically generates the corresponding access address and sends it back to the test terminal, which receives and stores each file according to its file identifier. Examples include network access addresses starting with Hypertext Transfer Protocol (HTTP), cloud-specific access links containing unique file identifiers, and direct access addresses for videos that support online playback.

[0030] By implementing step 103, the generated multiple video segment files are uploaded to the cloud and the corresponding video access links are obtained, enabling remote storage and online access to video data. This not only reduces the local storage pressure on the test terminal but also improves the accessibility, viewability, and sharing efficiency of video data, allowing testers to conveniently access relevant videos from different locations or at subsequent times.

[0031] Step 104: Associate multiple video access links with the multi-dimensional test data corresponding to the preset test task to form a test data set corresponding to the preset task.

[0032] In some examples, multidimensional test data consists of various types of test data from different vehicle data sources, collected synchronously with preset test tasks. These data cover key information such as vehicle operating status, bus transmission signals, and abnormal event records. They serve as important data support for comprehensively recreating test scenarios and assisting in problem analysis. The test terminal can collect various types of data in real time during the execution of preset test tasks through the vehicle data bus interface or related sensing devices and store them locally in a preset format. Examples include engine speed signals, vehicle speed signals, and brake pedal travel signals transmitted via the Controller Area Network (CAN) bus; vehicle body attitude signals and battery voltage signals collected by vehicle status sensors; and alarm log signals and equipment operating status signals recorded by the test system. The association processing process involves the test terminal using preset data association rules to establish a logical mapping relationship between multiple video access links and corresponding multidimensional test data. Its core purpose is to break down data silos and achieve corresponding matching between video data and other test data. The test terminal can have a built-in association processing algorithm that automatically matches and binds video access links and multidimensional test data based on a unified association identifier (such as test timestamp and task number). For example, this includes binding video access links within the same time period to the corresponding vehicle speed signal and engine speed signal according to the test timestamp, or establishing a mapping relationship between all associated video access links and all alarm log signals and vehicle posture signals under the preset test task's unique number. The test data set corresponding to the preset task is a structured and traceable data set that integrates all video access links and multi-dimensional test data related to the preset test task after association processing. It is the core data carrier for test result analysis and problem localization. After the association processing is completed, the test terminal can organize and encapsulate all the associated data according to the preset data structure to generate a unified dataset containing data indexes and classification labels for storage. For example, it includes structured data packets that integrate video access links, corresponding CAN bus signals and alarm logs for each time period, indexed by the test time axis, or complete test data files that are classified and stored according to data type and contain sets of video access links, bus signals and status signals.

[0033] By implementing step 104, multiple video access links are associated with the multi-dimensional test data corresponding to the preset test tasks. This allows video information to be integrated with test-related data such as time, parameters, and environment into a complete set of test data. This makes the test content more comprehensive and structured, facilitating analysis, comparison, and problem localization, thereby improving the data utilization efficiency of the test tasks.

[0034] In summary, this application embodiment, by performing video recording based on the target vehicle-mounted camera, can continuously acquire video cache data during the preset test task, achieving a complete record of the test scenario and helping to ensure the data continuity and traceability of the test process. Segmenting the video cache data avoids storage and transmission difficulties caused by excessively large single video files, improves file storage stability, and facilitates subsequent uploading, saving, and access. By uploading multiple video segment files to the cloud and obtaining corresponding access links, remote storage and online access to video data can be achieved, reducing local storage pressure and improving data accessibility, viewability, and access efficiency. Associating the multiple video access links generated by the upload with multi-dimensional test data related to the preset test task can form a complete test data set, enabling video recordings and other test information (such as time points, task parameters, and other collected data) to form a unified data structure, which is more conducive to the analysis, comparison, and problem localization of test results. In summary, the test data processing method provided in this application continuously records and manages vehicle-mounted videos in segments, uploads the videos to the cloud in segments and generates access links, and associates them with multi-dimensional test data. This enables complete data collection, stable storage, convenient access, and unified management of test process data, thereby improving the data continuity, traceability, and analysis efficiency of test tasks.

[0035] In some embodiments, step 102 may include: if the duration of the video cache data is detected to reach a preset duration threshold, segmenting the video cache data based on the preset duration to obtain multiple video segment files; and / or, if the file size of the video cache data is detected to reach a preset memory threshold, segmenting the video cache data based on the preset file size to obtain multiple video segment files; and / or, if a preset event is detected to occur, segmenting the video cache data based on the start and end nodes of the preset event to obtain multiple video segment files.

[0036] In some examples, the duration of video cache data refers to the time span corresponding to the continuously generated video cache data after the target vehicle camera starts recording. It is a key indicator for measuring the continuity and coverage of video data. The test terminal's built-in timing module can accumulate time from the start of video recording, synchronously recording the cumulative duration of the video cache data in real time. For example, this includes a 30-minute duration corresponding to video cache data generated from 30 minutes of continuous recording, and a 120-minute duration corresponding to video cache data generated from 2 hours of uninterrupted recording. The preset duration threshold is a time threshold set in advance in the test terminal based on video storage, transmission, and management requirements. It serves as the criterion for initiating duration-based segmentation. Testers can input specific time values ​​through the test terminal's interface or configuration file, and the test terminal stores these values ​​as the basis for segmentation judgment. For example, this includes a duration threshold set to 10 minutes and a duration threshold set to 60 minutes, used to limit the maximum recording time of a single video file. The preset duration is a fixed time length used to segment video cache data. After segmentation, the duration of each video segment file is consistent with the preset duration (except for the last segment). It can be configured synchronously with the preset duration threshold. After the tester sets the duration threshold, the test terminal automatically uses the threshold as the preset duration for segmentation; for example, it includes a 30-minute preset duration corresponding to a preset duration threshold of 60 minutes, and a 15-minute preset duration corresponding to a preset duration threshold of 40 minutes.

[0037] The file size of video cache data refers to the storage space occupied by the video cache data when it is stored locally on the test terminal. It is an indicator reflecting the size of the video data. The storage management module of the test terminal can dynamically update and report the file size information in real time, including the file size of video cache data occupying 500 megabytes of storage and the file size of video cache data occupying 1000 megabytes of storage. The preset memory threshold is a critical value of storage capacity that is pre-set in the test terminal to trigger video segmentation processing, based on the local storage capacity of the test terminal and the cloud transmission efficiency requirements. It is the judgment standard for starting segmentation based on storage capacity. Testers can input a specific storage capacity value through the configuration interface of the test terminal, and the test terminal stores this value and uses it for segmentation judgment. For example, the preset memory threshold can be set to 300 megabytes or 800 megabytes to avoid the size of a single video file being too large. The preset file size is a fixed storage capacity standard used to segment video cache data, corresponding to a preset memory threshold. The size of each video segment file after segmentation will not exceed the preset file size. It can be configured synchronously with the preset memory threshold. After the tester sets the memory threshold, the test terminal will automatically use the threshold as the preset file size for segmentation. For example, it includes a preset file size of 500 megabytes when the preset memory threshold is 500 megabytes, and a preset file size of 800 megabytes when the preset memory threshold is 1000 megabytes.

[0038] Preset events are specific test scenarios or abnormal situations that need to be recorded in advance based on vehicle testing objectives. They are the core conditions for triggering event-dimensional video segmentation. Testers can input information such as event type and judgment conditions through the test terminal, which stores the configuration and uses it for event detection. Examples include collision events detected by the vehicle acceleration sensor, engine fault alarm events detected by the test system, and preset rapid acceleration or emergency braking test scenario events. The start and end nodes of preset events are the start and end times of the preset event, corresponding to the time period boundaries related to the event in the video cache data. They are the basis for accurately segmenting event-related videos. After the test terminal detects the triggering of a preset event, it records the start timestamp of the event. After the event ends or the event termination condition is detected, it records the end timestamp of the event. The two timestamps together constitute the start and end nodes. Examples include the start time of a collision event at 16:30:22 and the end time of the collision at 16:30:35, and the start time of an engine fault alarm event at 09:15:08 and the end time of the alarm being cleared at 09:16:10.

[0039] For example, while continuously generating video cache data, the test terminal simultaneously initiates multi-dimensional monitoring of duration, file size, and preset events. When the duration of the video cache data reaches a preset duration threshold of 15 minutes, it is segmented into video segment files based on the 15-minute preset duration. If the file size first reaches a preset memory threshold of 500 megabytes, it is segmented into files based on the 500-megabyte preset file size. When the test terminal detects a preset event of collision through vehicle sensors, it immediately records the start and end points of the event, extracts the video cache data within that time period, and generates independent key event video segment files. The three segmentation methods can be triggered individually or simultaneously, ultimately resulting in multiple video segment files covering the entire test process and key scenarios, ensuring the integrity and manageability of the video data.

[0040] Through the implementation of the above embodiments, flexible file segmentation of video cache data is performed based on duration threshold, file size threshold and preset event triggering mechanism. This can effectively avoid storage and upload risks caused by excessively large single video files. At the same time, it can instantly preserve slices of sudden situations (such as fault alarms, collisions, etc.), making it easier to capture and keep the key segments in the vehicle testing process intact, and further ensuring the continuity of video and the traceability of events in long-term testing scenarios.

[0041] In some embodiments, uploading multiple video segment files to the cloud may include: when the current network status of the aforementioned test terminal meets preset transmission conditions, starting an upload task for multiple video segment files via a background asynchronous thread; during the execution of the upload task, if the current network status does not meet the preset transmission conditions, pausing the upload task and recording the breakpoint information of the uploaded data segments; during the pause of the upload task, if the current network status meets the preset transmission conditions, performing a breakpoint resume operation on the incompletely uploaded video segment files based on the breakpoint information; and when any video segment file is successfully uploaded to the cloud, receiving a success response signal returned by the cloud for the successfully uploaded target video segment file; wherein the success response signal may include a video access link for the target video segment file.

[0042] In some examples, the current network status refers to the real-time communication status of the network connected to the test terminal when performing video segment file upload operations. This can include attributes such as network connection validity, transmission rate, and stability. It is the core basis for determining whether it is suitable to start or continue the upload task. The test terminal can use a built-in network status monitoring module to collect and parse network communication parameters in real time by sending network probe packets and statistically analyzing transmission rates to generate current network status information. For example, it can be a 4G network status with a transmission rate of 10 Mbps, a 5G network status with a stable connection and no packet loss, a weak network status with a transmission rate of less than 1 Mbps, or an offline status with a network connection interruption. The preset transmission conditions are network status qualification standards pre-set in the test terminal based on cloud upload efficiency and data transmission stability requirements. These are the judgment thresholds that trigger the start or resumption of upload tasks. Testers can enter the threshold range of key parameters such as network transmission rate and connection stability through the configuration interface of the test terminal or the system configuration file. The test terminal stores the standard and uses it for network status comparison. For example, it includes setting network conditions with a transmission rate of not less than 5 megabits per second and a packet loss rate of less than 1%, or setting the network connection type as 4G or above mobile network or wired network connection conditions.

[0043] Background asynchronous threads are independent of the main business thread of the test terminal and are dedicated to performing video segment file upload tasks. Their operation will not block the core functions and interface response of the test terminal. The test terminal can automatically create independent background asynchronous threads when starting the upload task and allocate dedicated system resources for performing the upload operation. For example, these include Thread class instance threads created by the test terminal based on Java and AsyncIO asynchronous threads created based on Python, which are specifically responsible for packaging video file data and transmitting it to the cloud.

[0044] The test terminal monitors its current network status in real time, compares the collected network parameters with preset transmission conditions, and automatically creates a background asynchronous thread when the network status meets the standard. This thread handles the transmission of multiple video segment files, initiating the complete process of sending file data to the cloud. The network monitoring module of the test terminal continuously outputs network status data, and the condition judgment module compares the data with preset transmission conditions in real time. Once the conditions are met, the thread creation module is triggered to generate a background asynchronous thread, which then calls the file upload interface to start the upload task. For example, if the test terminal detects that the current 5G network transmission rate is 15 Mbps, which meets the preset transmission condition of no less than 5 Mbps, it will then create a background asynchronous thread, read the local video segment files in the order they are generated, and send upload requests to the Qiniu Cloud object storage platform.

[0045] The breakpoint information for uploaded data segments refers to the key identifiers of data segments successfully transmitted to the cloud during the video segment file upload process, when the upload is paused due to network anomalies. This includes the start and end positions of the uploaded data, data checksums, etc., and is the core basis for subsequent resume uploads. During the upload task execution, an asynchronous background thread records the data transmission progress in real time. When an upload pause is detected, the boundary parameters and checksums of the uploaded data are extracted, packaged in a preset format, and stored locally on the test terminal. For example, this includes the position information of the uploaded data of a certain video segment file from 0 bytes to 150 megabytes, the cyclic redundancy check (CRC) value of the corresponding data segment, and the confirmation identifier of the cloud receiving the data.

[0046] During the upload task, if the current network status is detected as not meeting the preset transmission conditions, the upload task is paused and the breakpoint information of the uploaded data segments is recorded. This process involves the background asynchronous thread synchronously monitoring the current network status while performing video segment file upload operations. When the network parameters are found to be lower than the preset transmission conditions (such as low speed or connection interruption), the data transmission operation is immediately stopped. At the same time, the key identification information of the uploaded data segments is extracted and stored to prepare for subsequent resumption of upload. The complete process can be achieved by the background asynchronous thread's built-in network status monitoring submodule, which can obtain the current network status data in real time and compare it with the preset transmission conditions. If the conditions are not met, an upload pause command is triggered, and the breakpoint recording module is called to collect the position, verification, and other information of the uploaded data and store it in a local specified directory. For example, during the video segment file upload process, if the test terminal detects that the current network has switched from 5G to 2G and the transmission rate has dropped to 0.8 Mbps, which is lower than the preset transmission condition of 5 Mbps, the background asynchronous thread immediately pauses the upload operation and records the breakpoint position where the file has been uploaded to 200 Mbps and the corresponding CRC check value.

[0047] During the upload task pause, if the current network status is detected to meet the preset transmission conditions, the process of resuming the unfinished video segment file upload based on the breakpoint information is as follows: After the upload task is paused due to unsatisfactory network conditions, the test terminal continuously monitors the network status. When the network status is detected to have recovered and meet the preset transmission conditions, the breakpoint information of the uploaded data segment stored locally is called, and the background asynchronous thread continues to transmit the unfinished video segment file data from the breakpoint position. This process does not require retransmitting the already uploaded part. The test terminal can maintain network monitoring status after the upload is paused. When the condition judgment module confirms that the network status meets the preset transmission conditions, it reads the breakpoint information stored locally. Based on this information, the background asynchronous thread locates the starting position of the unuploaded data, calls the breakpoint resume interface to initiate a resume request to the cloud, and transmits the data. For example, after the network recovers from a paused upload task, the test terminal detects that the current 4G network transmission rate has recovered to 8 megabits per second, meeting the preset conditions. It then reads the stored breakpoint information and confirms that a certain video segment file has been uploaded to 200 megabytes. The background asynchronous thread then starts transmitting the remaining 300 megabytes of data to the cloud from the 200 megabyte position.

[0048] A target video segment file is a single video segment file that is currently in the upload process (including uploading, paused and awaiting resumption, and completed upload) among multiple video segment files. It is the specific object of the upload operation and cloud response. The background asynchronous thread can select the file to be uploaded one by one from multiple video segment files in a preset order (such as generation time order or file name order), mark it as the target video segment file, and perform the upload operation. For example, it includes the video file "Test Task 20250520_1000_1015.mp4" which is currently being uploaded after being sorted by time, and the video file "Test Task 20250520_1015_1030.mp4" which is paused and awaiting resumption. During the transmission of the target video segment file, the background asynchronous thread continuously receives transmission status information from the cloud. Once it confirms that all data in the target video segment file has been completely uploaded to the cloud and passed verification, it receives a feedback signal from the cloud indicating successful upload. This process can be achieved by the cloud generating a success response signal containing the file storage status and a unique identifier after completing the reception, verification, and storage of the target video segment file. This signal is then fed back to the test terminal via the network channel. The background asynchronous thread detects and receives this signal. For example, after the target video segment file is completely uploaded to the Amazon Simple Storage Service platform, the cloud returns a Hypertext Transfer Protocol Response (HTTP Response) containing a "successful upload" status code and the file storage path. The background asynchronous thread on the test terminal receives this response signal and confirms successful upload. The video access link of the target video segment file is a unique remote access address assigned to the file by the cloud after the target video segment file is successfully uploaded and stored. This address allows authorized terminals to access and play the corresponding video file via the network. It is the key entry point for subsequent data association and video viewing. The cloud can automatically generate a unique access address after storing and verifying the target video segment file, encapsulate it in a success response signal and send it back to the test terminal. The test terminal receives, extracts and stores the link.

[0049] For example, after the test terminal completes the segmentation of the video file, it continuously monitors the current network status. When it detects that the 5G network transmission rate reaches 12 Mbps, meeting the preset transmission condition of no less than 5 Mbps, it immediately creates a background asynchronous thread to start the upload task. When a video segment file is transmitted up to 300 byte, a sudden network interruption causes the current network status to no longer meet the preset conditions. The background asynchronous thread then pauses the upload and records the breakpoint position and verification information of the uploaded data. After the network recovers, the test terminal detects that the current network transmission rate has recovered to 10 Mbps, meeting the preset conditions. Based on the breakpoint information, it starts the resume operation and continues to transmit the remaining data from the 300 byte position until the target video segment file is completely uploaded to the cloud. Then, it receives a successful response signal from the cloud containing the video access link, ensuring that each video segment file can be reliably uploaded and obtain the corresponding access entry.

[0050] By implementing the above embodiments, background asynchronous uploading is automatically started when the network condition is good, paused and the breakpoint is recorded when the network condition deteriorates, and the breakpoint resumed after the network condition is restored. This can improve the success rate and reliability of video file uploading in vehicle testing, avoid video loss or repeated uploading due to network fluctuations, and help ensure that test data can still be stably transmitted to the cloud under long-term road testing and weak network conditions, thereby maintaining the integrity and availability of test records.

[0051] In some embodiments, the aforementioned test data processing method may further include: upon receiving a successful response signal, releasing the memory space occupied by the locally stored target video segment file.

[0052] In some examples, the memory space occupied by the target video segment file in local storage represents the physical storage capacity used when the target video segment file is temporarily stored on the local storage medium of the test terminal before being uploaded to the cloud. This space is continuously occupied as the video file is stored until it is actively released. The storage management module (SMM) of the test terminal can monitor the space usage of the local storage medium in real time and accurately calculate the specific storage space occupied by the file by reading the storage attribute information of the target video segment file. After confirming that the target video segment file has been successfully uploaded from the cloud, the local storage release process can be triggered to delete the target video segment file from the local storage medium and reclaim the storage space it occupies.

[0053] For example, after the background asynchronous thread of the test terminal completely uploads a target video segment file to the cloud, it continuously listens for the response signal from the cloud. When it receives a response signal from the cloud containing the file's unique identifier and the upload success status, and after verifying that the signal is valid, the test terminal immediately sends a memory release command to the storage management module. The storage management module quickly locates the target video segment file stored locally according to the command, performs a safe deletion operation, and promptly reclaims the storage space occupied by the file. This ensures that the test terminal always has sufficient capacity to accommodate subsequent video recording and caching, guaranteeing the continuity and stability of data storage during long-term vehicle testing.

[0054] By implementing the above embodiments, local storage space is released in a timely manner after the video segment files are successfully uploaded to the cloud and a response is received. This can effectively alleviate the problem of insufficient storage resources in the test terminal during long-term testing, ensure that camera recording will not be interrupted due to storage exhaustion, thereby guaranteeing the continuity of video recording throughout the entire cycle and further improving the integrity of the testing process.

[0055] In some embodiments, step 104 may include: establishing a first association relationship based on the task identifiers of multiple video access links and preset test tasks; establishing a second association relationship based on the task identifiers and multidimensional test data; wherein the multidimensional test data is a variety of signal data from the vehicle data bus, and the signal data may include vehicle bus signals, vehicle status signals and alarm log signals; and generating a structured test data set based on the first association relationship and the second association relationship.

[0056] In some examples, the task identifier is a unique identifier used to identify a preset test task. It can associate video access links with multi-dimensional test data, ensuring that different types of data accurately belong to the same test task. When a preset test task is created, the test terminal or cloud system can automatically generate a unique character combination, which is then bound to the task information and stored synchronously on the test terminal and the cloud. For example, it includes the identifier "TEST_20250601_VEH001" composed of numbers, letters and symbols, or the identifier "f81d4fae-7dec-11d0-a765-00a0c91e6bf6" generated based on a Universally Unique Identifier (UUID). The first association relationship is a logical mapping relationship between multiple video access links established through task identifiers and corresponding preset test tasks. This relationship is used to clarify the boundary of the test task to which each video access link belongs. The test terminal can extract the association information of each video access link, combine it with the task identifier of the preset test task, and establish a one-to-one or one-to-many mapping relationship through the built-in association algorithm, which is then stored as an association record table. For example, this includes binding the task identifier "TEST_20250601_VEH001" to the 10 video access links generated under that task one by one, forming an association list between task identifiers and video access links.

[0057] The second association is a logical mapping between preset test tasks and corresponding multidimensional test data established through task identifiers. This clarifies the test task scope to which various types of test data belong. The test terminal can synchronously associate the task identifier of the preset test task with the data when collecting multidimensional test data. The identifier is embedded in the data header through data encapsulation, forming a mapping relationship between the task identifier and the multidimensional test data. For example, this includes binding the task identifier "TEST_20250601_VEH001" with multidimensional data such as engine speed, vehicle speed, and brake alarm logs collected during the task execution, ensuring that each type of data is labeled with its assigned task. The vehicle data bus is a dedicated communication bus used to transmit data between various electronic control units (ECUs), sensors, and actuators in the vehicle. It is the core channel for data interaction within the vehicle. The test terminal can establish a physical connection with the vehicle data bus through an adapted bus interface to obtain data transmission permissions. For example, it can include the CAN bus widely used in vehicles, the Ethernet bus for multimedia and navigation, and the LIN bus for low-cost device communication. Vehicle bus signals, vehicle status signals, and alarm log signals are all specific types of multidimensional test data. Vehicle bus signals refer to parameter signals transmitted through the vehicle data bus that reflect the operating status of the vehicle's core components. Vehicle status signals refer to data signals collected by various vehicle sensors that reflect the overall operating posture of the vehicle. Alarm log signals refer to log data generated by the vehicle system when it detects abnormal operating conditions and records abnormal events. For example, vehicle bus signals include engine speed signals and transmission gear signals; vehicle status signals include vehicle speed signals and vehicle tilt angle signals; and alarm log signals include engine fault alarm signals and braking system abnormality alarm signals.

[0058] The process of generating a structured test data set based on the first and second association relationships is a complete operational flow where the test terminal uses the task identifier as the core hub to integrate the first and second association relationships, deeply bind video access links under the same task with multidimensional test data, and organize and encapsulate them according to a preset data structure to form a unified dataset. The test terminal can call the data integration module to extract the common task identifier in the two types of association relationships, classify and combine the corresponding video access links and multidimensional test data according to time axis or data type, and generate a structured set containing indexes, classification labels, and data entries. For example, the test terminal can use "TEST_20250601_VEH001" as the core, integrate the 10 associated video access links with the corresponding engine speed, vehicle speed, fault alarm logs, and other data according to the test time sequence, and generate a structured data set indexed by the time axis.

[0059] Through the implementation of the above embodiments, a first association relationship is established between the video access link and the task identifier, and a second association relationship is established between the task identifier and multi-dimensional data such as vehicle bus signals, status signals, and alarm logs. Finally, a structured test data set is generated, which can achieve accurate correspondence between video information and vehicle dynamic behavior. This allows testers to view video and related signal changes synchronously on a unified platform, thereby greatly improving the efficiency and accuracy of problem localization, event reproduction, and anomaly analysis.

[0060] In some embodiments, prior to step 101, the aforementioned test data processing method may further include: upon receiving a start instruction for a preset test task, sending a device registration request to the cloud to bind the device identifier of the target vehicle camera to the task identifier of the preset test task; and upon receiving a binding success confirmation signal returned by the cloud, initializing the target vehicle camera device object based on preset recording parameters; wherein the preset recording parameters may include resolution and frame rate.

[0061] In some examples, the start command for a preset test task is an operation signal used to trigger the execution of the preset test task. It is the initial trigger condition for starting device registration, camera configuration, and subsequent video recording processes. The start command can be sent by the tester through the test terminal's human-machine interface (such as operation buttons or touch commands) or a remote control platform. The test terminal receives and parses the command before starting the subsequent processes. Examples include commands generated by the tester clicking the "Start 24-hour stability test" button on the test terminal interface, and remote start signals sent to the test terminal through the cloud management platform. The device registration request is a registration application signal sent by the test terminal to the cloud after receiving the preset test task start command. It contains device and task identifier information and is used to request the association between the target vehicle camera and the corresponding test task. The test terminal can extract the device identifier of the target vehicle camera and the task identifier of the preset test task, encapsulate them into a request data packet according to the cloud's communication protocol, and send it to the cloud over the network. Examples include HTTP request data packets sent by the test terminal to the Qiniu Cloud object storage platform containing the device identifier "CAM_001" and the task identifier "TEST_20250602_VEH002". The process of binding the device identifier of the target vehicle camera with the task identifier of the preset test task involves the cloud receiving the device registration request, verifying the legality of the device and the validity of the task, and establishing a unique mapping relationship between the unique identifier of the target vehicle camera and the unique identifier of the corresponding test task. This ensures that the video data and the test task are accurately associated. After receiving the device registration request, the cloud verifies the legality of the device identifier and the task identifier through a built-in verification module. Once the verification is successful, an association record between the two is created in the cloud database, forming a binding relationship. For example, the cloud may associate and store the "CAM_001" vehicle camera identifier with the "TEST_20250602_VEH002" long-term stability test task identifier, clearly indicating that the video data recorded by the camera belongs to the test task. The successful binding confirmation signal returned by the cloud is a response signal indicating successful binding sent back to the test terminal after the cloud completes the binding operation between the target vehicle camera and the preset test task. It is used to inform the test terminal that the subsequent camera configuration process can be started. For example, it includes a Hypertext Transfer Protocol response signal returned by the cloud containing a status code of "binding successful", a device identifier of "CAM_001", and a task identifier of "TEST_20250602_VEH002".

[0062] Preset recording parameters are core parameters that are pre-set to standardize the video recording effect of the target vehicle camera according to the requirements of the preset test task. They are the foundation for ensuring that the video data meets the test analysis requirements. Testers can input recording parameters that meet the test requirements through the test terminal or cloud platform when creating a preset test task. The test terminal stores these parameters and uses them for subsequent camera configuration. For example, these parameters include a 1920×1080 resolution parameter set for high-definition scene analysis and a 30 frames per second frame rate parameter set for smooth recording. Resolution and frame rate are both core components of preset recording parameters. Resolution refers to the pixel size of the video image, which determines the clarity of the video. Frame rate refers to the number of frames the camera captures per unit time, which determines the smoothness of the video. Testers can select or input the corresponding resolution and frame rate values ​​in the test terminal configuration interface according to the test scenario requirements (such as whether detailed analysis is required or whether fast dynamic processes need to be recorded).

[0063] The initial configuration process involves the test terminal receiving a successful binding confirmation signal from the cloud, then sending preset recording parameters to the target vehicle camera. This initial setup includes configuring the camera's recording mode and image parameters to ensure the camera starts recording as required by the test. The test terminal can establish a connection with the target vehicle camera via the device communication interface, converting preset parameters such as resolution and frame rate into control commands that the camera can recognize, and then sending and completing the configuration. For example, the test terminal might send control commands to the target vehicle camera to set its recording resolution to 1920×1080 and its frame rate to 30 frames per second, thus completing the initial configuration of the image acquisition parameters.

[0064] For example, the tester clicks the "Start 7-Day Urban Road Condition Cyclic Test" button on the test terminal interface, and the test terminal receives the start command for the preset test task. Subsequently, the test terminal extracts the "CAM_001" device identifier and "TEST_20250602_VEH002" task identifier of the target vehicle camera, encapsulates them into a device registration request, and sends it to the cloud. After the cloud verifies the request, it returns a confirmation signal containing the binding success status to the test terminal. Upon receiving the confirmation signal, the test terminal immediately sends the preset recording parameters to the target vehicle camera through the device API, configuring the resolution to 1920×1080 and the frame rate to 30 frames per second, completing the camera initialization configuration and preparing for subsequent video recording.

[0065] By implementing the above embodiments, the cloud binding of the vehicle camera device identifier and the test task identifier is completed before video recording, and the camera is initialized based on preset recording parameters. This ensures that the source of video data is clear and the configuration is consistent during the test, avoiding recording deviations caused by mixed use of devices or inconsistent parameters, making the test video more credible, and ensuring that subsequent analysis is based on correct and reliable data.

[0066] In some embodiments, the aforementioned test data processing method may further include: generating a segment index file based on the metadata of multiple video segment files; wherein the metadata may include the start timestamp, end timestamp, file size, associated preset event type, and corresponding video access link of the video segment file; and upon receiving a retrieval request for a preset test task, returning the video access link corresponding to the retrieval request based on the segment index file.

[0067] In some examples, metadata is data used to describe the core attributes, associated information, and access points of video segment files. It is the basic data for generating segment index files and enabling fast video retrieval. It does not include the image content of the video itself. The test terminal can collect and extract key attribute information of the file in real time during the generation and uploading of video segment files to the cloud, and integrate it into metadata according to a preset format. For example, it includes descriptive data such as the recording time range, storage capacity, associated event tags, and cloud access address of a certain video segment file. The start timestamp, end timestamp, file size, associated preset event type, and corresponding video access link of a video segment file are all specific components of the metadata. The start timestamp refers to the precise time when the video segment file begins recording; the end timestamp refers to the precise time when the video segment file stops recording; the file size refers to the storage capacity occupied by the video segment file; the associated preset event type refers to the predefined test scenario or abnormal situation type corresponding to the video segment file; the corresponding video access link refers to the unique remote access address obtained after the video segment file is uploaded to the cloud. For example, the metadata includes the start timestamp "2025-06-03 08:00:00", the end timestamp "2025-06-03 08:15:00", the file size "500 megabytes", the associated preset event type "emergency braking", and the corresponding video access link "https: / / xxx.yyy.com / TEST_20250603_VEH003_080000.mp4".

[0068] A retrieval request is a query sent by testers or authorized terminals to a test terminal or cloud system to obtain specific video segment files corresponding to a preset test task. It includes retrieval conditions (such as time range and event type). Testers can input or select specific retrieval conditions through the retrieval interface of the test terminal or the cloud management platform, which are then encapsulated into standardized retrieval request instructions and transmitted to the data processing module. For example, it includes a retrieval request to query "videos recorded between 08:00 and 09:00 on June 3, 2025" or a retrieval request to query "videos associated with collision events".

[0069] When a retrieval request for a preset test task is received, the process of returning the video access link corresponding to the retrieval request based on the segmented index file is a complete operation flow whereby the test terminal or cloud system receives a request containing specific search conditions, calls the segmented index file to perform condition matching, filters out the metadata corresponding to the video segment files that meet the requirements, extracts the video access link from them, and returns it to the requester. This can be achieved by the system receiving the retrieval request, parsing the search conditions (such as time range, event type), traversing all the metadata stored in the segmented index file, comparing the attribute information in the metadata with the search conditions, extracting the corresponding video access link after a successful match, and returning it in a preset format. For example, after the system receives a retrieval request to "query videos between 08:00 and 08:30 on June 3, 2025," it traverses the segmented index file, filters out the metadata of three video segment files whose start and end timestamps fall within that time period, extracts the corresponding three video access links, and returns them to the tester.

[0070] Through the implementation of the above embodiments, a segmented index file is generated based on the metadata of the video segment file, and relevant video access links are quickly returned based on the index when a retrieval request is received. This enables efficient retrieval of massive video data over a long period of time, allowing testers to accurately locate video segments of specific time periods or events, significantly reducing manual search time, and thus improving the efficiency of problem review and on-site reproduction in vehicle testing.

[0071] Furthermore, as an implementation of the foregoing method embodiments, this application also provides a test data processing device, applied to a test terminal, for implementing the foregoing method embodiments. This device embodiment corresponds to the foregoing method embodiments. For ease of reading, this test data processing device embodiment will not repeat the details of the foregoing method embodiments one by one, but it should be understood that the device in this application embodiment can correspondingly implement all the contents of the foregoing method embodiments. For example... Figure 2 As shown, the test data processing device 20 includes: a video acquisition unit 201, a video segmentation unit 202, a video upload unit 203, and a data integration unit 204. The video acquisition unit 201 records video based on a target vehicle-mounted camera corresponding to a preset test task, obtaining video cache data. The video segmentation unit 202 performs file segmentation processing on the video cache data to obtain multiple video segment files. The video upload unit 203 uploads the multiple video segment files to the cloud to obtain multiple video access links corresponding to the multiple video segment files. The data integration unit 204 associates the multiple video access links with multi-dimensional test data corresponding to the preset test task, forming a test data set corresponding to the preset task.

[0072] In some embodiments, the video segmentation unit 202 is further configured to, when the duration of the video cache data is detected to reach a preset duration threshold, segment the video cache data based on a preset duration to obtain multiple video segment files; and / or, when the file size of the video cache data is detected to reach a preset memory threshold, segment the video cache data based on a preset file size to obtain multiple video segment files; and / or, when a preset event is detected to occur, segment the video cache data based on the start and end nodes of the preset event to obtain multiple video segment files.

[0073] In some embodiments, the video uploading unit 203 is further configured to, when the current network status of the test terminal is detected to meet preset transmission conditions, initiate multiple video segment file upload tasks through a background asynchronous thread; during the execution of the upload task, if the current network status is detected to not meet the preset transmission conditions, the upload task is paused and the breakpoint information of the uploaded data segments is recorded; during the pause of the upload task, if the current network status is detected to meet the preset transmission conditions, the breakpoint resume operation is performed on the video segment files that have not been uploaded incompletely based on the breakpoint information; and when any video segment file is detected to have been successfully uploaded to the cloud, receive a success response signal returned by the cloud for the successfully uploaded target video segment file, wherein the success response signal includes the video access link of the target video segment file.

[0074] In some embodiments, the video uploading unit 203 is further configured to release the memory space occupied by the target video segment file stored locally upon receiving a successful response signal.

[0075] In some embodiments, the data integration unit 204 is further configured to establish a first association relationship based on multiple video access links and task identifiers of preset test tasks; establish a second association relationship based on task identifiers and multidimensional test data, wherein the multidimensional test data is various signal data from the vehicle data bus, including vehicle bus signals, vehicle status signals and alarm log signals; and generate a structured test data set based on the first association relationship and the second association relationship.

[0076] In some embodiments, the video acquisition unit 201 is further configured to send a device registration request to the cloud upon receiving a start command for a preset test task, so as to bind the device identifier of the target vehicle camera to the task identifier of the preset test task; and after receiving a binding success confirmation signal returned by the cloud, initialize the target vehicle camera device object based on preset recording parameters, wherein the preset recording parameters include resolution and frame rate.

[0077] In some embodiments, the test data processing device 20 further includes a video indexing unit, configured to generate a segmented index file based on the metadata of multiple video segment files, wherein the metadata includes the start timestamp, end timestamp, file size, associated preset event type, and corresponding video access link of the video segment file; and upon receiving a retrieval request for a preset test task, return the video access link corresponding to the retrieval request based on the segmented index file.

[0078] This application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, which, when executed by a processor, will cause the processor to perform any step of the test data processing method provided in this application.

[0079] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0080] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0081] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0082] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0083] like Figure 3As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described test data processing method.

[0084] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the test data processing method described above.

[0085] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A test data processing method, characterized by, The test data processing method applied to a test terminal comprises: Recording a video based on a target vehicle-mounted camera corresponding to a preset test task to obtain video cache data; Performing file segmentation processing on the video cache data to obtain a plurality of video segment files; Uploading the plurality of video segment files to a cloud to obtain a plurality of video access links corresponding to the plurality of video segment files; Associating the plurality of video access links with multi-dimensional test data corresponding to the preset test task to form a test data set corresponding to the preset task.

2. The test data processing method of claim 1, wherein, The file segmentation processing on the video cache data to obtain a plurality of video segment files comprises: In a case where it is detected that a time length of the video cache data reaches a preset time length threshold, performing segmentation processing on the video cache data based on a preset time length to obtain the plurality of video segment files; And / or, in a case where it is detected that a file size of the video cache data reaches a preset memory threshold, performing segmentation processing on the video cache data based on a preset file size to obtain the plurality of video segment files; And / or, in a case where it is detected that a preset event occurs, performing segmentation processing on the video cache data based on start and end nodes of the preset event to obtain the plurality of video segment files.

3. The test data processing method of claim 1, wherein, The uploading of the plurality of video segment files to the cloud comprises: In a case where it is detected that a current network state of the test terminal meets a preset transmission condition, starting an uploading task of the plurality of video segment files through a background asynchronous thread; In a process of executing the uploading task, if it is detected that the current network state does not meet the preset transmission condition, pausing the uploading task and recording breakpoint information of uploaded data segments; In a process of pausing the uploading task, if it is detected that the current network state meets the preset transmission condition, performing a breakpoint resume operation on a video segment file that has not been uploaded based on the breakpoint information; In a case where it is detected that any video segment file is successfully uploaded to the cloud, receiving a successful response signal returned by the cloud for a target video segment file that is successfully uploaded, wherein the successful response signal comprises a video access link of the target video segment file.

4. The test data processing method of claim 3, wherein, The test data processing method further comprises: In a case where the successful response signal is received, releasing a memory space occupied by the target video segment file stored locally.

5. The test data processing method of claim 1, wherein, The association of the plurality of video access links with multi-dimensional test data corresponding to the preset test task to form a test data set corresponding to the preset task comprises: Establishing a first association relationship based on the plurality of video access links and a task identifier of the preset test task; Establishing a second association relationship based on the task identifier and the multi-dimensional test data, wherein the multi-dimensional test data is a plurality of signal data from a vehicle data bus, and the signal data comprises vehicle bus signals, vehicle state signals and alarm log signals; Generating a structured test data set based on the first association relationship and the second association relationship.

6. The test data processing method of claim 1, wherein, Before video recording based on the target vehicle-mounted camera corresponding to the preset test task is performed to obtain video cache data, the test data processing method further includes: In the case where the starting instruction of the preset test task is received, a device registration request is sent to the cloud to bind the device identifier of the target vehicle-mounted camera with the task identifier of the preset test task; After the binding success confirmation signal returned by the cloud is received, the target vehicle-mounted camera device object is initialized and configured based on preset recording parameters, wherein the preset recording parameters include resolution and frame rate.

7. The test data processing method of claim 1, wherein, The test data processing method further includes: Based on the metadata of the plurality of video segment files, a segment index file is generated, wherein the metadata includes the start timestamp, the end timestamp, the file size, the associated preset event type and the corresponding video access link of the video segment file; When a retrieval request for the preset test task is received, based on the segment index file, a video access link corresponding to the retrieval request is returned.

8. A test data processing apparatus, characterized by, The test data processing apparatus applied to a test terminal includes: A video acquisition unit configured to perform video recording based on a target vehicle-mounted camera corresponding to a preset test task to obtain video cache data; A video segmentation unit configured to perform file segmentation processing on the video cache data to obtain a plurality of video segment files; A video upload unit configured to upload the plurality of video segment files to the cloud to obtain a plurality of video access links corresponding to the plurality of video segment files; A data integration unit configured to associate the plurality of video access links with multi-dimensional test data corresponding to the preset test task to form a test data set corresponding to the preset task.

9. An electronic device comprising: A memory and a processor, wherein the processor is configured to implement the steps of the test data processing method according to any one of claims 1 to 7 when executing the computer program stored in the memory.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the test data processing method according to any one of claims 1 to 7.

Images