Test assertion generation method based on ternary graph and related device

Abstract

This application discloses a test assertion generation method and related equipment based on ternary graphs, relating to the field of vehicle testing technology. The method includes: acquiring requirement description data, vehicle signal data, and user interface description data; constructing a target ternary graph set based on the requirement description data, vehicle signal data, and user interface description data; selecting a preset assertion template from a preset assertion template library and filling in parameters based on the target ternary graph set to generate a candidate assertion set; and testing and verifying the candidate assertion set to obtain a target assertion set used for testing vehicle functions. This application achieves automation, standardization, and verifiability of test assertion generation by uniformly constructing requirements, vehicle signals, and the user interface into a ternary graph, and automatically generating and verifying test assertions based on a template-based approach. This improves the consistency, reliability, and reusability of assertions with vehicle functions.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and more specifically, to a test assertion generation method and related equipment based on ternary graphs. Background Technology

[0002] With the rapid development of automotive electronics technology and intelligent connected vehicles, vehicle functions are constantly evolving towards higher software integration, intelligence, and more complex human-machine interaction. Vehicle function testing plays an increasingly important role in the whole vehicle development and quality assurance process. In order to verify whether the vehicle functions meet the requirements specifications, it is usually necessary to write a large number of test assertions based on multi-dimensional information such as requirements description, vehicle signals, and user interface display to determine whether the vehicle's functional performance under different operating conditions meets the design requirements.

[0003] However, in related technologies, the generation of vehicle functional test assertions largely relies on manual analysis of requirements documents, signal definition files, and interface design specifications. Testers manually establish the correspondence between requirements, signals, and interfaces, and write test assertions accordingly. This method is not only labor-intensive and inefficient, but also highly dependent on human experience, making it prone to incomplete or inconsistent assertions due to misunderstandings or omissions. Furthermore, requirements descriptions, vehicle signals, and user interfaces are typically stored in different documents or systems, lacking a unified structured expression, making it difficult to clearly depict the relationships between them, further increasing the complexity of assertion design and maintenance. In other words, related technologies suffer from low test assertion generation efficiency, poor consistency and maintainability, and insufficient reliability. Summary of the Invention

[0004] The summary section of this application introduces a series of simplified concepts, which will be further explained in detail in the detailed description section. The summary section of this application is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0005] The test assertion generation method and related equipment based on ternary graphs provided in this application can automatically generate and verify test assertions by uniformly constructing requirements, vehicle signals and user interfaces into a ternary graph and using a template-based approach. This achieves automation, standardization and verifiability of test assertion generation, and can improve the consistency, reliability and reusability of assertions with vehicle functions.

[0006] In a first aspect, this application provides a test assertion generation method based on ternary graphs, comprising: acquiring requirement description data, vehicle signal data, and user interface description data; constructing a target ternary graph set based on the requirement description data, the vehicle signal data, and the user interface description data, wherein the target ternary graph set includes at least one target ternary graph, and the target ternary graph contains requirement entities, signal entities, interface entities, and target association relationships between each entity; generating a candidate assertion set based on the target ternary graph set by selecting a preset assertion template from a preset assertion template library and filling in parameters; and testing and verifying the candidate assertion set to obtain a target assertion set for testing vehicle functions.

[0007] In some implementations, constructing a target ternary graph set based on the demand description data, the vehicle signal data, and the user interface description data includes: generating a demand entity containing a demand identifier and a first attribute set based on the demand description data; generating a signal entity containing a signal identifier and a second attribute set based on the vehicle signal data; generating an interface entity containing an interface element identifier and a third attribute set based on the user interface description data; determining the target association relationships between each pair of the demand entity, the signal entity, and the interface entity based on preset matching rules; and constructing the target ternary graph set based on the demand entity, the signal entity, the interface entity, and the target association relationships.

[0008] In some implementations, determining the target association relationships between each pair of the demand entity, the signal entity, and the interface entity based on preset matching rules includes: generating a candidate association relationship set based on keyword matching, alias matching, or semantic similarity matching, wherein the candidate association relationship set includes candidate association relationships between each pair of the demand entity, the signal entity, and the interface entity, and the confidence level of each candidate association relationship; and determining the candidate association relationships in the candidate association relationship set whose confidence level is higher than the preset confidence threshold as the target association relationships.

[0009] In some implementations, the step of selecting a preset assertion template from a preset assertion template library and filling in parameters based on the target ternary graph set to generate a candidate assertion set includes: determining a preset assertion template from the preset assertion template library according to the target association relationship in the target ternary graph set; filling in preset parameters for the preset assertion template based on at least one of the first attribute set, the second attribute set, and the third attribute set to obtain a structured assertion, wherein the preset parameters include at least one of a threshold, a time window, and a retry strategy; generating assertion scripts based on the structured assertions, and binding a matching version tag to each assertion script to obtain the candidate assertion set.

[0010] In some implementations, determining a preset assertion template from the preset assertion template library based on the target association relationships in the target ternary graph set includes: traversing the demand entities in the target ternary graph set and determining the entity attributes associated with the current demand entity; if the current demand entity is determined to be associated with both a signal entity and an interface entity, then the preset assertion template is determined to include a temporal causal template and a consistency template; if the current demand entity is determined to be associated with a signal entity but not with any interface entity, then the preset assertion template is determined to be a signal threshold template or a signal steady-state template; if the current demand entity is determined to be associated with an interface entity but not with any signal entity, then the preset assertion template is determined to be an interface text verification template or an interface state verification template.

[0011] In some implementations, the step of testing and verifying the candidate assertion set to obtain a target assertion set for testing vehicle functions includes: executing the candidate assertions in the candidate assertion set multiple times to obtain the execution result of each candidate assertion, wherein the execution result includes at least one of pass rate, log data, interface screenshot data, and signal curve data; and based on the execution result, selecting candidate assertions that meet preset requirements from the candidate assertion set to obtain the target assertion set.

[0012] In some implementations, the method further includes: if at least one of the demand description data, the vehicle signal data, and the user interface description data changes, then obtaining the entities and relationships affected by the change; based on the entities and relationships affected by the change, updating the target ternary graph set to update and re-verify the affected assertions in the target assertion set.

[0013] Secondly, this application also provides a test assertion generation device based on a ternary graph, comprising: a data acquisition unit for acquiring requirement description data, vehicle signal data, and user interface description data; a graph construction unit for constructing a target ternary graph set based on the requirement description data, the vehicle signal data, and the user interface description data, wherein the target ternary graph set includes at least one target ternary graph, and the target ternary graph contains requirement entities, signal entities, interface entities, and target association relationships between entities; a candidate assertion generation unit for selecting a preset assertion template from a preset assertion template library and filling in parameters based on the target ternary graph set to generate a candidate assertion set; and a target assertion generation unit for testing and verifying the candidate assertion set to obtain a target assertion set for testing vehicle functions.

[0014] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to execute a computer program stored in the memory to implement the steps of the test assertion generation method based on ternary graphs described in the first aspect.

[0015] Fourthly, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the test assertion generation method based on ternary graphs described in the first aspect.

[0016] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, wherein when the computer program or computer executable instructions are executed by a processor, the steps of the test assertion generation method based on ternary graphs provided in the embodiments of this application are implemented.

[0017] In summary, this application simultaneously acquires requirement description data, vehicle signal data, and user interface description data, and constructs a target ternary graph set containing requirement entities, signal entities, and interface entities based on these three types of data. This allows information originally scattered across different documents or systems to be uniformly represented in the same model. Leveraging the target association relationships between entities, the correspondence between requirements, vehicle signals, and interface performance can be clearly expressed, improving the accuracy and consistency of test object understanding. By selecting assertion templates from a pre-defined assertion template library based on the target ternary graph set and filling in the parameters, a candidate assertion set can be automatically generated, avoiding complete reliance on manually written test assertions. This reduces the workload of manually writing assertions and minimizes errors caused by human misunderstanding or omissions. The assertion generation process is based on the target ternary graph, and the selection of assertion templates and parameter filling are both derived from... By defining the demand entities, signal entities, and interface entities and their relationships, the generated candidate assertions can directly reflect the expected performance of vehicle functions at the signal and interface levels, improving the consistency and relevance between assertions and the functions under test. By testing and verifying the generated candidate assertion set, and obtaining the target assertion set based on the verification results, assertions can be screened and confirmed before being formally used in vehicle function testing, reducing invalid or unstable assertions from entering the actual testing process and improving the reliability of the final target assertion set in vehicle function testing. Using a pre-set assertion template library combined with ternary graphs for assertion generation gives the assertion structure and generation method a certain degree of standardization and universality. When different demands, signal, or interface data change, assertions can be regenerated based on the same generation process, improving the reusability of test assertions in different testing scenarios. In summary, the test assertion generation method based on ternary graphs provided in this application unifies the requirements, vehicle signals, and user interface into a ternary graph, and automatically generates and verifies test assertions based on a template-based approach. This achieves automation, standardization, and verifiability of test assertion generation, and can improve the consistency, reliability, and reusability of assertions with vehicle functions. Attached Figure Description

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

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

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

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

[0022] Figure 1 This is a schematic flowchart illustrating a test assertion generation method based on ternary graphs provided in an embodiment of this application. For example, see [link to example]. Figure 1 The test assertion generation method based on ternary graphs provided in this application embodiment may include the following steps 101 to 104: Step 101: Obtain the requirement description data, vehicle signal data, and user interface description data.

[0023] In some examples, requirement description data is used to clarify the goals and constraints that various vehicle functions should achieve. It can define the expected performance of vehicle functions and cover the function's goal description, execution conditions, performance requirements, etc. Requirement description data can be mainly extracted from product requirement documents and test case documents, or it can be obtained by compiling records from requirement review meetings with the product development team and the testing team. For example, requirement description data for a vehicle's air conditioning system (Heating, Ventilation and Air Conditioning, HVAC) could be that when the temperature in the driver's area is set to 22 degrees Celsius, the corresponding interface must accurately display this temperature value with a temperature control error not exceeding plus or minus 0.5 degrees Celsius.

[0024] Vehicle signal data refers to observable and controllable physical quantities or state-related data during vehicle operation. This data reflects the operating status and control commands of various vehicle systems. It can be parsed and extracted from database description files (DBC) and Automotive Open System Architecture XML (ARXML) files, or obtained from real-time operating data collected by signal acquisition equipment during actual vehicle testing. For example, data related to the HVAC driver's temperature setpoint signal (HVAC_DriverTemp_Setpoint) includes information such as message identifier 0x5A1, signal refresh period not less than 10 Hz, and resolution of 0.5 degrees Celsius per bit.

[0025] User interface description data is the descriptive information of all visible elements on the vehicle's Human Machine Interface (HMI), used to define the attributes, states, and presentation requirements of interface elements. It can be extracted from HMI design documents and UI tree sample files, or obtained by parsing image information after taking screenshots of the actual vehicle interface. For example, the relevant data for the driver's side temperature display text control includes information such as the control identifier being tv_temp_driver, the hierarchical path being HVAC interface - driver's side control area - temperature display module, the expected text to be displayed being 22°C, and the visibility being set to visible.

[0026] For example, automated parsing tools can be used to batch read specified data sources such as PRD, DBC, and HMI design documents, extract core information from the above three types of data, and perform preliminary sorting to ensure the integrity and accuracy of the data. For some unstructured document data, text recognition technology can be used to extract key content and convert it into a standardized structured data format, providing standardized and usable basic data support for the subsequent construction of the target ternary graph set.

[0027] By implementing step 101, requirement description data, vehicle signal data, and user interface description data are obtained, providing a comprehensive and complete source of basic data for the generation of subsequent test assertions. This ensures that test-related information can simultaneously cover the requirement layer, signal layer, and interface layer, avoiding misunderstandings or incomplete coverage caused by test design based on only a single data source. This lays a data foundation for building an accurate test model.

[0028] Step 102: Based on the demand description data, vehicle signal data, and user interface description data, construct a target ternary map set.

[0029] The target ternary graph set may include at least one target ternary graph, which includes demand entities, signal entities, interface entities, and the target association relationships between each entity.

[0030] In some examples, the target ternary graph set is a structured data set composed of at least one target ternary graph. It can unify the organization of scattered demand description data, vehicle signal data, and user interface description data through entities and relationships, forming a reusable and queryable relational data model. Individual target ternary graphs can be constructed based on various types of raw data, and then categorized and integrated according to dimensions such as vehicle functional modules, test scenarios, or vehicle models to obtain the target ternary graph set. For example, for different functional modules such as vehicle air conditioning system, turn signal system, and window control system, corresponding target ternary graphs can be constructed respectively, and then these graphs can be summarized to form the target ternary graph set.

[0031] A target ternary graph is a maintainable, structured carrier that encapsulates the three core elements of "demand, signal, and interface" in a vehicle automation testing scenario. It is the basic unit in a target ternary graph set, including demand entities, signal entities, interface entities, and the target relationships between these three types of entities. Based on demand description data, vehicle signal data, and user interface description data, three independent entities are first extracted and generated. Then, the semantic relationships and logical correspondences between entities are analyzed. Finally, the entities and relationships are combined to form a maintainable, structured target ternary graph. For example, regarding the HVAC driver's seat temperature control function, the corresponding driver's seat temperature demand entity, driver's seat temperature signal entity, driver's seat temperature display interface entity, and the relationships between them are integrated to form a target ternary graph for this function.

[0032] A requirement entity is a data unit formed by structuring requirement description data. It is used to accurately define the expected goals and constraints of vehicle functions, possessing a unique identifier and fixed attribute characteristics. It can be used to perform structured parsing of extracted requirement description data, extracting core information according to preset field rules to generate standardized requirement entities. A signal entity is a core data unit formed by structuring vehicle signal data. It is used to objectively reflect the operating physical quantities, control commands, and related technical parameters of various vehicle systems. It can be used to parse vehicle signal data extracted from database description files and automated testing and verification markup language files, extracting key information according to the technical characteristics of the signals to generate standardized signal entities. An interface entity is a core data unit formed by structuring user interface description data. It is used to clarify the attributes, presentation status, and technical requirements of visible elements on the vehicle's human-machine interface. It is obtained by parsing user interface description data extracted from HMI design documents and UI tree sample files, extracting the core feature information of interface elements, and generating standardized interface entities. The target association relationships between entities are semantic correspondences formed based on vehicle functional logic among demand entities, signal entities, and interface entities. These relationships are used to clarify the association logic between different entities in the process of realizing vehicle functions. Based on the core attribute information of the three types of entities, the functional associations and logical correspondences between entities can be analyzed to determine the association types and corresponding logic between entities. For example, there is a "demand trigger signal" association between the demand entity "When the driver's seat temperature is set to 22 degrees Celsius, the interface displays the corresponding temperature" and the signal entity "HVAC driver's seat temperature setpoint signal". There is a "demand corresponding interface presentation" association between the demand entity and the interface entity "driver's seat temperature display text control". There is a "signal status drives interface update" association between the signal entity and the interface entity.

[0033] For example, firstly, data parsing tools can be used to structure the requirement description data, vehicle signal data, and user interface description data, extracting core information according to preset rules and generating standardized requirement entities, signal entities, and interface entities one by one. Subsequently, based on the logic of vehicle function implementation, the semantic associations and correspondences between various entities are analyzed to clarify the association types and logical rules between entities. Finally, the three types of entities and their associations corresponding to a single functional module are combined to form a single target ternary graph. Then, according to the actual needs of vehicle testing, multiple target ternary graphs are integrated according to dimensions such as functional modules and test scenarios to form a complete set of target ternary graphs, providing structured and clearly associated basic data support for the subsequent generation of candidate assertion sets.

[0034] By implementing step 102, a target ternary graph set is constructed based on the requirement description data, vehicle signal data, and user interface description data. The requirement entity, signal entity, and interface entity and their target association relationship are modeled in a unified manner, which helps to clarify the correspondence between different entities and express the originally scattered information in the same structure. This can improve the clarity and consistency of the expression of the relationship between test objects and reduce ambiguity in the process of requirement understanding and mapping.

[0035] Step 103: Based on the target ternary graph set, select a preset assertion template from the preset assertion template library and fill in the parameters to generate a candidate assertion set.

[0036] In some examples, the preset assertion template library is a structured database that stores various standardized preset assertion templates. It provides a reusable and logically unified template foundation for the generation of candidate assertions, improving the standardization level of assertion generation. The preset assertion template is a standardized assertion generation framework with fixed verification logic and parameter placeholders stored in the preset assertion template library. It is used to clarify the verification rule structure of assertions. Only specific parameters need to be filled in to generate executable assertion content. Based on the functional verification scenarios of vehicle testing (such as signal status verification, interface presentation verification, functional logic verification, etc.), various adapted assertion templates can be pre-designed, classified and organized according to verification type, vehicle functional modules, etc., and then stored in the database. For example, the preset assertion template library contains templates for functional modules such as vehicle air conditioning system, turn signal system, and window control system, as well as templates for different verification types such as signal threshold verification, interface text display verification, and functional timing verification. The whole is stored in a structured form to support quick retrieval according to search conditions.

[0037] The parameter filling process involves extracting the attribute information of the demand entity, signal entity, and interface entity from the target ternary graph set and filling it into the reserved parameter placeholders in the preset assertion template. This allows the standardized template to combine with specific entity information to generate targeted assertion content. The acquisition method involves extracting the attribute information corresponding to the parameter placeholders in the preset assertion template from the demand entity, signal entity, and interface entity of the target ternary graph set, and using this information as the specific parameters to be filled into the template. For example, information such as the temperature threshold range of 22 degrees Celsius ± 0.5 degrees Celsius and the signal stabilization duration of 300 milliseconds are extracted from the demand entity; information such as the signal name HVAC driver temperature setpoint signal and the refresh cycle of 10 Hz are extracted from the signal entity; and information such as the interface control identifier tv_temp_driver and the expected text content 22°C are extracted from the interface entity, and these are then matched with the parameter placeholders in the template for filling.

[0038] A candidate assertion set is a structured set of assertions composed of multiple pre-defined assertion templates with filled parameters. It provides a set of assertions to be screened and verified for subsequent testing and verification stages, and centrally carries the verification logic of various vehicle functions. For each target ternary graph in the target ternary graph set, after completing the selection of pre-defined assertion templates and parameter filling, all generated independent assertions are summarized and integrated according to functional modules, verification types, and other dimensions to form a structured candidate assertion set. For example, for the target ternary graph of the HVAC driver's seat temperature control function, multiple assertions are generated such as "when the value of the HVAC driver's seat temperature setpoint signal is within the range of 22 degrees Celsius ± 0.5 degrees Celsius and lasts for 300 milliseconds, the signal is determined to meet the verification requirements" and "when the requirement trigger condition of setting the driver's seat temperature to 22 degrees Celsius is met, the interface element corresponding to tv_temp_driver should display 22°C". These assertions are summarized with the assertions corresponding to functions such as window control and turn signal control to form a complete candidate assertion set.

[0039] By implementing step 103, an assertion template is selected from the preset assertion template library based on the target ternary graph set and parameters are filled in. This enables the automatic generation of a candidate assertion set based on entities and their relationships, reducing the reliance on manual experience to write test assertions, improving the automation level of assertion generation, and ensuring that the generated assertions maintain a unified standard in structure and content, thereby improving the matching between assertions and the functions of the vehicle under test.

[0040] Step 104: Test and verify the candidate assertion set to obtain the target assertion set used to test vehicle functions.

[0041] In some examples, test verification is the process of checking the validity and suitability of each assertion in the candidate assertion set. It can determine whether the assertion meets the expected requirements of vehicle functional testing, eliminate invalid, logically contradictory, or unsuitable assertions, and provide a screening basis for the formation of the subsequent target assertion set. It can use simulation data generated by the Vehicle Simulation System (VSS) or real operating data collected in actual vehicle testing to perform the verification operation according to the verification logic of each assertion, record the execution results of the assertions, and determine whether the preset pass conditions are met. For example, for the assertion in the candidate assertion set that "when the value of the driver's seat temperature setpoint signal of the vehicle air conditioning system is within the range of 22 degrees Celsius ± 0.5 degrees Celsius and lasts for 300 milliseconds, the signal is determined to meet the verification requirements", the vehicle simulation system is used to simulate the operating scenario of the driver's seat temperature set to 22 degrees Celsius, the corresponding HVAC driver's seat temperature setpoint signal data is collected, the assertion is executed, and it is determined whether the signal value meets the threshold requirements and whether the duration meets the standard, while recording the complete execution process data.

[0042] The target assertion set is a structured collection of assertions that, after testing and verification, meet the requirements of vehicle functional testing and possess validity and executability. It can be directly applied to the actual testing of various vehicle functions, providing accurate and unified verification basis for test execution. The target assertion set is configured with two delivery formats: a web-based visual management format for assertion retrieval, viewing, version management, and execution status monitoring; and a Python import library format for directly importing into automated test scripts and calling assertion logic. In other words, the target assertion set is ultimately delivered to testers in two forms: first, the web-based visual management format, where testers can retrieve, view, manage versions, and monitor execution status of assertions in the target assertion set through a web interface, completing basic operations without writing code; second, the Python import library format, where testers can directly import the pre-packaged assertion library corresponding to the target assertion set into automated test scripts, quickly calling various assertion logics to complete code-level test development.

[0043] For example, firstly, based on the vehicle functional modules covered by the candidate assertion set, corresponding simulation test data or real-world operational data collected from actual vehicles can be prepared to ensure that the data covers the verification scenarios and requirements of each assertion. Subsequently, the candidate assertion set and test data are loaded through an automated test execution tool, and each assertion is run one by one according to a preset execution order, recording the execution results of the assertions, relevant vehicle signal data, and user interface status data in real time. Finally, valid assertions are selected based on preset verification pass criteria (such as assertion execution results being consistent with expectations and without logical contradictions), and classified and organized according to dimensions such as vehicle functional modules and test scenarios to form a structurally standardized and logically clear target assertion set for testing vehicle functions, providing reliable support for the efficient conduct of vehicle function testing.

[0044] By implementing step 104, the candidate assertion set is tested and verified, and the target assertion set is obtained based on the verification results. Before the assertions are officially used in vehicle function testing, the candidate assertions can be screened and confirmed, avoiding invalid or unstable assertions from participating in actual testing. This can improve the reliability and effectiveness of the final target assertion set in vehicle function testing.

[0045] In summary, this application's embodiments simultaneously acquire requirement description data, vehicle signal data, and user interface description data, and construct a target ternary graph set containing requirement entities, signal entities, and interface entities based on these three types of data. This allows information originally scattered across different documents or systems to be uniformly represented in the same model. Leveraging the target association relationships between entities, the correspondence between requirements, vehicle signals, and interface performance can be clearly expressed, improving the accuracy and consistency of test object understanding. By selecting assertion templates from a preset assertion template library based on the target ternary graph set and filling in the parameters, a candidate assertion set can be automatically generated, avoiding complete reliance on manually written test assertions. This reduces the workload of manually writing assertions and minimizes errors caused by human misunderstanding or omissions. The assertion generation process is based on the target ternary graph, and the selection of assertion templates and parameter filling are all derived from... Based on demand entities, signal entities, and interface entities and their relationships, the generated candidate assertions can directly reflect the expected performance of vehicle functions at the signal and interface levels, improving the consistency and relevance between assertions and the functions under test. By testing and verifying the generated candidate assertion set and obtaining the target assertion set based on the verification results, the assertions themselves can be screened and confirmed before being formally used in vehicle function testing, reducing invalid or unstable assertions from entering the actual testing process and improving the reliability of the final target assertion set in vehicle function testing. By using a preset assertion template library and combining it with ternary graphs for assertion generation, the structure and generation method of the assertions have a certain degree of standardization and universality. When different demands, signal, or interface data change, assertions can be regenerated based on the same generation process, improving the reusability of test assertions in different testing scenarios. In summary, the test assertion generation method based on ternary graphs provided in this application constructs a unified ternary graph of requirements, vehicle signals, and user interface, and automatically generates and verifies test assertions based on a template-based approach. This achieves automation, standardization, and verifiability of test assertion generation, and can improve the consistency, reliability, and reusability of assertions with vehicle functions.

[0046] In some embodiments, step 102 may include: generating a demand entity containing a demand identifier and a first set of attributes based on demand description data; generating a signal entity containing a signal identifier and a second set of attributes based on vehicle signal data; generating an interface entity containing an interface element identifier and a third set of attributes based on user interface description data; determining the target association relationships between each pair of demand entities, signal entities, and interface entities based on preset matching rules; and constructing a target ternary graph set based on the target association relationships of demand entities, signal entities, interface entities, and targets.

[0047] In some examples, the process of generating requirement entities containing requirement identifiers and a set of first attributes based on requirement description data involves structured parsing of the requirement description data, extracting core information, and standardizing and encapsulating it. This transforms unstructured or semi-structured requirement descriptions into standardized data units with unique identifiers and fixed attributes. Requirement identifiers are standardized codes used to uniquely distinguish different requirement entities. They assign a unique identity to each requirement entity, ensuring accurate location, querying, and management of requirement entities within the target ternary graph set, avoiding confusion between different requirements. These identifiers can be automatically generated according to preset coding rules, which can be formulated in conjunction with information such as vehicle functional modules, requirement types, and vehicle models to ensure the uniqueness and readability of the identifiers. For example, for the requirement of driver's seat temperature control in a vehicle air conditioning system, the generated requirement identifier is R-HVAC-DRIVER-TEMP-001, where R represents the requirement, HVAC represents the functional module, DRIVER-TEMP represents the driver's seat temperature control scenario, and 001 is the sequence number. The first attribute set is a collection of attribute information from the requirement entity, excluding the requirement identifier, that describes the core characteristics of the requirement. It can fully present key information such as the requirement's objectives, constraints, and sources, providing data support for subsequent entity association and assertion generation. It can extract requirement-related information from the requirement description data, organize and classify it according to preset attribute categories, and form a standardized attribute set. For example, for the requirement description data "When the driver's area temperature is set to 22 degrees Celsius, the corresponding interface must accurately display this temperature value and the temperature control error must not exceed ±0.5 degrees Celsius", the extracted first attribute set includes the target description: "When the driver's area temperature is set to 22 degrees Celsius, the interface displays the corresponding temperature", the constraint condition: "Temperature control error ≤ ±0.5 degrees Celsius", the source: "Product Requirement Document (PRD) Section 3.2.1", and the keywords: "driver's area temperature, driver's area air vent temperature", etc.

[0048] The process of generating signal entities containing signal identifiers and a set of second attributes based on vehicle signal data involves parsing vehicle signal data, extracting technical parameters, and standardizing and encapsulating them. This transforms signal data scattered across DBC or automated test and verification markup language files into standardized data units with unique identifiers and fixed attributes. Signal identifiers are standardized codes used to uniquely distinguish different signal entities, assigning each entity a unique identity. This ensures accurate identification, association, and management of signal entities within the target ternary map set, preventing confusion between different vehicle signals. The identifiers can be automatically generated according to preset coding rules, which can be formulated based on information such as the signal's system, signal type, and functional scenario, ensuring the uniqueness and relevance of the identifier. For example, for the HVAC driver's side temperature setpoint signal, the generated signal identifier is S-HVAC-DRIVER-TEMP-SP, where S represents signal, HVAC represents the system, and DRIVER-TEMP-SP represents the driver's side temperature setpoint scenario. The second attribute set is a collection of attribute information in a signal entity, excluding the signal identifier, that describes the technical characteristics of the vehicle signal. It can fully present key information such as the signal's technical parameters and control logic, providing accurate data for entity association and subsequent assertion parameter filling. It can extract signal-related technical information from vehicle signal data, organize and classify it according to preset attribute categories, and form a standardized attribute set. For example, the second attribute set of HVAC driver's temperature setpoint signal data extracted from the database description file includes attributes such as signal name HVAC_DriverTemp_Setpoint, message identifier 0x5A1, unit degrees Celsius, value range 16 to 32 degrees Celsius, refresh cycle 10 Hz, and resolution 0.5 degrees Celsius per bit.

[0049] The process of generating interface entities containing interface element identifiers and a set of third attributes based on user interface description data involves structured parsing of the user interface description data, extracting key information of interface elements, and standardizing and encapsulating it. This transforms interface element information from HMI design documents and UI tree samples into standardized data units with unique identifiers and fixed attributes. Interface element identifiers are standardized codes used to uniquely distinguish different interface entities. They assign a unique identity to each interface entity, ensuring accurate location, association, and management of interface entities within the target ternary graph set, avoiding confusion between different interface elements. These identifiers can be automatically generated according to preset coding rules, which can be formulated based on information such as the human-computer interaction interface functional module, interface element type, and region, ensuring the uniqueness and recognizability of the identifiers. For example, for an HVAC driver's side temperature display text control, the generated interface element identifier is U-HVAC-DRIVER-TEMP-TEXT, where U represents the User Interface, HVAC represents the functional module, and DRIVER-TEMP-TEXT represents the driver's side temperature display text control type. The third attribute set is a collection of attribute information in the interface entity that describes the characteristics of the interface element, excluding the interface element identifier. It can fully present the key information such as the control attributes, presentation requirements, and positioning methods of the interface element, providing detailed data support for entity association and assertion generation. It can extract core information related to the interface element from the user interface description data, organize and classify it according to preset attribute categories, and form a standardized attribute set. For example, the third attribute set of the driver's temperature display text control related data extracted from the HMI design document includes the control identifier tv_temp_driver, the hierarchical path HVAC interface - driver's control area - temperature display module, the expected display text 22°C, the visibility status visible, the screenshot positioning method control tree value, and the stability judgment rule text that does not change for 200 milliseconds as stable, etc.

[0050] Pre-defined matching rules are standardized criteria used to determine whether and what type of association exists between demand entities, signal entities, and interface entities. They provide a unified and reusable basis for determining relationships between entities, ensuring the accuracy and consistency of these relationships. These rules can be pre-defined by technical personnel based on the logic of vehicle function implementation, the attribute characteristics of each entity, and the actual needs of vehicle testing. Rules can be formulated separately according to the type of entity association (demand and signal, demand and interface, signal and interface). For example, pre-defined matching rules include: functional semantic matching rules (when the target description of a demand entity is consistent with the signal functional semantics of a signal entity, they are considered to be related); keyword correspondence rules (when the keywords of an interface entity and the keywords of a demand entity have a complete match or synonymous correspondence, they are considered to be related); and functional dependency rules (when changes in the signal of a signal entity directly lead to state updates in an interface entity, they are considered to be related).

[0051] The process of determining the target association relationships between each pair of demand entities, signal entities, and interface entities based on preset matching rules involves applying preset standardization criteria to analyze the attributes of the three types of entities and clarify the association logic between them. First, the core attributes of demand entities, signal entities, and interface entities (such as the target description of the demand, the functional purpose of the signal, and the presentation target of the interface) can be extracted. Then, each type of entity is paired and verified one by one using preset matching rules. Finally, combinations that conform to the rules are identified as having an association relationship, and the association type is determined. For example, combining demand entity R-HVAC-DRIVER-TEMP-001 with signal entity S-HVAC-DRIVER-TEMP-SP and applying functional semantic matching rules reveals that the target description of the demand entity, "driver's seat temperature set to 22 degrees Celsius," is semantically consistent with the signal function of the signal entity, "driver's seat temperature setpoint control," indicating a demand-triggered signal association relationship. Combining this demand entity with interface entity U-HVAC-DRIVER-TEMP-TEXT and applying keyword matching rules reveals that the keyword "driver's seat temperature" is a perfect match, indicating a target association relationship between the two.

[0052] The process of constructing a target ternary graph set based on demand entities, signal entities, interface entities, and target relationships involves structurally integrating standardized entities of three types with clear relationships to form a reusable and clearly related graph set. This allows for the combination of closely related entities and relationships into individual target ternary graphs according to vehicle functional modules or test scenarios, which are then aggregated into a set. The process can begin by classifying demand entities, signal entities, and interface entities according to vehicle functional modules (e.g., HVAC system, turn signal system, window control system). Then, within each functional module, entities of the three types with target relationships and their corresponding relationships are linked and bound, forming a target ternary graph for that single functional module. Finally, the target ternary graphs of all functional modules are integrated according to preset dimensions (e.g., test scenario, vehicle model version) to form a complete target ternary graph set. For example, in the HVAC system functional module, the demand entity R-HVAC-DRIVER-TEMP-001, signal entity S-HVAC-DRIVER-TEMP-SP, and interface entity U-HVAC-DRIVER-TEMP-TEXT are combined. The relationships between the three are bound together to form a target ternary graph corresponding to the HVAC driver's temperature control; similarly, target ternary graphs corresponding to HVAC passenger's temperature control, air conditioning mode switching and other functions are constructed. These graphs are then integrated to form a subset of the target ternary graph corresponding to the HVAC system. Finally, the graph subsets of other systems are combined to form a complete set of target ternary graphs.

[0053] Through the implementation of the above embodiments, the requirement description data, vehicle signal data, and user interface description data are abstracted into requirement entities, signal entities, and interface entities with clear identifiers and attribute sets, respectively. Furthermore, the target association relationships between entities are determined, enabling the test-related information that was originally scattered in different documents and systems to achieve a structured and standardized expression. This helps to clearly define the correspondence between requirements, signals, and interfaces, improve the consistency of assertion generation basis, and provide a stable data foundation for the automatic updating and maintenance of subsequent assertions, thereby improving overall maintainability.

[0054] In some embodiments, the aforementioned determination of the target association between each pair of demand entities, signal entities, and interface entities based on preset matching rules may include: generating a candidate association set based on keyword matching, alias matching, or semantic similarity matching, wherein the candidate association set may include candidate associations between each pair of demand entities, signal entities, and interface entities, and the confidence level of each candidate association; and determining the candidate associations in the candidate association set whose confidence level is higher than a preset confidence threshold as the target associations.

[0055] In some examples, keyword matching involves extracting key information from the core attributes of demand entities, signal entities, and interface entities for precise comparison to determine the matching method for potential relationships between entities. This method can quickly identify highly related entity pairs based on clear core keyword correspondences. Extraction rules for core entity attributes can be pre-defined (such as the target description of demand entities, the signal name of signal entities, and the control function description of interface entities). Core keywords are extracted from each entity, and then a complete or partial keyword matching rule is used to determine whether a relationship exists between entities. For example, the keyword "driver's seat temperature" is extracted from the target description of the demand entity, "When the driver's seat temperature is set to 22 degrees Celsius, the corresponding temperature is displayed on the interface," and the keyword "driver's seat temperature" is extracted from the signal name of the signal entity, "HVAC driver's seat temperature setpoint signal." Through complete keyword matching, a candidate relationship between the demand entity and the signal entity is determined.

[0056] Alias ​​matching is based on a pre-built entity alias mapping table. It identifies the matching methods of entity associations by mapping the common aliases of an entity to the core words of other entities. It can solve the problem of identifying associations between entities with different names but the same meaning. It can collect common aliases of various entities in the vehicle testing field and establish a structured alias mapping table (including the standard name of the entity, the name of each category and the corresponding relationship). During the matching process, the core words of the entity are compared with the contents of the alias mapping table to determine whether there is an alias correspondence. For example, the alias mapping table records "driver's seat vent temperature" and "Driver Temperature" as aliases of "driver's seat temperature". The keyword "driver's seat vent temperature" extracted from the demand entity is successfully matched with the standard keyword "driver's seat temperature" extracted from the signal entity through the alias mapping table, and it is determined that there is a candidate association relationship between the two.

[0057] Semantic similarity matching utilizes Natural Language Processing (NLP) technology to calculate the semantic similarity of the core descriptive texts of demand entities, signal entities, and interface entities to identify the associations between entities. It can solve the problem of identifying semantically related entities without explicit keywords or aliases. Pre-trained semantic models, such as Bidirectional Encoder Representations from Transformers (BERT), can be used to convert the core descriptive texts of entities (such as the target description of the demand entity and the functional description of the interface entity) into semantic vectors. By calculating metrics such as cosine similarity between vectors, a semantic similarity score is obtained between entities. For example, if the target description of the demand entity is "adjust the driver's seat temperature to 22 degrees Celsius," and the functional description of the interface entity is "real-time display of the driver's seat area temperature," the cosine similarity score of their semantic vectors calculated using the BERT model is 0.85, indicating a high semantic correlation and a potential association relationship.

[0058] The candidate association set is generated through keyword matching, alias matching, or semantic similarity matching. It is a structured data set containing all candidate associations and corresponding confidence levels between any two demand entities, signal entities, and interface entities. It can provide complete candidate criteria for screening target associations. For example, the candidate association set contains multiple candidate association records, such as the association between demand entity R-HVAC-DRIVER-TEMP-001 and signal entity S-HVAC-DRIVER-TEMP-SP (matching method: keyword matching, confidence level 0.92), the association between this demand entity and interface entity U-HVAC-DRIVER-TEMP-TEXT (matching method: semantic similarity matching, confidence level 0.85), and the association between signal entity S-HVAC-DRIVER-TEMP-SP and this interface entity (matching method: alias matching, confidence level 0.88).

[0059] A pre-set reliability threshold is a critical value set in advance to determine whether a candidate association is valid. It can filter out reliable candidate associations and eliminate low-confidence associations to ensure the accuracy of the target association. The pre-set reliability threshold can be set based on historical association data in the vehicle testing field, the actual verification effect of entity associations, and engineering experience. This pre-set reliability threshold can be flexibly adjusted according to the needs of different vehicle functional modules or testing scenarios. For example, based on the verification experience of vehicle air conditioning system test data, the pre-set reliability threshold can be set to 0.8, that is, candidate associations with a confidence level higher than 0.8 are judged as reliable associations, while associations lower than this threshold are considered as low-confidence associations.

[0060] By implementing the above embodiments, keyword matching, alias matching, or semantic similarity matching mechanisms are introduced to automatically generate candidate associations with confidence levels. Target associations are then filtered based on pre-set confidence thresholds. This reduces the workload of manually establishing demand, signal, and interface mapping relationships. While improving the efficiency of association construction, the confidence filtering mechanism reduces the probability of erroneous associations entering the graph, thereby improving the quality of the ternary graph from the source and enhancing the reliability and consistency of the generated test assertions.

[0061] In some embodiments, step 103 may include: determining a preset assertion template from a preset assertion template library based on the target association relationships in the aforementioned target ternary graph set; filling preset parameters into the preset assertion template based on at least one of the first attribute set, the second attribute set, and the third attribute set to obtain a structured assertion, wherein the preset parameters may include at least one of a threshold, a time window, and a retry strategy; generating assertion scripts based on the structured assertions, and binding a matching version tag to each assertion script to obtain a candidate assertion set.

[0062] In some examples, preset parameters are filled into preset assertion templates, which can clearly define the specific configuration information of assertion verification logic, execution conditions and constraint standards. This allows standardized templates to be combined with actual entity attributes to form targeted verification rules. Attribute information corresponding to the preset assertion template parameter placeholders can be extracted from the first attribute set of the demand entity, the second attribute set of the signal entity, and the third attribute set of the interface entity. For example, information such as temperature control error and signal stabilization duration can be extracted from the first attribute set of the demand entity, signal refresh cycle and numerical range can be extracted from the second attribute set of the signal entity, and interface update time limit can be extracted from the third attribute set of the interface entity. All of these can serve as sources for preset parameters.

[0063] A threshold is a type of preset parameter, used in assertion verification to determine whether an entity's state meets requirements. It clarifies the criteria for assertion acceptance, avoiding fuzzy verification. For example, in a temperature verification scenario for a vehicle air conditioning system, a threshold of 22 degrees Celsius ± 0.5 degrees Celsius is extracted from the first attribute set of the requirement entity; for signal stability verification, a signal fluctuation threshold of ± 0.1 degrees Celsius is extracted from the second attribute set of the signal entity. A time window is also a type of preset parameter, representing the time range within which the state of a relevant entity is allowed to change or meet conditions in assertion verification. It defines the time constraints for assertion execution, ensuring that the verification logic conforms to the actual response characteristics of vehicle functions. For example, a time window parameter of 500 milliseconds is extracted from the first attribute set of the requirement entity to indicate that "the interface must be updated within 500 milliseconds after the signal stabilizes"; a time window parameter of 100 milliseconds is extracted from the second attribute set of the signal entity to indicate that "the signal must reach a stable state within 100 milliseconds." The retry strategy is also a type of preset parameter. It is a rule configuration for retrying an assertion after it fails. It can avoid false assertions caused by instantaneous data fluctuations or accidental failures, and improve the stability of assertion verification. For example, the retry strategy can be set to retry twice after the first failure of an assertion, with an interval of 300 milliseconds; or for critical signal verification, the retry strategy can be set to retry three times after a failure with an interval of 500 milliseconds, to ensure coverage of instantaneous fluctuation scenarios.

[0064] Structured assertions are non-executable assertion statements with a fixed format and complete logic, formed by filling preset parameters into a preset assertion template. They clearly define the verification target, conditions, and judgment criteria of the assertion, providing a structured foundation for the subsequent generation of executable assertion scripts. The extracted preset parameters can be filled into the corresponding parameter placeholders according to the logical framework of the preset assertion template and organized in a standardized format. For example, if the preset assertion template is "When the value of [signal name] is within the range of [threshold] and remains stable for [duration], then [interface control] needs to present the [desired state] within the [time window]", the following parameters can be extracted from the second attribute set of the signal entity: HVAC driver temperature setpoint signal and threshold 22 degrees Celsius ± 0.5 degrees Celsius; from the first attribute set of the demand entity: stable duration 300 milliseconds and time window 500 milliseconds; and from the third attribute set of the interface entity: interface control tv_temp_driver and the desired state display 22°C text. Filling these parameters into the template forms a logically complete structured assertion.

[0065] Assertion scripts are sets of code snippets or instructions generated from structured assertions that can be directly executed in the test environment. They can transform the verification logic of structured assertions into machine-readable and executable operations, enabling automated verification. Script generation tools can convert the fixed logic and preset parameters of structured assertions into code formats (such as Python, Lua, etc.) that meet the requirements of the test execution environment. For example, for the structured assertion of the HVAC driver's temperature control mentioned above, the generated assertion script is a Python code snippet containing signal value judgment, duration statistics, interface status detection, and retry logic, which can be run directly in automated testing tools.

[0066] The process of binding a matching version tag to each assertion script is to establish an association between the assertion script and the corresponding version information. The matching version tag is used to identify the vehicle-related version information that the assertion script is adapted to, which can clarify the scope of application of the assertion and facilitate version management and cross-version reuse. Information such as vehicle model, software version, and human-machine interface version can be extracted from the attribute set of requirement entity, signal entity, or interface entity and integrated in a standardized format. For example, the matching version tag is "Vehicle Model A - Software Version V1.2 - HMI Version V2.0", which indicates that the assertion script is only applicable to software version V1.2 and the corresponding HMI version V2.0 of vehicle model A.

[0067] For example, firstly, preset parameters such as thresholds, time windows, and retry strategies can be accurately extracted from the first attribute set of the demand entity, the second attribute set of the signal entity, and the third attribute set of the interface entity corresponding to the target ternary graph set. These parameters are then filled in according to the logical framework of the preset assertion template to form a structured assertion with a unified format and clear logic. Subsequently, the verification logic and parameter configuration of the structured assertion are parsed using a script generation tool and transformed into an assertion script adapted to the vehicle automated testing environment, ensuring that the script can be directly executed and has no logical deviation. Finally, each assertion script is bound with matching version tags such as vehicle model and software version extracted from the entity attributes. All assertion scripts are classified and organized according to vehicle functional modules to form a complete set of candidate assertions, providing executable and traceable basic resources for subsequent testing and verification.

[0068] Through the implementation of the above embodiments, based on the association relationship in the target ternary graph, a matching assertion template is automatically selected from the preset assertion template library, and parameters such as threshold, time window, and retry strategy are filled in in combination with the entity attribute set to generate structured assertions and corresponding assertion scripts. This makes the structure and parameter sources of test assertions have unified rules, avoiding the problems of inconsistent format and arbitrary parameter configuration when manually writing assertions. At the same time, the manageability of assertions under different vehicle models or software versions is improved by binding version tags, which can improve the problems of poor assertion consistency and high maintenance costs.

[0069] In some embodiments, determining the preset assertion template from the preset assertion template library based on the target association relationships in the target ternary graph set may include: traversing the demand entities in the target ternary graph set and determining the entity attributes associated with the current demand entity; if it is determined that the current demand entity is associated with both a signal entity and an interface entity, then the preset assertion template may include a time-series causal template and a consistency template; if it is determined that the current demand entity is associated with a signal entity but not with any interface entity, then the preset assertion template is determined to be a signal threshold template or a signal steady-state template; if it is determined that the current demand entity is associated with an interface entity but not with any signal entity, then the preset assertion template is determined to be an interface text verification template or an interface state verification template.

[0070] In some examples, each demand entity in the target ternary graph set can be accessed one by one according to preset rules. By parsing the target association relationships recorded in the target ternary graph, it can be determined whether the current demand entity is associated with signal entities, interface entities, and the type of associated entities. The current demand entity is the single demand entity being processed and analyzed during the traversal of demand entities in the target ternary graph set. It can be used as the object for association attribute judgment, providing a targeted basis for the accurate selection of preset assertion templates. The demand entities in the target ternary graph set can be extracted one by one according to a preset order (such as functional module priority, entity identifier sorting) using a graph traversal tool. The demand entity that is currently extracted and in the analysis state is the current demand entity. For example, if the target ternary graph set contains demand entities of multiple functional modules such as vehicle air conditioning system and turn signal system, when the traversal tool extracts the demand entity identified as R-HVAC-DRIVER-TEMP-001, this demand entity is the current demand entity.

[0071] The template selection logic can be based on the compatibility of the current demand entity's associated scenarios and template functions, ensuring that the selected templates can fully cover the timing constraints and consistency verification requirements under the "demand-signal-interface" associated scenarios. The timing causal template is a standardized template stored in the preset assertion template library, which can verify the time logic relationship of "the change of the state of the cause entity triggers the update of the state of the consequence entity". It can clarify the timing constraints between two associated entities and ensure that the response of the vehicle function meets the expected time requirements. For example, the timing causal template is expressed as "when the [cause entity] meets the [state condition], the [cause entity] needs to reach the [target state] within the [time window]", which is suitable for timing scenarios such as verifying the interface update after the signal is triggered and the signal response after the operation is triggered. Consistency templates are standardized templates stored in a pre-defined assertion template library that can verify that the state, values, or frequencies of related entities are consistent. They can ensure that the behavior of related entities conforms to unified logic and avoid contradictory states. For example, a consistency template can be expressed as "The deviation between the [feature parameter] of [entity A] and the [corresponding feature parameter] of [entity B] does not exceed the [allowable deviation range]", which is suitable for verifying the consistency between signal values ​​and displayed values ​​on the interface, signal frequencies and the blinking frequency of interface elements, etc.

[0072] If it is determined that the current requirement entity is associated with a signal entity but not with any interface entity, then the process of determining the preset assertion template as a signal threshold template or a signal steady-state template is based on the logic of selecting templates for functional verification requirements in a single "requirement-signal" association scenario. This logic can comprehensively verify whether the signal entity meets the requirement constraints through threshold and steady-state judgments. The signal threshold template is a standardized template stored in the preset assertion template library that can verify whether the value of a signal entity is within a preset numerical range. It can clearly define the acceptable numerical boundaries of the signal entity, ensuring that the signal state meets the requirement constraints. For example, the signal threshold template is expressed as "The value of [signal entity name] must be within [threshold range]", which is suitable for scenarios verifying the compliance of numerical signals such as temperature and voltage signals. The signal steady-state template is a standardized template stored in the preset assertion template library. It can verify that the value of a signal entity remains stable within a preset time and does not exceed the allowable fluctuation range. It can ensure the stability of the signal state and avoid functional abnormalities caused by instantaneous fluctuations. For example, the expression of the signal steady-state template is "[signal entity name]'s value remains stable within [threshold range] for [steady-state duration]", which is suitable for verifying signal scenarios that need to remain stable, such as HVAC temperature signals and vehicle speed signals.

[0073] If it is determined that the current requirement entity is associated with an interface entity but not with any signal entity, then the process of determining the preset assertion template as either the interface text verification template or the interface state verification template is based on the logic of selecting templates for functional verification requirements in a single "requirement-interface" association scenario. This logic comprehensively covers the presentation requirements of interface entities through text verification and state verification, ensuring that the interface performance conforms to the requirement description. The interface text verification template is a standardized template stored in the preset assertion template library that verifies whether an interface entity displays preset text content. It clearly defines the text presentation requirements of the interface entity, ensuring that the interface text conforms to the requirement description. For example, the interface text verification template might state "[interface control identifier] corresponding to the interface element must display [expected text content]", suitable for scenarios verifying the accuracy of interface text such as temperature display text and fault prompt text. Interface state verification templates are stored in the preset assertion template library. They are standardized templates that can verify whether the non-text attributes of interface entities, such as visibility, lit state, and blinking state, meet preset requirements. They can cover other state verification needs of interface entities besides text, ensuring that the interface presentation meets functional expectations. For example, the interface state verification template is described as "[interface control identifier] The interface element corresponding to it must be in the [expected state]", where the expected state can include visible, hidden, lit, blinking, etc., which is suitable for verifying the state scenarios of interface elements such as turn signal icons and air conditioning mode icons.

[0074] By implementing the above embodiments, the system traverses requirement entities and automatically selects different types of assertion templates based on their associated signal and interface entity types. This ensures that the assertion template selection process matches the vehicle functional testing scenario. For example, requirements that are associated with both signals and interfaces automatically generate time-series causality and consistency assertions, while requirements that are associated with only signals or interfaces generate corresponding single-type assertions. This strategy reduces the reliance on manual template type judgment and avoids assertion failures or insufficient coverage caused by improper template selection, thereby improving the accuracy and reliability of assertion generation.

[0075] In some embodiments, step 104 may include: executing the candidate assertions in the candidate assertion set multiple times to obtain the execution result of each candidate assertion, wherein the execution result may include at least one of pass rate, log data, interface screenshot data and signal curve data; and based on the execution result, selecting candidate assertions that meet preset requirements from the candidate assertion set to obtain the target assertion set.

[0076] In some examples, candidate assertion sets can be loaded using automated testing tools. Each candidate assertion can be executed repeatedly a preset number of times in a vehicle simulation system or real-vehicle testing environment, simultaneously collecting various relevant data during the execution process, ultimately forming a unique execution record for each assertion. Alternatively, an automated testing execution tool can be configured to import the candidate assertion set, setting the execution number for each assertion (e.g., 5 or 10 times). A vehicle simulation environment or a real vehicle equipped with the target software version can be selected as the execution platform. After starting the tool, each assertion is executed sequentially according to a preset order, automatically collecting various data and associating them with the corresponding assertion during execution. For example, for the assertion "When the HVAC driver's seat temperature setpoint signal value is within the range of 22 degrees Celsius ± 0.5 degrees Celsius and lasts for 300 milliseconds, the tv_temp_driver control displays 22°C" in the candidate assertion set, the automated testing tool can execute it 10 times in a vehicle simulation system. Each execution simulates the driver's seat temperature setting operation, simultaneously collecting relevant data during the execution process, ultimately obtaining a complete data record corresponding to the 10 executions of this assertion. The execution results are a collection of various data that reflect the execution status and verification effect of the candidate assertions after multiple executions. This data can provide a comprehensive and objective basis for subsequent selection of target assertions. For example, the execution results of a certain HVAC-related candidate assertion include a 90% pass rate for 10 executions, timestamps of each execution, step logs, HMI screenshots of 3 key execution nodes, time-series change curves of the driver's seat temperature signal, and records of the reasons for failure in 2 executions that failed.

[0077] The pass rate is the proportion of executions that satisfy the verification requirements out of the total number of executions of a candidate assertion. It quantifies the stability and effectiveness of the assertion and reflects its reliability in repetitive execution scenarios. It can be calculated using the formula: "Pass rate = Number of successful executions ÷ Total number of executions × 100%". Log data is the detailed execution trajectory information recorded by the automated testing tool during the execution of candidate assertions. It can trace every step of the assertion execution, state changes, and anomalies, providing a basis for analyzing the reasons for assertion success or failure. During assertion execution, the automated testing tool can record execution time, operation steps, involved entity identifiers, parameter values, and execution result judgment criteria in real time according to preset log levels (such as information level, warning level, and error level), forming a structured log file. Interface screenshot data consists of image data captured from the vehicle's human-machine interface during candidate assertion execution. It visually presents the interface state during assertion execution and verifies whether interface elements meet preset requirements. Automated screenshot tools can be used to capture screenshots of the HMI according to preset rules (e.g., at the start of execution, key verification nodes, or at the end of execution) or triggered actions (e.g., when the signal reaches a threshold or when the interface state changes). The image data is then stored after being associated with the assertion ID and execution timestamp. Signal curve data consists of time-series data curves showing the changes in vehicle signals over time during candidate assertion execution. It visually reflects the changes in vehicle signal values, stable states, and response speeds, verifying whether the signals meet the assertion's constraints. Signal acquisition tools (e.g., signal parsing tools based on database description files) can be used to collect vehicle signal data related to the assertion at a preset sampling frequency (e.g., not less than 20 Hz), converting the collected time-series data into visual curves and storing them.

[0078] The execution results of each candidate assertion can be compared one by one with the preset requirements. Assertions that do not meet the requirements are eliminated, and those that meet the requirements are retained and standardized. The preset requirements are standardized judgment conditions used to screen candidate assertions. They can clarify the basic requirements that the target assertions must meet, ensuring that the screened assertions have effectiveness, stability, and adaptability, and can be directly applied to vehicle functional testing. Quantitative or qualitative judgment conditions can be set based on the project requirements of vehicle testing, industry testing specifications, and reliability standards for functional verification. These conditions can be flexibly adjusted according to the assertion type (signal type, interface type, etc.). For example, the preset requirements for signal-type candidate assertions are a pass rate of not less than 95%, no serious error records in the log data, and signal curve data showing that the signal stability duration meets the constraints. The preset requirements for interface-type candidate assertions are a pass rate of not less than 90%, clear interface screenshot data that meets the expected presentation state, and no interface response timeout related logs.

[0079] By implementing the above embodiments, candidate assertions are executed multiple times, and the results are filtered based on the pass rate, logs, interface screenshots, and signal curves. This allows the test assertions to complete stability and validity verification before being put into actual vehicle functional testing. This effectively filters out assertions with logical errors or that are unstable in actual operation, reduces false alarms and false negatives during the testing process, and improves the reliability and credibility of the final target assertion set in vehicle functional testing.

[0080] In some embodiments, the aforementioned method may further include: if at least one of the demand description data, vehicle signal data, and user interface description data changes, then obtaining the entities and relationships affected by the change; and updating the target ternary graph set based on the entities and relationships affected by the change, so as to update and re-verify the affected assertions in the target assertion set.

[0081] In some examples, the entities and relationships affected by the change are the demand entities, signal entities, and interface entities directly or indirectly associated with the changed data when any type of data—demand description data, vehicle signal data, or user interface description data—is changed, as well as the original target relationships between these entities. Data comparison tools can be used to compare the changed data with the original data before the change item by item to identify the specific content of the data change. Then, based on the binding relationships between entities and data and the target relationships between entities in the target ternary graph set, the entities and relationships directly related to the changed content can be traced and filtered out. For example, production... The requirement description data in the product requirement document has changed. The error threshold for the driver's seat temperature control has been adjusted from ±0.5 degrees Celsius to ±0.8 degrees Celsius. After identifying the change through a data comparison tool, the data was traced back to the corresponding requirement entity R-HVAC-DRIVER-TEMP-001 in the target ternary graph, as well as the "requirement trigger signal" and "requirement corresponding interface presentation" relationships between this requirement entity and the signal entity S-HVAC-DRIVER-TEMP-SP and the interface entity U-HVAC-DRIVER-TEMP-TEXT. These entities and relationships are the entities and relationships affected by the change.

[0082] The process of updating the target ternary graph set based on the entities and relationships affected by the changes, and then updating and re-validating the affected assertions in the target assertion set, involves adjusting the corresponding content in the target ternary graph set based on the affected entities and relationships, locating the assertions in the target assertion set that are bound to these entities and relationships, updating their parameters or logic, and then re-executing the verification. This can be done by first modifying the attribute information of the corresponding entities and the logical descriptions of the relationships in the target ternary graph set according to the affected entities and relationships to ensure that the graph is consistent with the changed data; then, based on the "entity-relationship-assertion" binding mapping, filtering out the assertions associated with the affected entities or relationships from the target assertion set; next, adjusting the parameters (such as thresholds, time windows) or verification logic of these assertions according to the updated graph content; and finally, placing the updated assertions in a test environment for re-verification to confirm their effectiveness.

[0083] Through the implementation of the above embodiments, when requirements, signals, or interfaces change, only the affected entities, relationships, and corresponding assertions are identified and updated, rather than the entire assertion set is rebuilt. This transforms assertion maintenance from "full modification" to "differentiated update." This change awareness and local update mechanism based on ternary graphs can reduce the assertion maintenance cost in scenarios with frequent iterations of vehicle software, improve the assertion system's adaptability to changes in requirements and versions, and thus enhance the maintainability of test assertions.

[0084] Furthermore, as an implementation of the aforementioned method embodiments, this application also provides a test assertion generation device based on ternary graphs, capable of implementing the aforementioned method embodiments. This device embodiment corresponds to the aforementioned method embodiments. For ease of reading, this embodiment of the test assertion generation device based on ternary graphs will not repeat the details of the aforementioned method embodiments one by one, but it should be clear that the device in this application embodiment can correspondingly implement all the content of the aforementioned method embodiments. For example... Figure 2As shown, the test assertion generation device 20 based on ternary graphs includes: a data acquisition unit 201, a graph construction unit 202, a candidate assertion generation unit 203, and a target assertion generation unit 204. The data acquisition unit 201 acquires requirement description data, vehicle signal data, and user interface description data. The graph construction unit 202 constructs a target ternary graph set based on the aforementioned requirement description data, vehicle signal data, and user interface description data. The target ternary graph set may include at least one target ternary graph, which contains requirement entities, signal entities, interface entities, and target relationships between these entities. The candidate assertion generation unit 203 selects a preset assertion template from a preset assertion template library and fills in parameters based on the target ternary graph set to generate a candidate assertion set. The target assertion generation unit 204 tests and verifies the candidate assertion set to obtain a target assertion set used for testing vehicle functions.

[0085] In some embodiments, the graph construction unit 202 is further configured to generate a demand entity containing a demand identifier and a first set of attributes based on demand description data; generate a signal entity containing a signal identifier and a second set of attributes based on vehicle signal data; generate an interface entity containing an interface element identifier and a third set of attributes based on user interface description data; determine the target association relationships between each pair of demand entities, signal entities, and interface entities based on preset matching rules; and construct a target ternary graph set based on the target association relationships of demand entities, signal entities, interface entities, and targets.

[0086] In some embodiments, the graph construction unit 202 is further configured to generate a candidate association set based on keyword matching, alias matching, or semantic similarity matching, wherein the candidate association set includes candidate associations between each pair of demand entities, signal entities, and interface entities, and the confidence level of each candidate association; and to determine the candidate associations in the candidate association set whose confidence level is higher than a preset confidence threshold as target associations.

[0087] In some embodiments, the candidate assertion generation unit 203 is further configured to determine a preset assertion template from a preset assertion template library based on the target association relationship in the target ternary graph set; fill the preset assertion template with preset parameters based on at least one of the first attribute set, the second attribute set, and the third attribute set to obtain a structured assertion, wherein the preset parameters include at least one of a threshold, a time window, and a retry strategy; generate assertion scripts based on the structured assertions, and bind a matching version tag to each assertion script to obtain a candidate assertion set.

[0088] In some embodiments, the candidate assertion generation unit 203 is further configured to traverse the demand entities in the target ternary graph set and determine the entity attributes associated with the current demand entity; if it is determined that the current demand entity is associated with both a signal entity and an interface entity, then the preset assertion template is determined to include a temporal causal template and a consistency template; if it is determined that the current demand entity is associated with a signal entity but not with any interface entity, then the preset assertion template is determined to be a signal threshold template or a signal steady-state template; if it is determined that the current demand entity is associated with an interface entity but not with any signal entity, then the preset assertion template is determined to be an interface text verification template or an interface state verification template.

[0089] In some embodiments, the target assertion generation unit 204 is further configured to execute the candidate assertions in the candidate assertion set multiple times to obtain the execution result of each candidate assertion, wherein the execution result includes at least one of pass rate, log data, interface screenshot data and signal curve data; based on the execution result, candidate assertions that meet preset requirements are selected from the candidate assertion set to obtain the target assertion set.

[0090] In some embodiments, the target assertion generation unit 204 is further configured to, if at least one of the demand description data, vehicle signal data, and user interface description data changes, obtain the entities and relationships affected by the change; and update the target ternary graph set based on the entities and relationships affected by the change, so as to update and re-verify the affected assertions in the target assertion set.

[0091] This application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, which, when executed by a processor, will cause the processor to perform any step of the test assertion generation method based on ternary graphs provided in this application.

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

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

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

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

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

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

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

Claims

1. A test assertion generation method based on ternary graphs, characterized in that, include: Acquire requirement description data, vehicle signal data, and user interface description data; Based on the demand description data, the vehicle signal data, and the user interface description data, a target ternary graph set is constructed, wherein the target ternary graph set includes at least one target ternary graph, and the target ternary graph contains demand entities, signal entities, interface entities, and target association relationships between each entity; Based on the target ternary graph set, a preset assertion template is selected from the preset assertion template library and parameters are filled in to generate a candidate assertion set; The candidate assertion set is tested and verified to obtain the target assertion set used for testing vehicle functions.

2. The method according to claim 1, characterized in that, The construction of a target ternary map set based on the demand description data, the vehicle signal data, and the user interface description data includes: Based on the requirement description data, a requirement entity containing a requirement identifier and a first set of attributes is generated; Based on the vehicle signal data, a signal entity containing a signal identifier and a second set of attributes is generated; Based on the user interface description data, an interface entity containing interface element identifiers and a third set of attributes is generated; Based on preset matching rules, the target association relationships between each pair of the demand entity, the signal entity, and the interface entity are determined. Based on the relationship between the demand entity, the signal entity, the interface entity, and the target, the target ternary graph set is constructed.

3. The method according to claim 2, characterized in that, The step of determining the target association relationships between each pair of the demand entity, the signal entity, and the interface entity based on preset matching rules includes: Based on keyword matching, alias matching, or semantic similarity matching, a candidate association set is generated, wherein the candidate association set includes the candidate associations between each pair of the demand entity, the signal entity, and the interface entity, and the confidence level of each candidate association. Candidate associations in the candidate association set whose confidence level is higher than the preset confidence threshold are identified as the target associations.

4. The method according to claim 2, characterized in that, The step of generating a candidate assertion set by selecting a preset assertion template from a preset assertion template library and filling in parameters based on the target ternary graph set includes: Based on the target association relationships in the target ternary graph set, a preset assertion template is determined from the preset assertion template library; Based on at least one of the first attribute set, the second attribute set, and the third attribute set, preset parameters are filled into the preset assertion template to obtain a structured assertion, wherein the preset parameters include at least one of a threshold, a time window, and a retry strategy; Based on the structured assertions, assertion scripts are generated, and a matching version tag is bound to each assertion script to obtain the candidate assertion set.

5. The method according to claim 4, characterized in that, The step of determining a preset assertion template from the preset assertion template library based on the target association relationships in the target ternary graph set includes: The required entities in the target ternary graph set are traversed, and the entity attributes associated with the current required entity are determined. If it is determined that the current demand entity is associated with both a signal entity and an interface entity, then the preset assertion template is determined to include a time-series causal template and a consistency template. If it is determined that the current demand entity is associated with a signal entity but not with any interface entity, then the preset assertion template is determined to be a signal threshold template or a signal steady state template. If it is determined that the current requirement entity is associated with one of the interface entities but not with any of the signal entities, then the preset assertion template is determined to be an interface text verification template or an interface status verification template.

6. The method according to any one of claims 1 to 5, characterized in that, The step of testing and verifying the candidate assertion set to obtain the target assertion set for testing vehicle functions includes: The candidate assertions in the candidate assertion set are executed multiple times to obtain the execution result of each candidate assertion, wherein the execution result includes at least one of the following: pass rate, log data, interface screenshot data, and signal curve data; Based on the execution result, candidate assertions that meet the preset requirements are selected from the candidate assertion set to obtain the target assertion set.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: If at least one of the demand description data, the vehicle signal data, and the user interface description data changes, then obtain the entities and their relationships affected by the change. Based on the entities and relationships affected by the changes, the target ternary graph set is updated to update and re-verify the affected assertions in the target assertion set.

8. A test assertion generation device based on ternary graphs, characterized in that, include: The data acquisition unit is used to acquire demand description data, vehicle signal data, and user interface description data. The graph construction unit is used to construct a target ternary graph set based on the demand description data, the vehicle signal data, and the user interface description data. The target ternary graph set includes at least one target ternary graph, and the target ternary graph includes demand entities, signal entities, interface entities, and target association relationships between each entity. The candidate assertion generation unit is used to select a preset assertion template from the preset assertion template library and fill in the parameters based on the target ternary graph set to generate a candidate assertion set; The target assertion generation unit is used to test and verify the candidate assertion set to obtain a target assertion set for testing vehicle functions.

9. An electronic device, comprising: The memory and processor are characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the test assertion generation method based on ternary graphs as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the test assertion generation method based on ternary graphs as described in any one of claims 1 to 7.

Images