Vehicle test method and vehicle test system

Abstract

The present application relates to a kind of vehicle test method and vehicle test system, wherein, vehicle test method includes: when the change test log content in the vehicle test log exists change, in the multiple preset agent modules corresponding to vehicle test flow, determine the target agent module corresponding to change test log content, multiple preset agent modules correspond to different test stages in vehicle test flow;Change test log content is sent to target agent module;Target agent module executes test operation based on change test log content, obtains the test data of current test stage, and sends the test data.This application embodiment is initiated by system in each test stage, no longer waits for manual triggering in the middle of the way, directly solve the problem of blocking in test process, realize the automation of vehicle test flow, improve test efficiency.

Description

Technical Field

[0001] This application relates to the field of testing, and more particularly to a vehicle testing method and a vehicle testing system. Background Technology

[0002] In the era of intelligent connectivity, the release of a vehicle version involves three major stages: requirements review, development, and testing. Testers' work includes writing test cases based on requirements, manually or automatically executing these test cases on a bench, reporting bugs, and finally generating test reports upon successful testing. Throughout these stages, testers interact with different modules: the requirements module to view and break down requirements and write test cases; the test case module to input test cases and establish relationships between test cases and statistical data such as test requirements, test lists, and test metrics; the execution module to perform manual and automated testing tasks; the defect module to submit and process bug reports; and the version module to understand the requirements included in each vehicle version, thereby defining the testing scope and the test cases to be used.

[0003] Traditional solutions typically take the form of software systems, with each testing module being a separate software system. Interactions between these systems generally utilize REST API interfaces. For scenarios involving requirement generation, test case generation scripts, end-to-end tracking of intelligent repair requirements, and test case refinement, traditional solutions suffer from low testing efficiency, are time-consuming and manpower-intensive, and cannot meet the rapid iteration demands of intelligent connected vehicles. Currently, no product in the industry can simultaneously and fully satisfy all of these requirements. Summary of the Invention

[0004] To solve the above-mentioned technical problems, or at least partially solve them, this application provides a vehicle testing method and a vehicle testing system.

[0005] Firstly, this application provides a whole vehicle testing method, including:

[0006] The backend service checks whether there are any changed test log entries in the vehicle test logs.

[0007] If there is changed test log content in the vehicle test log, the backend service determines the target proxy module corresponding to the changed test log content from multiple preset proxy modules corresponding to the vehicle test process. The multiple preset proxy modules correspond to different test stages in the vehicle test process.

[0008] The backend service sends the change test log content to the target proxy module;

[0009] The target proxy module performs test operations based on the changed test log content, obtains the test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle test process.

[0010] Optionally, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0011] If the changed test log content is the log content corresponding to the test requirement, the backend service obtains the first test requirement data from the changed test log content.

[0012] The backend service determines whether the first test requirement data differs from the historical second test requirement data;

[0013] If the first test requirement data differs from each of the second test requirement data, the backend service determines the requirement proxy module as the target proxy module.

[0014] Optionally, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0015] The requirement proxy module obtains the requirement format information of multiple test requirements from historical records;

[0016] The requirement proxy module parses the first test requirement data according to the requirement format information to obtain requirement parsing data, which is used as the test data for the current testing phase.

[0017] The demand proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

[0018] Optionally, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0019] If the test log content is changed to the log content corresponding to the test case, the backend service obtains the first test case data from the changed test log content.

[0020] The backend service determines whether the data of the first test case is different from the data of the second test case in the historical records;

[0021] If the data of the first test case is different from the data of each of the second test cases, the backend service will determine the test case proxy module as the target proxy module.

[0022] Optionally, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0023] The test case proxy module obtains the test case format information of multiple test cases from historical records;

[0024] The test case proxy module generates test cases and related information based on the test case format information.

[0025] The test case proxy module generates automated test scripts for test bench execution based on the test case information that can be automatically executed and the preset script library, and stores them in the script repository;

[0026] The test case proxy module determines the automated test script, the storage address of the automated test script in the script repository, the test case identifier of the test case, and the script identifier of the automated test script as the test data for the current testing phase.

[0027] The test case proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

[0028] Optionally, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0029] If the test log content is changed to the log content corresponding to the test version, the backend service obtains the first test version data from the changed test log content.

[0030] The backend service determines whether the data of the first test version is different from the data of the second test version in the historical records;

[0031] If the data of the first test version is different from the data of each of the second test versions, the backend service will determine the version proxy module as the target proxy module.

[0032] Optionally, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0033] The version proxy module creates manual test tasks based on the test cases that cannot be automatically executed, generated by the test case proxy module.

[0034] The version proxy module generates automated test tasks based on the automated test scripts that can be automatically executed, generated by the test case proxy module.

[0035] The version proxy module retrieves version format information for multiple test versions from historical records;

[0036] The version proxy module assigns the manual testing task to the corresponding tester based on the version format information and obtains the manual assignment information.

[0037] The version proxy module allocates automated test tasks to target test benches according to the version format information and obtains automated allocation information.

[0038] The version proxy module determines the manually allocated information and the automatically allocated information as the test data for the current testing phase;

[0039] The version proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

[0040] Optionally, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0041] If the changed test log content is the log content corresponding to the test defect, the backend service obtains the first test defect data from the changed test log content.

[0042] The backend service determines whether the first test defect data is different from the historical second test defect data;

[0043] If the first test defect data is different from each of the second test defect data, the backend service will identify the defect proxy module as the target proxy module.

[0044] Optionally, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0045] The defect proxy module obtains the defect format information of multiple test defects from historical records, the manual test results obtained from manual test tasks, and the automated test results obtained from automated test tasks.

[0046] The defect proxy module generates a defect report based on the defect format information, the manual test results, and the automated test results, which serves as the test data for the current testing phase.

[0047] The defect proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

[0048] Optionally, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0049] If the changed test log content is the same as the log content corresponding to the test report, the backend service retrieves the first test report data from the changed test log content.

[0050] The backend service determines whether the first test report data differs from the historical second test report data;

[0051] If the data in the first test report is different from the data in each of the second test reports, the backend service will identify the report proxy module as the target proxy module.

[0052] Optionally, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0053] The report proxy module obtains the report format information of multiple test reports from historical records and the defect report generated by the defect proxy module;

[0054] The report agent module generates a report based on the report format information and the defect report, which serves as the test data for the current testing phase.

[0055] The report proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

[0056] Secondly, this application provides a whole vehicle testing system, including: a backend service and a test agent cluster, wherein the test agent cluster includes: multiple preset agent modules;

[0057] The backend service is used to detect whether there is any changed test log content in the vehicle test log. If there is changed test log content in the vehicle test log, the target proxy module corresponding to the changed test log content is determined from multiple preset proxy modules corresponding to the vehicle test process. The multiple preset proxy modules correspond to different test stages in the vehicle test process, and the changed test log content is sent to the target proxy module.

[0058] The target proxy module is used to perform test operations based on the changed test log content, obtain the test data of the current test stage, and send the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle test process.

[0059] The beneficial effects of this invention are:

[0060] This embodiment of the application monitors changes to the test log content through a backend service and sends the changed test log content to the target proxy module corresponding to the corresponding test stage in the vehicle testing process. The target proxy module then performs test operations based on the changed test log content to obtain the test data for the current stage, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process. Through the collaborative cooperation between the backend service and the target proxy module, the corresponding stage of the vehicle testing process is completed. Each test stage is initiated proactively by the system, without waiting for manual triggering, directly solving the problem of blocking during the test. Moreover, since the target proxy module can be a preset proxy module corresponding to different test stages in the vehicle testing process, the collaboration between the backend service and the target proxy modules of different test stages can realize the automation of the vehicle testing process and improve testing efficiency. Attached Figure Description

[0061] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0062] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 An architecture diagram of a vehicle testing system provided in this application embodiment;

[0064] Figure 2 A schematic diagram illustrating the interaction of a preset proxy module using the A2A protocol, provided as an embodiment of this application;

[0065] Figure 3 A schematic diagram illustrating the interaction of another preset proxy module using the A2A protocol, provided in an embodiment of this application;

[0066] Figure 4 A schematic diagram illustrating the interaction of another preset proxy module using the A2A protocol, provided in an embodiment of this application;

[0067] Figure 5A schematic diagram illustrating the interaction of another preset proxy module using the A2A protocol, provided in an embodiment of this application;

[0068] Figure 6 A flowchart of a vehicle testing method provided in this application embodiment;

[0069] Figure 7 A schematic diagram of a vehicle testing process in a practical application provided by an embodiment of this application;

[0070] Figure 8 This is a flowchart illustrating a vehicle testing method in a practical application, as provided in an embodiment of this application. Detailed Implementation

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

[0072] Traditional solutions typically take the form of software systems, with each testing module operating as a separate system. Interactions between these systems generally rely on REST APIs. For scenarios involving requirement generation of test cases, test case generation scripts, end-to-end intelligent repair of requirements, and test case refinement, traditional solutions suffer from low testing efficiency, high time and manpower consumption, and cannot meet the rapid iteration demands of intelligent connected vehicles. Currently, no product in the industry can simultaneously and fully satisfy all these requirements. Therefore, this application provides a vehicle testing method and system to address the challenge of testers testing a single vehicle version across multiple systems in vehicle-level testing scenarios. It offers a test case and script generation model that is more closely aligned with the overall vehicle testing scenario compared to existing commercially available models.

[0073] like Figure 1 As shown in the embodiment of this application, a whole vehicle testing system is provided, including: a backend service (server) and a test agent cluster. The test agent cluster can be an AI Agent cluster, and the server and the AI ​​Agent cluster interact using the MCP standard protocol.

[0074] Most commercially available open-source AI models cannot perform data preprocessing. Due to the confidentiality and massive volume of data in vehicle testing, commercially available AI models often cannot adapt to vertical business scenarios. This application breaks down the vehicle testing process into multiple stages, each corresponding to a proxy module. Therefore, in this embodiment, the test proxy cluster includes multiple preset proxy modules. Specifically, the preset proxy modules can be requirement proxy modules, test case proxy modules, version proxy modules, defect proxy modules, or report proxy modules. Each proxy module is trained and fine-tuned separately for a precise business scenario. Its main functions are: requirement to test case generation, test case to script generation, automatic task generation and execution, automatic order submission (automatic defect generation), and automatic test report generation. During application, users can add or remove proxy modules and flexibly combine them according to actual business scenario requirements to achieve high scalability.

[0075] The backend service is used to detect whether there is any changed test log content in the vehicle test log. If there is changed test log content in the vehicle test log, the target proxy module corresponding to the changed test log content is determined from multiple preset proxy modules corresponding to the vehicle test process. The multiple preset proxy modules correspond to different test stages in the vehicle test process, and the changed test log content is sent to the target proxy module.

[0076] The primary function of the backend service (server) is listening to the binlogs of each database table in various modules. The binlog content is categorized into five main types: requirements, use cases, versions, defects, and reports. Specifically, the server listens to data from multiple databases and tables across multiple systems (such as the requirements system, use case system, version system, defect system, and reporting system). These include the requirements database (requirements details table, requirements attachment table, requirements function table, requirements reuse table, etc.), the use case database (use case details table, use case steps table, use case requirements table, use case script table), the version database (version details table, version project table, version requirements table, version personnel table, etc.), the task database (task details table, task execution table, task use case table, task plan table, etc.), and the defect database (defect details table, defect process table, defect operation table, defect use case table, etc.). Each table transmits data to the AI ​​Agent cluster via the MCP protocol.

[0077] The second function of the backend service (server) is to receive data sent back by various proxy modules and add or update it to the specified database table. If the data returned by the proxy module contains the database primary key id, it is an update; otherwise, it is an add.

[0078] The target proxy module is used to perform test operations based on the changed test log content, obtain the test data of the current test stage, and send the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle test process.

[0079] After receiving data, the AI ​​Agent cluster generates test cases based on requirements, and then generates scripts based on the test cases. Based on this, when a vehicle version (the version must be generated based on requirements) is released, the cluster finds the test cases related to the requirements by associating the version with the requirements, then creates test tasks and starts executing automated tasks directly. Then, defects are generated based on the execution of the tasks, and test reports are generated based on the defects and execution. Finally, the reports drive the modification of test cases and requirements.

[0080] The various agent modules within the Agent cluster interact using the A2A protocol. The A2A protocol provides native support for four interaction modes through basic protocol adaptation and core component encapsulation. When using A2A interaction, you can choose one of the following four methods based on your actual needs:

[0081] like Figure 2 As shown, the request-response mode is a standardized synchronous communication based on JSON-RPC, mainly used in scenarios that require immediate feedback (such as querying basic information between proxy modules). In the request-response mode, application A (the requester) sends a message containing a unique request identifier to application B (the responder). After processing, application B returns a response with the identifier, ensuring that the request and response correspond one-to-one. It supports two triggering methods: synchronous (the requester blocks and waits for the response) or semi-synchronous (the requester is non-blocking and obtains the response through callback / polling).

[0082] Technical implementation: The request and response formats are directly encapsulated based on the JSON-RPC 2.0 protocol.

[0083] The initiator (proxy module A) constructs a JSON-RPC request containing the method name, parameters, and request ID, and sends it to the receiver (proxy module B) via HTTP POST.

[0084] After processing, the receiver returns a JSON response containing the request ID, result, and error information, ensuring that each request corresponds to a specific response.

[0085] Core safeguards: Requests and responses are bound by request IDs to prevent message corruption; a timeout retry mechanism is supported to ensure the reliability of synchronous communication.

[0086] like Figure 3As shown, the publish-subscribe pattern is a multi-terminal collaboration based on event brokers and topic subscriptions. It is mainly used in scenarios where an event requires multiple broker modules to respond (such as notifying multiple broker modules such as logistics, finance, and membership systems after a successful order payment). The publish-subscribe pattern introduces a message broker as a relay station. The publisher sends the message to the specified topic of the broker. The broker stores the message and pushes it to all subscribers according to the subscription relationship. It supports topic filtering (such as filtering messages by tags) and persistence (to avoid message loss when subscribers are offline).

[0087] Technical implementation: Based on the A2A event broker component and topic subscription mechanism.

[0088] The publisher (any proxy module) publishes the event (including event type, data, and timestamp) to the specified Topic (e.g., order.paid).

[0089] The event broker maintains a mapping table of Topic and subscribers, and automatically pushes events to all broker modules that have subscribed to the Topic (such as the logistics broker module and the financial broker module).

[0090] The subscriber processes the data asynchronously after receiving it, without needing to return the result to the publisher, thus achieving decoupled one-to-many communication.

[0091] Key features: Supports Topic hierarchical division (such as order.paid.online, order.paid.offline) to meet refined subscription needs.

[0092] like Figure 4 As shown, streaming mode: based on SSE / WebSocket, it is a continuous data transmission mode used in scenarios requiring continuous bidirectional / unidirectional streaming (such as real-time voice interaction, video stream analysis, and multimodal data synchronization). Streaming mode uses a data stream as its core carrier: data is continuously generated in chronological or business-order sequence (such as user behavior logs and sensor data). The sender uses a stream processing platform to split the data into partitions for parallel transmission, and the receiver (stream processor) consumes and processes the data in real time, supporting Exactly-Once reliability assurance.

[0093] Technical implementation: Adapt SSE (Server-Sent Events) or WebSocket protocols according to the scenario and encapsulate them as an A2A streaming channel.

[0094] One-way streaming (such as real-time log push): uses the SSE protocol. The sender (such as a monitoring agent module) establishes a long connection via HTTP and continuously pushes text / binary streams to the receiver, which does not need to return data.

[0095] Two-way streaming (e.g., voice dialogue): Employs the WebSocket protocol. Full-duplex connections are established between proxy modules, allowing simultaneous sending and receiving of streaming data (e.g., voice clips, captions), with latency below 100ms, meeting real-time interaction requirements.

[0096] Protocol adaptation: A2A will standardize the format header of stream data (including stream type and encoding method) to ensure that stream data between different proxy modules can be parsed in a compatible manner.

[0097] like Figure 5 As shown, asynchronous message mode: non-blocking communication based on event queue + state tracking, used in scenarios where immediate response is not required and message loss must be guaranteed (such as task scheduling, non-real-time data processing).

[0098] The asynchronous messaging pattern implements point-to-point asynchronous communication based on message queues: the sender writes messages to the queue, the queue stores messages in first-in-first-out (FIFO) order, the receiver pulls or receives pushed messages from the queue, and does not need to return a response after processing (or returns an asynchronous response through another queue); it supports reliability mechanisms such as message persistence dead-letter queues (for processing failed messages).

[0099] Technical implementation: Combining A2A message queue and task status management components.

[0100] The sender (agent module M) delivers the message (including task instructions and priority) to the built-in message queue of A2A and immediately returns the message ID without waiting for processing.

[0101] The receiver (agent module N) pulls messages from the queue and processes them asynchronously according to its own load and priority. After processing, the receiver writes the processing result and message ID into the A2A status database. The sender can query the task status (such as pending, processing, or completed) by message ID.

[0102] Reliability assurance: Supports message persistence (such as writing to Redis / MongoDB), and unprocessed messages can be recovered from the queue after restarting even if the agent module goes offline; provides a dead-letter queue, and messages that fail to be processed will be transferred to avoid blocking the queue.

[0103] All interactions between the proxy modules described above utilize the A2A protocol. The A2A protocol supports four interaction modes: request-response, publish-subscribe, streaming, and asynchronous messaging. In contrast, the traditional MCP protocol only supports request-response. This diversity of interaction modes gives A2A greater capabilities. Request-response mode provides basic synchronous communication; publish-subscribe mode supports multi-device subscriptions via event-driven mechanisms and message brokers; streaming mode natively supports SSE and WebSocket, enabling the transmission of multimodal streams; and asynchronous messaging mode implements non-blocking message delivery based on event queues.

[0104] Based on the aforementioned vehicle testing system, this application provides a vehicle testing method, such as... Figure 6 As shown, it includes the following steps:

[0105] Step S101: The backend service checks whether there are any changed test log contents in the vehicle test log.

[0106] In this embodiment of the application, the vehicle test log is log data that is updated in real time in the databases of multiple related systems (such as a requirement system for collecting, processing and storing test requirements, a test case system for collecting, processing and storing test cases, a version system for collecting, processing and storing test versions, a defect system for collecting, processing and storing test defects, and a report system for collecting, processing and storing test reports) during the vehicle test.

[0107] The changed log content is the change test log content. A change refers to the addition or modification of log content. The change test log content can be user input or returned by various preset proxy modules to the backend service, which then stores it in the corresponding database. The data service receives the data sent back by each proxy module and adds or modifies it in the specified database table. The backend service can determine the log change type based on whether the database primary key ID is present in the data returned by the proxy module. If the database primary key ID is present in the data returned by the proxy module, it is a modification type; otherwise, it is an addition type.

[0108] When the backend service detects an addition or modification to a requirement, it distributes the relevant information (requirement level, requirement content, requirement attachments, and requirement developer) to the requirement proxy module. If the requirement is modified, the test cases originally associated with the requirement will be discarded, and the new test cases returned by the requirement proxy module will be associated with the discarded test cases and stored in the database for easy backtracking.

[0109] When the backend service detects the addition or modification of test cases, it distributes the relevant content of the test case (test case primary key ID (not present when adding, but present when updating), test case level, test case details, test case preconditions, test case steps and expectations, and the relationship between the test case and the requirement) to the test case proxy module. Then, it uses the test case script address and test case primary key ID returned by the test case proxy module to update the data in the test case table.

[0110] When the backend service detects version additions or modifications, it distributes version-related information (version name, version start time, version end time, version requirements, version testers, test cases related to version requirements, association between test cases and scripts, test cases between scripts, current configuration and workload status of the HIL bench) to the version proxy module.

[0111] When the backend service detects additions or modifications to test cases in a task, it distributes the relevant information of the test cases that result in failure (test case level, test case content, current operator of the test case, version associated with the task, association between the test case and the requirement, and the developer of the requirement) to the defect proxy module.

[0112] The backend service listens for the addition and modification of tasks and defects. Based on the version associated with the listened task, it queries all tasks and defects under the current version to determine whether all tasks under the current version have been completed and whether all defects have been closed. If both are true, it distributes the necessary information, such as the execution results and execution time of all test cases in the tasks under the current version, the severity level, creation time, resolution time of all defects, and the email address of the person in charge of the version, to the report agent module.

[0113] Step S102: If there is changed test log content in the vehicle test log, the backend service determines the target proxy module corresponding to the changed test log content from among the multiple preset proxy modules corresponding to the vehicle test process.

[0114] In this embodiment of the application, multiple preset agent modules correspond to different testing stages in the vehicle testing process, such as... Figure 7 As shown, the whole vehicle testing process includes: requirements analysis, test case generation, script generation, version analysis, task generation, task execution, defect generation / tracking and report generation, etc. The backend service interacts with multiple preset proxy modules in the order of each testing stage in the whole vehicle testing process, which can realize the automation of the whole vehicle testing process.

[0115] In this step, the backend service can determine the test phase associated with the changed test log content, and then use the preset proxy module corresponding to the associated test phase as the target proxy module.

[0116] In one embodiment of this application, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0117] If the changed test log content corresponds to the test requirement, the backend service retrieves the first test requirement data from the changed test log content; the backend service determines whether the first test requirement data is different from the historical second test requirement data; if the first test requirement data is different from each of the second test requirement data, the backend service determines that the requirement proxy module is the target proxy module.

[0118] In other words, if the backend service determines that the changed test log content is related to the test requirement, it can extract the first test requirement data from the changed test log content. The backend service compares the first test requirement data with each second test requirement data in the historical records. When the first test requirement data is different from all the second test requirement data, it automatically determines that the first test requirement data is a newly added or modified test requirement, and can process the test requirement. The backend service determines the requirement proxy module as the target proxy module so that the requirement proxy module, as the target proxy module, can automatically process the test requirement in the future.

[0119] For example, if the test log content is changed to include the log content corresponding to the new test requirement "remote unlock", and this changed test content is different from all the second test requirement data in the historical records, the first test requirement data is automatically determined to be a newly added or modified test requirement. This test requirement can be processed, and the requirement proxy module can be identified as the target proxy module so that the requirement proxy module can automatically parse and decompose the "remote unlock" test requirement. The entire trigger determination and proxy module allocation process does not require manual intervention, thus improving the testing efficiency of this test requirement test phase.

[0120] In another embodiment of this application, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0121] If the changed test log content corresponds to the log content of the test case, the backend service obtains the first test case data from the changed test log content; the backend service determines whether the first test case data is different from the historical second test case data; if the first test case data is different from each of the second test case data, the backend service determines the test case proxy module as the target proxy module.

[0122] In other words, if the backend service determines that the changed test log content is related to the test case, it can extract the first test case data from the changed test log content. The backend service compares the first test case data with the second test case data in the historical records. When the first test case data is different from all the second test case data, it automatically determines that the first test case data is a newly added or modified test case, and can process the test case. The backend service determines the test case proxy module as the target proxy module so that the test case proxy module, as the target proxy module, can automatically process the test case subsequently.

[0123] For example, if the change in the test log content is: modifying the log content of the test case corresponding to "remote unlock", and the changed test content is different from all the second test case data in the historical records, it indicates that the first test case data is a newly added or modified test case. This test case can be processed, and the test case proxy module can be identified as the target proxy module so that the test case proxy module can automatically generate one or more test cases for "remote unlock" based on the changed test log content. The entire trigger determination and proxy module allocation process does not require manual intervention, thus improving the testing efficiency of this test case test phase.

[0124] In another embodiment of this application, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0125] If the changed test log content corresponds to the test version, the backend service retrieves the first test version data from the changed test log content; the backend service determines whether the first test version data is different from the historical second test version data; if the first test version data is different from each of the second test version data, the backend service determines the version proxy module as the target proxy module.

[0126] In other words, if the backend service determines that the changed test log content is related to the test version, it can extract the first test version data from the changed test log content. The backend service compares the first test version data with the second test version data in the historical records. When the first test version data is different from all the second test version data, it automatically determines that the first test version data is a newly added or modified test version and can be processed. The backend service determines the version proxy module as the target proxy module so that the version proxy module, as the target proxy module, can automatically process the test version in the future.

[0127] For example, if the test log content is changed to include the log content of the newly added "remote unlock" test version, and this changed test content is different from all the second test version data in the historical records, it indicates that the first test version data is a newly added or modified test version. This test version can be processed, and the version proxy module can be identified as the target proxy module so that the version proxy module can be automatically assigned to the corresponding testers or automatically generate automated tasks, allocate test benches and execution times, etc. The entire trigger determination and proxy module allocation process does not require manual intervention, thereby improving the testing efficiency of this test version in this test phase.

[0128] In another embodiment of this application, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0129] If the changed test log content corresponds to the test defect, the backend service retrieves the first test defect data from the changed test log content; the backend service determines whether the first test defect data is different from the second test defect data in the historical records; if the first test defect data is different from each of the second test defect data, the backend service determines the defect proxy module as the target proxy module.

[0130] In other words, if the backend service determines that the changed test log content is related to the test defect, it can extract the first test defect data from the changed test log content. The backend service compares the first test defect data with each second test defect data in the historical records. When the first test defect data is different from all the second test defect data, it automatically determines that the first test defect data is a newly added or modified test defect, and can process the test defect. The backend service determines the defect proxy module as the target proxy module so that the defect proxy module, as the target proxy module, can automatically process the test defect in the future.

[0131] For example, if the test log content is changed to modify the log content of the "remote unlock" test defect, and this changed test content is different from all the second test defect data in the historical records, it indicates that the first test defect data is a newly added or modified test defect. This test defect can be processed, and the defect proxy module can be identified as the target proxy module so that the defect proxy module can automatically generate defect tickets in the future. The entire trigger judgment and proxy module allocation process does not require manual intervention, thus improving the testing efficiency of this test defect test phase.

[0132] In another embodiment of this application, the backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including:

[0133] If the changed test log content is the same as the log content corresponding to the test report, the backend service obtains the first test report data from the changed test log content; the backend service determines whether the first test report data is different from the historical second test report data; if the first test report data is different from each of the second test report data, the backend service determines the report proxy module as the target proxy module.

[0134] In other words, if the backend service determines that the changed test log content is related to the test report, it can extract the first test report data from the changed test log content. The backend service compares the first test report data with each second test report data in the historical records. When the first test report data is different from all the second test report data, it automatically determines that the first test report data is a newly added or modified test report, and can process the test report. The backend service determines the report proxy module as the target proxy module so that the report proxy module, as the target proxy module, can automatically process the test report in the future.

[0135] For example, if the change in the test log content is: modifying the log content of the "remote unlock" test report, and this changed test content is different from all the second test report data in the historical records, it indicates that the first test report data is a newly added or modified test report. This test report can be processed, and the report proxy module can be identified as the target proxy module so that the report proxy module can automatically generate reports in the future. The entire trigger determination and proxy module allocation process does not require manual intervention, thus improving the testing efficiency of this test report test phase.

[0136] Step S103: The backend service sends the change test log content to the target proxy module;

[0137] Step S104: The target proxy module performs test operations based on the changed test log content, obtains the test data for the current test stage, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle test process.

[0138] After receiving the changed test log content, the target agent module can perform corresponding test operations based on the changed test log content, such as: requirement analysis, test case and automated script generation, version allocation, defect handling and report generation.

[0139] In one embodiment of this application, the target proxy module performs test operations based on the changed test log content, obtains test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0140] The requirement proxy module obtains requirement format information of multiple test requirements from historical records; the requirement proxy module parses the first test requirement data according to the requirement format information to obtain requirement parsing data, which is used as the test data for the current test stage; the requirement proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

[0141] In practical applications, the requirement proxy module needs to learn the table structure and data content related to the requirements (requirement module) and / or use cases (use case module) in advance. The data content includes: requirement name, requirement description, and requirement attachments, etc. After receiving the relevant information of the requirement, the module automatically parses and decomposes the requirement. For example, if the test requirement is remote unlocking, it can parse out multiple details, such as: Detail 1, after the APP clicks the unlock function, it uploads the unlock request with the vehicle identifier to the cloud; Detail 2, the cloud finds the vehicle to be unlocked based on the vehicle identifier; Detail 3, controls the vehicle to power on; Detail 4, controls the vehicle to unlock, etc. The parsed requirement data is automatically sent to the use case proxy module, version proxy module, and defect proxy module. The entire testing phase does not require manual intervention, improving the testing efficiency of the test requirement parsing and decomposition phase.

[0142] In another embodiment of this application, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0143] The test case proxy module obtains the test case format information of multiple test cases from historical records; the test case proxy module generates test cases and related information based on the test case format information; the test case proxy module generates automated test scripts for test bench execution based on the test case information that can be automatically executed and a preset script library, and stores them in the script repository; the test case proxy module determines the automated test script, the storage address of the automated test script in the script repository, the test case identifier of the test case, and the script identifier of the automated test script as the test data for the current test phase; the test case proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process.

[0144] In practical applications, the test case proxy module needs to pre-configure a script signal library and learn in advance the relationship between the whole vehicle test scripts and test cases, as well as the table structure and data related to the test cases (test case module). After receiving relevant information about the requirements, it automatically generates one or more test cases based on the requirements information, including the test case name, level, preconditions, steps, expectations, and association with the requirements. It automatically integrates the data according to the fields in the test case table in the test case system, and sends the data and test case table name back to the server for storage. Then, it automatically generates an automated script executable for the hardware-in-the-loop (HIL) test bench based on the integrated test case information and the pre-configured script signal library, and stores the automated script in the Git Hub repository (i.e., the script repository). It returns the repository address and test case primary key ID to the server so that the server can modify the test case system. The entire testing phase does not require manual intervention, improving the testing efficiency of the test case generation phase.

[0145] In another embodiment of this application, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0146] The version proxy module creates manual test tasks based on test cases that cannot be automatically executed, generated by the test case proxy module; the version proxy module generates automated test tasks based on automated test scripts that can be automatically executed, generated by the test case proxy module; the version proxy module obtains version format information of multiple test versions in history; the version proxy module assigns the manual test tasks to corresponding testers according to the version format information, obtaining manual assignment information; the version proxy module assigns automated test tasks to target test benches according to the version format information, obtaining automated assignment information; the version proxy module determines the manual assignment information and automated assignment information as the test data for the current test phase; the version proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process.

[0147] The version proxy module is mainly used to create tasks and plan their execution time. It needs to learn the relevant table structures and data for versions (version module), manual tasks (test case module), test cases (test case module), and automated tasks (execution module) in advance, including which requirements and developers are included in each version. Upon receiving version-related information, for manual tasks (such as checking if a screen click operation works manually), if historical personnel and test case allocation methods can be found, they will be used to automatically assign them to the appropriate personnel. If no reference is available, test cases will be automatically and evenly allocated to testers, with each tester responsible for one test task. Test cases will be evenly distributed within each test task, and task message reminders will be automatically sent to each tester performing a manual task. For automated tasks (i.e., tasks that can be executed automatically without human intervention), the module automatically generates automated tasks based on the test case preconditions and the relationship between scripts sent by the test case proxy module (e.g., one test case generates three scripts). It automatically assigns associated test cases to an automated task and automatically sets the target platform and target execution time for each task based on the current platform configuration and workload. Each task integrates data according to the fields in the task table, and automatically sends the data and task table name back to the server. All tasks generated by the version agent module are new, and no manual intervention is required throughout the entire testing phase, which improves the testing efficiency of the test version generation and allocation phase.

[0148] In another embodiment of this application, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0149] The defect proxy module acquires the defect format information of multiple test defects from historical records, the manual test results obtained from manual test tasks, and the automated test results obtained from automated test tasks; the defect proxy module generates a defect report based on the defect format information, the manual test results, and the automated test results, as test data for the current test stage; the defect proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

[0150] In practical applications, the defect proxy module needs to learn the relevant table structures and data of the version (version module), manual tasks (use case module), use case tasks (use case module), automated tasks (execution module), and requirement developers (requirement module) in advance. After receiving relevant information about task use cases, it automatically generates defect tickets, integrates data according to the fields in the defect table in the defect ticket, and automatically sends the defect (bug) data and defect table name (including version data, which task generated it, and who the target person to solve it) back to the server. The tasks generated by the defect proxy module are all new, and no manual intervention is required in the entire testing phase, which improves the testing efficiency of the test defect summary testing phase.

[0151] In another embodiment of this application, the target proxy module performs test operations based on the changed test log content to obtain test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including:

[0152] The report proxy module obtains the report format information of multiple test reports from historical records and the defect report generated by the defect proxy module; the report proxy module generates a report based on the report format information and the defect report as test data for the current test phase; the report proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process.

[0153] In practical applications, the report broker module needs to pre-learn the requirements, test case content, test report templates, and historical report examples, and has a built-in chart generation component. Upon receiving relevant information about test cases and defects, it directly generates a test report, sends it to the server for storage, and finally sends it to the version manager's email address. Within the test report, the report broker module analyzes defects and test cases, outputting improvements to the test cases and requirements, thus completing the test loop. The entire testing phase requires no manual intervention, improving the efficiency of the test report generation stage.

[0154] All interactions between the proxy modules described above utilize the A2A protocol, covering the entire testing lifecycle from requirement generation to report-based test case and requirement optimization, thus completing the testing loop. Through the proxy module cluster, each module can directly access the others, improving efficiency throughout the entire testing cycle. The A2A protocol supports four interaction modes: request-response, publish-subscribe, streaming, and asynchronous messaging. In contrast, the traditional MCP protocol only supports the request-response mode. This diversity of interaction modes gives A2A more capabilities. The request-response mode provides basic synchronous communication; the publish-subscribe mode supports multi-terminal subscriptions via event-driven mechanisms and message brokers; the streaming mode natively supports SSE and WebSocket, enabling the transmission of multimodal streams; and the asynchronous messaging mode implements non-blocking message delivery based on event queues.

[0155] A cluster of proxy modules is adopted, interacting directly via an A2A protocol to shorten data transmission links. This enables a complete testing loop, starting from requirements, generating test cases, generating scripts, executing test cases / scripts, identifying defects, generating reports, and finally back-engineering and optimizing test cases and requirements. The cluster contains multiple proxy modules, each using datasets from their respective module's database. Regardless of changes to the interfaces between modules, the data and definitions of the database tables remain largely unchanged. Each proxy module directly accesses the database fields of each module. Through training and fine-tuning, every piece of business data can be matched with the data table fields, shortening the data interaction links between modules and significantly reducing communication and development costs between modules.

[0156] For ease of understanding, such as Figure 8As shown in the embodiment of this application, an overall process for a whole vehicle testing method is also provided. The requirement proxy module receives data from the requirement library. If it finds that the data is new, it starts the workflow. After analyzing the requirements, the requirement source, and the requirement developer, the requirement proxy module decomposes the requirements and transmits the parsed requirement data to the test case proxy module. It also sends the parsed requirements, requirement developer data, and requirement tester data to the version proxy module and the defect proxy module. After receiving the requirement data, the test case proxy module generates test cases for the requirements and generates automated test scripts for the generated test cases. Then, it sends the test cases and script data to the version proxy module, sends the test case data to the report proxy module, and finally transmits the test cases to the server via MCP, where they are stored in the database. The version proxy module combines the data sent by the requirement proxy module and the test case proxy module, selects test cases to create manual tasks, and selects scripts to create automated tasks. Manual tasks are assigned to the corresponding personnel, and automated tasks are automatically deployed to the test bench for execution via the server. Then, it sends the task and test case data to the defect proxy module, sends the version data to the report proxy module, and finally stores the manual and automated tasks in the database. The defect proxy module automatically generates defect tickets for failed test cases and scripts based on the received data, matches them with the corresponding development personnel, and then sends the defect data to the report proxy module. Finally, the defect is stored in the database via the server. The report proxy module analyzes versions, test cases, tasks, and defects, sends test reports to testers and developers, and then sends the report data to the requirements and test case proxy modules for optimization. Finally, the report is stored in the database via the server.

[0157] In other words, after a version release (which defines the scope of requirements and testers), virtual employees proactively select the scope of test cases, automatically creating test tasks (manual or automated). For automated tasks, they autonomously select the test bench and run the test directly. If a failed test case occurs within the task (manual or automated), a bug report is automatically generated, and the designated person to resolve the bug is automatically assigned. The bug's progress is then tracked, and a test report is automatically generated after the bug is closed and the task is completed, completing the test loop. Each step is proactively initiated by the system, eliminating the need for manual intervention and directly resolving any bottlenecks during testing, thus improving testing efficiency.

[0158] In summary, after the requirements are generated, the decomposition of requirements, the generation of test cases, and the generation of test case scripts are all automatically triggered and generated by virtual employees. No user intervention is required. For manual task scenarios, human participation is only required in the manual task stage. For automated task scenarios, zero human intervention can be achieved from the time the requirements are released, achieving an automated closed loop for the entire testing process and improving the efficiency of the entire testing process.

[0159] This embodiment of the application monitors changes to the test log content through a backend service and sends the changed test log content to the target proxy module corresponding to the corresponding test stage in the vehicle testing process. The target proxy module then performs test operations based on the changed test log content to obtain the test data for the current stage, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process. Through the collaborative cooperation between the backend service and the target proxy module, the corresponding stage of the vehicle testing process is completed. Each test stage is initiated proactively by the system, without waiting for manual triggering, directly solving the problem of blocking during the test. Moreover, since the target proxy module can be a preset proxy module corresponding to different test stages in the vehicle testing process, the collaboration between the backend service and the target proxy modules of different test stages can realize the automation of the vehicle testing process and improve testing efficiency.

[0160] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0161] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for testing a complete vehicle, characterized in that, include: The backend service checks whether there are any changed test log entries in the vehicle test logs. If there are changed test log contents in the vehicle test log, the backend service determines the target proxy module corresponding to the changed test log contents from multiple preset proxy modules corresponding to the vehicle test process. The multiple preset proxy modules correspond to different test stages in the vehicle test process. The backend service sends the change test log content to the target proxy module; The target proxy module performs test operations based on the changed test log content, obtains the test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle test process.

2. The vehicle testing method according to claim 1, characterized in that, The backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including: If the changed test log content is the log content corresponding to the test requirement, the backend service obtains the first test requirement data from the changed test log content. The backend service determines whether the first test requirement data differs from the historical second test requirement data; If the first test requirement data differs from each of the second test requirement data, the backend service determines the requirement proxy module as the target proxy module.

3. The vehicle testing method according to claim 2, characterized in that, The target proxy module performs test operations based on the changed test log content, obtains the test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including: The requirement proxy module obtains the requirement format information of multiple test requirements from historical records; The requirement proxy module parses the first test requirement data according to the requirement format information to obtain requirement parsing data, which is used as the test data for the current testing phase. The demand proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

4. The vehicle testing method according to claim 1, characterized in that, The backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including: If the test log content is changed to the log content corresponding to the test case, the backend service obtains the first test case data from the changed test log content. The backend service determines whether the data of the first test case is different from the data of the second test case in the historical records; If the data of the first test case is different from the data of each of the second test cases, the backend service will determine the test case proxy module as the target proxy module.

5. The vehicle testing method according to claim 4, characterized in that, The target proxy module performs test operations based on the changed test log content, obtains the test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including: The test case proxy module obtains the test case format information of multiple test cases from historical records; The test case proxy module generates test cases and related information based on the test case format information. The test case proxy module generates automated test scripts for test bench execution based on the test case information that can be automatically executed and the preset script library, and stores them in the script repository; The test case proxy module determines the automated test script, the storage address of the automated test script in the script repository, the test case identifier of the test case, and the script identifier of the automated test script as the test data for the current testing phase. The test case proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

6. The vehicle testing method according to claim 1, characterized in that, The backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including: If the test log content is changed to the log content corresponding to the test version, the backend service obtains the first test version data from the changed test log content. The backend service determines whether the data of the first test version is different from the data of the second test version in the historical records; If the data of the first test version is different from the data of each of the second test versions, the backend service will determine the version proxy module as the target proxy module.

7. The vehicle testing method according to claim 6, characterized in that, The target proxy module performs test operations based on the changed test log content, obtains the test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including: The version proxy module creates manual test tasks based on the test cases that cannot be automatically executed, generated by the test case proxy module. The version proxy module generates automated test tasks based on the automated test scripts that can be automatically executed, generated by the test case proxy module. The version proxy module retrieves version format information for multiple test versions from historical records; The version proxy module assigns the manual testing task to the corresponding tester based on the version format information and obtains the manual assignment information. The version proxy module allocates automated test tasks to target test benches according to the version format information and obtains automated allocation information. The version proxy module determines the manually allocated information and the automatically allocated information as the test data for the current testing phase; The version proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

8. The vehicle testing method according to claim 1, characterized in that, The backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including: If the changed test log content is the log content corresponding to the test defect, the backend service obtains the first test defect data from the changed test log content. The backend service determines whether the first test defect data is different from the historical second test defect data; If the first test defect data is different from each of the second test defect data, the backend service will identify the defect proxy module as the target proxy module.

9. The vehicle testing method according to claim 8, characterized in that, The target proxy module performs test operations based on the changed test log content, obtains the test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including: The defect proxy module obtains the defect format information of multiple test defects from historical records, the manual test results obtained from manual test tasks, and the automated test results obtained from automated test tasks. The defect proxy module generates a defect report based on the defect format information, the manual test results, and the automated test results, which serves as the test data for the current testing phase. The defect proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

10. The vehicle testing method according to claim 1, characterized in that, The backend service determines the target proxy module corresponding to the changed test log content from among multiple preset proxy modules corresponding to the vehicle testing process, including: If the changed test log content is the same as the log content corresponding to the test report, the backend service retrieves the first test report data from the changed test log content. The backend service determines whether the first test report data differs from the historical second test report data; If the data in the first test report is different from the data in each of the second test reports, the backend service will identify the report proxy module as the target proxy module.

11. The vehicle testing method according to claim 10, characterized in that, The target proxy module performs test operations based on the changed test log content, obtains the test data for the current test phase, and sends the test data to the backend service and / or the preset proxy modules corresponding to other test phases in the vehicle testing process, including: The report proxy module obtains the report format information of multiple test reports from historical records and the defect report generated by the defect proxy module; The report agent module generates a report based on the report format information and the defect report, which serves as the test data for the current testing phase. The report proxy module sends the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle testing process.

12. A vehicle testing system, characterized in that, include: Backend service and test proxy cluster, wherein the test proxy cluster includes: multiple preset proxy modules; The backend service is used to detect whether there is any changed test log content in the vehicle test log. If there is changed test log content in the vehicle test log, the target proxy module corresponding to the changed test log content is determined from multiple preset proxy modules corresponding to the vehicle test process. The multiple preset proxy modules correspond to different test stages in the vehicle test process, and the changed test log content is sent to the target proxy module. The target proxy module is used to perform test operations based on the changed test log content, obtain the test data of the current test stage, and send the test data to the backend service and / or the preset proxy modules corresponding to other test stages in the vehicle test process.

Images