Test case automatic generation method and device, terminal and storage medium
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ZHEJIANG AGILE AUTOMOTIVE TECHNOLOGY CO LTD
- Filing Date
- 2026-01-31
- Publication Date
- 2026-06-19
Smart Images

Figure CN122240460A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software testing, and in particular to a method, apparatus, terminal, and storage medium for automatically generating test cases. Background Technology
[0002] Automotive electronic software testing is a core component in ensuring the reliability of safety-critical systems such as ECUs and ADAS, and must strictly adhere to functional safety standards such as ISO 26262. Currently, test case generation in this field mainly relies on two types of technical solutions, but both have significant shortcomings.
[0003] The first category is text parsing solutions based on Natural Language Processing (NLP). This method generates basic test cases by analyzing textual requirements documents, but it can only handle a single text modality and cannot effectively utilize multimodal requirements sources such as protocol documents, images, and charts, resulting in incomplete requirements coverage and a high rate of scenario omissions. In addition, this method completely lacks automatic integration for functional safety compliance, requiring manual mapping of standard clauses, which is inefficient and prone to omissions.
[0004] The second type is a static solution based on compliance templates. This solution predefines test templates corresponding to ASIL levels. While compliance is taken into account, the template library is rigid, requiring manual maintenance and configuration, and cannot adapt to changes in requirements, resulting in extremely low generation efficiency. More importantly, it also fails to integrate with multimodal requirement inputs, leading to a disconnect between compliance testing and functional testing.
[0005] In summary, existing technologies generally suffer from three major pain points: data silos, lack of compliance, low automation, and poor traceability. This leads to long test and development cycles, insufficient coverage, high certification risks, and slow change response.
[0006] Therefore, there is an urgent need in this field for an automated test case generation method that can solve the above problems simultaneously. Summary of the Invention
[0007] The purpose of this application is to overcome the above-mentioned technical problems and provide a method, device, terminal and storage medium for automatically generating test cases based on multimodal requirements analysis and compliance constraints.
[0008] Firstly, this application provides a method for automatically generating test cases, employing the technical solution described below: Receive multimodal demand information, which includes demand data in at least two different forms, and parse and fuse the multimodal demand information across modes to generate a structured demand model. Based on a pre-defined functional safety standard rule library, the system dynamically matches corresponding compliance rules according to the safety level attributes of elements in the structured requirements model, and generates a set of compliance constraint instructions. By integrating the functional logic in the structured requirements model with the compliance constraint instruction set, and through parameterized combination and test optimization strategies, a test case set that simultaneously verifies the functional logic and compliance requirements is automatically generated. During the generation of the test case set, a two-way traceability relationship is established and recorded between each test case and the corresponding requirement data and the compliance rules covered, forming a traceability matrix.
[0009] By adopting the above technical solutions, multimodal requirement information from different forms of requirement data is received, parsed, and fused across modalities to generate structured requirement models. This overcomes the limitations of traditional text parsing, enabling collaborative processing of multimodal data and ensuring coverage of most automotive software requirements. Based on a pre-set functional safety standard rule base and a generated compliance constraint instruction set, abstract clauses can be transformed into machine-understandable constraint rules, ensuring complete verification of safety mechanisms and guaranteeing clause coverage. Through parameterized combination and test optimization strategies, test case sets are automatically generated, solving the problems of incomplete scenario coverage, boundary omissions, and low efficiency in traditional test case design, thus improving the efficiency of test case writing. A traceability matrix is established and recorded to form a two-way traceability relationship between test cases, requirement data, and compliance rules, realizing a full-link traceability system from requirements to test cases to compliance, saving audit traceability time.
[0010] Preferably, the step of receiving multimodal demand information, parsing and cross-modal fusing the multimodal demand information to generate a structured demand model specifically includes the following steps: Receive multimodal requirement information, including textual requirement data, protocol specification documents, and image data; Natural language processing technology is used to preprocess the text requirement data, and dependency parsing and semantic role labeling are performed on the obtained plain text data to extract key semantic elements. Logical triples are obtained based on the key semantic elements, and the logical triples represent the logical relationship of condition-action-constraint. The protocol specification document is parsed to extract the protocol specification elements, and the protocol specification elements are then structured. The image data is subjected to feature extraction and behavior recognition based on computer vision technology to obtain visual element information.
[0011] By adopting the above technical solutions, multimodal requirement information in different forms can be received. Natural language processing technology can be used to extract key semantic elements and logical triples from textual requirement data. Syntactic parsing and structuring of protocol specification documents can be performed to extract protocol specification elements. Computer vision technology can be used to extract visual element information from image data, thereby solving the limitation of the single nature of traditional text parsing, realizing the collaborative processing of multimodal data such as text, protocol, image and video, and transforming scattered and heterogeneous requirement inputs into unified structured machine data, thereby improving requirement coverage.
[0012] Preferably, the method further includes the following steps: Establish a mapping relationship between the common elements among the key semantic elements, the structured protocol specification elements, and the visual element information to obtain the aligned common elements; Based on the logical triples, contradictory statements in the aligned common elements are identified, marked as conflicting elements, and the identified conflicting elements are resolved according to a predefined conflict resolution strategy. If there are no conflicting elements among the aligned shared elements, information complementarity is achieved using the key semantic elements, the protocol specification elements, and the visual element information. The multimodal analysis results, after alignment, conflict resolution, or information complementation, are integrated to construct and output a unified structured requirement model.
[0013] By adopting the above technical solutions, the establishment of shared element mapping relationships can achieve cross-modal alignment of key semantic elements, protocol specification elements, and visual element information based on semantics, which goes beyond simple text matching and solves the problem of data silos. Identifying and resolving conflicting elements can eliminate contradictions in multimodal requirement information, and information complementarity can supplement and improve multimodal requirement information. A complete fusion process of alignment, conflict detection, conflict resolution / information complementarity, and integration is defined. Through conflict resolution and information complementarity, a consistent, complete, and reliable structured requirement model is generated, laying a solid foundation for subsequent high-quality test generation.
[0014] Preferably, the step of dynamically matching corresponding compliance rules based on the safety level attributes of elements in the structured requirements model according to a preset functional safety standard rule base to generate a compliance constraint instruction set specifically includes the following steps: The structured requirement model is analyzed, which contains multiple interrelated functional logic elements, and the security level attributes associated with the functional logic elements are identified. Using the identified security attribute as an index, a matching and retrieval process is performed in a preset functional safety standard rule base to obtain all compliance rules corresponding to the security attribute. Associate and map the abstract objects in the compliance rules with the functional logic elements in the structured requirements model, bind the abstract constraint values of the abstract objects with the attribute parameters of the functional logic elements, and generate parameterized test constraints. All the aforementioned test constraints are summarized and formatted to obtain a structured compliance constraint instruction set, which is then output.
[0015] By adopting the above technical solution, compliance constraints are dynamically generated through the process of identifying security levels, matching rules, association mapping, and parameter binding. This differs from conventional static compliance constraints and avoids the disconnect between compliance and design. By transforming abstract standard clauses into executable test instructions through association mapping and parameter binding, the automatic conversion from industry standards to executable test strategies is realized. By dynamically associating with security levels such as ASIL, it ensures that high-risk components receive more rigorous and thorough testing and optimizes the allocation of test resources.
[0016] Preferably, the step of integrating the functional logic in the structured requirements model with the compliance constraint instruction set, and automatically generating a test case set that simultaneously verifies the functional logic and compliance requirements through parameterized combination and test optimization strategies, specifically includes the following steps: Extract all test input parameters from the structured requirements model, and determine all possible values of the test input parameters based on the logical triples and protocol specification elements in the structured requirements model. The constraints contained in the compliance constraint instruction set are integrated into the test input parameters as parameter value filtering conditions to obtain the filtered parameter value combination. A preset combination test algorithm is used to generate an optimized test parameter combination table based on the parameter value combination. Traverse the test parameter combination table, combine each row of the test parameter combination table with the structured requirement model and the compliance constraint instruction set, automatically generate corresponding test cases, and populate the test cases into the predefined test case template; Populate each test case with its associated requirement identifier and the covered compliance clause identifier, and output the complete test case set.
[0017] By adopting the above technical solutions, a complete automated process was planned, ensuring generation efficiency. The combined testing algorithm solved the problem of test case "combination explosion," ensuring that the number of test cases was reduced while meeting coverage requirements, greatly improving generation efficiency. Unsafe and invalid test points were automatically eliminated through the filtering conditions of the compliance constraint instruction set, preventing the generation of dangerous test cases and ensuring test security. Filling test cases with associated requirement identifiers and compliance clause identifiers and outputting a complete test case set ensures that test cases can verify functional logic and compliance requirements, improving the efficiency and quality of automated test case generation.
[0018] Preferably, the step of traversing the test parameter combination table and combining each row of the test parameter combination table with the structured requirement model and the compliance constraint instruction set to automatically generate corresponding test cases specifically includes the following steps: Load the predefined test case template, traverse the test parameter combination table, and perform test sequence generation and expected result derivation operations for each row of parameter combination; The test sequence generation includes substituting the parameter values of the current parameter combination into the logical chain of conditions and actions defined in the logical triplet of the structured requirements model to generate an executable test sequence instruction. If the parameters indicate that a fault needs to be injected, a corresponding fault injection instruction is inserted into the test sequence instruction. The derivation of the expected result includes: inputting the current parameter value, calculating the basic output value according to the structured requirement model, applying the constraints of the current test scenario to the compliance constraint instruction set, correcting and limiting the range of the basic output value, and synthesizing the final expected result.
[0019] By adopting the above technical solution, executable test sequence instructions are generated based on logical triples during test sequence generation. If a fault needs to be injected, corresponding instructions can also be inserted. This enables unified handling of normal functional testing and fault injection testing, covering both normal and abnormal scenarios and ensuring the comprehensiveness of testing. Furthermore, the expected results are dynamically synthesized based on two methods: calculating the base value from the model and correcting it using application compliance rules. This allows for a deep integration of functionality and compliance, thereby generating test cases efficiently and accurately.
[0020] Preferably, in the process of generating the test case set, establishing and recording a two-way traceability relationship between each test case and the corresponding requirement data and the compliance rules covered, forming a traceability matrix, specifically includes the following steps: Extract the unique requirement identifier of each functional logic element in the structured requirement model, and extract the unique clause identifier of each compliance rule corresponding to each constraint instruction in the compliance constraint instruction set; During the generation of each test case, the functional logic elements verified by the test case and the constraint instructions satisfied are captured in real time, and a unique test case identifier is automatically generated for each test case. The unique use case identifier is associated with the unique requirement identifier and the unique clause identifier, and the resulting mapping relationship is stored in the bidirectional traceability matrix; When any of the aforementioned requirement data sources is detected to have changed, all affected unique requirement identifiers are automatically located according to the bidirectional traceability matrix, and the test case set that needs to be updated synchronously is located.
[0021] By adopting the above technical solutions, traceability is automatically and seamlessly completed during the use case generation process through real-time capture and automatic association, eliminating the need for manual maintenance afterward. This achieves a full-link traceability system for requirements, use cases, and compliance, facilitating coverage statistics. When changes are detected, the system automatically locates the affected use cases, enabling agile responses to changes in requirements. It solves the problems of delayed change response and low audit efficiency, and has significant advantages in maintenance costs.
[0022] Secondly, this application provides an automatic test case generation device, which adopts the following technical solution: An automatic test case generation device includes the following modules: A multimodal parsing and fusion module is used to receive multimodal demand information, which includes demand data in at least two different forms, and to parse and fuse the multimodal demand information separately to generate a structured demand model. The compliance constraint module is used to dynamically match the corresponding compliance rules based on the safety level attributes of the elements in the structured requirements model, according to the preset functional safety standard rule library, and generate a compliance constraint instruction set. The test case automatic generation module is used to integrate the functional logic in the structured requirements model with the compliance constraint instruction set, and automatically generate a test case set that simultaneously verifies the functional logic and compliance requirements through parameterized combination and test optimization strategies. The traceability management module is used to establish and record a two-way traceability relationship between each test case and the corresponding requirement data and the compliance rules covered during the generation of the test case set, forming a traceability matrix.
[0023] Thirdly, this application provides a smart terminal, which adopts the following technical solution: A smart terminal includes a memory and a processor, wherein the memory stores at least one instruction, at least one program, code set, or instruction set, and the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the test case automatic generation method as described above.
[0024] Fourthly, this application provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the test case automatic generation method as described above.
[0025] In summary, this application has at least the following beneficial effects: This application generates a structured requirement model by receiving, parsing, and fusing multimodal requirement information, thus solving the problem of data silos and avoiding incomplete requirement coverage and scenario omissions. This application dynamically matches compliance rules based on a structured requirements model, integrates functional safety standards into the test constraint rule base, ensures complete verification of safety mechanisms, high clause coverage, and reduces certification risks; it also integrates the structured requirements model and compliance constraint instruction set to automatically generate test case sets, improve test case writing efficiency, and shorten the test development cycle. This application establishes a two-way traceability relationship between test cases, requirement data, and compliance rules, forming a traceability matrix, which solves the problem of weak traceability. When the requirement data source changes, the affected requirements and the test case sets that need to be updated can be automatically located based on the two-way traceability matrix, improving dynamic adaptability and reducing iteration costs and change response delays. Attached Figure Description
[0026] Figure 1 This is a flowchart of the method for automatically generating test cases in the implementation example; Figure 2 This is a flowchart illustrating the multimodal requirements analysis and fusion process of the automatic test case generation method in the implementation example; Figure 3 This is a schematic diagram illustrating the dynamic injection of compliance constraints in the automatic test case generation method of the embodiment. Figure 4 This is an example image of the Excel test case template output from the automatic test case generation method of the embodiment; Figure 5 This is a structural diagram of the test case automatic generation device for the embodiment. Detailed Implementation
[0027] This application provides a method, system, terminal, and storage medium for automatically generating test cases. To make the purpose, technical solution, and advantages of this application clearer, the implementation methods of this application will be further described in detail below.
[0028] The following describes in further detail an embodiment of an automatic test case generation method of this application, with reference to the accompanying drawings.
[0029] This application provides a method for automatically generating test cases, such as... Figure 1 As shown, it includes the following steps: S1. Receive multimodal demand information, which includes demand data in at least two different formats. Analyze and fuse the multimodal demand information separately to generate a structured demand model, such as... Figure 2 As shown, the specific steps include the following: S11. Receive multimodal requirement information, including text requirement data, protocol specification documents, and image data.
[0030] In this embodiment, the textual requirement data is the software requirement document, protocol specification files such as DBC, LDF, etc., and the image data includes images and videos. The images include charts, flowcharts, state diagrams, timing diagrams, etc.
[0031] S12. Preprocess the text requirements data using natural language processing technology: Remove non-text content such as tables, images, and annotations from the software requirements document through text cleaning, unify the encoding format to handle special symbols, and convert the software requirements document into plain text; at the same time, split long paragraphs into independent sentences and segment the sentences; and standardize the terminology, converting colloquial descriptions into standardized expressions, such as converting "speed exceeding 30" into "vehicle speed ≥ 30km / h", and mapping industry terms to a standard vocabulary.
[0032] By combining regular expressions and a terminology database for rule matching, key entities and parameters in the domain are identified and labeled. For example, key entities in the automotive field include "suspension" and "sensors," and parameters include "vehicle speed" and "height."
[0033] Dependency parsing and semantic role labeling were performed on the obtained plain text data to extract key semantic elements.
[0034] Specifically, dependency parsing is used to identify predicates in sentences and their associated roles. Predicates are actions, and associated roles include triggering conditions, target objects, constraints, etc. Finally, semantic role labeling is performed.
[0035] The identified key semantic elements include entities, relations, conditions, and constraints. Based on these key semantic elements, logical triples of "condition-action-constraint" are obtained. In specific implementable methods, various functional logical relations can be obtained based on key semantic elements, and are not limited to the aforementioned logical triples.
[0036] Specifically, the semantic role annotation results are transformed into "condition-action-constraint" triples to identify entities such as signals, conditions, and actions in sentences (not listed here). Logical relationships between entities are established, such as condition-action and signal-threshold relationships. A rule-driven approach is used to define logical connectors to associate conditions and actions, such as "when…" and "if…then".
[0037] In one specific implementation method, the conversion rules for semantic role annotation results are shown in the table below: Table 1 Semantic Role Rule Conversion Table
[0038] In this implementation, if the text requirement data input is "when the vehicle speed exceeds 140km / h and the driving mode is 'Sport', the air suspension should reduce the vehicle height to -25mm within 2s, with an error not exceeding ±5mm and a height change rate not exceeding 10mm / s".
[0039] After preprocessing and standardization, the output plain text is: When the vehicle speed is >140km / h and the driving mode is =Sport, the air suspension should reduce the vehicle height to -25±5mm within 2s, and the height change rate is ≤10mm / s; After performing domain terminology recognition, the following was obtained: A. "Vehicle height": Parameter type; Unit of measurement: mm; B. "Altitude Sensor": Component category; Safety level: ASIL-B; After semantic role labeling, The predicate, or action subject, is "descend to"; The trigger for this action is when a specific condition is met; The trigger conditions include "vehicle speed > 140km / h" and "driving mode = Sport"; The action to be performed is "descend to"; The target of this action is the "vehicle height"; The target value achieved after the action is executed is "-25±5mm"; The constraint during the execution of the action is "within 2 seconds".
[0040] After extracting logical triples, the structured logic rules are as follows: The trigger condition is "vehicle speed greater than 140km / h and driving mode is 'Sport'"; The action to be performed is "Set Suspension Height (SET_SUSPENSION_HEIGHT)"; The target parameter for the action is: height value of -25mm, tolerance of 5mm; The constraints for action execution include: a timeout of 2.0 seconds and a maximum speed of 10.0.
[0041] S13. Perform syntax parsing on the protocol specification document to extract the protocol specification elements, and structure these elements for subsequent requirement association and logical modeling. Protocol specification elements include signals, messages, interfaces, value ranges, and communication timing characteristics.
[0042] Specifically, the protocol type is first identified based on the file extension or content. The corresponding parser is then called based on the protocol type to extract elements such as messages, signals, and nodes. At the same time, information such as comments, units, and value ranges in the protocol are added to enhance the metadata. Finally, the relationships between messages and signals, and between nodes and messages are constructed.
[0043] In one specific implementation, the input original protocol specification file is a .DBC file, which contains the vehicle speed, driving mode, and vehicle height signals mentioned in the above requirements. The corresponding signal information is extracted as follows: vehicle speed signal (ID 0x111), driving mode signal (ID 0x55), and vehicle height signal (ID 0x101). Construct signal constraints, extract special rules such as value tables in DBC, and output protocol specification elements.
[0044] S14. Based on computer vision technology, feature extraction and behavior recognition are performed on the image data to extract visual element information. Visual element information in videos includes vehicle posture and dynamic behavior, while visual element information in graphics includes state transitions, data flow, and temporal relationships.
[0045] For image data, the input type is first determined to be either an image or video, and then parsed and processed accordingly. Specifically, First, the file type is initially determined by checking the file extension and analyzing the filename and suffix. Then, the file is opened using a professional image or video library for final confirmation. Once the type is determined, the appropriate parser is used to extract the necessary information.
[0046] A. For images, use image processing libraries, such as Python's Pillow (PIL); Extract metadata and pixel data: Metadata: dimensions (width and height), mode (RGB, CMYK), file format, etc.
[0047] Pixel data: Obtain the pixel matrix of the image for further processing.
[0048] Basic operations: crop, rotate, scale, apply filters, and save in different formats.
[0049] B. For video, use Python's OpenCV (cv2) video processing library; Then extract the metadata, including total number of frames, frame rate (FPS), resolution, duration, and encoding format; The video is read frame by frame and its content is analyzed. Each frame of the video is an image.
[0050] Advanced operations: segment extraction, watermarking, object detection, face recognition, frame extraction, etc.
[0051] Based on the above image type parsing structure, including object detection, vehicle posture, and temporal behavior, feature extraction and behavior analysis are performed.
[0052] Generate machine-readable structured representations, such as JSON and XML.
[0053] In one specific implementation, the input video file is a video of vehicle height adjustment, which includes a vehicle height gauge.
[0054] Analysis yielded the key performance parameters during the vehicle height adjustment process: The maximum observation rate (max_observed_rate) is 12.3 mm / s, which is the maximum speed that can be achieved during vehicle height adjustment. The adjustment completion time (achievement_time) is 1.85 seconds, which refers to the time required for the vehicle height to be adjusted from the initial state to the target state; The overshoot is 2.7 millimeters (mm), which is the maximum deviation of the vehicle height from the target value during the adjustment process.
[0055] S15. Establish the mapping relationship between the common elements among the key semantic elements, structured protocol specification elements, and visual element information to obtain the aligned common elements.
[0056] Before mapping, the parsing results of the three types of multimodal data are standardized and converted into a unified intermediate representation format; then, based on the common element names, units and numerical ranges, a mapping relationship is established between elements from different forms of data that point to the same real-world entity.
[0057] Aligned common elements are those elements for which a mapping relationship has been established. The above steps achieve cross-modal alignment and associate different data sources.
[0058] S16. Based on logical triples, identify contradictory statements in aligned common elements, mark them as conflicting elements, and resolve the conflicts of the identified conflicting elements according to a predefined conflict resolution strategy.
[0059] Conflicts can include numerical conflicts, behavioral conflicts, or existential conflicts; The conflict resolution strategy specifies that the priorities, from highest to lowest, are: security-related constraints, communication protocol constraints, text requirement constraints, and image / video analysis constraints.
[0060] S17. If there are no conflicting elements among the aligned common elements, information complementarity is achieved by utilizing key semantic elements, protocol specification elements, and visual element information.
[0061] That is, by using the analysis results from one type of data to supplement the missing or ambiguous information in the analysis results of another type of data, a more complete and accurate demand model is formed.
[0062] S18. Integrate the multimodal analysis results after alignment, conflict resolution, or information complementation to construct and output a unified structured requirement model.
[0063] In one specific implementation, the input multimodal data are analyzed as described in the steps above, and the parsing process is as follows: A. NLP extracts the following: signal (vehicle speed, driving mode), condition (greater than 140km / h), logical relationship (AND), action (reduction), and object (vehicle height); B. Protocol Binding: Map "Vehspeed" to signal VehSpdLgtA under CAN ID 0x111, "Driving Mode" to signal DrvModReq under CAN ID 0x55, and "Vehicle Height" to signal BodyHei under CAN ID 0x101; C: Video analysis: The maximum speed was extracted to be 12.3 mm / s, the adjustment time was 1.85 seconds, and the overshoot was 2.7 mm.
[0064] The detected conflict scenario is that the text requirement specifies a descent rate of ≤10mm / s, while the actual rate in the video detection is 12.3mm / s. Conflicts are resolved in accordance with conflict resolution strategies. Safety-related constraints (SAFETY), priority level 0, highest priority; Communication protocol constraint (PROTOCOL), priority level 1; Text requirement (TEXT), priority level 2; Actual observation (VISION), priority level 3, lowest priority; Since safety-related constraints are the highest priority, followed by communication protocol constraints, then textual requirement constraints, and finally actual video observations, and since there are no safety-related constraints or communication protocol constraints in this example, the upper limit of the textual requirement rate of 10 mm / s is adopted.
[0065] Finally, a unified structured requirements model is output, namely: The trigger condition is "vehicle speed > 140km / h and driving mode = Sport mode"; The input parameters include: VehSpdLgtA > 39 m / s (the conversion value in meters per second for a vehicle speed > 140 km / h), and DrvModReq = 3 (the enumeration value corresponding to the sport mode). The action to be performed is "Set Height". The target of the action is "vehicle height"; The output parameter (Outputparameter) is the vehicle height parameter BodyHei, which has a value range between [-0.03m, -0.02m]. The constraints include: a timeout of 2.0 seconds and a maximum speed of 10.0 millimeters per second.
[0066] S2. Based on a pre-defined functional safety standard rule base, dynamically match corresponding compliance rules according to the safety level attributes of elements in the structured requirements model to generate a set of compliance constraint instructions that includes fault modes, coverage requirements, and response time constraints. Specifically, this includes the following steps: S21. Analyze the structured requirements model. The structured requirements model contains multiple interrelated functional logic elements. Identify the security level attributes associated with the functional logic elements.
[0067] Functional logic elements include at least one of signals, components, operations, and states, wherein: A signal represents a data unit that is input or output to a system, and its attributes include name, data type, value range, and unit. A component represents a software or hardware unit that performs a specific function, and its attributes include name, function description, and security level. An operation represents an action or function that the system can perform, and its attributes include name, triggering condition, execution result, and performance constraints. State represents the mode or condition in which the system is in, and its attributes include name and transition conditions.
[0068] In a specific implementation, the four ASIL security levels defined by ISO 26262, such as ASIL A, ASIL B, ASIL C, and ASIL D, are typically derived from prior security analysis and are annotated in the requirements model in the form of metadata.
[0069] The key functional test constraints comparison table is as follows: Table 2 Comparison of Functional Test Constraints
[0070] S22. Using the identified security attributes as indexes, perform matching and retrieval in the preset functional safety standard rule base to obtain all compliance rules corresponding to the security attributes, such as... Figure 3 As shown.
[0071] For example, in one specific implementation, a compliance rule is defined in the rule base: When the security level (ASIL) is determined to be ASIL B, the single point of failure coverage must be greater than or equal to 90% and fault injection testing must be performed. If a "vehicle height sensor" in the demand model is identified as ASIL B, then it matches the above compliance rule.
[0072] S23. Associate and map the abstract objects in the compliance rules with the functional logic elements in the structured requirements model.
[0073] Abstract objects such as "sensors", "actuators", and "safety-related functions" are used, while functional logic elements such as a signal named Body Height Sensor or a component named Main Controller are used.
[0074] S24. Bind the abstract constraint values of the abstract object to the attribute parameters of the functional logic element to generate parameterized test constraints.
[0075] Abstract constraints such as "response time ≤ 100ms", attribute parameters of functional logic elements such as the valid value range of the Body HeightSensor signal, or the ASIL C level of the Main Controller component.
[0076] The above steps enable the retrieved, abstract compliance test requirements to be bound to specific functional logic elements and transformed into parameterized, executable test constraints, thus achieving constraint instantiation.
[0077] In a specific feasible implementation, a compliance rule is: Functional logic element: height sensor; Requirements: ISO 26262 single point fault coverage; Parameterized instructions: Inject height sensor signal loss / out-of-range fault.
[0078] Then, output constraint instructions: Maximum adjustment rate (max_rate): 10 mm / s; Response time: no more than 200 milliseconds (ms); The fault types to be covered (faults_to_cover) are: "HeightSensor_Stuck" and "CAN bus timeout". Fault coverage requirement: 0.9 (i.e., 90%). Fault handling logic: Fault Trigger: When a "height sensor failure" fault is detected, a preset processing action is initiated; Execute action: Trigger the "Freeze vehicle height" operation to keep the current vehicle height unchanged and prevent incorrect height adjustment due to sensor failure; Diagnostic fault code (dtc_code): Synchronously generate diagnostic fault code "0x5A0396" for fault storage and subsequent diagnosis and repair.
[0079] S25. Summarize and format all test constraints to obtain a structured compliance constraint instruction set and output it.
[0080] In one specific implementation, the compliance constraint instruction set includes, Fault injection instructions: the specific fault type to be simulated, the target of the fault injection, and the parameters; Coverage metrics: The coverage target values that need to be achieved, such as fault coverage and code coverage; Timing and performance constraints: maximum response time of security mechanisms, performance indicator thresholds, etc.
[0081] Source information: The legal clause number from which each directive originates, such as ISO 26262-5:2018, Clause 8.4.3.
[0082] The above steps, through the process of "identification-matching-instantiation", realize the intelligent transformation from static regulatory documents to dynamic, executable test instructions.
[0083] S3. Integrating the functional logic and compliance constraint instruction set from the structured requirements model, and through parameterized combination and test optimization strategies, automatically generating a test case set that simultaneously verifies the functional logic and compliance requirements. This includes the following steps: S31. Extract all test input parameters from the structured requirements model, such as vehicle speed, load, temperature, etc., and determine all values of the test input parameters based on the logical triples and protocol specification elements in the structured requirements model, including the value range, normal value, boundary value and invalid value of each parameter.
[0084] For example, in a specific implementation, to test the "vehicle speed" parameter, first find the logical triple related to "vehicle speed" in the model, find the condition speed>140, and obtain a logical boundary; Then, the definition of the "vehicle speed" signal is found in the model, and its physical value range is [0,250] km / h, thus obtaining a physical boundary; Based on the testing strategy, the boundary values and invalid values of this parameter are automatically generated.
[0085] S32. Integrate the constraints contained in the compliance constraint instruction set as parameter value filtering conditions into the test input parameters to obtain the filtered parameter value combination.
[0086] Using these constraints as filtering rules can eliminate unsafe or invalid test points, such as vehicle speeds exceeding the maximum rate of height change.
[0087] For example, the constraint is to prohibit the suspension lowering operation when the vehicle speed is >5km / h. A test point is generated, namely, vehicle speed: 100km / h, operation: lowering the suspension. Logically judging this test point with the compliance constraint, it is found that the combination violates the safety mechanism, so it is filtered out and no final test case is generated.
[0088] S33. A preset combination test algorithm is used to generate an optimized test parameter combination table based on the parameter value combination. In this embodiment, the combination test algorithm is Pairwise, which is used to generate parameter combinations that cover all constraints and are minimized.
[0089] S34. Traverse the test parameter combination table, combining each row with the structured requirements model and compliance constraint instruction set to automatically generate corresponding test cases. Each test case includes a sequence of test steps and expected results. Specifically, this includes the following steps: S341. Load a predefined test case template. The template defines the structured fields of the test cases.
[0090] In this embodiment, a fixed Excel test case template structure based on project experience is loaded. This template contains fixed columns, such as Test Case ID and Requirement ID.
[0091] The following table shows an example of the structure of an Excel test case template: Table 3. Use Case Template Structure Table
[0092] Traverse the test parameter combination table, and perform test sequence generation and expected result derivation operations for each row of parameter combination. That is, instantiate the test scenario and test action for each row of parameter combination, and dynamically synthesize the expected result under the test scenario.
[0093] S342. For each parameter combination, before executing the test sequence generation and expected result derivation, it also includes generating preconditions, that is, setting the initial test state based on the value of the current parameter combination.
[0094] S343. Test sequence generation includes substituting the parameter values of the current parameter combination into the "condition-action" logic chain in the logical triple defined by the structured requirements model to generate an executable test sequence instruction. If the parameters indicate that a fault needs to be injected, the corresponding fault injection instruction is inserted into the test sequence instruction.
[0095] Overall, the steps for generating the test sequence describe how to set parameters, inject faults, and execute specific instruction sequences.
[0096] S344. The derivation of expected results includes: inputting the current parameter value, executing the "action-output" mapping relationship defined in the unified requirement model according to the structured requirement model, calculating the basic output value, and applying the constraint conditions of the current test scenario in the compliance constraint instruction set, such as output accuracy tolerance, time delay range, or expected safety state under fault.
[0097] S345. Correct and limit the range of the basic output values to synthesize the final expected result.
[0098] S35. Fill the test cases containing preconditions, test sequences, expected results, and parameter combinations into the corresponding fields of the predefined test case template; S36. Fill in the associated requirement identifier and the covered compliance clause identifier for each test case, and output the complete test case set.
[0099] To facilitate understanding, the above steps will be explained in a specific way below: Input multimodal requirements and compliance constraints, and extract test input parameters. Example dimensions of the test input parameters are as follows: Vehicle speed (Velocity) threshold values (km / h): [130 (below threshold), 140 (equal to threshold), 150 (above threshold)]; Driving Mode (DrvMode): [Sport (valid equivalence class), Err (invalid equivalence class)]; Fault Injection: ["None", "HeightSensor_Stuck", "CAN_Timeout"]; The final parameter combination table is as follows: Table 4 Parameter Combination Table
[0100] Load the Excel test case template from step S341, generate tests row by row according to the parameter combination table, and combine the test steps and expected results. Finally, output an example of an Excel row that conforms to the template, such as... Figure 4 As shown.
[0101] This step automates the transformation from abstract models and rules to concrete, executable test cases without human intervention, greatly improving efficiency.
[0102] S4. During the process of generating test case sets, establish and record the two-way traceability relationship between each test case and the corresponding requirement data and the compliance rules covered, forming a traceability matrix. The specific steps include the following.
[0103] S41. After generating a unified structured requirement model, extract the unique requirement identifier of each functional logic element in the structured requirement model. After generating a compliance constraint instruction set, extract the unique clause identifier of the compliance rule corresponding to each constraint instruction in the compliance constraint instruction set.
[0104] In this embodiment, logical triples, signals, messages, value ranges, visual elements, state transitions, or spatiotemporal relationship information are collectively referred to as functional logic elements; functional logic elements are the basic units that constitute a unified requirement model, including their own attributes, behaviors, and relationships with other elements.
[0105] S42. During the generation of each test case, the functional logic elements and constraint instructions satisfied by the test case are captured in real time, and a unique test case identifier is automatically generated for each test case.
[0106] The unique test case identifier is automatically generated based on its corresponding requirement identifier, test parameter combination, and test type. The test type is used to distinguish the test purpose, such as normal functional testing, boundary testing, or fault injection testing. The requirement identifier is used to ensure traceability, and the test parameter combination ensures uniqueness.
[0107] S43. Associate and map the unique use case identifier with the unique requirement identifier and the unique clause identifier, and store the resulting mapping relationship in the bidirectional traceability matrix.
[0108] The bidirectional traceability matrix supports querying all related test case identifiers by using requirement identifiers or clause identifiers as indexes; at the same time, it supports reverse lookup of all requirement identifiers and clause identifiers covered by a test case identifier as an index.
[0109] The bidirectional traceability matrix and test case set are organized and output as a structured spreadsheet file, which includes: A main worksheet stores detailed information about all test cases, including test steps, input parameters, and expected results; A parameter configuration table is used to store the parameter combinations used to generate test cases; A traceability matrix worksheet, where each row corresponds to a requirement identifier, and the columns cover all test case identifiers for that requirement and their associated regulatory clause identifiers.
[0110] S44. When any change in the data source of a requirement is detected, all affected unique requirement identifiers are automatically located according to the bidirectional traceability matrix, and the test case set that needs to be updated synchronously is located.
[0111] Based on the same inventive concept described above, this application also discloses an automatic test case generation device, the architecture of which is as follows: Figure 5 As shown, it includes the following modules: The multimodal parsing and fusion module is used to receive multimodal demand information, which includes demand data in at least two different forms. The module parses and fuses the multimodal demand information across modes to generate a structured demand model. The compliance constraint module is used to dynamically match the corresponding compliance rules based on the safety level attributes of elements in the structured requirements model, according to the preset functional safety standard rule library, and generate a compliance constraint instruction set. The test case automatic generation module is used to integrate the functional logic and compliance constraint instruction set in the structured requirements model. Through parameterized combination and test optimization strategies, it automatically generates a test case set that simultaneously verifies the functional logic and compliance requirements. The traceability management module is used to establish and record a two-way traceability relationship between each test case and its corresponding requirement data and the compliance rules it covers during the generation of test case sets, forming a traceability matrix.
[0112] In a specific feasible implementation, the multimodal parsing and fusion module includes the following units: The first multimodal parsing and fusion unit is used to receive multimodal requirement information, including text requirement data, protocol specification documents, and image data. The second multimodal parsing and fusion unit is used to preprocess the text requirement data using natural language processing technology, perform dependency parsing and semantic role labeling on the obtained plain text data, extract key semantic elements, and obtain logical triples based on the key semantic elements. The logical triples represent the constraint relationship between condition, action, and constraint. The protocol specification document is parsed to extract the protocol specification elements, and these elements are then structured. By using computer vision technology to extract features and recognize behaviors from image data, visual element information is obtained.
[0113] The third multimodal parsing and fusion unit is used to establish the mapping relationship between the common elements among the key semantic elements, structured protocol specification elements and visual element information, and to obtain the aligned common elements. The fourth multimodal parsing and fusion unit is used to identify contradictory statements in aligned common elements based on logical triples, mark them as conflicting elements, and resolve the conflicts of the identified conflicting elements according to a predefined conflict resolution strategy. The fifth multimodal parsing and fusion unit is used to complement information by utilizing key semantic elements, protocol specification elements, and visual element information if there are no conflicting elements among the aligned common elements. The sixth multimodal analysis and fusion unit is used to integrate the multimodal analysis results after alignment, conflict resolution, or information complementation, and to construct and output a unified structured demand model.
[0114] In a specific feasible implementation, the compliance constraint module includes the following units: The first compliance constraint unit is used to parse the structured requirement model, which contains multiple interrelated functional logic elements, and to identify the security level attributes associated with the functional logic elements. The second compliance constraint unit is used to match and retrieve all compliance rules corresponding to the identified security attributes from a pre-defined functional safety standard rule base, using the identified security attributes as indexes. The third compliance constraint unit is used to associate and map abstract objects in compliance rules with functional logic elements in structured requirement models, bind abstract constraint values of abstract objects with attribute parameters of functional logic elements, and generate parameterized test constraints. The fourth compliance constraint unit is used to summarize and format all test constraints to obtain a structured compliance constraint instruction set and output it.
[0115] In a specific feasible implementation, the test case automatic generation module includes the following units: The first test case automatic generation unit is used to extract all test input parameters from the structured requirement model and determine all values of the test input parameters based on the logical triples and protocol specification elements in the structured requirement model. The second test case automatic generation unit is used to integrate the constraints contained in the compliance constraint instruction set as parameter value filtering conditions into the test input parameters to obtain the filtered parameter value combination. It then uses a preset combination test algorithm to generate an optimized test parameter combination table based on the parameter value combination. The third test case automatic generation unit is used to traverse the test parameter combination table, combine each row of the test parameter combination table with the structured requirement model and compliance constraint instruction set, automatically generate corresponding test cases, and populate the test cases into the predefined test case template. The fourth test case automatic generation unit is used to fill in the associated requirement identifier and the covered compliance clause identifier for each test case, and output a complete test case set.
[0116] In a specific feasible implementation, the third test case automatic generation unit includes the following sub-units: The test case automatic generation sub-unit is used to load predefined test case templates, traverse the test parameter combination table, and perform test sequence generation and expected result derivation operations for each row of parameter combination; Test sequence generation includes substituting the parameter values of the current parameter combination into the logical chain of conditions and actions defined in the logical triplet of the structured requirements model to generate executable test sequence instructions. If the parameters indicate that a fault needs to be injected, the corresponding fault injection instruction is inserted into the test sequence instructions. The derivation of the expected result includes: inputting the current parameter value, calculating the basic output value based on the structured requirement model, applying the constraints of the compliance constraint instruction set for the current test scenario, correcting and limiting the range of the basic output value, and synthesizing the final expected result.
[0117] In a specific feasible implementation, the traceability management module includes the following units: The first traceability management unit is used to extract the unique requirement identifier of each functional logic element in the structured requirement model and the unique clause identifier of the compliance rule corresponding to each constraint instruction in the compliance constraint instruction set. The second traceability management unit is used to capture the functional logic elements verified by the test cases and the constraint instructions satisfied in real time during the generation of each test case, and automatically generate a unique test case identifier for each test case. The third traceability management unit is used to associate and map unique use case identifiers with unique requirement identifiers and unique clause identifiers, and store the resulting mapping relationship in a two-way traceability matrix. The fourth traceability management unit is used to automatically locate all affected unique requirement identifiers based on the two-way traceability matrix when any change in the requirement data source is detected, and to locate the test case set that needs to be updated synchronously.
[0118] Based on the same inventive concept described above, this application also discloses a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set can be loaded and executed by a processor to implement the test case automatic generation method provided in the above method embodiments.
[0119] Based on the same inventive concept described above, this application also discloses a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the test case automatic generation method described above.
[0120] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code.
[0121] The above are merely optional embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A method for automatically generating test cases, characterized in that, Includes the following steps: Receive multimodal demand information, which includes demand data in at least two different forms, and parse and fuse the multimodal demand information separately to generate a structured demand model; Based on a pre-defined functional safety standard rule library, the system dynamically matches corresponding compliance rules according to the safety level attributes of elements in the structured requirements model, and generates a set of compliance constraint instructions. By integrating the functional logic in the structured requirements model with the compliance constraint instruction set, and through parameterized combination and test optimization strategies, a test case set that simultaneously verifies the functional logic and compliance requirements is automatically generated. During the generation of the test case set, a two-way traceability relationship is established and recorded between each test case and the corresponding requirement data and the compliance rules covered, forming a traceability matrix.
2. The test case automatic generation method according to claim 1, characterized in that, The process of receiving multimodal demand information, parsing and fusing the multimodal demand information across modes to generate a structured demand model specifically includes the following steps: Receive multimodal requirement information, including textual requirement data, protocol specification documents, and image data; Natural language processing technology is used to preprocess the text requirement data, and dependency parsing and semantic role labeling are performed on the obtained plain text data to extract key semantic elements. Logical triples are obtained based on the key semantic elements, and the logical triples represent the logical relationship of condition-action-constraint. The protocol specification document is parsed to extract the protocol specification elements, and the protocol specification elements are then structured. The image data is subjected to feature extraction and behavior recognition based on computer vision technology to obtain visual element information.
3. The test case automatic generation method according to claim 2, characterized in that, It also includes the following steps: Establish a mapping relationship between the common elements among the key semantic elements, the structured protocol specification elements, and the visual element information to obtain the aligned common elements; Based on the logical triples, contradictory statements in the aligned common elements are identified, marked as conflicting elements, and the identified conflicting elements are resolved according to a predefined conflict resolution strategy. If there are no conflicting elements among the aligned shared elements, information complementarity is achieved using the key semantic elements, the protocol specification elements, and the visual element information. The multimodal analysis results, after alignment, conflict resolution, or information complementation, are integrated to construct and output a unified structured requirement model.
4. The test case automatic generation method according to claim 2, characterized in that, The method, based on a preset functional safety standard rule base, dynamically matches corresponding compliance rules according to the safety level attributes of elements in the structured requirements model to generate a compliance constraint instruction set, specifically including the following steps: The structured requirement model is analyzed, which contains multiple interrelated functional logic elements, and the security level attributes associated with the functional logic elements are identified. Using the identified security attribute as an index, a matching and retrieval process is performed in a preset functional safety standard rule base to obtain all compliance rules corresponding to the security attribute. Associate and map the abstract objects in the compliance rules with the functional logic elements in the structured requirements model, bind the abstract constraint values of the abstract objects with the attribute parameters of the functional logic elements, and generate parameterized test constraints. All the aforementioned test constraints are summarized and formatted to obtain a structured compliance constraint instruction set, which is then output.
5. The test case automatic generation method according to claim 4, characterized in that, The process of integrating the functional logic from the structured requirements model with the compliance constraint instruction set, and automatically generating a test case set that simultaneously verifies both the functional logic and compliance requirements through parameterized combination and test optimization strategies, specifically includes the following steps: Extract all test input parameters from the structured requirements model, and determine all possible values of the test input parameters based on the logical triples and protocol specification elements in the structured requirements model. The constraints contained in the compliance constraint instruction set are integrated into the test input parameters as parameter value filtering conditions to obtain the filtered parameter value combination. A preset combination test algorithm is used to generate an optimized test parameter combination table based on the parameter value combination. Traverse the test parameter combination table, combine each row of the test parameter combination table with the structured requirement model and the compliance constraint instruction set, automatically generate corresponding test cases, and populate the test cases into the predefined test case template; Populate each test case with its associated requirement identifier and the covered compliance clause identifier, and output the complete test case set.
6. The test case automatic generation method according to claim 5, characterized in that, The step of traversing the test parameter combination table and combining each row of the test parameter combination table with the structured requirement model and the compliance constraint instruction set to automatically generate corresponding test cases includes the following steps: Load the predefined test case template, traverse the test parameter combination table, and perform test sequence generation and expected result derivation operations for each row of parameter combination; The test sequence generation includes substituting the parameter values of the current parameter combination into the logical chain of conditions and actions defined in the logical triplet of the structured requirements model to generate an executable test sequence instruction. If the parameters indicate that a fault needs to be injected, a corresponding fault injection instruction is inserted into the test sequence instruction. The derivation of the expected result includes: inputting the current parameter value, calculating the basic output value according to the structured requirement model, applying the constraints of the current test scenario to the compliance constraint instruction set, correcting and limiting the range of the basic output value, and synthesizing the final expected result.
7. The test case automatic generation method according to claim 5, characterized in that, In the process of generating the test case set, a two-way traceability relationship is established and recorded between each test case and the corresponding requirement data and the compliance rules it covers, forming a traceability matrix. This specifically includes the following steps: Extract the unique requirement identifier of each functional logic element in the structured requirement model, and extract the unique clause identifier of each compliance rule corresponding to each constraint instruction in the compliance constraint instruction set; During the generation of each test case, the functional logic elements verified by the test case and the constraint instructions satisfied are captured in real time, and a unique test case identifier is automatically generated for each test case. The unique use case identifier is associated with the unique requirement identifier and the unique clause identifier, and the resulting mapping relationship is stored in the bidirectional traceability matrix; When any of the aforementioned requirement data sources is detected to have changed, all affected unique requirement identifiers are automatically located based on the bidirectional traceability matrix, and the test case set that needs to be updated synchronously is located.
8. A test case automatic generation device, characterized in that, Includes the following modules: A multimodal parsing and fusion module is used to receive multimodal demand information, which includes demand data in at least two different forms, and to parse and fuse the multimodal demand information separately to generate a structured demand model. The compliance constraint module is used to dynamically match the corresponding compliance rules based on the safety level attributes of the elements in the structured requirements model, according to the preset functional safety standard rule library, and generate a compliance constraint instruction set. The test case automatic generation module is used to integrate the functional logic in the structured requirements model with the compliance constraint instruction set, and automatically generate a test case set that simultaneously verifies the functional logic and compliance requirements through parameterized combination and test optimization strategies. The traceability management module is used to establish and record a two-way traceability relationship between each test case and the corresponding requirement data and the compliance rules covered during the generation of the test case set, forming a traceability matrix.
9. A smart terminal, characterized in that, The system includes a memory and a processor, wherein the memory stores at least one instruction, at least one program, code set, or instruction set, and the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the test case automatic generation method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, The readable storage medium stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by a processor to implement the test case automatic generation method as described in any one of claims 1 to 7.