Test case generation method and device, equipment and storage medium

Abstract

The invention relates to the technical field of computers, and discloses a test case generation method, device and equipment and a storage medium, and the method comprises the steps: constructing a scene feature model based on the multi-source sensing data of a vehicle collected in a to-be-tested target scene, and matching a target source scene from a pre-constructed test template library based on the scene feature model; mapping test configuration information corresponding to the target source scene to the target scene to generate an initial test template adaptive to the target scene; and generating a target test case in combination with the scene feature model, the initial test template, the multi-modal interaction rule base and the target test case evaluation rule. The scene coverage rate, the scene adaptability and the test efficiency of the intelligent cabin test can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a test case generation method, apparatus, device, and storage medium. Background Technology

[0002] With the development of automotive intelligence, smart cockpits have evolved from traditional driver assistance systems into comprehensive platforms that integrate multiple interaction methods such as voice recognition, gesture control, touch operation, and visual perception (e.g., eye tracking). Multimodal interaction improves user operating efficiency, but it also leads to increasingly complex interaction logic.

[0003] Currently, multimodal interaction testing of smart cockpits mainly relies on manually written static test cases, which has obvious limitations: First, the scenario coverage is insufficient. Faced with a massive number of modal combinations (such as voice and gesture coordination under strong noise during high-speed driving), it is difficult to exhaust all kinds of situations, especially easy to miss low-probability but high-risk edge scenarios. Second, the adaptability is poor. Different driving environments have different requirements for interaction modalities (such as high-speed scenarios relying more on voice-based hands-free operation), while fixed templates cannot be dynamically adjusted with the scenario. Cross-scenario reuse requires repeated writing, which is inefficient. Third, there is a lack of quantitative evaluation and optimization mechanisms. The test results rely on subjective judgment and lack objective indicators such as scenario coverage and modal coordination. It is also impossible to achieve automatic iteration of test cases, which restricts the continuous improvement of test quality. Summary of the Invention

[0004] In view of this, embodiments of this application provide a test case generation method, apparatus, terminal device, and computer-readable storage medium, which can improve the scenario coverage, scenario adaptability, and testing efficiency of intelligent cockpit testing.

[0005] In a first aspect, embodiments of this application provide a test case generation method, including: A scene feature model is constructed based on multi-source sensor data of the vehicle collected in the target scene to be tested, and the target source scene is matched from a pre-built test template library based on the scene feature model. Map the test configuration information corresponding to the target source scenario to the target scenario to generate an initial test template adapted to the target scenario; The target test cases are generated by combining the scenario feature model, the initial test template, the multimodal interaction rule library, and the target test case evaluation rules.

[0006] In an optional implementation, the step of generating target test cases by combining the scene feature model, the initial test template, the multimodal interaction rule base, and the target test case evaluation rules includes: At least one candidate test case is generated by combining the scene feature model, the initial test template, and the multimodal interaction rule base; The performance of each candidate test case is evaluated based on the preset quantitative evaluation index in order to determine the test cases to be optimized and the initial test cases. The test cases to be optimized are optimized, and the target test cases are selected from the optimized test cases and the initial test cases.

[0007] In an optional implementation, matching the target source scene from a pre-built test template library based on the scene feature model includes: Calculate the similarity between each feature vector in the scene feature model of the target scene and the feature vectors of each source scene; The source scenes with a similarity greater than or equal to a preset similarity threshold are used as the target source scenes.

[0008] In an optional implementation, mapping the test configuration information corresponding to the target source scenario to the target scenario to generate an initial test template adapted to the target scenario includes: The feature distribution of the target source scene and the target scene is aligned using a domain-adaptive transfer learning algorithm. According to preset semantic mapping rules, modality-related parameters in the target source scene are converted into adaptation parameters under the target scene; wherein, the semantic mapping rules are determined based on human-machine interaction safety constraints and operating habits under different driving conditions; Based on the adaptation parameters, an initial test template adapted to the target scenario is generated.

[0009] In an optional implementation, generating at least one candidate test case by combining the scene feature model, the initial test template, and the multimodal interaction rule base includes: The scene feature model and the initial test template are used as state inputs, and the multimodal interaction combination actions are used as a set of executable actions. These are input into the decision model to output at least one of the candidate test cases. The decision model aims to maximize a preset reward function, which is composed of a weighted average of at least two of the following: scene coverage, modal synergy, and defect detection rate.

[0010] In an optional implementation, the multimodal interaction rule base is constructed based on a knowledge graph; the knowledge graph includes entities, attributes, and relationships between entities; wherein, the entities include scene entities, interaction modal entities, instruction entities, and functional system entities; the relationships between entities include at least one of triggering relationships, priority relationships, and conflict resolution rules.

[0011] In an optional implementation, the step of selecting target test cases from the obtained optimized test cases and the initial test cases includes: determining target test cases from the optimized test cases and the initial test cases based on target test case judgment rules; After selecting the target test cases from the optimized test cases and the initial test cases, the process further includes: The target test cases are converted into standardized templates, and the standardized templates are labeled with corresponding scenario tags before being fed back to the test template library.

[0012] Secondly, embodiments of this application provide a test case generation apparatus, comprising: The construction module is used to build a scene feature model based on the multi-source sensor data of the vehicle collected in the target scene to be tested, and to match the target source scene from the pre-built test template library based on the scene feature model. The mapping module is used to map the test configuration information corresponding to the target source scenario to the target scenario, so as to generate an initial test template adapted to the target scenario; The determination module is used to generate target test cases by combining the scene feature model, the initial test template, the multimodal interaction rule library, and the target test case evaluation rules.

[0013] Thirdly, embodiments of this application provide a terminal device, the terminal device including a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the above-described test case generation method.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed on a processor, implements the above-described test case generation method.

[0015] The embodiments of this application have the following beneficial effects: By constructing a multi-dimensional scene feature model that integrates vehicle state, environmental perception, and user interaction behavior, this application achieves a refined and quantifiable representation of complex driving scenarios. Based on this model, matching similar historical source scenarios from a pre-built test template library effectively reuses verified test knowledge, significantly shortens the test preparation cycle, and improves the efficiency of test resource utilization. Furthermore, by introducing domain-adaptive transfer learning and semantic mapping rules based on human-computer interaction safety constraints, the test configuration information of the source scenario is dynamically adjusted and adapted to the current target scenario, generating an initial test template that meets the actual working conditions, enhancing the adaptability and safety of test cases in different driving environments. On this basis, by combining the scene feature model, the initial test template, the multimodal interaction rule library based on knowledge graphs, and the quantified test case evaluation rules, target test cases with high coverage, high collaboration, and defect exposure capabilities are collaboratively generated. This application can improve the automation level, scene coverage completeness, and edge case detection capability of the testing process for complex human-computer interaction systems such as intelligent cockpits, effectively solving the problems of insufficient coverage, poor reusability, and lack of optimization in traditional manually written test cases. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This paper illustrates a first flowchart of a test case generation method according to an embodiment of this application. Figure 2 This paper illustrates a second flowchart of the test case generation method according to an embodiment of this application. Figure 3 A schematic diagram of the third process of the test case generation method according to an embodiment of this application is shown; Figure 4 A schematic diagram of the fourth process of the test case generation method according to an embodiment of this application is shown; Figure 5 A schematic diagram of a test case generation device according to an embodiment of this application is shown. Detailed Implementation

[0018] The technical solutions in 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, and not all embodiments.

[0019] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0021] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0022] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0023] The following examples illustrate the test case generation method.

[0024] Figure 1 A flowchart illustrating a test case generation method according to an embodiment of this application is shown. Exemplarily, the test case generation method includes steps S100-S300: Step S100: Construct a scene feature model based on the multi-source sensor data of the vehicle collected in the target scene to be tested, and match the target source scene from the pre-built test template library based on the scene feature model.

[0025] The multi-source sensor data includes, but is not limited to, vehicle status data, environmental perception data, and user interaction behavior data. Vehicle status data includes vehicle speed, steering angle, and acceleration; environmental perception data includes in-vehicle noise level (decibels), light intensity, and temperature; and user interaction behavior data includes voice command content, gesture trajectory, and touch operation frequency.

[0026] The aforementioned multi-source sensor data can be acquired in real time through hardware devices such as CAN bus, microphone array, camera, and inertial measurement unit, and transmitted to the central processing module for unified processing.

[0027] Because the raw data collected may contain noise interference or missing values, data preprocessing is required, including but not limited to outlier removal, linear interpolation completion, and normalization scaling, to ensure the accuracy and stability of subsequent modeling. After preprocessing, deep learning models can be used to extract features from different categories of data. For example, convolutional neural networks (CNNs) can be used to extract spatiotemporal features from environmental data (such as analyzing the trend of the spectral distribution of noise signals over time); recurrent neural networks (RNNs), such as long short-term memory networks (LSTM), can be used to extract temporal features from user behavior data to capture interaction sequences such as "gesture adjustment within 0.5 seconds after voice wake-up"; after fusing the extracted high-dimensional features, a unified multi-dimensional feature vector is formed, which then constitutes a scene feature model of the current target scene to be tested.

[0028] As can be understood, a scenario here refers to a comprehensive driving situation constituted by vehicle operating status, surrounding environmental factors, and user interaction behavior under specific spatiotemporal conditions. Each scenario corresponds to a scenario feature model. In other words, each "scenario" represents a specific set of operating conditions (e.g., "high-speed driving + high noise + low light at night + driver voice adjustment of air conditioning"), essentially an aggregated representation of multi-dimensional sensor data within a certain time period. By constructing a scenario feature model—a multi-dimensional vector that can quantify the key attributes under that situation—the system can achieve refined and computable modeling of the driving environment. Therefore, each independent and distinguishable target scenario corresponds to a unique scenario feature model, which serves as the core input for subsequent scenario matching, knowledge transfer, and test case generation. Simultaneously, each validated source scenario accumulated in historical data also possesses its corresponding feature model, thus supporting cross-scenario similarity calculation and test configuration migration.

[0029] Furthermore, after constructing the scene feature model of the target scenario, the system matches the most suitable source scene template from a pre-established test template library stored in the database. This test template library stores test configuration information corresponding to multiple historically validated scenarios. Each source scenario is associated with a set of structured templates, which include, but are not limited to, test objectives, input data types, expected output results, applicable modal combinations, and their parameter constraints.

[0030] In some implementations, such as Figure 2 As shown, matching the target source scene from the pre-built test template library based on the scene feature model includes steps S110-S120: Step S110: Calculate the similarity between each feature vector in the scene feature model of the target scene and the feature vectors of each source scene.

[0031] Step S120: Select source scenes with a similarity greater than or equal to a preset similarity threshold as target source scenes.

[0032] Exemplarily, to ensure accurate scene matching, this embodiment employs a method of calculating the similarity between each feature vector in the target scene's scene feature model and the feature vectors of each source scene. Specifically, the multidimensional feature vector of the current target scene can be compared one by one with the feature vectors corresponding to each known source scene in the test template library, and the feature similarity between the two can be calculated. This similarity can be achieved using various algorithms, such as cosine similarity, Euclidean distance, Jaccard coefficient, or, for temporal features, a dynamic time warping algorithm can be used for non-linear alignment before calculating the similarity distance. When the calculated similarity is greater than or equal to a preset similarity threshold m (e.g., m=0.7), the source scene is determined to have sufficiently high transferability with the current target scene, and is thus identified as the target source scene.

[0033] It should be noted that the similarity threshold m can be set according to actual engineering needs and historical data analysis. For example, a reasonable classification boundary can be determined by clustering analysis of a large number of real driving scenarios, or it can be initialized by referring to industry-standard transfer learning criteria, and dynamic adjustment can be supported later.

[0034] Once the target source scenario is identified, the system can access its associated test configuration information as the basic input for generating an initial test template adapted to the target scenario. This process enables the effective reuse of cross-scenario testing knowledge, avoiding the inefficiency of manually writing templates from scratch.

[0035] Step S200: Map the test configuration information corresponding to the target source scenario to the target scenario to generate an initial test template adapted to the target scenario.

[0036] In this step, after matching the target source scenario in step S100 above, the system enters the test knowledge migration phase. This step is mainly used to achieve adaptive mapping of cross-scenario test configurations, ensuring that test templates from historical scenarios can be effectively reused in new driving environments, while meeting the safety, usability, and interaction rationality requirements of the target scenario.

[0037] In some implementations, such as Figure 3 As shown, step S200 includes steps S210-S230: Step S210: Align the feature distributions of the source scene and the target scene using a domain-adaptive transfer learning algorithm.

[0038] Exemplary, the system first acquires the test configuration information associated with the target source scene. This configuration information includes, but is not limited to, the length range of voice commands (e.g., 5-8 characters), the threshold for gesture amplitude (e.g., medium amplitude corresponds to an angle change of 30°-60°), touch response sensitivity parameters, visual focus recognition time window, modal priority settings, and the expected response latency of each operation. These parameters form the basis of the original test template, but directly applying them to the target scene may lead to false triggering, operational difficulties, or security risks; therefore, targeted adjustments are necessary. To achieve this adjustment, this embodiment can employ a domain-adaptive transfer learning algorithm for transfer. Furthermore, since the data distribution of the source scene and the target scene may differ significantly (e.g., low-speed driving on urban roads and high-speed cruising have completely different aspects in terms of vehicle speed, noise level, and user attention distribution), directly using the original parameters will lead to model bias. Therefore, it is necessary to perform feature distribution alignment processing on the multidimensional feature vectors of the target source scene and the current target scene.

[0039] In some implementations, a domain adaptation method based on subspace alignment or minimization of the maximum mean difference can be used to project the feature spaces of two scenes into a shared low-dimensional subspace, making the statistical distributions of the source and target domains as close as possible within that subspace. For example, the MMD distance can be calculated after kernel function mapping, and the feature transformation matrix can be optimized to minimize this distance, thereby eliminating the systematic offset caused by environmental differences.

[0040] Step S220: Based on the preset semantic mapping rules, the modality-related parameters in the target source scene are converted into adaptation parameters in the target scene.

[0041] Exemplary, after feature distribution alignment is completed, parameter transformation driven by semantic mapping rules continues. These semantic mapping rules are determined based on human-computer interaction safety constraints and user operating habits under different operating environments. For example, in high-speed driving scenarios, the driver's attention is primarily focused on the road conditions ahead, making complex or large-amplitude gestures inadvisable. Therefore, a rule can be set: when the target scenario speed exceeds 60 km / h... At this time, the amplitude of the gesture should be reduced to a small amplitude level, that is, the medium amplitude originally suitable for low-speed scenarios. The oscillation should be adjusted to a small amplitude (≤25°) to reduce the risk of distraction; in high-noise environments (such as tunnels or congested road sections), the noise level should be adjusted accordingly. (70dB) The accuracy of voice recognition may decrease. At this time, the following rules are enabled: If the noise level in the target scene is higher than 65dB, the volume detection threshold in the voice command template will be automatically increased and the voice timeout waiting time will be shortened to avoid misjudging silence as no command; For changes in lighting conditions, rules can be set: When the light intensity is lower than 300 lux (night or underground parking garage), the priority of touch mode will be weakened, the weight of voice mode will be strengthened, and the response speed of automatic screen brightness adjustment will be increased accordingly; For the length of voice commands, rules are established based on cognitive load theory: For example, in high-speed scenarios, it is recommended that the number of voice commands be as small as possible. Therefore, the long command templates allowed in the source scene, such as "navigate to the parking lot near the company", are converted into simplified versions for the target scene, such as "go to the company to park", and equivalent short sentences are constructed through natural language generation technology.

[0042] It is understandable that the aforementioned semantic mapping rules can be stored in the rule engine in the form of production rules, supporting dynamic loading and expansion. Whenever a new scene feature is input, the system automatically matches applicable rules and performs item-by-item transformation on the modality-related parameters in the source scene to obtain a set of preliminary adaptation parameters for the target scene.

[0043] Furthermore, in some cases, the feature dimensions of the source scene and the target scene are not completely consistent (e.g., the source scene contains humidity but the target scene does not have this sensor data). The system also introduces a cross-dimensional mapping mechanism, which uses adversarial training or feature completion models to infer the hidden state of the missing dimension, so as to ensure that the mapping process is complete and reliable.

[0044] Step S230: Based on the adaptation parameters, generate an initial test template adapted to the target scenario.

[0045] In this step, the system integrates the semantically mapped adaptation parameters, reconstructs the original test template structure, and generates an initial test template suitable for the current target scenario. This initial test template retains the functional logic framework of the original template (e.g., the test objective is to verify voice + gesture-based collaborative adjustment of air conditioning temperature), but its specific parameters have been reset according to the characteristics of the target scenario. For example, the input condition is updated to: vehicle speed. ,noise The voice command format is limited to concise commands consisting of 3-5 Chinese characters; the gesture action type is adjusted to: small up-and-down swiping with the left hand to control the airflow; the expected response time has been reduced from 1.5 seconds to less than 1.2 seconds. It is understandable that the generated initial test template has good scenario adaptability and can serve as the basic input for generating subsequent multimodal combined test cases.

[0046] Step S300: Combine the scene feature model, initial test template, multimodal interaction rule library and target test case evaluation rules to generate target test cases.

[0047] In some implementations, such as Figure 4 As shown, step S300 includes steps S310-S330: Step S310: Combine the scene feature model, the initial test template, and the multimodal interaction rule library to generate at least one candidate test case.

[0048] In some implementations, step S310 specifically includes: taking the scene feature model and the initial test template as state inputs, and taking the multimodal interaction combination actions as a set of executable actions as inputs to the decision model to output at least one candidate test case; wherein, the decision model aims to maximize a preset reward function, and the reward function is composed of at least two of scene coverage, modal synergy and defect detection rate weighted together.

[0049] As an example, after generating the initial test template adapted to the target scenario, the system enters the stage of generating multimodal interaction combination test cases. This step introduces a set of candidate test cases that are automatically generated based on a decision model, offering high coverage, high collaboration, and defect detection capabilities.

[0050] Specifically, the system uses the scene feature model and the initial test template as state inputs, feeding them into the reinforcement learning model to construct the agent's state perception space. The scene feature model provides complete contextual information about the current driving situation, including but not limited to dynamic parameters such as vehicle speed, noise, lighting, and user behavior patterns. The initial test template defines the basic constraints and objectives of this test, such as the functional modules to be tested (air conditioning control, navigation startup), allowed interaction modalities (voice, gesture, touch), the range of input parameters, and the expected output format.

[0051] Based on this, the system establishes a set of executable actions, including various possible combinations of multimodal interaction actions. Each action represents a specific test instruction configuration, including the modal type involved in the interaction, the specific input parameters of each modality, and their execution sequence. To ensure that the generated actions conform to actual human-computer interaction logic and avoid invalid or conflicting combinations, the system introduces a pre-built multimodal interaction rule base as the basis for action selection and constraint. This rule base is structured based on a knowledge graph and includes modal triggering rules, instruction priority rules, and conflict resolution rules.

[0052] Modal triggering rules specify the priority of interaction modalities in specific scenarios. For example, when the vehicle speed is greater than 60 km / h, the voice modality is triggered first, or when the light intensity is less than 200 lux, the weight of the touch modality is reduced. This rule is derived from the scene entity-triggering relationship-modal entity triple in the knowledge graph. Command priority rules handle the execution order of multiple concurrent commands. For example, emergency braking commands have higher priority than entertainment system adjustment commands, or ADAS-related alarms should interrupt ongoing navigation settings. These rules are modeled based on the urgency attribute of the command entity and the safety level of the associated system. Conflict resolution rules arbitrate when the same functional objective is triggered simultaneously by different modalities. For example, when voice commands and gesture commands conflict, if the voice command has a higher urgency, the voice command takes precedence; or in high-noise environments, touch input takes precedence over voice input.

[0053] The aforementioned rules are stored in the rule engine as formal expressions, supporting real-time invocation and inference. During the action generation process, each candidate action proposed by the reinforcement learning model undergoes compliance verification by the rule base, retaining only actions that meet all constraints, thereby ensuring the technical feasibility and security of the generated use cases.

[0054] The reinforcement learning model in this embodiment can use a deep Q-network as its core architecture. This model consists of a neural network that receives the current state (i.e., a state vector formed by concatenating the scene feature vector with the initial template parameters) and outputs the Q-value corresponding to each possible action, representing the expected cumulative reward that can be obtained in the future by taking that action. The agent continuously tries different action sequences, observes the feedback results in a simulated environment, and optimizes its strategy using experience replay and target network update mechanisms, gradually approaching the optimal decision path.

[0055] The entire training process of a deep Q-network aims to maximize a predefined reward function. This reward function is a key metric for evaluating the quality of test cases and is composed of multiple weighted quantitative dimensions. The expression for the reward function is: Where r represents scenario coverage, reflecting whether the current use case covers feature interval combinations that have not yet been tested; s represents modal synergy, evaluating the rationality and smoothness of cooperation between multiple modalities; and t represents defect detection rate, predicting the likelihood of the use case causing system anomalies based on historical data. , , The corresponding weighting coefficients can be obtained through methods such as the analytic hierarchy process (AHP), orthogonal experimental design, or expert calibration. It should be noted that the weighting coefficients can be dynamically adjusted according to the objective emphasis of different testing phases. For example, in the early stages of functional verification, the focus may be on scenario coverage, while in the regression testing phase, the weight of defect detection rate may be increased.

[0056] In each iteration, if the test cases generated by the agent successfully cover new sub-scenarios, conform to multimodal collaborative logic, or trigger known potential defects, it receives a positive reward; conversely, if redundant tests, modal conflicts, or invalid operations are generated, a negative penalty is imposed. Through this reward and penalty mechanism, the model gradually learns to identify high-value test actions. For example, in a high-speed, high-noise environment, combining short voice commands with small gestures to test the air conditioning adjustment function is both close to real user behavior and has a high potential for defect exposure. The reinforcement learning process continues until the cumulative reward tends to converge or reaches the preset maximum number of iterations p (e.g., 1000 rounds). Finally, the system outputs the several action sequences with the highest cumulative rewards. Each sequence corresponds to a complete candidate test case, the contents of which include, but are not limited to, triggering conditions, participating modalities, input parameters, execution order, and expected response.

[0057] In some implementations, prior to step S310, to ensure that the generation process of multimodal interaction test cases conforms to the actual human-computer interaction logic and has security and executability, this embodiment further includes: constructing a multimodal interaction rule base based on a knowledge graph; the knowledge graph includes entities, attributes, and relationships between entities, and the relationships between entities include triggering relationships, priority relationships, and conflict resolution rules.

[0058] Specifically, the knowledge graph uses a triple structure of entities, attributes, and relationships between entities to formally represent and organize the key elements of the intelligent cockpit interaction system. By transforming unstructured technical specifications, user operation logs, and engineering experience into a structured semantic network, the system can achieve a unified description and dynamic reasoning of multimodal interaction logic.

[0059] In the process of building a knowledge graph, four core entities are first defined: scene entities, interaction modal entities, instruction entities, and functional system entities.

[0060] Scene entities represent the specific environmental conditions in which the vehicle operates, such as "high-speed driving scenario," "nighttime low-light scenario," "urban congestion scenario," and "underground parking garage scenario." Each scene entity is associated with a set of quantitative attributes, such as vehicle speed range ([90, 110] km / h), noise level ([65, 75] dB), light intensity (<300 lux), and turning frequency, to accurately characterize the technical features of the driving situation. Interaction modality entities represent the types of interaction methods available to the user, including voice modality, gesture modality, touch modality, eye-tracking modality, and physical button modality. Each modality entity has corresponding attribute parameters, such as response latency (approximately 800 ms for voice modality), applicable environment (gesture modality is suitable for low to medium speeds), and operation complexity (medium for touch modality). Command entities represent specific function requests issued by the user, such as navigating to the company, adjusting the air conditioning to 24°C, playing music, and emergency braking reminders. Each instruction entity is labeled with multiple semantic attributes, including urgency level (high / medium / low), execution time, associated systems (such as navigation system, air conditioning control system), input modality preference, etc.; functional system entities correspond to the functional modules inside the smart cockpit, such as voice recognition system, touch screen interaction system, ADAS advanced driver assistance system, entertainment system, air conditioning control unit, etc., used to establish the dependency relationship between instructions and underlying systems.

[0061] Based on the aforementioned entities, the system establishes various types of semantic relationships (such as triggering relationships, adaptation relationships, priority relationships, conflict relationships, and dependency relationships) to form a complete knowledge network connection. Triggering relationships are used to describe the interaction modalities that are preferentially activated in a specific scenario. For example, triggering the voice modality in high-speed driving scenarios indicates that voice interaction should be prioritized to reduce driver distraction under high-speed driving conditions; similarly, suppressing the touch modality in low-light scenarios reflects the reduced screen visibility in dark environments, making touch operation unsuitable; adaptation relationships indicate the degree of matching between different modalities and specific commands. For example, the voice modality adapts to long commands (such as setting a destination), while the gesture modality adapts to short commands (such as volume adjustment), reflecting the differences in the operational characteristics of each modality; priority relationships are used to resolve execution order conflicts between concurrent commands. For example, an emergency braking reminder has higher priority than playing music, or an ADAS warning interrupts the navigation setting process. Such relationships are sorted according to the urgency of the command and the safety level of the associated system; conflict relationships identify mutually exclusive or potentially ambiguous interaction combinations. For example, a voice command to increase volume and a gesture to swipe down constitute a semantic conflict; another example is that prohibiting the parsing of gesture commands during voice wake-up is a system-level anti-interference design; dependency relationships are used to depict the call chain between commands and functional systems. For example, adjusting the air conditioning temperature depends on the air conditioning control system, while activating cruise control depends on the power control system and the ADAS system.

[0062] The knowledge graph construction process includes an instantiation phase and a knowledge completion phase. In the instantiation phase, real-world driving data collected in step S100 is used to populate concrete instances for abstract entities. For example, based on a 10-minute driving record on an urban expressway, an instance named "Urban Expressway Moderate Rain Weather Scenario" is created, and its attribute value is bound to it: vehicle speed. ,noise The rain indicator is set to TRUE. Subsequently, historical data analysis reveals that users in this scenario tend to use voice rather than gestures, thus establishing a rainy weather scenario on an urban expressway and triggering a triplet for the voice modality. During the knowledge completion phase, the system introduces a rule-based reasoning engine and a machine learning model to automatically deduce missing relationships. For example, given two facts—that high-noise environments are unsuitable for voice modalities and that tunnel scenarios are high-noise environments—the new knowledge "tunnel scenarios are unsuitable for voice modalities" can be deduced through logical deduction. Furthermore, a graph neural network (GNN) model can be trained based on millions of real user interaction logs to predict potential unstated relationships. For instance, if it is found that elderly drivers use physical buttons more frequently in low-temperature environments, corresponding population and modality preference relationships can be added. Finally, three types of core rules for test control (modal triggering rules, instruction priority rules, and conflict resolution rules) are extracted from the knowledge graph and transformed into machine-executable formal expressions, stored in a multimodal interaction rule base.

[0063] Step S320: Based on the preset quantitative evaluation indicators, the performance of each candidate test case is evaluated to determine the test cases to be optimized and the initial test cases.

[0064] The purpose of this step is to overcome the limitations of traditional testing that relies on human experience to judge effectiveness. By introducing a quantifiable and objective technical indicator system, we can comprehensively evaluate the coverage, collaborative rationality, and defect discovery potential of each candidate test case. Based on this, we can identify test cases that need to be deleted, test cases whose evaluation results do not meet the requirements but can be slightly optimized to meet the requirements (test cases to be optimized), and test cases with good evaluation results (initial test cases).

[0065] In the specific implementation process, the system constructs a three-dimensional quantitative evaluation model, which includes three core evaluation dimensions: scenario coverage, modal synergy, and defect detection rate. These three indicators together constitute a comprehensive characterization of the overall performance of test cases, and their calculation process is based on the scenario feature model, multimodal interaction rule library, and historical test data support built in the early stage.

[0066] Regarding the calculation of scene coverage, the system uses the multi-dimensional scene feature space established in step S100 as a basis, dividing continuous features into several key intervals with practical engineering significance. For example, vehicle speed is divided into... (Low speed) (Medium speed) (high speed), (Ultra-high speed); noise levels are classified in decibels as follows: (Quiet), (Medium noise) (High noise); Illumination intensity is divided into, (at night), (daytime), (Strong light); temperature is divided into, (Low temperature) (normal temperature), (High temperature) etc.

[0067] Each combination of intervals forms a sub-scene unit, and all possible combinations constitute the complete scene feature space. The system iterates through the scene parameters corresponding to each candidate test case, maps them to the specific sub-scene location in this space, and records whether the sub-scene has been covered. Finally, the scene coverage rate is defined as the ratio of the number of covered sub-scenes to the total number of enumerable sub-scenes, calculated using the following formula: Where F is the scene coverage rate, A is the number of sub-scenes that have been covered by at least one test case, and B is the total number of all possible combinations of sub-scenes in the feature space.

[0068] For sparse sub-scenarios that are not yet covered by any use cases or are covered by only a very small number of use cases, the system will assign higher evaluation weights to these marginal but high-risk driving scenarios (such as speech recognition tests under combined conditions of high speed, strong noise, and nighttime).

[0069] In addition, the system focuses on evaluating the logical consistency, smoothness, and conflict avoidance capabilities among multimodal interaction actions in the assessment of modal collaboration. This indicator is composed of two weighted sub-items: rule compliance and interaction fluency. Rule compliance measures whether candidate use cases follow the constraints in the multimodal interaction rule base constructed before step S310 during execution. For example, if a use case triggers a large gesture operation in a high-speed scenario at a speed of 90km / h, it violates the rule of suppressing gesture modality triggering in high-speed scenarios; similarly, if a voice command for emergency braking and a touch operation for changing songs occur simultaneously, and the system does not prioritize the former, it violates the priority rule. The system compares the behavior sequence of candidate use cases with the clauses in the rule base, calculates the percentage of compliant behaviors, and obtains the rule compliance score. Interaction fluency evaluates the quality of multimodal collaboration from a user experience perspective, mainly including conflict occurrence rate and response time compliance rate. Among them, the conflict occurrence rate is used to detect whether there are semantic contradictions or multi-source input competition within the same time window. For example, if a user simultaneously issues a volume increase command via voice and then swipes down, this reverse action is considered a coordination conflict. The response time compliance rate verifies whether the end-to-end response latency of composite modal operations is reasonable. For example, the overall time for "voice wake-up + touch click" should not exceed the sum of the voice wake-up time and the touch response time; otherwise, it indicates a resource scheduling bottleneck or system blocking problem. After normalization, the scores of the above items are merged according to preset weights to form the final modal coordination score.

[0070] Furthermore, in evaluating the defect detection rate, this embodiment also combines the historical defect database with the current simulation execution results to assess the actual testing value of candidate test cases. This database structurally stores all defect information discovered in past tests, including defect ID, type (such as speech misrecognition, modal preemption failure, response timeout), triggering scenario characteristics, associated functional modules, risk level (high / medium / low), and repair status.

[0071] The system executes each candidate test case through a hardware-in-the-loop testing platform or a simulated testing environment, collects its actual output behavior (such as response time and function execution results), and automatically compares it with the preset expected results. If a deviation occurs (such as no response to voice commands or incorrect execution of unexpected functions), it is marked as a potential anomaly. Subsequently, the system matches the anomaly with existing defect patterns in the database: if it can accurately match a certain historical defect (such as the same model having experienced multiple ASR failures in similar high-noise environments), it is included in the known defect detection count; if it is a completely new anomaly pattern and occurs in a high-frequency missed detection scenario (such as touch failure under extreme temperatures), it combines statistical data such as historical defect density and scenario occurrence frequency, and uses statistical modeling methods (such as Bayesian probability models) to estimate its potential risk level, and incorporates it into the potential defect exposure capability score.

[0072] After independently calculating the above three metrics, determine the test cases to be optimized, the initial test cases, and the test cases to be deleted based on the scores of the three metrics. If all three metrics are below a certain threshold, or if two metrics are below a certain threshold (such as coverage), further action will be taken. Coordination Detection rate or coverage Coordination Detection rate Test cases that do not meet the threshold are directly eliminated. If only one metric is below the threshold, it can be judged as a test case to be optimized; if all three metrics are greater than or equal to the preset corresponding threshold, it is judged as an initial test case. It should be noted that the above classification rules are only an exemplary implementation method and can be flexibly adjusted according to actual testing needs, such as setting differentiated thresholds according to different functional modules.

[0073] Step S330: Optimize the test cases to be optimized, and select the target test cases from the optimized test cases and the initial test cases.

[0074] As an example, after completing the performance evaluation of candidate test cases, the system performs automated optimization operations on the identified test cases to be optimized in order to improve their test effectiveness, coverage and interaction rationality. The optimized test cases and the initial test cases are then screened according to the target test case judgment rules to obtain the target test cases. This process not only fixes inefficient or defective test designs, but also feeds high-quality test cases back to the knowledge system through a closed-loop mechanism, so as to achieve the continuous evolution of test assets.

[0075] The optimization process aims to ensure that the optimized test cases achieve preset thresholds in three key metrics: scenario coverage, modal synergy, and defect detection rate. During the optimization iterations, the genetic algorithm performs selection, crossover, and mutation operations. The selection phase sorts test cases based on fitness, retaining high-scoring individuals for the next generation. Crossover involves randomly selecting two parent test cases and exchanging fragments at the modal combination or parameter configuration level to generate new combinations. Mutation introduces perturbations to certain key parameters to explore unknown areas; for example, the original gesture could be slightly modified from an upward swipe to a double-tap followed by a short swipe. The optimization process can continue for k iterations (e.g., k=200) until the overall fitness converges or the maximum computational resource budget is reached. The individual with the highest fitness is then output as the optimized version of the test case. After obtaining the optimized test case set, further filtering is performed according to the target test case judgment rules, retaining only high-value test cases with long-term reuse value for conversion and storage.

[0076] In some implementations, selecting target test cases from the obtained optimized test cases and initial test cases includes: determining target test cases from the optimized test cases and initial test cases based on target test case judgment rules.

[0077] After selecting target test cases from the optimized test cases and initial test cases, the process also includes: converting the target test cases into standardized templates, labeling the standardized templates with corresponding scenario tags, and then feeding them back to the test template library.

[0078] For example, the judgment rules for target test cases meet at least one of the following conditions: Covering high-priority scenarios or low-probability, high-risk edge scenarios (e.g., the test case successfully activates and tests a multimodal degradation strategy under complex extreme conditions such as "high-speed driving + strong noise + sudden visual occlusion," which is a crucial verification path for safety); Successfully detecting high-risk defects or historically frequently missed defects (if the test case triggers high-risk issues such as ADAS misjudgment or loss of emergency commands during simulation, or reproduces historical defects that were repeatedly missed in previous automated tests, it indicates outstanding defect exposure capabilities); Achieving collaborative operation of three or more modalities without interaction conflicts (e.g., a three-modal linkage process of voice wake-up + eye gaze at the target area + gesture confirmation selection is representative of complex human-computer collaboration functions, and its execution process fully conforms to the collaborative logic in the rule base, without preemption or ambiguity); Execution resource consumption is lower than a preset threshold, but test coverage or defect detection rate is higher than the baseline level (i.e., the test case has high testing efficiency characteristics and can be executed in a short time (e.g., in a single execution)). (3 seconds) Covers multiple key sub-scenes or exposes multiple potential issues, suitable for inclusion in regression test suites.

[0079] For a test case that meets any of the above conditions, the system identifies it as a target test case and initiates a template conversion process. This involves abstracting it from a one-off test instance into a reusable, general template, extracting information such as the test objective, multimodal combinations, parameter ranges, expected output behavior, and applicable constraints, and then encapsulating this information to form a standardized template.

[0080] After creating a standardized template, one or more scenario tags need to be attached to it to identify the applicable driving scenarios. Scenario tags are obtained based on the main feature ranges covered by the use case, such as labeled as high-speed cruising, high-noise environments, and multimodal collaboration. These tags enable rapid matching of similar scenarios through semantic retrieval in subsequent step S100, improving migration efficiency. Finally, the tagged standardized template is fed back into the test template library for subsequent use.

[0081] To more clearly illustrate the technical solution of this embodiment, the following describes in detail the complete execution process of the method of the present invention from data acquisition to closed-loop optimization, taking the intelligent cockpit multimodal interaction test under high-speed cruising scenario (vehicle speed 90-110km / h, in-vehicle noise 65-75 decibels) as an example.

[0082] I. Data Acquisition and Preprocessing This embodiment uses an onboard sensor network to collect real-time vehicle operating status, environmental perception information, and user interaction data. Specifically, it includes acquiring vehicle dynamic parameters via the CAN bus: vehicle speed is 100 km / h. Steering angle is The acceleration is 0.2. ²; The noise level inside the vehicle was measured to be 70dB by the noise sensor and the light intensity was measured to be 5000 lux by the light sensor; The user's voice command "Turn on the air conditioner to 24℃" was recorded by the microphone array, and the user's gesture to adjust the volume was captured by the camera; The response time (1.2s) and execution result (the air conditioner was successfully turned on and set to 24℃) were obtained by the intelligent cockpit system log.

[0083] The raw data is preprocessed, including outlier removal, linear imputation of missing values, and numerical normalization, to ensure the stability and accuracy of subsequent modeling.

[0084] II. Scene Feature Modeling After data preprocessing, the system uses a deep neural network model to extract multidimensional features: for environmental perception data (such as noise signals), a convolutional neural network (CNN) is used to analyze the spatiotemporal patterns in its spectrum distribution, identify the energy concentration phenomenon in the 60-80Hz frequency band, and determine the presence of continuous engine noise interference; for user behavior sequences (such as "gesture operation 0.5 seconds after voice wake-up"), a long short-term memory network (LSTM) is used to model its temporal dependencies and capture typical human-machine collaboration rhythms; various high-dimensional feature vectors are concatenated and fused, and then dimensionality reduced by a fully connected layer to finally generate a 128-dimensional high-speed cruise scene feature vector, which serves as the scene feature model for this driving scenario.

[0085] III. Cross-Scenario Knowledge Transfer and Initial Template Generation After constructing the feature model of the target scene, the system accesses a pre-built test template library to search for transferable historical source scene templates. For example, the system matches an urban road scene (vehicle speed 40-60 km / h). The verified "voice + gesture" composite modal test template includes the following configurations: voice command length of 5-8 Chinese characters, gesture type of left and right swipe to control media switching, and amplitude defined as medium.

[0086] To assess the feasibility of migration, the system calculates the feature similarity between the urban road scene and the current highway cruising scene. A cosine similarity algorithm is used to compare the 128-dimensional feature vectors of the two scenes, yielding a similarity value of 0.75, which is higher than the preset threshold of 0.7. Therefore, the system is deemed to have sufficiently high transferability, and the parameter mapping process is initiated.

[0087] Subsequently, the system performs the following two adjustments: 1. Feature distribution alignment: A domain-adaptive transfer learning algorithm based on minimizing the maximum mean difference (MMD) is adopted to project the feature spaces of the source and target scenes into a shared subspace, eliminating systematic biases caused by factors such as vehicle speed and attention allocation; 2. Semantic mapping rule-driven adjustment: Based on the safety principle of reducing driver distraction at high speeds, semantic rules are triggered according to the vehicle speed. At 60km / h, the range of hand gestures is adjusted from medium to small, that is, the permissible angle range is compressed to... 25°; Based on cognitive load theory, voice commands in high-speed scenarios should be concise and clear. The original 5-8 character limit has been shortened to 3-5 characters. It is recommended to use "turn on the air conditioner to 24" instead of lengthy expressions such as "set the air conditioner to 24 degrees". Based on the above adjustments, the system generates an initial test template adapted to the high-speed cruise scenario, retaining the original functional logic framework (such as verifying the coordinated adjustment of air conditioner by voice and gesture), but the key parameters have been reset to meet the safety and usability requirements of the target scenario.

[0088] IV. Generation of Multimodal Interaction Combination Test Cases After obtaining the initial test template, the system combines the current scene feature model with the multimodal interaction rule library to start the candidate test case generation process based on reinforcement learning.

[0089] The multimodal interaction rule base is built on a knowledge graph and includes modal triggering rules, priority rules, and conflict resolution rules.

[0090] The reinforcement learning model uses a deep Q-network as its core architecture, encoding scene feature vectors and initial test templates together as state inputs. The action space is defined as the set of all legal multimodal combination operations, such as: "voice command to turn on cruise control 100". + Gesture confirmation, voice-activated music playback, and touch-based volume adjustment. This model ultimately outputs a set of optimal action sequences, forming 20 structured candidate test cases, all encapsulated in standard JSON format, covering fields such as trigger conditions, participating modalities, parameter configurations, and expected outputs, which can be directly injected into the HIL (Hardware-in-the-Loop) test platform for execution.

[0091] V. Test Case Performance Evaluation and Optimization To verify the quality of the generated test cases, the system conducted performance analysis based on a three-dimensional quantitative evaluation system. The analysis results were: scene coverage 80%, modal coherence 70%, and defect detection rate 75%. One test case, "voice to turn off navigation + gesture to zoom in on map," had a modal coherence of only 65%, which was lower than the preset threshold of 70%, and was marked as a test case to be optimized.

[0092] For this use case to be optimized, the system initiated a genetic algorithm optimization process, tried various alternatives in the mutation operation, and finally found that adjusting the gesture to zoom in on the map to gesture to zoom out on the map significantly improved semantic consistency. That is, after closing the navigation, the interface is further collapsed, which is more in line with the user's psychological expectations. After optimization and re-evaluation, the modal coherence of this use case increased to 78%, which meets the requirements.

[0093] Subsequently, all test cases that meet the requirements are used as target test cases, and following the template transformation logic in step S330, they are abstracted into standardized test templates, labeled with the scenario tag "high-speed cruising," and stored in the test template library. In the future, when similar high-speed scenarios reappear, this template can be quickly matched and migrated again through semantic retrieval, significantly shortening the test preparation cycle and achieving continuous accumulation and closed-loop evolution of test assets.

[0094] This embodiment constructs a multi-dimensional scene feature model integrating vehicle state, environmental perception, and user behavior. Combined with knowledge graphs and deep reinforcement learning techniques, it achieves intelligent generation of multimodal interaction combinations, improving test coverage for complex and edge scenarios. Utilizing domain-adaptive transfer learning and semantic mapping rules, it supports automatic transfer of test knowledge and parameter tuning across scenarios, avoiding redundant development and significantly improving test adaptation efficiency. Furthermore, by establishing a quantitative evaluation system encompassing scene coverage, modal synergy, and defect detection rate, and introducing a genetic algorithm for closed-loop optimization of inefficient test cases, it achieves objective evaluation and continuous improvement of test quality. High-value test cases can be automatically identified and converted into standardized templates, flowing back to the test template library for automatic test case improvement.

[0095] Figure 5 A schematic diagram of a test case generation apparatus according to an embodiment of this application is shown. Exemplarily, the test case generation apparatus includes: The construction module 100 is used to construct a scene feature model based on the multi-source sensor data of the vehicle collected in the target scene to be tested, and to match the target source scene from a pre-built test template library based on the scene feature model.

[0096] The mapping module 200 is used to map the test configuration information corresponding to the target source scenario to the target scenario, so as to generate an initial test template adapted to the target scenario.

[0097] The determination module 300 is used to generate target test cases by combining the scene feature model, the initial test template, the multimodal interaction rule library, and the target test case evaluation rules.

[0098] It is understood that the apparatus in this embodiment corresponds to the test case generation method in the above embodiments, and the options in the above embodiments are also applicable to this embodiment, so they will not be described again here.

[0099] This application also provides a terminal device, exemplary of which includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to enable the terminal device to perform the functions of the various modules in the above-described test case generation method or the above-described test case generation apparatus.

[0100] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0101] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0102] This application also provides a computer-readable storage medium for storing the computer program used in the aforementioned terminal device. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0103] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, in alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0104] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0105] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0106] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A test case generation method, characterized in that, include: A scene feature model is constructed based on multi-source sensor data of vehicles collected in the target scene to be tested, and the target source scene is matched from a pre-built test template library based on the scene feature model. Map the test configuration information corresponding to the target source scenario to the target scenario to generate an initial test template adapted to the target scenario; Target test cases are generated by combining the scenario feature model, the initial test template, the multimodal interaction rule library, and the target test case evaluation rules.

2. The test case generation method according to claim 1, characterized in that, The process of generating target test cases by combining the scene feature model, the initial test template, the multimodal interaction rule base, and the target test case evaluation rules includes: At least one candidate test case is generated by combining the scene feature model, the initial test template, and the multimodal interaction rule base; The performance of each candidate test case is evaluated based on the preset quantitative evaluation index in order to determine the test cases to be optimized and the initial test cases. The test cases to be optimized are optimized, and the target test cases are selected from the optimized test cases and the initial test cases.

3. The test case generation method according to claim 1, characterized in that, The matching of the target source scene from the pre-built test template library based on the scene feature model includes: Calculate the similarity between each feature vector in the scene feature model of the target scene and the feature vectors of each source scene; The source scenes with a similarity greater than or equal to a preset similarity threshold are used as the target source scenes.

4. The test case generation method according to claim 1, characterized in that, The step of mapping the test configuration information corresponding to the target source scenario to the target scenario to generate an initial test template adapted to the target scenario includes: The feature distribution of the target source scene and the target scene is aligned using a domain-adaptive transfer learning algorithm. According to preset semantic mapping rules, modality-related parameters in the target source scene are converted into adaptation parameters under the target scene; wherein, the semantic mapping rules are determined based on human-machine interaction safety constraints and operating habits under different driving conditions; Based on the adaptation parameters, an initial test template adapted to the target scenario is generated.

5. The test case generation method according to claim 2, characterized in that, The step of combining the scene feature model, the initial test template, and the multimodal interaction rule base to generate at least one candidate test case includes: The scene feature model and the initial test template are used as state inputs, and the multimodal interaction combination actions are used as a set of executable actions. These are input into the decision model to output at least one of the candidate test cases. The decision model aims to maximize a preset reward function, which is composed of a weighted average of at least two of the following: scene coverage, modal synergy, and defect detection rate.

6. The test case generation method according to claim 2, characterized in that, The multimodal interaction rule base is constructed based on a knowledge graph; the knowledge graph includes entities, attributes, and relationships between entities; wherein, the entities include scene entities, interaction modal entities, instruction entities, and functional system entities; the relationships between entities include at least one of triggering relationships, priority relationships, and conflict resolution rules.

7. The test case generation method according to claim 2, characterized in that, The step of selecting target test cases from the optimized test cases and the initial test cases includes: determining target test cases from the optimized test cases and the initial test cases based on target test case judgment rules; After selecting the target test cases from the optimized test cases and the initial test cases, the process further includes: The target test cases are converted into standardized templates, and the standardized templates are labeled with corresponding scenario tags before being fed back to the test template library.

8. A test case generation device, characterized in that, include: The construction module is used to build a scene feature model based on the multi-source sensor data of the vehicle collected in the target scene to be tested, and to match the target source scene from the pre-built test template library based on the scene feature model. The mapping module is used to map the test configuration information corresponding to the target source scenario to the target scenario, so as to generate an initial test template adapted to the target scenario; The determination module is used to generate target test cases by combining the scene feature model, the initial test template, the multimodal interaction rule library, and the target test case evaluation rules.

9. A terminal device, characterized in that, The terminal device includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the test case generation method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed on a processor, implements the test case generation method according to any one of claims 1-7.

Images