Vehicle software testing method and device based on large model

Abstract

The invention provides a vehicle software testing method and device based on a large model, and relates to the technical field of software testing, and the method comprises the steps: obtaining the testing demand information of to-be-tested vehicle software; generating a model prompt according to the test demand information, wherein the model prompt is used for indicating to generate resources required by the vehicle software test; inputting the model prompt into the large model, and obtaining each driving scene and a vehicle software test case output by the large model; performing physical rule verification on each driving scene; determining the driving scene passing the verification as a target driving scene, and inputting the target driving scene into a simulation platform to obtain simulation data of the target driving scene; and inputting the simulation data and the test case into an automatic test platform to enable the automatic test platform to analyze the simulation data, and executing the test case according to the analyzed simulation data to obtain a test result. By applying the method provided by the invention, the test efficiency and the coverage rate can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of software testing, and in particular to a vehicle software testing method and device based on a large model. Background Art

[0002] With the rapid development of autonomous driving technology and intelligent vehicle systems, ensuring the safety and reliability of vehicle software has become critical. Traditional software testing methods often seem inadequate when faced with complex and changing driving scenarios.

[0003] Existing testing methods usually rely on manually writing and maintaining a large number of test cases, which is not only time-consuming and labor-intensive, but also difficult to cover all possible driving scenarios. In addition, manually written test cases are prone to missing edge cases and extreme conditions, leading to potential safety hazards. Summary of the invention

[0004] The technical problem to be solved by this application is to provide a vehicle software testing method and device based on a large model, which can improve the testing efficiency and coverage. The specific solution is as follows: A vehicle software testing method based on a large model, the method comprising: Obtaining test requirement information of the vehicle software to be tested; generating a model prompt according to the test requirement information, wherein the model prompt is used to indicate resources required for generating vehicle software testing; Inputting the model prompts into the trained large model to obtain various driving scenarios and vehicle software test cases output by the large model; Performing physical rule verification on each of the driving scenarios; If there are multiple driving scenarios that pass the physical rule verification, the driving scenarios that pass the physical rule verification are determined as candidate driving scenarios, and each of the candidate driving scenarios is input into a pre-built risk prediction model to obtain an output result of the risk prediction model; the output result includes a priority ranking of each of the candidate driving scenarios; the risk prediction model and the large model share latent space representation in historical data through joint training; Determining a target driving scenario from among the candidate driving scenarios according to the priority ranking of the candidate driving scenarios; Inputting the target driving scene into a simulation platform to obtain simulation data of the target driving scene; The simulation data of the target driving scenario and the vehicle software test case are input into the automated testing platform so that the automated testing platform parses the simulation data, and executes the vehicle software test case according to the parsed simulation data to obtain a test result.

[0005] In the above method, optionally, generating a model prompt according to the test requirement information includes: Obtaining software version information, function type information, test target information, and driving scenario requirements in the test requirement information; The software version information, function type information, test target information and driving scenario requirements are input into a preset prompt word template to obtain a model prompt.

[0006] In the above method, optionally, inputting the simulation data of the target driving scenario and the vehicle software test case into the automated testing platform comprises: Using a pre-trained anomaly recognition model to perform anomaly detection on the simulation data of the target driving scene to obtain a recognition result of the simulation data; When the recognition result indicates that the simulation data is normal, the simulation data of the target driving scenario and the vehicle software test case are input into an automated testing platform.

[0007] The above method, optionally, after performing physical rule verification on each of the driving scenarios, further comprises: Generating a training data set according to the verification results of each of the driving scenarios; The parameters of the large model are updated using the training data set.

[0008] The above method, optionally, after obtaining the test result, further includes: generating a test report according to the test results; The test report is sent to the terminal.

[0009] A vehicle software testing device based on a large model, comprising: An acquisition unit, used to acquire test requirement information of the vehicle software to be tested; A first generating unit, configured to generate a model prompt according to the test requirement information, wherein the model prompt is used to indicate resources required for generating vehicle software testing; A first execution unit, configured to input the model prompt into a trained large model to obtain various driving scenarios and vehicle software test cases output by the large model; A verification unit, used for performing physical rule verification on each of the driving scenarios; A second execution unit is used for determining the driving scenarios that have passed the physical rule verification as candidate driving scenarios if there are multiple driving scenarios that have passed the physical rule verification, and inputting each of the candidate driving scenarios into a pre-built risk prediction model to obtain an output result of the risk prediction model; the output result includes a priority ranking of each of the candidate driving scenarios; the risk prediction model and the large model share latent space representation in historical data through joint training; a determining unit, configured to determine a target driving scene from among the candidate driving scenes according to the priority ranking of the candidate driving scenes; A third execution unit, configured to input the target driving scenario into a simulation platform to obtain simulation data of the target driving scenario; The fourth execution unit is used to input the simulation data of the target driving scenario and the vehicle software test case into the automated testing platform, so that the automated testing platform parses the simulation data and executes the vehicle software test case according to the parsed simulation data to obtain a test result.

[0010] In the above device, optionally, the first generating unit includes: An extraction subunit, used to obtain software version information, function type information, test target information and driving scenario requirements in the test requirement information; The first input subunit is used to input the software version information, function type information, test target information and driving scenario requirements into a preset prompt word template to obtain a model prompt.

[0011] In the above device, optionally, the fourth execution unit includes: A detection subunit, configured to perform anomaly detection on the simulation data of the target driving scene using a pre-trained anomaly recognition model to obtain a recognition result of the simulation data; The second input subunit is used to input the simulation data of the target driving scenario and the vehicle software test case into the automated testing platform when the recognition result indicates that the simulation data is normal.

[0012] The above device may optionally further include: A second generating unit, configured to generate a training data set according to the verification results of each of the driving scenarios; A training unit is used to update the parameters of the large model using the training data set.

[0013] The above device may optionally further include: A third generating unit, configured to generate a test report according to the test result; The sending unit is used to send the test report to the terminal.

[0014] Based on the above-mentioned implementation of the present application, a vehicle software testing method and device based on a large model can obtain test requirement information of the vehicle software to be tested; generate model prompts according to the test requirement information, and the model prompts are used to indicate the resources required for generating vehicle software testing; the model prompts are input into the trained large model to obtain various driving scenarios and vehicle software test cases output by the large model; physical rule verification is performed on each of the driving scenarios; if there are multiple driving scenarios that pass the physical rule verification, the driving scenarios that pass the physical rule verification are determined as candidate driving scenarios, and each of the candidate driving scenarios is input into a pre-built risk prediction model to obtain the The output result of the risk prediction model; the output result includes the priority ranking of each of the candidate driving scenarios; the risk prediction model and the large model share latent space representation in historical data through joint training; determine the target driving scenario in each of the candidate driving scenarios according to the priority ranking of each of the candidate driving scenarios; input the target driving scenario into the simulation platform to obtain the simulation data of the target driving scenario; input the simulation data of the target driving scenario and the vehicle software test case into the automated testing platform, so that the automated testing platform parses the simulation data, and executes the vehicle software test case according to the parsed simulation data to obtain the test result. The method provided in the embodiment of the present application can not only improve the test efficiency and coverage, but also enhance the reliability and accuracy of the test results, providing a strong guarantee for the safety and reliability of vehicle software. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0016] Figure 1 A method flow chart of a vehicle software testing method based on a large model provided in this application; Figure 2 A flowchart of a process for generating model prompts based on test requirement information provided by the present application; Figure 3 A flowchart of a process of inputting simulation data and test cases into an automated test platform provided by the present application; Figure 4 A schematic diagram of the structure of a vehicle software testing device based on a large model provided in this application. DETAILED DESCRIPTION

[0017] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0018] In this application, the terms "comprises", "comprising" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element.

[0019] The embodiment of the present invention provides a vehicle software testing method based on a large model, which is applied to electronic equipment. The method flow chart of the method is as follows: Figure 1 As shown, specifically including: S101: Acquire test requirement information of vehicle software to be tested.

[0020] In this embodiment, the test requirement information may include software version information, function type information, test target information, and driving scenario requirements.

[0021] In this embodiment, a feature extraction algorithm can be used to perform block hash calculation on the binary file of the target software, and hierarchical aggregation can be used to generate software version information such as a version feature matrix V∈R^{n×d} containing the main version number, patch sequence, and dependency library fingerprint, where n is the number of version levels and d is the feature dimension.

[0022] In this embodiment, the requirement document is semantically parsed through a natural language processing model, and a topological coding vector F=[f_1, f_2, ..., f_m] of the function type is generated based on the encoder. The topological coding vector is the function type, where f_i∈{0, 1} represents the activation state of the i-th function module.

[0023] In this embodiment, a three-dimensional test target vector T=(t1, t2, t3) can be constructed as test target information, where t1∈[0, 1] represents the functional coverage weight, t2∈[0, 1] represents the performance test intensity coefficient, and t3∈N represents the specification compliance level.

[0024] In this embodiment, the driving scenario requirements may include a scenario constraint tensor. Specifically, the driving scenario requirements may be formally described using a spatiotemporal knowledge graph to generate a scenario constraint tensor S∈R^{h×w×c}, where h represents the time dimension, w represents the space dimension, and c represents the constraint type channel.

[0025] S102: Generate a model prompt according to the test requirement information, where the model prompt is used to indicate the resources required for generating the vehicle software test.

[0026] In this embodiment, the resources required for vehicle software testing may include resources such as driving scenarios and vehicle software test cases.

[0027] In an embodiment provided in the present application, based on the above solution, optionally, a process of generating a model prompt according to the test requirement information is as follows: Figure 2 As shown, including: S201: Obtain software version information, function type information, test target information, and driving scenario requirements in the test requirement information.

[0028] S202: Input software version information, function type information, test target information, and driving scenario requirements into a preset prompt word template to obtain a model prompt.

[0029] In this embodiment, the generation process of the model prompt is implemented by a three-level linkage intelligent template engine, which specifically includes: (1) Basic template construction: Call the preset standardized template library, which is built based on functional safety standards and contains version compatibility declaration fields and dependency library verification rules. Perform linear transformation operations on the software version feature matrix and the trainable weight matrix to generate compatibility parameters carrying version fingerprint identifiers and inject them into the placeholder node of the template.

[0030] (2) Extended condition generation: parse the activation state bit sequence of the function type encoding vector, and generate a test instruction with Boolean logic conditions for each activation state bit. According to the coverage weight parameter in the test target vector, dynamically adjust the scenario complexity constraint condition and generate a scenario description statement containing a dynamic threshold interval.

[0031] (3) Optimize template selection: Load the feature template library that stores historical test patterns, and calculate the matching probability distribution between the current fusion feature and the historical template through a multi-layer neural network. Use a normalized exponential function to quantify the probability of the matching results, select the preferred template whose probability peak exceeds the preset threshold, and perform feature weighted fusion with the standardized template.

[0032] The model prompt statement finally generated contains the version identification field, the function condition instruction set and the dynamic scenario parameter constraint, and its grammatical structure conforms to the generation rules defined in the specification. Through the collaborative work of the layered template engine, the organic combination of standard compliance constraints and historical experience data is realized. The dynamic adjustment mechanism of the scenario parameters is realized through the element-by-element coupling operation of the feature vector and the template weight, ensuring that the generated test scenario meets both the formal verification requirements and the actual test needs.

[0033] S103: Input the model prompt into the trained large model to obtain various driving scenarios and vehicle software test cases output by the large model.

[0034] In this embodiment, the large model adopts a transformer architecture for multi-task joint training, including a scenario generation branch and a test case generation branch. The output layer adopts a dual-stream decoding mechanism to generate a scenario description file that meets the standard and a vehicle software test case set that meets the specification.

[0035] In some embodiments, the vehicle software test case may include a multi-modal input stimulus set, a functional verification condition group, and an execution environment constraint item. Among them, the input stimulus set includes a sensor signal simulation data stream generated by the simulation platform, including a controller area network bus CAN message sequence that conforms to the standard, multi-camera video frame data based on H.265 encoding, and a vehicle wireless communication technology V2X communication message packet that conforms to the standard. The environmental simulation parameter set includes a gradient distribution of the road surface friction coefficient, a dynamic light intensity change curve, and a meteorological condition timing parameter. The functional verification condition group includes preset functional correctness verification conditions, including an expected system response trigger flag set, a maximum allowable response delay time threshold, and a trajectory deviation tolerance interval; and performance boundary constraints, defining the processor resource occupancy upper limit, memory leak detection threshold, and task scheduling real-time indicators. The execution environment constraint items include resource configuration parameters and safety monitoring strategies of the hardware-in-the-loop test platform; resource configuration parameters include a specified electronic control unit ECU processor model compatibility list, bus load balancing strategy, and signal sampling rate matching rules; the safety monitoring strategy sets the abnormal state fuse mechanism trigger condition and data integrity verification cycle.

[0036] In some embodiments, the driving scenario includes a spatiotemporal parameter group, a participant behavior model, and physical rule constraints; the spatiotemporal parameter group includes time dimension parameters, spatial topological structure, and environmental dynamic parameters; the time dimension parameters include the segment configuration of the duration of the scenario, the event triggering timing logic, and the dynamic change rate control curve; the spatial topological structure is used to define a set of road geometric features, including but not limited to the curvature radius gradient distribution, the slope change matrix, and the lane line topological relationship network; the environmental dynamic parameters include the configuration of the light intensity timing regulator, the meteorological condition state machine, and the road friction coefficient mapping table. The participant behavior model includes the main vehicle control command chain and the traffic participant behavior logic library; the main vehicle control command chain: generates a timing control sequence of acceleration and steering angular velocity, and the sequence meets the safety operation boundary conditions defined by the standard. The traffic participant behavior logic library includes the construction of a decision state transition diagram for pedestrians, vehicles, and non-motor vehicles, and the transition diagram includes a collaborative avoidance strategy based on V2X communication. The physical rule constraints include an embedded vehicle dynamics verification module and an energy conservation monitor. The embedded vehicle dynamics verification module is used to verify in real time whether the scene parameters satisfy a predefined set of vehicle kinematic equations; the energy conservation monitor is configured to detect whether the mechanical energy loss rate in the scene exceeds a preset safety threshold.

[0037] S104: Perform physical rule verification on each driving scenario.

[0038] In this embodiment, a physical rule base including vehicle kinematic equations, dynamic constraints and traffic flow continuity conditions is established. Each scenario is numerically verified by a differential algebraic equation solver, the feasible domain of scenario parameters in phase space is calculated, and the dynamic consistency index of the scenario is evaluated using the Lyapunov stability theory to determine whether each driving scenario complies with the physical rules.

[0039] S105: If there are multiple driving scenarios that pass the physical rule verification, the driving scenarios that pass the physical rule verification are determined as candidate driving scenarios, and each candidate driving scenario is input into a pre-built risk prediction model to obtain an output result of the risk prediction model; the output result includes a priority ranking of each candidate driving scenario; the risk prediction model and the big model share latent space representation in historical data through joint training.

[0040] In this embodiment, the risk prediction model includes a feature extraction network and a sorting network, wherein the feature extraction network and the large model share a latent space through comparative learning. The risk prediction model adopts the risk coefficient calculation method:

[0041] Among them, R is the risk entropy value, is a learnable parameter, φ(·) is the scene feature projection function, Represents the feature vector of the i-th candidate scenario. The output of the risk prediction model includes the priority queue based on the risk entropy value and the scenario coverage evaluation result.

[0042] Optionally, the risk entropy value is an indicator used to measure the risk uncertainty in the driving scenario. In vehicle software testing, different driving scenarios contain different degrees and types of risks. The larger the risk entropy value, the higher the risk uncertainty of the scenario, and there may be more unpredictable risk factors; conversely, the smaller the risk entropy value, the risk of the scenario is relatively certain and controllable. The risk prediction model will sort these scenarios according to the calculated risk entropy values ​​of each candidate driving scenario to form a priority queue. Specifically, scenarios with higher risk entropy values ​​will be placed at the front of the queue, while scenarios with lower risk entropy values ​​will be placed at the back of the queue.

[0043] Optionally, scenario coverage refers to the degree to which the driving scenarios involved in the test process cover all possible driving scenarios. It reflects the comprehensiveness of the test, that is, whether the test covers various different situations that the vehicle software may encounter in actual use.

[0044] S106: Determine a target driving scenario from among the candidate driving scenarios according to the priority ranking of the candidate driving scenarios.

[0045] In this embodiment, a multi-objective optimization algorithm is used to construct a scene selection function: ,in, is the target driving scenario, S represents the candidate driving scenario, and C is the candidate driving scenario set; Coverage(S) is the scenario coverage index, Risk(S) is the scenario risk entropy value; α is the first dynamic weight coefficient, and β is the second dynamic weight coefficient.

[0046] In this embodiment, a scene diversity constraint condition may be set, and a scene topology coverage map may be generated by iterative selection through a greedy algorithm until the test adequacy index is met.

[0047] S107: Input the target driving scene into the simulation platform to obtain simulation data of the target driving scene.

[0048] In this embodiment, the simulation platform includes a high-fidelity vehicle dynamics model and a V2X environment simulator. The hardware-in-the-loop HIL architecture is used to generate simulation data including CAN bus signal flow, point cloud data matrix and multi-camera video stream in real time, and synchronously record the state snapshot sequence with time stamp alignment.

[0049] In this embodiment, prioritizing target driving scenarios with high risk entropy values ​​helps to promptly discover and resolve potential high-risk issues, reduce the possibility of serious failures in vehicle software during actual use, and enhance the safety and reliability of the software.

[0050] S108: Input the simulation data of the target driving scenario and the vehicle software test case into the automated testing platform, so that the automated testing platform parses the simulation data, and executes the vehicle software test case according to the parsed simulation data to obtain the test result.

[0051] In this embodiment, the automated testing platform includes a test case parsing engine and an anomaly detection module. Test cases are executed in a containerized test environment, and a formal verification method is used to compare the difference matrix between the actual output and the expected response. Finally, a test report containing failure mode classification is generated and associated to the original demand node through a traceability link matrix.

[0052] Optionally, after the test case is executed, the automated test platform collects the test results. The test results include actual output data, expected response data, execution status information, etc. These results are stored in the database for subsequent analysis and processing. The actual output data is compared and analyzed with the expected response data to find out the differences between the two. Data analysis techniques, such as machine learning algorithms and pattern recognition, are used to classify and diagnose the differences and determine the causes and impact of the differences. Based on the results of the difference analysis, a detailed test report is generated. The test report includes test overview, test result summary, difference analysis report, problem suggestions, etc. The report uses a visual way to display the test results, such as tables, charts, graphs, etc., so that testers and developers can intuitively understand the test situation.

[0053] Applying the method provided in the embodiments of the present application can not only improve the test efficiency and coverage, but also enhance the reliability and accuracy of the test results, thereby providing a strong guarantee for the safety and reliability of vehicle software.

[0054] In an embodiment provided in the present application, based on the above solution, optionally, the process of inputting simulation data and test cases into the automated test platform is as follows: Figure 3 As shown, including: S301: Use a pre-trained anomaly recognition model to perform anomaly detection on simulation data to obtain recognition results of the simulation data.

[0055] In this embodiment, the anomaly recognition model adopts a multimodal spatiotemporal fusion network architecture, and the specific processing flow includes: The CAN bus signal stream, point cloud data matrix and multi-camera video stream output by the simulation platform are time-stamp aligned and divided into time-continuous frame sequence data blocks through sliding windows; For each frame sequence data block, the temporal convolutional network is used to extract the temporal dependency features of the CAN signal in the frame sequence data block; a three-dimensional voxel grid is constructed for the point cloud data in the frame sequence data block, and the spatial topological features are extracted through the 3D sparse convolution layer; the optical flow method is used to extract the motion features of the video stream data in the frame sequence data block, and the motion features are spliced ​​with the visual semantic features extracted by the residual network ResNet-50 backbone network. Finally, the multimodal features of the frame sequence data block are obtained; the multimodal features include the splicing features of temporal dependency features, spatial topological features, motion features and visual semantic features.

[0056] The multimodal features are input into the spatiotemporal attention module, the anomaly probability value of each data frame in the joint feature space is calculated, and a recognition result vector containing anomaly type coding and confidence score is generated, where the anomaly type includes at least one of signal jump violation, sensor data loss of lock and environmental modeling distortion.

[0057] S302: When the recognition result indicates that the simulation data is normal, the simulation data and the test case are input into the automated test platform.

[0058] In this embodiment, when the recognition result indicates that the data is normal, the following processing flow is performed: First, the timestamp-aligned simulation data is serialized into data blocks in the standard intermediate representation format, including: encoding the CAN signal stream into a test vector in the ASAM XIL format; converting the point cloud data into a normalized dot matrix in a preset coordinate system; and encoding the video stream data in H.265 and adding metadata tags.

[0059] Then, the hash value is calculated for the data block after format conversion and compared with the original hash chain output by the simulation platform to verify the data integrity.

[0060] Finally, the simulation data that passes the hash check is synchronously injected into the automated testing platform together with the test cases through the message queue telemetry transmission protocol. The test case parsing engine loads the corresponding test instruction set from the container image library; the data distribution module routes the simulation data to the corresponding test sandbox instance according to the timestamp information.

[0061] In some embodiments, when the anomaly recognition model detects abnormal data with a confidence level exceeding a threshold value η, a data rollback mechanism is triggered. Specifically, the abnormal data frame can be cached in an isolated storage area with a version tag; a re-simulation instruction can be sent to the simulation platform to request data regeneration in a specific time window; an abnormal event report is generated and associated with the test case traceability matrix, where η∈[0, 1] is a preset threshold.

[0062] In an embodiment provided by the present application, based on the above solution, optionally, after performing physical rule verification on each driving scene in S104, the following is further included: Generate training data sets based on the verification results of each driving scenario; Use the training dataset to update the parameters of the large model.

[0063] In this embodiment, the method for generating a training data set according to the driving scene verification result specifically includes: The scenes that pass the physical rule verification are annotated with the dynamic consistency index γ∈[0, 1], where γ=1 means that the vehicle dynamics constraints are fully met; the scenes that fail the verification are annotated with the category labels that violate the physical rules (including kinematic conflicts, energy non-conservation, trajectory discontinuity, etc.) and the violation degree parameter δ∈R+; The scene parameters and the verification results are concatenated into tensors to generate enhanced training samples X'=Concat(X, [γ, δ]), where X is the original scene feature vector; A spatiotemporal perturbation strategy is used to amplify the training samples, including: applying Gaussian noise perturbations on the boundaries of the feasible domain; elastically scaling the time dimension; and creating critical verification scenarios through adversarial sample generation technology.

[0064] In some embodiments, the parameter update process of the large model adopts a two-stage joint optimization strategy; in the basic training stage, the scene is frozen to generate branch parameters, and the verification result prediction module is optimized by comparing the loss function; in the fine-tuning stage, the gradient accumulation update strategy is adopted, and the physical rule verification result is added as a regularization term to the total loss function:

[0065] in, is the total loss function, is the basic loss function; λ is the dynamic adjustment coefficient, which is automatically adjusted according to the exponential moving average of the verification error; ∈[0, 1] is the predicted dynamic consistency index; is the true value of physical verification.

[0066] In an embodiment provided by the present application, based on the above solution, optionally, after obtaining the test result in S106, the following is further included: Generate a test report based on the test results; Send the test report to the terminal.

[0067] In this embodiment, the difference matrix in the test results is feature compressed to generate a standardized report structure containing the following elements: failure mode classification tree, risk entropy value distribution heat map, scenario coverage radar map and traceability link matrix (associating test cases with original demand nodes).

[0068] In this embodiment, the analysis results can be converted into a multimodal report document through a distributed rendering engine, supporting at least one of the following formats: interactive 3D visualization dashboard; standard XML structured report; PDF verification document with digital signature. The terminal can be a mobile phone, a personal computer, a car computer, etc.

[0069] See also Figure 4 , is a structural diagram of a vehicle software testing method device based on a large model provided in an embodiment of the present application, the device comprising: The acquisition unit 401 is used to acquire the test requirement information of the vehicle software to be tested; A first generating unit 402, configured to generate a model prompt according to the test requirement information, wherein the model prompt is used to indicate resources required for generating vehicle software testing; The first execution unit 403 is used to input the model prompt into the trained large model to obtain various driving scenarios and vehicle software test cases output by the large model; A verification unit 404, used to perform physical rule verification on each driving scenario; The second execution unit 405 is used to determine the driving scenes that pass the physical rule verification as candidate driving scenes if there are multiple driving scenes that pass the physical rule verification, and input each candidate driving scene into a pre-built risk prediction model to obtain an output result of the risk prediction model; the output result includes a priority ranking of each candidate driving scene; the risk prediction model and the big model share latent space representation in historical data through joint training; A determination unit 406 is configured to determine a target driving scenario from among the candidate driving scenarios according to the priority ranking of the candidate driving scenarios; The third execution unit 407 is used to input the target driving scene into the simulation platform to obtain simulation data of the target driving scene; The fourth execution unit 408 is used to input the simulation data of the target driving scenario and the vehicle software test case into the automated test platform, so that the automated test platform parses the simulation data and executes the vehicle software test case according to the parsed simulation data to obtain the test result.

[0070] In an embodiment provided in the present application, based on the above solution, optionally, the first generating unit 402 includes: An extraction subunit is used to obtain software version information, function type information, test target information and driving scenario requirements in the test requirement information; The first input subunit is used to input software version information, function type information, test target information and driving scenario requirements into a preset prompt word template to obtain a model prompt.

[0071] In an embodiment provided in the present application, based on the above solution, optionally, the fourth execution unit 408 includes: The detection subunit is used to perform anomaly detection on the simulation data using a pre-trained anomaly recognition model to obtain a recognition result of the simulation data; The second input subunit is used to input the simulation data and the test case into the automated test platform when the recognition result indicates that the simulation data is normal.

[0072] In an embodiment provided in the present application, based on the above solution, optionally, it further includes: A second generating unit, used to generate a training data set according to the verification results of each driving scenario; The training unit is used to update the parameters of the large model using the training data set.

[0073] In an embodiment provided in the present application, based on the above solution, optionally, it further includes: A third generating unit, used to generate a test report according to the test result; The sending unit is used to send the test report to the terminal.

[0074] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0075] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are merely used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations.

[0076] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0077] It can be known from the description of the above implementation methods that those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present application or certain parts of the embodiments.

[0078] The above is a detailed introduction to a vehicle software testing method based on a large model provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A vehicle software testing method based on a large model, characterized in that: include: Obtaining test requirement information of the vehicle software to be tested; generating a model prompt according to the test requirement information, wherein the model prompt is used to indicate resources required for generating vehicle software testing; Inputting the model prompts into the trained large model to obtain various driving scenarios and vehicle software test cases output by the large model; Performing physical rule verification on each of the driving scenarios; If there are multiple driving scenarios that pass the physical rule verification, the driving scenarios that pass the physical rule verification are determined as candidate driving scenarios, and each of the candidate driving scenarios is input into a pre-built risk prediction model to obtain an output result of the risk prediction model; the output result includes a priority ranking of each of the candidate driving scenarios; the risk prediction model and the large model share latent space representation in historical data through joint training; Determining a target driving scenario from among the candidate driving scenarios according to the priority ranking of the candidate driving scenarios; Inputting the target driving scene into a simulation platform to obtain simulation data of the target driving scene; The simulation data of the target driving scenario and the vehicle software test case are input into the automated testing platform so that the automated testing platform parses the simulation data, and executes the vehicle software test case according to the parsed simulation data to obtain a test result.

2. The method according to claim 1, characterized in that The generating of the model prompt according to the test requirement information includes: Obtaining software version information, function type information, test target information, and driving scenario requirements in the test requirement information; The software version information, function type information, test target information and driving scenario requirements are input into a preset prompt word template to obtain a model prompt.

3. The method according to claim 1, characterized in that The step of inputting the simulation data of the target driving scenario and the vehicle software test case into the automated testing platform comprises: Using a pre-trained anomaly recognition model to perform anomaly detection on the simulation data of the target driving scene to obtain a recognition result of the simulation data; When the recognition result indicates that the simulation data is normal, the simulation data of the target driving scenario and the vehicle software test case are input into an automated testing platform.

4. The method according to claim 1, characterized in that: After the physical rule verification is performed on each of the driving scenarios, the method further includes: Generating a training data set according to the verification results of each of the driving scenarios; The parameters of the large model are updated using the training data set.

5. The method according to claim 1, characterized in that After obtaining the test results, it also includes: generating a test report according to the test results; The test report is sent to the terminal.

6. A vehicle software testing device based on a large model, characterized in that: include: An acquisition unit, used to acquire test requirement information of the vehicle software to be tested; A first generating unit, configured to generate a model prompt according to the test requirement information, wherein the model prompt is used to indicate resources required for generating vehicle software testing; A first execution unit, configured to input the model prompt into a trained large model to obtain various driving scenarios and vehicle software test cases output by the large model; A verification unit, used for performing physical rule verification on each of the driving scenarios; A second execution unit is used for determining the driving scenarios that have passed the physical rule verification as candidate driving scenarios if there are multiple driving scenarios that have passed the physical rule verification, and inputting each of the candidate driving scenarios into a pre-built risk prediction model to obtain an output result of the risk prediction model; the output result includes a priority ranking of each of the candidate driving scenarios; the risk prediction model and the large model share latent space representation in historical data through joint training; a determining unit, configured to determine a target driving scene from among the candidate driving scenes according to the priority ranking of the candidate driving scenes; A third execution unit, configured to input the target driving scenario into a simulation platform to obtain simulation data of the target driving scenario; The fourth execution unit is used to input the simulation data of the target driving scenario and the vehicle software test case into the automated testing platform, so that the automated testing platform parses the simulation data and executes the vehicle software test case according to the parsed simulation data to obtain a test result.

7. The device according to claim 6, characterized in that The first generating unit comprises: An extraction subunit, used to obtain software version information, function type information, test target information and driving scenario requirements in the test requirement information; The first input subunit is used to input the software version information, function type information, test target information and driving scenario requirements into a preset prompt word template to obtain a model prompt.

8. The device according to claim 6, characterized in that The fourth execution unit includes: A detection subunit, configured to perform anomaly detection on the simulation data of the target driving scene using a pre-trained anomaly recognition model to obtain a recognition result of the simulation data; The second input subunit is used to input the simulation data of the target driving scenario and the vehicle software test case into the automated testing platform when the recognition result indicates that the simulation data is normal.

9. The device according to claim 6, characterized in that Also includes: A second generating unit, configured to generate a training data set according to the verification results of each of the driving scenarios; A training unit is used to update the parameters of the large model using the training data set.

10. The device according to claim 6, characterized in that Also includes: A third generating unit, configured to generate a test report according to the test result; The sending unit is used to send the test report to the terminal.

Images