Function test script generation method, device, equipment, medium and product

Abstract

The application relates to the technical field of vehicle testing, in particular to a function test script generation method, device, equipment, medium and product, wherein the method comprises the following steps: obtaining a test excitation primitive set of a target test bench, and constructing a primitive knowledge base according to the test excitation primitive set; obtaining a function requirement set, source code and configuration data of a measured electronic control unit, and generating an enhanced requirement set according to the function requirement set, the source code and the configuration data; generating a function test script of the measured electronic control unit according to the enhanced requirement set and the primitive knowledge base; and the target test bench tests the measured electronic control unit by using the function test script. Therefore, the manual intervention fault in the generation process caused by the difference between the test steps and the bench primitive granularity in the related art is solved, and the executable rate and the function correctness of the generated script are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and in particular to a method, apparatus, equipment, medium and product for generating functional test scripts. Background Technology

[0002] Before mass production and release, electronic control units typically need to complete functional verification in a hardware-in-the-loop test bench. Testers compile test scripts based on functional requirements and perform operations such as power supply control, signal injection, status observation, and result determination through the test bench interface.

[0003] In related technologies, test behavior trees are constructed from a node library and converted into test scripts. However, the correspondence between the node configurations of the test behavior tree and the callable primitives actually provided by the bench interface still needs to be manually established by testers. The difference in granularity between the test steps and the bench primitives leads to a gap in manual intervention during the generation process. This gap causes the script generation efficiency to be limited by manual translation, and the generated results to depend on personal experience, resulting in repeated debugging, limited coverage, and quality fluctuations. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and product for generating functional test scripts to solve problems such as the difference between test steps and bench primitive granularity in related technologies, which leads to gaps in the generation process due to human intervention.

[0005] The first aspect of this application provides a method for generating a functional test script, comprising the following steps: obtaining a set of test stimulus primitives for a target test bench; constructing a primitive knowledge base based on the set of test stimulus primitives, wherein the test stimulus primitives in the set represent functions called in the functional test script to drive the target test bench; obtaining a set of functional requirements, source code, and configuration data for an electronic control unit under test (ECU); generating an enhanced requirement set based on the set of functional requirements, source code, and configuration data, wherein the original functional requirement text in the functional requirement set is a natural language description of the function to be tested in the ECU, and the enhanced requirement set includes multiple enhanced functional requirement texts; generating a functional test script for the ECU under test based on the enhanced requirement set and the primitive knowledge base; and using the functional test script to test the ECU under test on the target test bench.

[0006] Optionally, the source code for the functional test script generation method follows the layered specifications of the automotive open system architecture, and the configuration data includes multiple diagnostic fault codes, timing and delay constraints, parameter ranges, hardware input / output mappings of the target test bench, controlled object model parameters, and fault injection configurations.

[0007] Optionally, a primitive knowledge base is constructed based on the set of test stimulus primitives, including: extracting each test stimulus primitive from the set of test stimulus primitives; obtaining the functional description, syntax and semantics of the target test bench input and output parameters, usage patterns, and attribute access paths of each test stimulus primitive; generating a record array based on the functional description, syntax and semantics, usage patterns, and attribute access paths; using the record array as the knowledge record of the test stimulus primitive; and generating a primitive knowledge base based on the knowledge record of each test stimulus primitive.

[0008] Optionally, before obtaining the functional description of each test stimulus primitive, the syntax and semantics of the target test bench's input and output parameters, usage patterns, and attribute access paths, the method further includes: if the attribute access path is identified as a target test bench that provides structured interface documents, then extracting the functional description, syntax and semantics, and usage patterns from the structured interface documents; if the attribute access path is identified as a target test bench that provides interface source code, then extracting the interface layer entry function set from the interface source code, generating a function summary based on the interface layer entry function set, and extracting the functional description, syntax and semantics, and usage patterns from the context data generated by the function summary.

[0009] Optionally, generating a function summary based on the interface layer entry function set includes: treating all entry functions in the interface layer entry function set as callable primitives; generating code closures based on the callable primitives reachable by the functional test script; generating a code property graph based on the code closures, abstract syntax tree, control flow graph, and program dependency graph; generating a code call graph based on the caller-callee relationship in the code property graph; identifying the signature, source file path, line number, and macros used for each entry function in the code call graph; generating metadata based on the signature, source file path, line number, and macros used for each entry function; and generating a function summary based on the metadata.

[0010] Optionally, generating an enhanced requirement set based on the functional requirement set, source code, and configuration data includes: generating a requirement point corpus based on the source code; selecting multiple target requirement points from the requirement point corpus; generating multiple enhanced functional requirement texts based on the multiple target requirement points and configuration data; and generating an enhanced requirement set based on the multiple enhanced functional requirement texts.

[0011] Optionally, generating a requirement point corpus based on the source code includes: segmenting the source code according to module entry points; generating a module call graph and hierarchical semantic summary based on the segmentation results; and generating a requirement point corpus based on the module call graph and hierarchical semantic summary.

[0012] Optionally, multiple target demand points are selected from the demand point corpus, including: extracting each original demand point from the demand point corpus; calculating the similarity between the original functional demand text and the original demand points in the functional demand set; selecting multiple candidate demand points from the original demand points in the demand point corpus based on the similarity; obtaining the completeness and confidence of each candidate demand point; and determining multiple target demand points from the multiple candidate demand points based on the completeness and confidence.

[0013] Optionally, generating a functional test script for the electronic control unit under test based on the enhanced requirements set and the primitive knowledge base includes: generating multiple test steps based on the enhanced requirements set; representing the multiple test steps as a behavior tree and applying constraints to the behavior tree using the primitive knowledge base; and generating a functional test script based on the behavior tree with the constraints applied.

[0014] Optionally, the constraints of the behavior tree include primitive constraints, parameter constraints, and expression constraints. Primitive constraints include that the function name of each action node can be resolved to the record of the test stimulus primitive in the primitive knowledge base. Parameter constraints include that the actual parameters of each action node conform to the parameter definitions of the test stimulus primitive in the primitive knowledge base. Expression constraints include that the logic in the condition nodes and loop nodes is restricted to a safe subset, and the safe subset includes at least one comparison operation, Boolean operation, arithmetic operation, and parentheses.

[0015] A second aspect of this application provides a functional test script generation apparatus, comprising: a construction module, configured to acquire a set of test stimulus primitives for a target test bench, and construct a primitive knowledge base based on the set of test stimulus primitives, wherein the test stimulus primitives in the set of test stimulus primitives represent functions called in the functional test script to drive the target test bench; an enhancement module, configured to acquire a set of functional requirements, source code, and configuration data of an electronic control unit under test, and generate an enhancement requirement set based on the set of functional requirements, source code, and configuration data, wherein the original functional requirement text in the functional requirement set is a natural language description of the function to be tested in the electronic control unit under test, and the enhancement requirement set includes multiple enhancement functional requirement texts; and a generation module, configured to generate a functional test script for the electronic control unit under test based on the enhancement requirement set and the primitive knowledge base, wherein the target test bench uses the functional test script to test the electronic control unit under test.

[0016] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the functional test script generation method as described in the above embodiments.

[0017] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the functional test script generation method as described in the above embodiments.

[0018] A fifth aspect of this application provides a computer program product, which, when executed, is used to implement the functional test script generation method as described in the above embodiments.

[0019] Therefore, this application has the following beneficial effects: This application obtains the test stimulus primitive set of the target test bench and constructs a primitive knowledge base, providing a source of primitive records that can be called in subsequent generation stages. This avoids situations where the generated script calls non-existent interfaces or misuses parameters due to differences in test bench interfaces. By obtaining the functional requirement set, source code, and configuration data of the electronic control unit under test and generating an enhanced requirement set, the original natural language requirements are transformed into a structured requirement description containing enhanced information, providing a more complete test context for subsequent generation stages. By generating functional test scripts based on the enhanced requirement set and primitive knowledge base, the enhanced requirement description is combined with the primitive record source, enabling the automatic completion of the conversion path from requirement description to executable primitive call. This automatically establishes the correspondence between the node configuration of the behavior tree and the callable primitives provided by the test bench interface during the generation process, and the test steps are automatically decomposed into a continuous primitive call sequence. This eliminates the gaps in manual intervention caused by differences in the granularity of test steps and test bench primitives in related technologies, achieving end-to-end automated test script generation.

[0020] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0021] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a schematic diagram illustrating the manual creation process of functional test scripts in related technologies. Figure 2 This is a general framework diagram of the functional test script generation method provided according to the embodiments of this application; Figure 3 This is a flowchart of a method for generating functional test scripts according to embodiments of this application; Figure 4 This is a roadmap for constructing a test incentive primitive knowledge base according to embodiments of this application; Figure 5 This is a schematic diagram of out-degree reverse topology layering according to an embodiment of this application; Figure 6 This is a schematic diagram of a strongly connected component overall summary provided according to an embodiment of this application; Figure 7This is a schematic diagram of the data flow and two-stage retrieval for enhanced requirements provided in the embodiments of this application; Figure 8 This is a schematic diagram of the behavior tree organization method provided according to the embodiments of this application; Figure 9 This is a schematic diagram of three-level constraints provided according to an embodiment of this application; Figure 10 This is a schematic diagram illustrating the comparison of ablation experiments provided according to the embodiments of this application; Figure 11 This is a performance comparison diagram under different large language models provided in the embodiments of this application; Figure 12 This is a block diagram of a functional test script generation apparatus provided according to an embodiment of this application; Figure 13 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0022] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0023] Automotive electronic control units (ECUs) are responsible for functions such as braking, airbags, chassis, and power management. System-level failures can lead to unacceptable hazards, therefore, system functional testing must be completed before mass production and release. Functional testing is performed on a hardware-in-the-loop test bench: the ECU under test is connected to a real-time closed-loop simulation environment, where the bench simulates the vehicle's network and sensor actuator models, thus enabling repeatable functional verification without using a real vehicle. The test bench exposes a set of operational primitives through a programmable interface, allowing test scripts to drive the interaction between the test bench and the ECU; these are referred to as test stimulus primitives. Primitives typically cover power management, operating condition loading, bus transceiver, signal injection and fault simulation, as well as real-time model control and data acquisition.

[0024] In related technologies, the transformation from functional requirements to executable scripts largely relies on manual processes, such as... Figure 1 As shown, it specifically includes: ①Pre-test knowledge preparation: Test engineers first review the bench interface specifications and vehicle configuration to understand the functional boundaries, parameter semantics, and timing prerequisites of the primitives; ② Pre-test requirement clarification: Test engineers and system architects clarify the vague expressions in the requirements, and refine the coarse-grained requirements into specific behavioral scenarios that include preconditions, triggering events, expected behaviors and tolerances; ③ Test script writing: Test engineers write scripts in the order of initialization, stimulus, observation, verification and cleanup; ④ Bench execution and debugging: Deployment and execution, log analysis, failure location, and if necessary, backtracking to the requirement clarification or script writing stage.

[0025] However, Figure 1 The process shown presents at least the following issues that need to be addressed: Bottleneck 1: Heterogeneous interface architecture: Architectures from different sources do not agree on primitive naming conventions, parameter types and units, or call timing. Self-developed architectures typically overlay project-level encapsulation on top of the underlying driver, resulting in heavily wrapped primitives, implicit state machines, and incomplete documentation. Relying solely on primitive names or sparse comments is insufficient to support reliable automatic generation: the language model may fabricate non-existent interfaces, misuse parameters, or omit necessary initialization steps, rendering the generated scripts syntactically or semantically unexecutable.

[0026] Bottleneck 2: Incomplete requirements: Early functional requirements were generally irrelevant to implementation. Internal state machines, filtering strategies, error recovery paths, and parameter thresholds were gradually filled in by testers based on their personal experience or by consulting the source code. This kind of implicit domain knowledge was not included in the requirements document, which meant that the scripts generated based solely on the requirements could only cover the most superficial input and output logic and could not trigger boundary conditions or expose deep defects.

[0027] Bottleneck 3: Misaligned granularity: The logical steps decomposed by testers do not correspond one-to-one with the bench primitives. High-level test intentions are difficult to translate directly into an executable primitive call sequence, and there is a lack of end-to-end automated paths.

[0028] In summary, the relevant technologies cannot automatically generate test scripts for electronic control unit functions that can be directly executed on the hardware-in-the-loop test bench and whose test logic is equivalent to that of a manual script, under conditions of heterogeneous test bench interfaces and lack of implicit domain knowledge in functional requirements.

[0029] To solve the above problems, such as Figure 2 As shown, the overall process of this application is divided into four stages. Figure 2 In this process, the four types of input artifacts are the test stimulus primitive set T, the functional requirement set R, the source code of the unit under test S, and the configuration data C; the first phase is the construction of the test stimulus primitive knowledge base, such as... Figure 2 As shown in ①, it receives a set of test stimulus primitives T, performs static analysis, hierarchical summarization, and vector indexing, and outputs a primitive knowledge base K, transforming heterogeneous and low-structured primitive artifacts into a machine-readable, semantically explicit knowledge base; the second stage is requirement enhancement, such as... Figure 2As shown in step ②, it receives the functional requirement set R, the source code S of the unit under test, and configuration data C. After module semantic extraction and retrieval enhancement, it outputs an enhanced requirement set R'. Implementation layer evidence is extracted from the source code of the unit under test and injected into the original requirements along with the configuration data. Phase three involves the automatic generation of test scripts, such as... Figure 2 As shown in ③, it receives the primitive knowledge base K and the enhanced requirement set R', and sequentially processes them through requirement decomposition, behavior tree intermediate representation, and script code generation, outputting a test script set P. Using enhanced requirements as input and the primitive knowledge base as the retrieval source, it produces an executable script. If the static check fails, it is regenerated via a feedback loop; stage four is bench execution and judgment, such as... Figure 2 As shown in ④, it deploys scripts, collects responses, and makes assertion judgments on the test script set P. The script contains assertions as test predictions. After execution, it generates a pass or fail judgment and summarizes them into a test report.

[0030] The following description, with reference to the accompanying drawings, details a method, apparatus, device, medium, and product for generating functional test scripts according to embodiments of this application.

[0031] Specifically, Figure 3 This is a flowchart of a method for generating functional test scripts according to an embodiment of this application.

[0032] like Figure 3 As shown, the method for generating this functional test script includes the following steps: In step S301, the test stimulus primitive set of the target test bench is obtained, and a primitive knowledge base is constructed based on the test stimulus primitive set. The test stimulus primitives in the test stimulus primitive set represent functions that are called in the functional test script to drive the target test bench.

[0033] It is understood that by constructing a primitive knowledge base, the subsequent generation process can retrieve matching primitive records from the primitive knowledge base based on the test intent described in natural language when primitives need to be called, and generate a valid primitive call statement according to the information recorded in the record. This avoids the problems of fictitious interfaces and misused parameters caused by differences in bench primitive naming conventions or unclear parameter semantics.

[0034] It should be noted that the target test bench refers to the test equipment used to perform hardware-in-the-loop functional verification of the electronic control unit under test.

[0035] Specifically, test stimulus primitives are extracted one by one from the set of test stimulus primitives. The invocation information for each primitive is obtained, and corresponding knowledge records are generated based on this information. All knowledge records are then aggregated into a primitive knowledge base. Each knowledge record in the primitive knowledge base is serialized and converted into a high-dimensional vector using an embedding model, then stored in a vector database for semantic retrieval in subsequent steps.

[0036] For example, the test stimulus primitives are derived from the interface documentation or source code of a certain test bench. Each test stimulus primitive corresponds to a function that can be directly called in the test script. After extracting the call information for each function, a knowledge record is generated for each function, and all knowledge records constitute the primitive knowledge base. When subsequent steps require calling primitives related to "injecting acceleration signals," the most relevant knowledge record can be retrieved from the vector database through semantic similarity, thereby determining the function to be called and its calling method.

[0037] In this embodiment of the application, constructing a primitive knowledge base based on a set of test stimulus primitives includes: extracting each test stimulus primitive from the set of test stimulus primitives; obtaining the functional description, syntax and semantics of the target test bench input and output parameters, usage patterns, and attribute access paths of each test stimulus primitive; generating a record array based on the functional description, syntax and semantics, usage patterns, and attribute access paths; using the record array as the knowledge record of the test stimulus primitive; and generating a primitive knowledge base based on the knowledge record of each test stimulus primitive.

[0038] Each knowledge record can be represented as a quadruple:

[0039] This represents the j-th test incentive primitive. This is the functional description of the j-th test stimulus primitive. For the input and output parameter information of the j-th test stimulus primitive, For the j-th test incentive primitive usage pattern, Let j be the attribute access path for the j-th test incentive primitive.

[0040] The function description describes the function and business semantics of the primitive. The parameters include the name, type, unit, value range and default value of the input parameters, as well as the name and type of the output parameters. The usage pattern includes the typical calling method of the primitive, the calling sequence prerequisites and common calling combinations. The attribute access path is used to locate the call chain required for the primitive in the script.

[0041] It is understood that, by organizing each test stimulus primitive into a four-tuple knowledge record containing a functional description, parameters, usage mode, and attribute access path, the subsequent generation process can directly generate a valid primitive call statement based on the parameter definition and calling method recorded in the knowledge record after retrieving the relevant primitive, without having to re-infer the parameter type or call chain during the generation process, thereby further reducing the probability of generating incorrect calls.

[0042] Specifically, for each test stimulus primitive in the test stimulus primitive set, extract its function name, module or classpath, parameter list and type information in the function signature; combine the interface documentation or source code comments to obtain the business meaning, value range and unit of each parameter; extract the call sequence prerequisites and typical call combinations based on the call constraints recorded in the documentation or the call context in the source code; organize the above extracted information into a knowledge record in the format of a four-tuple; perform the above operations on all primitives in the test stimulus primitive set in sequence, and summarize all knowledge records to obtain the primitive knowledge base.

[0043] For example, for a certain acceleration signal injection primitive, its four-tuple knowledge record is as follows: the function description is "injecting an analog waveform signal into a specified lateral acceleration channel"; the input and output parameter information is waveform identifier, gain, and start time; the usage mode of the primitive is "first enable the target channel through channel validity settings, then call this primitive to inject the waveform, and after injection is completed, call the injection stop primitive to release the channel"; the attribute access path is "bench, signal generator, acceleration, injection". Summarizing the four-tuple knowledge records of all primitives forms the primitive knowledge base.

[0044] In this embodiment of the application, before obtaining the functional description of each test stimulus primitive, the syntax and semantics of the target test bench's input and output parameters, the usage pattern, and the attribute access path, the method further includes: if the attribute access path is identified as a target test bench that provides a structured interface document, then extracting the functional description, syntax and semantics, and usage pattern from the structured interface document; if the attribute access path is identified as a target test bench that provides interface source code, then extracting the interface layer entry function set from the interface source code, generating a function summary based on the interface layer entry function set, and extracting the functional description, syntax and semantics, and usage pattern from the context data generated by the function summary.

[0045] It is understood that by distinguishing between two types of test benches and adopting different acquisition routes, this application embodiment can produce knowledge records with consistent format regardless of whether the test bench provides structured interface documents or interface source code. This enables the subsequent generation process to have the same processing logic for different test benches, thereby enhancing the versatility and adaptability of the method.

[0046] It should be noted that the knowledge records produced by both routes are in the form of four-tuples and are ultimately used for subsequent semantic retrieval and primitive invocation. The only difference lies in the source of the knowledge records. For the platform that provides structured interface documents, the knowledge records come directly from the structured fields of the documents; for the platform that provides interface source code, the knowledge records come from function summaries generated after static analysis of the source code. The specific implementation method for generating function summaries based on the interface layer entry function set will be described in detail in subsequent embodiments.

[0047] Specifically, such as Figure 4 As shown, Figure 4 This is a roadmap for constructing the test incentive primitive knowledge base according to the embodiments of this application. For the platform where the interface source code is available, route A is used to construct the primitive knowledge base: starting with the interface layer entry function set, it sequentially proceeds through self-contained sub-package extraction, code attribute graph construction, call sub-graph merging, static metadata collection, and out-degree reverse topology layering, followed by bottom-up function-level summary generation, where the callee summary serves as the caller's generation context; subsequently, a primitive knowledge quadruple K(t) = (functional description, parameters, usage mode, attribute access path) is generated, i.e., the aforementioned quadruple. The quadruple is then serialized and quantized into the knowledge base K.

[0048] For frameworks with only structured interface documentation, Route B is used to construct a primitive knowledge base: quadruples are directly extracted at the class or module level to obtain a primitive knowledge quadruple K(t) = (functional description, parameters, usage mode, attribute access path). This quadruple is then serialized and quantized into the knowledge base K. The quadruples produced by both routes have the same format, thus ensuring that subsequent generation processes are independent of the framework type.

[0049] In this embodiment, generating a function summary based on the interface layer entry function set includes: treating all entry functions in the interface layer entry function set as callable primitives; generating code closures based on the callable primitives reachable by the functional test script; generating a code attribute graph based on the code closures, abstract syntax tree, control flow graph, and program dependency graph; generating a code call graph based on the caller-caller relationship in the code attribute graph; identifying the signature, source file path, line number, and macros used for each entry function in the code call graph; generating metadata based on the signature, source file path, line number, and macros used for each entry function; and generating a function summary based on the metadata.

[0050] In this context, code closure refers to the set of code formed from the perspective of the test script, consisting of all module dependencies traversed by the recursive parsing of import statements by each callable primitive. Metadata includes the signature of each function, the source file path, the line number, and the macros used, where macros are recursively expanded to restore their semantic names and logical code.

[0051] It is understood that the embodiments of this application limit the scope of static analysis to a subset of code related to the bench interface by constructing code closures, thereby reducing interference and computational overhead from irrelevant library code; by deriving a call graph from the code attribute graph and generating a function summary based on the call graph, the summary generation process can utilize the context of the call relationship between functions, and the generated summary can contain the typical usage and parameter passing patterns of the function when it is called; by recursively expanding macro definitions, the logic code encapsulated by macros can be restored, avoiding information loss caused by macro expansion.

[0052] It should be noted that when multiple primitives exist, their respective subgraphs may share function vertices and edges. For example, multiple primitives may jointly depend on the same underlying utility function. By merging the identical function vertices and shared edges in the subgraphs to form a unified call graph, common dependencies are processed only once in the unified graph, avoiding redundant analysis.

[0053] Specifically, starting with the project interface layer, all functions exported from this layer are considered callable primitives. Each primitive's import statements are recursively parsed, collecting all directly or indirectly dependent modules to form a code closure accessible from the self-test script's perspective. A code attribute graph, integrating an abstract syntax tree, control flow graph, and program dependency graph, is generated on this closure. The call graph is derived from the explicitly maintained caller-callee relationships within this graph. For each primitive, a depth-first search is performed rooted at that primitive to obtain its own subgraph. Then, identical function vertices and shared edges from each subgraph are merged to form a unified call graph. For each function in the unified call graph, its signature, source file path, line number, and macros used are recorded. Macros are recursively expanded to restore their semantic names and logical code. Metadata is generated based on this information, and a function summary for each entry function is generated based on this metadata.

[0054] For example, such as Figure 5 As shown, Figure 5 In this system, vertices are represented as functions, and directed edges represent call relationships. F and G are level 1 (leaf functions), C, D, and E are level 2, and A and B are level 3 (exposed test stimulus primitives). Starting from primitive A, its import statements are recursively parsed, collecting all directly or indirectly dependent modules to form a code closure. In the code attribute graph generated on the code closure, A calls C and D, C calls F, and D calls F and G, meaning A can reach C, D, F, and G; B calls D and E, D calls F and G, and E calls G, meaning B can reach D, E, F, and G. A depth-first search is performed with primitive A as the root to obtain a subgraph dedicated to A containing vertices A, C, D, F, and G, along with the aforementioned directed edges; a search is performed with primitive B as the root to obtain a subgraph dedicated to B containing vertices B, D, E, F, and G, along with the aforementioned directed edges. After merging the two subgraphs, D→F and D→G, as shared edges, are only retained in one copy in the unified call graph. For each function in the unified call graph, extract the function signature, file path, and line number from its source file, expand the macro definitions referenced internally, and generate metadata. Based on the metadata, generate a function summary for each entry function. This summary contains the function's semantic information, parameter descriptions, and calling method, which will be used in subsequent steps to extract the function description, parameter semantics, and usage patterns.

[0055] In this embodiment of the application, generating function summaries further includes: performing reverse topological sorting of the unified call graph according to its out-degree to determine the layers, so that the summaries of the callees are generated before those of the callers; for circular dependencies, generating component-level descriptions in units of strongly connected components and then regenerating summaries of each function within the component; within each layer, generating the function's functional description, parameter semantics, and usage patterns based on the function signature, source code fragments, macro definitions, and the summaries of the direct callees.

[0056] It is understood that the out-degree reverse topology layering in this application ensures that the summary of any function is generated only after the summaries of all its callees have been generated, guaranteeing that the semantic information of the callees can be correctly referenced in the caller's summary. The processing method of overall summary of strongly connected components solves the common circular call problem in embedded software, enabling recursive functions to be understood as a whole, avoiding deadlock or semantic fragmentation in summary generation caused by circular dependencies.

[0057] Specifically, the reverse topological order of each vertex in the unified call graph is calculated based on its out-degree. For acyclic components, summaries are generated layer by layer upwards, starting from the leaf function with an out-degree of 0. For cyclic components, strongly connected components are detected, and the source code and mutual call relationships of all functions within the component are submitted to the language model to generate a component-level description of the overall functionality of the component. Then, based on this description and the individual characteristics of each function, a separate summary is generated for each function within the component. Within each layer, the language model is provided with the function signature, the source code fragment located by the source file path and line number, macro definitions, and summaries of all direct callees, based on which the function's functional description, parameter semantics, and usage patterns are generated.

[0058] For example, such as Figure 5 As shown, vertices A and B are the externally exposed test stimulus primitives, while the remaining vertices are their reachable internal functions. The horizontal dotted lines divide the vertices into three layers, and the summary generation order is from layer 1 upwards, ensuring that when the summary of any vertex is generated, the summaries of all its callers are already ready. For example... Figure 6 As shown, X, Y, and Z within the dashed box are mutually reachable and therefore cannot be ordered. First, a component-level description is generated based on their implementation and mutual calling relationships. Then, summaries of each component are generated accordingly. P and Q outside the box are still... Figure 5The hierarchical processing is shown below. The data dependencies described above can be further referenced in Table 1, which shows the correspondence between intermediate artifacts, processing, and output in the construction of source code-based primitive knowledge. The intermediate artifacts listed in Table 1 correspond to the aforementioned source code-based primitive knowledge construction process: code closures are used to limit the scope of static analysis, corresponding to the recursive parsing of imported dependencies and collection of reachable modules starting from the interface layer entry function set; call graphs and unified call graphs are used to provide the call structure skeleton and merge common dependencies, corresponding to the generation of code attribute graphs on code closures, exporting call relationships, and merging identical function vertices and shared edges; signatures, source file paths, line numbers, and macros used in metadata are used to locate source code fragments, restore the encapsulated semantics and logic, and generate function summaries accordingly; attribute access paths in metadata are used to generate the actual call chains in the script. These intermediate artifacts sequentially enter the hierarchical summarization, primitive quadruple construction, and subsequent retrieval and verification stages.

[0059] Table 1

[0060] The aforementioned data dependencies enable "code closure, unified call graph, static metadata, hierarchical summarization, primitive quadruples, and retrieval and verification" to form a continuous processing chain, rather than being parallel steps of conventional static analysis, retrieval, or language model summarization.

[0061] In step S302, the functional requirements set, source code, and configuration data of the electronic control unit under test are obtained, and an enhanced requirements set is generated based on the functional requirements set, source code, and configuration data. The original functional requirements text in the functional requirements set is a natural language description of the function to be tested in the electronic control unit under test, and the enhanced requirements set includes multiple enhanced functional requirements texts.

[0062] It is understood that by acquiring the functional requirements set, source code, and configuration data, the subsequent generation process can further obtain the implementation layer context and project configuration information based on the original requirements, providing a data foundation for refining the coarse-grained requirements into ready descriptions that can generate test steps.

[0063] It should be noted that the configuration data includes at least one of the following: diagnostic fault codes, timing and delay constraints, parameter ranges, hardware input / output mappings of the target test bench, controlled object model parameters, and fault injection configurations. Each enhancement requirement text in the enhancement requirement set contains six fields: preconditions, trigger conditions, desired behavior, tolerance, configuration value, and criteria. Preconditions correspond to the initial state settings of the test, trigger conditions correspond to the stimulus operations, desired behavior and tolerance correspond to the baseline for observation and verification, configuration values ​​provide specific engineering parameters for the test, and criteria determine the pass or fail standard.

[0064] Specifically, the original functional requirement texts are extracted one by one from the functional requirement set. For each original functional requirement text, a requirement enhancement operation is performed to generate corresponding enhanced functional requirement texts. All enhanced functional requirement texts are then aggregated to obtain an enhanced requirement set. The requirement enhancement operations include: extracting implementation-level evidence related to the current requirement from the source code; extracting engineering values ​​related to the current requirement from the configuration data; and integrating the original requirement, implementation-level evidence, and configuration facts into a structured description.

[0065] In this embodiment of the application, generating an enhanced requirement set based on a functional requirement set, source code, and configuration data includes: generating a requirement point corpus based on the source code; selecting multiple target requirement points from the requirement point corpus; generating multiple enhanced functional requirement texts based on the multiple target requirement points and configuration data; and generating an enhanced requirement set based on the multiple enhanced functional requirement texts.

[0066] The requirement point corpus consists of a collection of independent behavioral descriptions extracted from the source code, with each requirement point corresponding to a fine-grained behavior implemented by a traceable function or code snippet in the source code. The target requirement points are a subset of requirement points selected from the requirement point corpus that are relevant to the original functional requirement text to be enhanced.

[0067] It is understood that, by extracting requirement point corpus from the source code, the implicit domain knowledge accumulated in the implementation code is made explicit into a searchable and matchable structured description, so that the subsequent enhancement process can associate the original requirements with the implementation layer evidence, thereby supplementing the information missing in the original requirements such as internal state transitions, filtering strategies, error recovery paths and parameter thresholds.

[0068] It's important to note that requirement points differ from the requirements in the original requirement text. Requirement points describe fine-grained implementation behaviors in the source code, rather than describing system-level functionality. Completeness indicates the degree of completeness of the requirement point information, while confidence indicates the model's confidence in the accuracy of that requirement point.

[0069] Specifically, such as Figure 7 As shown, Figure 7 This is a schematic diagram illustrating the enhanced data flow and two-stage retrieval based on embodiments of this application. Original Requirements The set of functional requirements R, configuration data C, and the source code S of the unit under test are used as inputs. A requirement point corpus is generated from the source code, specifically including: segmenting the source code according to module entry points; generating a module call graph and hierarchical semantic summary based on the segmentation results; and generating a requirement point corpus Q based on the module call graph and hierarchical semantic summary. Each requirement point in the requirement point corpus Q includes traceability, description, trigger, expectation, completeness, and confidence. When selecting a target requirement point from the requirement point corpus, the original functional requirement text is used. For the query, candidate requirement points are retrieved from the requirement point corpus Q through vector similarity in the first stage. Then, in the second stage, these candidate requirement points are rearranged based on their completeness and confidence to determine the target requirement point. Enhancement feature requirement text is generated based on the target requirement point and configuration data C. At that time, the implementation layer evidence recorded in the target requirement points is integrated with the engineering values ​​in the configuration data C. The language model then synthesizes the original requirements, evidence set, and configuration facts to generate the enhanced functional requirement text. Enhanced functional requirements text It belongs to the set of enhanced requirements R', which is in the form of a six-tuple:

[0070] Here, GIVEN is the precondition, specifying the initial state of the test; WHEN is the trigger condition, specifying the stimulus event; THEN is the expected behavior, specifying the response to be observed; WITHIN is the tolerance, specifying the threshold or time limit for the expected behavior; CONFIG is the configuration item, specifying the specific engineering values; and CRITERIA is the criterion, establishing the test prediction containing pass and fail assertions. Each newly added item is marked as originating from the configuration data C or the requirement corpus Q to maintain traceability.

[0071] For example, the original requirement for the side collision decision module is "the side collision algorithm should enter the working state and begin decision-making after detecting a significant side impact." After extracting the requirement corpus from the module's source code, a first-stage vector similarity recall is performed using the original requirement text as the query to filter semantically relevant candidate requirement points from the corpus. The second stage involves rearranging these candidate requirement points based on their completeness and confidence to determine the target requirement points, including: the filtering and wake-up criterion comparison is performed before the state branch and is executed every cycle; a wake-up request is set when the second-order filter output of any enabled sensor exceeds the positive wake-up threshold or falls below the negative wake-up threshold; velocity accumulation only occurs after entering the wake-up state; and if the signal remains below the wake-up threshold for a weak reset duration after wake-up, the wake-up state is exited and the accumulated amount and state machine data for this event are reset. Combining the wake-up threshold parameters, algorithm cycle, and weak reset duration in the configuration data, the language model integrates the original requirement, evidence set, and configuration facts to generate the enhanced functionality requirement text.

[0072] In this embodiment of the application, generating a demand point corpus based on the source code includes: segmenting the source code according to the module entry point; generating a module call graph and a hierarchical semantic summary based on the segmentation results; and generating a demand point corpus based on the module call graph and the hierarchical semantic summary.

[0073] Here, a module refers to an end-to-end functional chain that follows an open system architecture and spans multiple architectural layers. The module entry point refers to the operating system task function responsible for scheduling the module's behavior or the main function of the runnable entity that directly implements the logic.

[0074] It is understood that, by dividing the source code according to the module entry point and generating a module call graph and hierarchical semantic summary, the subsequent requirement extraction process can utilize the call relationship context and semantic summary between functions to more accurately identify the fine-grained behavior implemented by each function and its role in the overall module function.

[0075] It should be noted that the generation method of hierarchical semantic summarization is similar to the hierarchical summarization strategy for platform primitives in the aforementioned steps. That is, a bottom-up approach is adopted, so that the summarization of any function is generated only after the summarization of all its callees is generated, in order to ensure that the semantic information of the callees can be correctly referenced in the caller's summarization.

[0076] Specifically, for each module explicitly listed in the configuration data, its entry function is first determined, i.e., the operating system task function responsible for scheduling the module's behavior or the main function of the executable entity that directly implements the logic. Starting from the entry function, the included statements are recursively parsed, collecting directly and indirectly referenced source files and header files to construct a self-contained sub-package for the module, thereby isolating its code closure from the complete unit codebase for focused analysis. Then, the aforementioned hierarchical summarization process is reused to generate a semantic summary for each function within the sub-package. Based on the module call graph and semantic summaries, the module skeleton is gradually identified, function-level functionality is understood, and independent requirement points are extracted through thought chain reasoning. In one possible implementation, the semantic summary of each function is represented as: Summary_M(f) = <role, key_vars, trigger, logic_pts>. Here, role represents the function's responsibility within the module, key_vars represents the key variables that the function reads and writes and their business semantics, trigger represents the event that triggers the function's specific behavior, and logic_pts represents the boundary checks, error code assignments, or loop termination conditions related to testing in the function's implementation.

[0077] Based on the module call graph and semantic summary, this embodiment of the application can gradually identify the module skeleton, understand function-level functionality, and extract independent requirement points through thought chain reasoning. Each requirement point is represented as: req_pt=<traceability, desc, trigger, expected, completeness, confidence>, where traceability links to specific source code functions, desc describes behavior according to the GIVEN-WHEN-THEN-WITHIN paradigm, trigger and expected record the triggering condition and expected result, respectively, and completeness and confidence record the information completeness and model confidence, respectively. Each requirement point records its traceable source code function, a description following the "precondition, triggering condition, expected behavior, tolerance" paradigm, the event that triggers the behavior, the expected result, and two attributes: information completeness and model confidence. All requirement points are compiled into a requirement point corpus.

[0078] For example, refer to Figure 7 As shown, for the CAN (Controller Area Network) communication module, starting from the module's main execution entry point (a 5ms cycle operating system task function), the included statements are recursively analyzed to collect directly and indirectly referenced source files and header files, constructing a self-contained sub-package for the module. A module call graph is constructed starting from the entry point, and a bottom-up hierarchical summarization method is used to generate a semantic summary for each function. Based on the module call graph and semantic summary, requirement point corpus is extracted. For example, the requirement point "reset the counter when the bus is off" is extracted from the bus shutdown management function, and the requirement point "enable communication loss monitoring after bus shutdown recovery" is extracted from the message loss monitoring function. Each requirement point is labeled with its traceable source code function, information completeness, and model confidence.

[0079] In this embodiment of the application, selecting multiple target demand points from the demand point corpus includes: extracting each original demand point from the demand point corpus; calculating the similarity between the original functional demand text and the original demand points in the functional demand set; selecting multiple candidate demand points from the original demand points in the demand point corpus based on the similarity; obtaining the completeness and confidence of each candidate demand point; and determining multiple target demand points from the multiple candidate demand points based on the completeness and confidence.

[0080] The similarity is calculated based on vector cosine similarity. The original functional requirement text and the original requirement points are transformed into high-dimensional vectors through an embedding model, and then the cosine distance between them is calculated. Completeness represents the degree of completeness of the requirement point information, while confidence represents the model's degree of certainty regarding the accuracy of that requirement point.

[0081] It is understood that the embodiments of this application employ a two-stage retrieval process. First, candidate demand points are recalled based on vector similarity, and then they are rearranged based on completeness and confidence. This ensures that the final selected target demand points are not only semantically related to the original demand, but also meet the requirements in terms of information quality and model confidence, thereby guaranteeing the quality of evidence on which the enhanced demand is based.

[0082] It should be noted that the first stage is vector similarity recall, which aims to quickly filter out a candidate set that is semantically similar to the original demand from the demand point corpus; the second stage is re-ranking by completeness and confidence, which aims to select the target demand point with the highest information quality from the candidate set as the basis for enhancement. The two-stage retrieval takes into account both recall efficiency and ranking quality.

[0083] Specifically, for each original functional requirement text, it is input into an embedding model to obtain a query vector. The description fields of each requirement point in the requirement corpus are input into the same embedding model to obtain vector representations of each requirement point. The cosine similarity between the query vector and each requirement point vector is calculated, and the requirements points are sorted from highest to lowest similarity. The top-ranked requirements points are selected as candidate requirements points. The completeness and confidence attribute values ​​of each candidate requirement point are obtained, and they are sorted from highest to lowest completeness. If the completeness is the same, they are sorted from highest to lowest confidence. The top-ranked candidate requirements points are selected as target requirements points.

[0084] For example, given the original requirement text "The side collision algorithm should enter the working state and begin decision-making after detecting a significant side impact," multiple candidate requirement points are recalled from the requirement point corpus using vector similarity. Among them, requirement points related to wake-up criteria and state switching have high similarity. After obtaining the completeness and confidence of each candidate requirement point, four requirement points with high completeness and confidence are selected as target requirement points. Filtering and wake-up criterion comparison are performed before the state branch and are executed every cycle; the second-order filter output of any enabled sensor sets a wake-up request if it exceeds the positive wake-up threshold or falls below the negative wake-up threshold; velocity accumulation is only performed after entering the wake-up state; and if the signal remains below the wake-up threshold for a weak reset duration after wake-up, the wake-up state is exited and the accumulated amount and state machine data for this event are reset. These target requirement points collectively cover the implementation details missing from the original requirement.

[0085] The above process can be referred to Table 2. Table 2 takes the CAN communication module as an example and gives a complete traceability example from module entry identification to enhanced requirement output. Table 2 is the traceability example table of "entry point - code closure - requirement point - enhanced requirement" of the CAN communication module.

[0086] Table 2

[0087] Therefore, the bench interface source code closure and the unit under test module source code closure can be two different artifacts: the former produces callable primitive knowledge records, and the latter produces requirement points describing the behavior under test; the two are only connected when the enhanced requirements are decomposed into test steps and matched with primitives.

[0088] In step S303, a functional test script for the electronic control unit under test is generated based on the enhanced requirements set and the primitive knowledge base. The target test bench then uses the functional test script to test the electronic control unit under test.

[0089] The functional test script is program code that can be directly executed on the target test bench to verify the functionality of the electronic control unit under test. Each statement in the functional test script corresponds to the test implementation of one enhanced functional requirement text in the enhanced requirements set.

[0090] It is understood that the embodiments of this application generate functional test scripts based on the enhanced requirement set and the primitive knowledge base, so that the generation process can simultaneously utilize the implementation layer context carried in the enhanced requirements and the legal primitive information recorded in the primitive knowledge base to automatically transform the test intent into a primitive call sequence that can be executed on the bench, thereby eliminating the step in the related technology where testers manually establish the correspondence between behavior tree nodes and primitives.

[0091] Specifically, the process from the enhancement requirement set and primitive knowledge base to the generation of functional test scripts includes decomposing the enhancement requirements into test steps, representing the test steps as intermediate behavior trees and applying primitive knowledge base constraints, and translating the validated behavior trees into executable scripts according to deterministic rules.

[0092] In this embodiment of the application, generating a functional test script for the electronic control unit under test based on an enhanced requirement set and a primitive knowledge base includes: generating multiple test steps based on the enhanced requirement set; representing the multiple test steps as a behavior tree and applying constraints to the behavior tree using the primitive knowledge base; and generating a functional test script based on the behavior tree with the constraints applied.

[0093] Among them, the behavior tree is a tree-shaped data structure used to carry the hierarchical structure and control flow of test steps. The test steps are organized according to five phases: initialization, activation, observation, verification, and cleanup.

[0094] It is understood that, by representing the test steps as an intermediate representation of a behavior tree, the high-level test intent can be decomposed layer by layer in the behavior tree until it is aligned with the bench primitives, providing a structured intermediate carrier for subsequent deterministic translation.

[0095] It should be noted that the node types in the behavior tree include composite nodes, decorator nodes, and leaf nodes. Composite nodes are used to define the control flow, including sequential nodes and selection nodes. Sequential nodes execute child nodes in order and fail immediately if any child node fails. Selection nodes execute child nodes sequentially and succeed immediately if the first one succeeds. Decorator nodes are used to decorate their unique child nodes, including loop nodes and traversal nodes. Loop nodes repeatedly execute child nodes a fixed number of times or until a termination condition is met. Traversal nodes execute child nodes element by element in the dataset. Leaf nodes include action nodes and condition nodes. Action nodes encapsulate specific primitive calls, and condition nodes compute Boolean predicates and represent assertion results as success or failure. The five phases of the test steps each perform different testing functions. The initialization phase establishes the power supply and environment settings for the preconditions, mainly composed of action nodes. The excitation phase applies the events defined by the trigger conditions, covering operations such as signal injection, mainly composed of action nodes. The observation phase periodically monitors the actual behavior or state values ​​of the capture unit, typically consisting of loop nodes nested with traversal nodes and including read actions. The verification phase compares the observed results with the expected behavior and tolerance terms, and asserts compliance according to the criteria terms, with the assertions carried by the condition nodes. The cleanup phase restores the safe state to avoid affecting subsequent tests, and mainly consists of action nodes.

[0096] Specifically, when generating multiple test steps based on enhancement requirements, each field in the six-tuple is mapped to the test actions of the corresponding stage: the precondition item is mapped to the initialization stage action, the trigger condition item is mapped to the stimulus stage action, the expected behavior item and tolerance item are mapped to the expected and tolerance benchmarks of the observation and verification stage, the configuration item provides the actual parameter values ​​for each action, and the criterion item is mapped to the assertion conditions of the verification stage. When representing the test steps as a behavior tree, the five stages are organized sequentially under the root sequence node, and each stage is expanded into one or more child nodes. When applying constraints to the behavior tree using the primitive knowledge base, the natural language description in the action node is mapped to a query vector, and the cosine similarity is calculated with the functional description of each primitive in the primitive knowledge base. The primitive record with the closest semantics is retrieved, and the action node is instantiated using the function name, parameter definition, and attribute access path in that record.

[0097] For example, such as Figure 8As shown in Table 5, and in conjunction with the test steps and primitive instantiation results of the side collision decision module, the root node in the behavior tree logic topology view is a sequential node, with the five stages of initialization, activation, observation, verification, and cleanup serving as child nodes of the root node in sequence. Specifically, the initialization stage establishes preconditions and expands into four action nodes: power supply control, calibration data loading, channel validity setting, and algorithm reset. The activation stage applies trigger conditions and expands into a signal waveform injection action node. The observation stage periodically collects and traverses key variables, encapsulating them in a loop node and nesting traversal nodes within it to iterate over each enabled channel; the child nodes of the traversal node are sequential nodes containing time event readings and internal signal readings. The verification stage asserts against the expected behavior and tolerance, transforming it into a condition node carrying time event existence assertions and weak reset timer assertions. The cleanup stage restores the safe state and expands into three action nodes: injection stop, channel release, and power supply control. The function names of each action node can be resolved to records in the primitive knowledge base, and the actual parameters are instantiated from the configuration data.

[0098] In the embodiments of this application, the constraints of the behavior tree include primitive constraints, parameter constraints, and expression constraints.

[0099] Among them, primitive constraints include that the function name of each action node can be resolved to the record of test stimulus primitives in the primitive knowledge base; parameter constraints include that the actual parameters of each action node conform to the parameter definitions of test stimulus primitives in the primitive knowledge base; and expression constraints include that the logic in condition nodes and loop nodes is restricted to a safe subset, and the safe subset includes at least one comparison operation, Boolean operation, arithmetic operation, and parentheses.

[0100] It is understood that the embodiments of this application use primitive-level, parameter-level and expression-level triple constraints to make the behavior tree statically checked during the generation stage, ensuring that the function name, actual parameters and logical expressions of each action node meet the executable conditions before code generation, thus avoiding execution failures caused by non-existent primitives, mismatched parameters or unsafe expressions after generation.

[0101] It should be noted that each of the three constraints performs a different verification function. The primitive constraint verifies whether the action node uses a function name that does not exist in the primitive knowledge base, preventing fictitious interfaces. The parameter constraint verifies whether the actual parameter type, unit, and value range of the action node are consistent with the definition of the primitive in the knowledge base, preventing parameter misuse. The expression constraint verifies whether the logical expressions in the condition and loop nodes contain only safe operation types, preventing uncontrollable logical behavior at runtime.

[0102] Specifically, structure and type checks are performed immediately after the behavior tree is generated. At the primitive level, all action nodes in the behavior tree are traversed, and the function name field of each action node is matched against the function names of the corresponding records in the primitive knowledge base. If a match fails, a feedback loop is triggered for regeneration. At the parameter level, the argument dictionary of each action node is checked item by item to ensure that the argument name, type, unit, and value range conform to the parameter definition of the corresponding primitive in the knowledge base. If not, a feedback loop is triggered for regeneration. At the expression level, the logical expressions in conditional and loop nodes are parsed to ensure they only contain comparison, Boolean, arithmetic, and parentheses operations. If other operation types are included, a feedback loop is triggered for regeneration. Any failed check is fed back to the generation stage for regeneration until all three levels of checks pass.

[0103] For example, such as Figure 9 As shown, Figure 9 The diagram illustrates a three-level constraint system according to an embodiment of this application. The three levels of constraints, from top to bottom, are primitive level, parameter level, and expression level. Primitive level checks whether the function name of each action node can be resolved to a quadruple in the primitive knowledge base K. For example, function names such as "power supply control" and "signal waveform injection" can be resolved to corresponding records in the knowledge base and pass. If a function name not found in the knowledge base is present, regeneration is triggered. Parameter level checks whether the actual parameters of the action node conform to the type, unit, and value range of the quadruple in the knowledge base. For example, the parameter state value of "power supply control" should be "ON" or "OFF." If other values ​​such as "True" are present, regeneration is triggered. Expression level checks whether the logical expressions in condition nodes and loop nodes are limited to comparison operations, Boolean operations, arithmetic operations, and parentheses. For example, "entering a time event exists and the time of entering the time event is less than or equal to the upper limit" only contains comparison operations and Boolean operations and passes. If it contains function calls or pointer operations, regeneration is triggered. If any level of validation fails, the feedback loop will send the data back to the generation stage for regeneration. Only after all three levels of validation pass can the behavior tree enter the script code generation stage.

[0104] In this embodiment of the application, generating a functional test script based on a behavior tree with imposed constraints includes: translating the behavior tree into an executable script according to deterministic rules, and configuring the language model to perform minimal repairs on the functional test script while keeping the control flow structure unchanged.

[0105] Among them, deterministic rules refer to the pre-established fixed mapping relationship between behavior tree syntax and target script syntax. Minimal repair refers to correcting only formatting issues or argument literals.

[0106] It is understood that the embodiments of this application translate behavior trees into scripts through deterministic rule mapping, making the transformation path from behavior trees to target code deterministic and predictable. This eliminates the need for the language model to re-infer the code structure each time it is generated, thus ensuring the structural consistency and stability of the generated scripts. Simultaneously, placing the cleanup phase within the final executed code block ensures that resource recovery operations are performed regardless of whether test assertions pass or fail, preventing bench remnants from abnormal script exits from affecting subsequent test execution. The minimal repair constraint of the language model ensures that the refinement phase will not introduce new errors or alter the established test logic.

[0107] It should be noted that in hardware-in-the-loop testing, if the bench power supply is not disconnected or the signal channel is not released due to an abnormal script exit, the residual state may affect the execution results of subsequent test cases, or even cause hardware damage. The final execution code block is the code block in the scripting language's exception handling structure that will be executed regardless of whether the main execution sequence ends normally or an exception occurs. Placing the cleanup phase within the final execution code block ensures that safe recovery operations are still performed in the event of verification failure or an exception.

[0108] Specifically, when translating the behavior tree into an executable script according to deterministic rules, each node type of the behavior tree is mapped to the corresponding syntactic structure of the target scripting language. The root sequence node becomes the top-level test function, its child nodes expand into sequential code blocks, selection nodes are translated into branching structures, condition nodes into conditional statements or assertion checks, loop nodes and traversal nodes into iterative structures, and action nodes expand into direct primitive function calls, with the function name and arguments extracted from the information recorded in the action node. The cleanup phase is fixed in the final executable code block. After the rule transformation, a lightweight refinement phase is introduced, providing the language model with a summary of the generated script and related primitives for syntax and semantic checks. This phase is strictly limited to minimal repairs, such as correcting indentation, adding missing parentheses, and adjusting the unit representation of numerical values; it must not change the control flow structure or introduce new primitives. Before refinement, the node type sequence, parent-child relationships, phase identifiers, and primitive record identifiers of the behavior tree are saved. After refinement, the generated script is re-parsed and structural consistency checks are performed according to the following rules: The number of control flow nodes (sequence nodes, selection nodes, loop nodes, traversal nodes) is checked against the original count; the nesting relationships of nodes are checked against changes; the cleanup phase is checked to ensure it remains fixed within the final execution block and has not been moved or deleted; the set of action nodes included in the cleanup phase is checked against the original count; and all primitive calls are checked to ensure they can be resolved to records in the primitive knowledge base. If any of these checks fail, the refinement result is rejected, and the original script is retained. Modifications to formatting or argument literals, such as adjusting indentation, adding parentheses, correcting numerical formats or string literals, are added to the whitelist of allowed modifications. Modifications such as adding branch structures, deleting or moving action nodes in the cleanup phase, introducing function calls not found in the primitive knowledge base, or changing loop boundaries or traversal ranges are added to the blacklist of prohibited modifications and are rejected upon detection. The refined script undergoes three levels of checks: primitive level, parameter level, and expression level. It also performs target language syntax checks or compilation checks. Once all checks pass, the final executable script is output.

[0109] For example, for the behavior tree of the side collision decision module, combining the test steps in Table 5 and the primitive instantiation results, the root sequence node becomes the top-level test function. The action nodes in the initialization phase, such as power supply control, calibration data loading, channel validity setting, and algorithm reset, are sequentially expanded into corresponding primitive call statements. The loop nodes in the observation phase are translated into loop structures, and the traversal nodes into traversal structures. The condition nodes in the verification phase are translated into assertion statements. The action nodes in the cleanup phase, such as injection stop, channel release, and power supply control, are fixed in the final executed code block. After rule transformation, the language model checks the generated script for formatting errors, such as correcting indentation or adding missing parentheses, but does not change the branch structure, loop structure, function call order, or assertion position, nor does it introduce function calls that do not exist in the primitive knowledge base. If the language model attempts to add branch structures, delete cleanup phase action nodes, or introduce unregistered primitive calls during refinement, the refined structural consistency check will reject the result and retain the script before refinement. After passing the structural consistency check, a third-level check and a target language syntax check are performed again; after all checks pass, the final executable script is output.

[0110] The above process can be referred to in Table 3. Taking the CAN communication module as an example, Table 3 shows the complete intermediate results and their data dependencies from the enhancement requirements to the primitive sequence, behavior tree intermediate representation, and final executable script. Table 3 is a specific example of the end-to-end intermediate results and preceding and following data dependencies of the CAN communication module. The deterministic mapping rules from behavior tree to script can be applied to embodiments of other modules. In Table 3, main_steps represents the main execution sequence; Message_List represents the message list, whose elements include configurations such as message name, timeout, and fault code, where name represents the message name, timeout represents the timeout, and dtc represents the fault code; cleanup_steps represents the cleanup sequence.

[0111] Table 3

[0112] According to the functional test script generation method proposed in this application, the method obtains the test stimulus primitive set of the target test bench and constructs a primitive knowledge base, enabling subsequent generation stages to obtain semantically explicit and searchable primitive record sources; it obtains the functional requirement set, source code, and configuration data of the electronic control unit under test and generates an enhanced requirement set, transforming the original natural language requirements into a structured description containing preconditions, triggering conditions, expected behaviors, tolerances, configuration values, and criteria, providing a complete test context for the generation stage; it decomposes the enhanced requirements into five stages of test steps—initialization, stimulus, observation, verification, and cleanup—and uses a behavior tree as an intermediate representation, allowing high-level test intentions to be decomposed layer by layer in the behavior tree until aligned with the bench primitives; it applies triple constraints at the primitive level, parameter level, and expression level and provides feedback for regeneration when verification fails, ensuring that each node in the behavior tree automatically meets the executable conditions at the function name, actual parameter, and logical expression levels; and it translates the behavior tree into an executable script according to deterministic rules, making the conversion path from the behavior tree to the target code deterministic and predictable, with the cleanup stage fixed in the final execution code block to ensure that resource recovery is not affected by assertion failures or exceptions. This allows the correspondence between the node configuration of the behavior tree and the callable primitives provided by the bench interface to be automatically established during the generation process. The test steps can be automatically decomposed into a continuous primitive call sequence, eliminating the gaps in manual intervention caused by the difference in granularity between test steps and bench primitives in related technologies, and realizing end-to-end automated test script generation.

[0113] The following uses the side collision decision module of a passenger vehicle restraint system control unit as an example to illustrate the functional test script generation method of this application embodiment. The algorithm task cycle of the side collision decision module can be 0.5ms. The decision chain is only connected when the algorithm is in the wake-up state, while signal filtering and wake-up criterion comparison are executed cycle by cycle in both the sleep state and the wake-up state. Specifically: The original requirement was a coarse-grained description: the side collision algorithm should enter the working state and begin decision-making after detecting a significant side impact. This description did not specify which signal the wake-up criterion applies to, the time limit for state transition, or the conditions for exiting the wake-up state, making it a typical early requirement irrelevant to implementation.

[0114] The requirement enhancement phase starts from the module entry point, constructs a self-contained sub-package, and generates a hierarchical semantic summary, extracting four relevant requirement points: the filtering and wake-up criterion comparison is located before the state branch and is executed every cycle; a wake-up request is set when the second-order filter output of any enabled sensor exceeds the positive wake-up threshold or falls below the negative wake-up threshold; speed accumulation only occurs after entering the wake-up state; if the signal remains below the wake-up threshold for a weak reset duration after wake-up, the wake-up state is exited and the accumulated amount and state machine data of this event are reset. Combining the wake-up threshold parameter, algorithm cycle, and weak reset duration in the configuration data, the generated enhanced requirements are shown in Table 4, which is a table of six-tuple examples of enhanced requirements.

[0115] Table 4

[0116] The threshold-crossing sampling point refers to the sampling moment when the signal filter output first crosses the wake-up threshold, that is, the sampling point when the second-order filter output first exceeds the positive wake-up threshold or first falls below the negative wake-up threshold. The state transition is completed within one algorithm cycle from the threshold-crossing sampling point, meaning that the state transition from sleep state to wake-up state is completed within 0.5ms from that sampling moment.

[0117] During the requirement decomposition phase, the enhanced requirement is converted into a five-stage test step, and each step is aligned with a specific primitive, as shown in Table 5. Table 5 is a table of test steps and primitive instantiation results.

[0118] Table 5

[0119] The behavior tree generation stage constructs the above sequence into a behavior tree rooted at the sequential node, with the five stages serving as its child nodes in sequence, such as... Figure 8 As shown, the observation phase is encapsulated within a loop node, which in turn nests traversal nodes to iterate through each enabled channel. The verification phase transitions to a condition node. The child nodes of the root sequence node are arranged in the following order: initialization phase action node group, activation phase action node group, observation phase loop node, verification phase condition node group, and cleanup phase action node group. The traversal nodes within the loop node contain nested sequence nodes for the observation phase read actions, forming an execution sequence of initialization, activation, loop observation, verification, and finally cleanup. After generation, the code undergoes triple constraint verification: the function names of each action node can be resolved to primitive knowledge base entries; the types, units, and value ranges of the actual parameters conform to the parameter definitions in the knowledge base; and the condition node expressions only contain comparisons and Boolean operations.

[0120] During the script generation phase, the behavior tree is translated into a script according to deterministic mapping rules: the root sequential node becomes the top-level test function, action nodes expand into primitive calls, loop and traversal nodes are translated into iterative structures, and condition nodes are translated into assertions. In the cleanup phase, the final executable code block is translated in, and the function returns true only if all assertions pass and there are no exceptions. The refinement phase only corrects the format of the actual parameter literals, without altering the control structure. The resulting script can be directly deployed to the test bench for execution.

[0121] The embodiments of this application have been verified on two industrial-grade electronic control units. Test Object A is a constraint system control unit, tested on a hardware-in-the-loop test bench with a project-level encapsulated interface containing 511 test stimulus primitives. Test Object B is an active safety domain controller, also tested on a hardware-in-the-loop test bench, with its interface provided in a structured document containing 1548 test stimulus primitives. Test Object A contains 18 modules and 683 functional requirements, while Test Object B contains 19 modules and 1252 functional requirements. Both have engineer-verified manual test scripts as benchmarks.

[0122] Executability is evaluated at three progressive levels: syntax, semantics, and oracle. Functional correctness is determined by engineers through random sampling and comparison of the test logic of the generated script and the manual script, as shown in Table 6. Table 6 is a table of the executability and functional correctness of the generated script.

[0123] Table 6

[0124] The judgment results of the manually generated script were compared with those of the manually generated script. The generated script identified 39 functional defects on test object A and 25 on test object B that were not covered or triggered by the manually generated script, totaling 64 defects, all of which were confirmed as valid defects. Defect analysis showed that these defects are related to the boundary conditions and internal state criteria introduced by the source code grounding requirement enhancement mechanism.

[0125] In terms of efficiency, the end-to-end time required to build a complete test script set for a single test object was recorded and compared with the conventional manual process. The results are shown in Table 7, which is a comparison table of end-to-end time consumption.

[0126] Table 7

[0127] Furthermore, statistics show that 74.21% of the generated scripts can be used without any manual modification, while the remaining scripts requiring repair have a code change ratio of 9.98%, indicating that this method handles the writing of the vast majority of boilerplate code and structured test logic.

[0128] Ablation experiments were used to evaluate the impact of each component. Removing the primitive knowledge base reduced the executable rate to zero, and the generated scripts were filled with fictitious functions that did not exist in the bench environment. Removing the requirement enhancement still resulted in a relatively high executable rate, but the accuracy of functional correctness and defect detection dropped significantly, indicating that the generated scripts only covered the simplest input and output logic when the implementation layer context was lacking. Removing the requirement decomposition significantly reduced the executable rate, which was due to the overload of context to be processed in a single generation, leading to skipped logical steps and missing variable definitions.

[0129] like Figure 10 As shown, Figure 10 This is a schematic diagram comparing ablation experiments provided according to embodiments of this application. The four schemes, from bottom to top, are: the complete scheme, scheme without requirement decomposition, scheme without requirement enhancement, and scheme without primitive knowledge base. The three metrics for each scheme are executability, functional correctness, and defect detection accuracy. Specifically, the complete scheme has an executability rate of 90.3%, a functional correctness rate of 89.7%, and a defect detection accuracy rate of 95.0%; the scheme without requirement decomposition has an executability rate of 79.6%, a functional correctness rate of 73.2%, and a defect detection accuracy rate of 74.7%. The significant decrease in executability after removing requirement decomposition is due to the overload of context to be processed in a single generation, leading to skipped logical steps and missing variable definitions; the scheme without requirement enhancement has an executability rate of 89.2%, a functional correctness rate of 50.5%, and a defect detection accuracy rate of 46.1%. Even after removing requirement enhancement, the executable rate remained high, while the functional correctness and defect detection accuracy dropped significantly. This indicates that without implementation layer context, the generated scripts only cover the simplest input / output logic, presenting superficial success but lacking testing depth. Removing the primitive knowledge base reduced the executable rate to 0%. The generated scripts would call fictitious functions that did not exist in the benchtop environment, failing at the syntax level. Since no executable script existed at this point, functional correctness and defect detection accuracy could not be statistically analyzed, hence the dash "-". The above data shows that the three core steps of primitive knowledge base, requirement enhancement, and requirement decomposition all significantly contribute to the executable rate, functional correctness, and defect detection accuracy of the generated scripts. Removing any one of these steps leads to a significant decrease in at least one of these metrics.

[0130] like Figure 11 As shown, Figure 11 This diagram illustrates the performance comparison of different large language models according to embodiments of this application. When changing to four different large language models, the functional test script generation method provided in this application can generate executable scripts in all cases. Specifically, Model A has an execution rate of 90.33%, functional correctness of 89.69%, and 39 new defects; Model B has an execution rate of 89.87%, functional correctness of 86.60%, and 37 new defects; Model C has an execution rate of 89.42%, functional correctness of 82.47%, and 34 new defects; and Model D has an execution rate of 86.75%, functional correctness of 79.38%, and 30 new defects. Thus, the functional correctness and other indicators vary with the model performance, indicating that the process design has cross-model applicability, and that the choice of model affects the processing results.

[0131] Next, the functional test script generation apparatus according to the embodiments of this application is described with reference to the accompanying drawings.

[0132] Figure 12This is a block diagram of a functional test script generation apparatus provided according to an embodiment of this application.

[0133] like Figure 12 As shown, the functional test script generation device 1200 includes: a construction module 1201, an enhancement module 1202, and a generation module 1203.

[0134] The construction module 1201 is used to obtain the test stimulus primitive set of the target test bench and construct a primitive knowledge base based on the test stimulus primitive set. The test stimulus primitives in the test stimulus primitive set represent functions called in the functional test script to drive the target test bench. The enhancement module 1202 is used to obtain the functional requirements set, source code, and configuration data of the electronic control unit under test and generate an enhancement requirement set based on the functional requirements set, source code, and configuration data. The original functional requirement text in the functional requirement set is a natural language description of the function to be tested in the electronic control unit under test, and the enhancement requirement set includes multiple enhancement functional requirement texts. The generation module 1203 is used to generate a functional test script for the electronic control unit under test based on the enhancement requirement set and the primitive knowledge base. The target test bench uses the functional test script to test the electronic control unit under test.

[0135] It should be noted that the foregoing explanation of the functional test script generation method embodiment also applies to the functional test script generation device of this embodiment, and will not be repeated here.

[0136] According to the functional test script generation device proposed in this application, by acquiring the test stimulus primitive set of the target test bench and constructing a primitive knowledge base, the subsequent generation stage obtains semantically explicit and searchable primitive record sources; by acquiring the functional requirement set, source code, and configuration data of the electronic control unit under test and generating an enhanced requirement set, the original natural language requirements are transformed into a structured description containing preconditions, triggering conditions, expected behaviors, tolerances, configuration values, and criteria, providing a complete test context for the generation stage; by decomposing the enhanced requirements into five stages of test steps—initialization, stimulus, observation, verification, and cleanup—and using a behavior tree as an intermediate representation, the high-level test intent is decomposed layer by layer in the behavior tree until it aligns with the bench primitives; by applying triple constraints at the primitive level, parameter level, and expression level and feeding back regeneration when verification fails, each node in the behavior tree automatically satisfies the executable conditions at the level of function name, actual participants, and logical expressions; by translating the behavior tree into an executable script according to deterministic rules, the conversion path from the behavior tree to the target code is determined and predictable, and the cleanup stage is fixed in the final execution code block so that resource recovery is not affected by assertion failures or exceptions. This allows the correspondence between the node configuration of the behavior tree and the callable primitives provided by the bench interface to be automatically established during the generation process. The test steps can be automatically decomposed into a continuous primitive call sequence, eliminating the gaps in manual intervention caused by the difference in granularity between test steps and bench primitives in related technologies, and realizing end-to-end automated test script generation.

[0137] Figure 13 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. The electronic device may include: The memory 1301, the processor 1302, and the computer program stored on the memory 1301 and executable on the processor 1302.

[0138] When the processor 1302 executes the program, it implements the functional test script generation method provided in the above embodiments.

[0139] Furthermore, electronic devices also include: Communication interface 1303 is used for communication between memory 1301 and processor 1302.

[0140] The memory 1301 is used to store computer programs that can run on the processor 1302.

[0141] The memory 1301 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage.

[0142] If the memory 1301, processor 1302, and communication interface 1303 are implemented independently, then the communication interface 1303, memory 1301, and processor 1302 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 13 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0143] Optionally, in a specific implementation, if the memory 1301, processor 1302, and communication interface 1303 are integrated on a single chip, then the memory 1301, processor 1302, and communication interface 1303 can communicate with each other through an internal interface.

[0144] The processor 1302 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement the embodiments of this application.

[0145] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method for generating functional test scripts.

[0146] This application also provides a computer program product, including a computer program or instructions, which, when executed, implement the above-described method for generating functional test scripts.

[0147] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0148] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0149] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0150] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (FPGAs), field-programmable gate arrays (FPGAs), etc.

[0151] Those skilled in the art will understand that all or part of the steps of the methods implementing the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0152] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for generating functional test scripts, characterized in that, Includes the following steps: Obtain the test stimulus primitive set of the target test bench, and construct a primitive knowledge base based on the test stimulus primitive set, wherein the test stimulus primitives in the test stimulus primitive set represent functions that are called in the functional test script to drive the target test bench; Obtain the functional requirements set, source code, and configuration data of the electronic control unit under test. Generate an enhanced requirements set based on the functional requirements set, the source code, and the configuration data. The original functional requirements text in the functional requirements set is a natural language description of the function to be tested in the electronic control unit under test. The enhanced requirements set includes multiple enhanced functional requirements texts. The electronic control unit under test is generated based on the enhanced requirements set and the primitive knowledge base, and the target test bench uses the functional test script to test the electronic control unit under test.

2. The functional test script generation method according to claim 1, characterized in that, The source code follows the layered specifications of the automotive open system architecture, and the configuration data includes multiple diagnostic fault codes, timing and delay constraints, parameter ranges, hardware input / output mapping of the target test bench, controlled object model parameters, and fault injection configurations.

3. The functional test script generation method according to claim 1, characterized in that, The step of constructing a primitive knowledge base based on the test stimulus primitive set includes: Extract each test stimulus primitive from the set of test stimulus primitives; Obtain the functional description of each test stimulus primitive, the syntax and semantics of the target test bench input and output parameters, the usage mode, and the attribute access path, and generate a record array based on the functional description, the syntax and semantics, the usage mode, and the attribute access path; The record array is used as the knowledge record of the test stimulus primitive; The primitive knowledge base is generated based on the knowledge record of each of the aforementioned test incentive primitives.

4. The functional test script generation method according to claim 3, characterized in that, Before obtaining the functional description of each test stimulus primitive, the syntax and semantics of the target test bench input and output parameters, the usage pattern, and the attribute access path, the following steps are also included: If the attribute access path is identified as a target test bench that provides structured interface documentation, then the functional description, the syntax and semantics, and the usage pattern are extracted from the structured interface documentation. If the attribute access path is identified as a target test bench that provides interface source code, then the interface layer entry function set is extracted from the interface source code, a function summary is generated based on the interface layer entry function set, and the function description, the syntax and semantics, and the usage pattern are extracted from the context data generated by the function summary.

5. The functional test script generation method according to claim 4, characterized in that, The step of generating a function summary based on the interface layer entry function set includes: All entry functions in the interface layer entry function set are treated as callable primitives; Generate code closures based on the callable primitives reachable by the functional test script; A code property graph is generated based on the code closure, abstract syntax tree, control flow graph, and program dependency graph. A code call graph is generated based on the caller-callee relationship in the code property graph. Identify the signature, source file path, line number, and macros used for each entry function in the code call graph. Generate metadata based on the signature, source file path, line number, and macros used for each entry function. Generate a function summary based on the metadata.

6. The functional test script generation method according to claim 1, characterized in that, The step of generating an enhanced requirement set based on the functional requirement set, the source code, and the configuration data includes: Generate a demand point corpus based on the source code, and select multiple target demand points from the demand point corpus; Multiple enhanced feature requirement texts are generated based on the multiple target requirement points and the configuration data; The enhancement requirement set is generated based on multiple enhancement requirement texts.

7. The functional test script generation method according to claim 6, characterized in that, The step of generating the demand point corpus based on the source code includes: The source code is divided according to the module entry point; Generate a module call graph and hierarchical semantic summary based on the segmentation results; The requirement point corpus is generated based on the module call graph and the hierarchical semantic summary.

8. The method for generating functional test scripts according to claim 6, characterized in that, The step of selecting multiple target demand points from the demand point corpus includes: Extract each original demand point from the demand point corpus; Calculate the similarity between the original functional requirement text and the original requirement points in the functional requirement set; Based on the similarity, multiple candidate demand points are selected from the original demand points in the demand point corpus. The completeness and confidence of each candidate requirement point are obtained, and multiple target requirement points are determined from the multiple candidate requirement points based on the completeness and the confidence.

9. The method for generating functional test scripts according to claim 1, characterized in that, The step of generating the functional test script for the electronic control unit under test based on the enhanced requirements set and the primitive knowledge base includes: Multiple test steps are generated based on the enhanced requirements set; Multiple test steps are represented as behavior trees, and constraints are imposed on the behavior trees using the primitive knowledge base. The functional test script is generated based on the behavior tree after constraints are applied.

10. The method for generating functional test scripts according to claim 9, characterized in that, The constraints of the behavior tree include primitive constraints, parameter constraints, and expression constraints. The primitive constraints include that the function name of each action node can be resolved to the record of the test stimulus primitive in the primitive knowledge base. The parameter constraints include that the actual parameters of each action node conform to the parameter definitions of the test stimulus primitives in the primitive knowledge base. The expression constraints include that the logic in the condition nodes and loop nodes is restricted to a safe subset, and the safe subset includes at least one comparison operation, Boolean operation, arithmetic operation, and parentheses.

11. A functional test script generation device, characterized in that, include: A construction module is used to obtain the test stimulus primitive set of the target test bench and construct a primitive knowledge base based on the test stimulus primitive set. The test stimulus primitives in the test stimulus primitive set represent functions that are called in the functional test script to drive the target test bench. An enhancement module is used to acquire the functional requirements set, source code, and configuration data of the electronic control unit under test, and generate an enhancement requirement set based on the functional requirements set, the source code, and the configuration data. The original functional requirement text in the functional requirements set is a natural language description of the function to be tested in the electronic control unit under test, and the enhancement requirement set includes multiple enhancement functional requirement texts. A generation module is used to generate a functional test script for the electronic control unit under test based on the enhanced requirements set and the primitive knowledge base, and the target test bench uses the functional test script to test the electronic control unit under test.

12. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the functional test script generation method according to any one of claims 1-10.

13. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they implement the functional test script generation method according to any one of claims 1-10.

14. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed, they implement the functional test script generation method according to any one of claims 1-10.

Images