A method, architecture and device for generating a test case set for an embedded system

Abstract

The application discloses a kind of test case set generation method, architecture and equipment of embedded system, method includes: obtaining the source code and hardware description file of embedded system, source code exists multiple program points for indicating code position when executing in embedded system;According to source code, abstract syntax tree and control flow graph are constructed, abstract syntax tree is used to indicate the static structure information of multiple program points, control flow graph is used to indicate the dynamic execution path of multiple program points;According to abstract syntax tree, control flow graph and hardware description file, construct risk image;According to risk image, the computing resource corresponding to multiple program points respectively is dynamically distributed, and multiple program points respectively corresponding test case set is generated based on computing resource.The present application can realize high coverage under the premise of guaranteeing the effectiveness of real hardware test.

Description

Technical Field

[0001] This invention relates to the field of embedded system testing technology, and in particular to a method, architecture, and device for generating test case sets for embedded systems. Background Technology

[0002] Current embedded systems typically use the following methods to generate test cases: 1) Manually writing test cases: Test engineers manually write test scripts based on experience and understanding of the system specifications. However, this method relies heavily on personal experience and cannot identify the program points when the embedded system executes the source code, resulting in low coverage of the embedded system's source code by the generated test cases. 2) Automated generation based on symbolic execution: This method uses symbolic execution engines such as KLEE and SAGE to automatically generate test cases by analyzing program path constraints. However, this method abstracts the actual hardware into an ideal model. The inability to perceive timing jitter, register side effects, and interrupt behavior in actual hardware makes it difficult to effectively test embedded systems in a real hardware environment using generated test cases.

[0003] Therefore, in the existing technology, generating test case sets for testing embedded systems cannot achieve high coverage while ensuring the effectiveness of real hardware testing. Summary of the Invention

[0004] In order to overcome the shortcomings of the prior art, the purpose of this invention is to provide a method, architecture and device for generating test case sets for embedded systems, which can achieve high coverage while ensuring the effectiveness of real hardware testing.

[0005] This invention is implemented according to the following scheme: A method for generating test case sets for embedded systems is provided, including: Obtain the source code and hardware description file of the embedded system. When the source code is executed by the embedded system, there are multiple program points used to indicate the code location. An abstract syntax tree and a control flow graph are constructed based on the source code. The abstract syntax tree is used to represent the static structure information of multiple program points, and the control flow graph is used to represent the dynamic execution path of multiple program points. A risk profile is constructed based on the abstract syntax tree, the control flow graph, and the hardware description file. Based on the risk profile, computing resources are dynamically allocated to multiple program points, and test case sets corresponding to multiple program points are generated based on the computing resources.

[0006] Optionally, constructing an abstract syntax tree and a control flow graph based on the source code includes: The source code is parsed to construct the abstract syntax tree; The abstract syntax tree is traversed using a depth-first search algorithm to identify branch statements, sequential statements, function entry points, and jump targets. The control flow graph is constructed based on the branch statements, the sequential statements, the function entry points, and the jump targets.

[0007] Optionally, the risk profile includes risk coefficients corresponding to multiple program points; the risk profile is constructed based on the abstract syntax tree, the control flow graph, and the hardware description file, including: Construct a hardware semantic model based on the hardware description file; Static taint analysis was performed on the control flow graph to obtain the taint propagation characteristics of multiple program points; Based on the abstract syntax tree and the hardware semantic model, hardware correlation features corresponding to multiple program points are obtained respectively; The abstract syntax tree is annotated and extracted to generate constraints corresponding to multiple program points. Based on the abstract syntax tree, the control flow graph, the taint propagation characteristics, the hardware correlation characteristics and constraints corresponding to multiple program points, the risk coefficients corresponding to multiple program points are determined.

[0008] Optionally, based on the abstract syntax tree, the control flow graph, the taint propagation characteristics, the hardware correlation characteristics and constraints corresponding to multiple program points, the risk coefficients corresponding to each program point are determined, including: Acquire historical test data of the embedded system and determine the historical defect characteristics corresponding to multiple program points; Based on the abstract syntax tree and the control flow graph, determine the static complexity features corresponding to multiple program points respectively; Based on the constraints corresponding to each of the multiple program points, determine the constraint risk characteristics corresponding to each of the multiple program points. Based on the taint propagation characteristics, historical defect characteristics, static complexity characteristics, hardware correlation characteristics, and constraint risk characteristics corresponding to multiple program points, the risk coefficients corresponding to multiple program points are determined.

[0009] Optionally, based on the risk profile, computing resources corresponding to multiple program points are dynamically allocated, including: Based on the risk coefficients corresponding to multiple procedure points in the risk profile, determine the priority order among the multiple procedure points and the allocation weights corresponding to each of the multiple procedure points. The computing resources corresponding to each program point are determined according to the weights assigned to each program point and the priority order among the program points. If the risk coefficient corresponding to a program point exceeds a preset risk threshold, the program point is designated as a high-risk program point, and the GPU acceleration resources of the embedded system are used as the computing resources for the high-risk program point.

[0010] Optionally, generate test case sets corresponding to multiple program points based on computing resources, including: Generate initial test case sets corresponding to multiple program points based on computing resources; The embedded system executes the initial test case set in a simulation environment, determines the crash rate of multiple initial test cases in the initial test case set, filters out initial test cases with a crash rate greater than a preset crash rate, and obtains a filtered initial test case set. The filtered initial test case set is subjected to multi-objective iterative optimization to obtain test case sets corresponding to multiple program points respectively; the number of iterations of the multi-objective iterative optimization is less than or equal to the preset number of iterations or the same dynamic number of iterations, the dynamic number of iterations is determined based on the dynamic termination criterion of Pareto front hypervolume, and the preset number of iterations is greater than or equal to the dynamic number of iterations.

[0011] Optionally, after generating test case sets corresponding to multiple program points, the generation method further includes: The embedded system executes the test case set in a physical simulation environment or a semi-physical simulation environment, and generates an evaluation result for the test case set; Based on the assessment results, the risk profile is dynamically updated to obtain the updated risk profile. Based on the updated risk profile, generate the next set of test cases.

[0012] A test case set generation architecture for embedded systems is also provided, and the method for generating test case sets for embedded systems described above includes: Analyzing intelligent agents for: Obtain the source code and hardware description file of the embedded system. When the source code is executed by the embedded system, there are multiple program points used to indicate the code location. An abstract syntax tree and a control flow graph are constructed based on the source code. The abstract syntax tree is used to represent the static structure information of multiple program points, and the control flow graph is used to represent the dynamic execution path of multiple program points. Generate modules for: A risk profile is constructed based on the abstract syntax tree, the control flow graph, and the hardware description file. Based on the risk profile, computing resources corresponding to multiple program points are dynamically allocated, and test case sets corresponding to multiple program points are generated based on the computing resources. An evaluation agent is used by the embedded system to execute the test case set in a physical simulation environment or a semi-physical simulation environment, and to generate an evaluation result for the test case set. An updated agent is used to dynamically update the risk profile based on the evaluation results, resulting in an updated risk profile.

[0013] Optionally, the generation module includes generating an intelligent agent and optimizing the intelligent agent; The generated intelligent agent is used for: Generate initial test case sets corresponding to multiple program points based on computing resources; The embedded system executes the initial test case set in a simulation environment, determines the crash rate of multiple initial test cases in the initial test case set, filters out initial test cases with a crash rate greater than a preset crash rate, and obtains a filtered initial test case set. The optimization agent is used to perform multi-objective iterative optimization on the filtered initial test case set to obtain test case sets corresponding to multiple program points respectively; the number of iterations of the multi-objective iterative optimization is less than or equal to the preset number of iterations or the same dynamic number of iterations, the dynamic number of iterations is determined based on the dynamic termination criterion of Pareto front hypervolume, and the preset number of iterations is greater than or equal to the dynamic number of iterations.

[0014] A computer device is also provided, including a processor and a memory, wherein the memory stores at least one instruction, at least one program, code set or instruction set, and the at least one instruction, at least one program, code set or instruction set is loaded and executed by the processor to implement the method for generating test case sets for an embedded system.

[0015] Compared with existing technologies, the beneficial effects of the test case set generation method for embedded systems of the present invention are as follows: by constructing an abstract syntax tree and control flow graph to identify multiple program points, the coverage of generated test cases for program points is improved; and a risk profile is constructed based on the hardware description file, enabling test cases to perceive the timing and register behavior of real hardware, thereby achieving effective testing in a real hardware environment; at the same time, computing resources are dynamically allocated according to the risk profile to generate test case sets for multiple program points respectively, effectively improving the coverage of source code while ensuring the effectiveness of real hardware testing. Attached Figure Description

[0016] Figure 1 This is a flowchart of the generation method of the present invention. Detailed Implementation

[0017] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0018] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0019] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. In the description of this application, it should be understood that the terms "first," "second," "third," etc., are used only to distinguish similar objects and are not necessarily used to describe a specific order or sequence, nor should they be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0020] See Figure 1 As shown, the present invention provides a method for generating a test case set for an embedded system, comprising: S1: Obtain the source code and hardware description file of the embedded system. When the embedded system executes the source code, there are multiple program points that indicate the code location. The source code includes the scheduler, interrupt handling, register operation and other processing logic in the embedded system. The code location includes but is not limited to the location of functions, statements and basic blocks in the source code. The hardware description file is used to describe the hardware information of the chip, such as the register address, bit field definition, interrupt vector and so on. For example, the SVD file of CMSIS. Through the hardware description file, the test case set generated based on the hardware description file can be aware of the actual hardware, thereby ensuring the effectiveness of the test case set in testing the real hardware.

[0021] S2: Construct an abstract syntax tree and a control flow graph based on the source code. The abstract syntax tree is used to represent the static structure information of multiple program points, and the control flow graph is used to represent the dynamic execution path of multiple program points. This invention identifies multiple program points of the embedded system when executing the source code through the abstract syntax tree and control flow graph, ensuring that the subsequently generated test cases can cover the identified program points, effectively improving the coverage of the source code. This solves the problem in the prior art that relies on human experience, cannot identify all program points, and thus leads to low coverage of the embedded system's source code by manually written test cases.

[0022] In one embodiment of the present invention, constructing an abstract syntax tree and a control flow graph based on source code includes: parsing the source code to construct an abstract syntax tree; traversing the abstract syntax tree based on a depth-first search algorithm to identify branch statements, sequential statements, function entry points, and jump targets; and constructing a control flow graph based on the branch statements, sequential statements, function entry points, and jump targets.

[0023] In one embodiment of the present invention, parsing the source code and constructing an abstract syntax tree includes: using Clang LibTooling as the parser, calling clang_createIndex to create an index object, and setting compilation options, including header file paths, macro definitions, and target platform specified parameters; then calling clang_parseTranslationUnit to parse the source code and construct an abstract syntax tree with TranslationUnit as nodes.

[0024] After constructing the abstract syntax tree, this invention extracts key information such as function declarations, variable declarations, and type definitions by traversing the nodes of the abstract syntax tree and stores them as an intermediate representation in JSON format for subsequent processing. For nodes that are function nodes, the function body is recursively traversed to record statement types, expressions, and operator details.

[0025] In one embodiment of the present invention, a control flow graph is constructed based on branch statements, sequential statements, function entry points, and jump targets, including: using branch statements as basic block boundaries, including but not limited to if statements, switch statements, for statements, and while statements; merging sequential statements into the same basic block; using function entry points and jump targets as the starting points of basic blocks; assigning a unique identifier ID to each basic block and recording the entry statement, exit statement, predecessor basic block list, and successor basic block list of each basic block; then constructing jump edges between basic blocks and labeling the types of edges, including but not limited to sequential execution edges, conditional true branch edges, conditional false branch edges, and loop back edges; for jump targets that are indirect jumps, pointer analysis or value set analysis is used to determine possible target basic blocks, including but not limited to function pointer calls and switch-case jump tables; finally, constructing an adjacency list representation of the control flow graph, which supports predecessor and successor queries with O(1) time complexity.

[0026] S3: Construct a risk profile based on the abstract syntax tree, control flow graph, and hardware description file; the risk profile includes risk coefficients corresponding to multiple program points. In one embodiment of the present invention, a risk profile is constructed based on an abstract syntax tree, a control flow graph, and a hardware description file, including: constructing a hardware semantic model based on the hardware description file; performing static taint analysis on the control flow graph to obtain taint propagation characteristics of multiple program points; obtaining hardware correlation characteristics corresponding to each of the multiple program points based on the abstract syntax tree and the hardware semantic model; extracting annotations from the abstract syntax tree to generate constraints corresponding to each of the multiple program points; and determining the risk coefficients corresponding to each of the multiple program points based on the abstract syntax tree, the control flow graph, the taint propagation characteristics, the hardware correlation characteristics corresponding to each of the multiple program points, and the constraints.

[0027] In one embodiment of the present invention, constructing a hardware semantic model based on a hardware description file includes: First, the hardware description file is parsed using libxml2 or Python's xml.etree XML parser to read the device description and obtain the parsing results, including: Extracting from the parsed hardware description file <peripheral>For each tagged hardware device, obtain its base address, name, and description to extract the peripheral list; iterate through the list. <register>The peripheral register definition of the tag is used to extract the register name, offset address, bit width, and read / write attributes of the peripheral; parsing is performed. <field>Define the bit field of the tag, and obtain the bit field name, bit offset, bit width, and enumeration value; for interrupt configuration, extract... <nvic>The node's interrupt vector table information includes the interrupt number, priority bits, preemption priority, and sub-priority allocation; the parsing results of the hardware description file are stored as structured hardware description objects, supporting fast lookup by name or address.

[0028] Next, based on the parsing results, a hardware semantic model including three layers of semantic mapping is constructed, including: Based on the parsing results, the physical addresses of registers are mapped to the peripheral-register hierarchy to construct the first layer of semantic mapping for address mapping. Based on the parsing results, functional semantics are inferred from register / bit field names to construct the second layer of semantic mapping for function mapping. For example, register / bit field names ending in "EN" are identified as enable bits, register / bit field names ending in "IE" are identified as interrupt enable bits, and register / bit field names ending in "IF" are identified as interrupt flags. Based on the parsing results, access constraints for registers are extracted, including but not limited to... Limited to read-only, write-only, read-modify-write, and write-1 clear, a third-layer semantic mapping is constructed as a constraint mapping. When constructing the above three-layer semantic mapping, for special registers such as ISER / ICER of NVIC, it is also necessary to establish the correspondence between bit index and interrupt number, and for DMA channel registers, it is also necessary to establish the mapping between channel number and request source. Based on the above three-layer semantic mapping, a hardware semantic model represented by a knowledge graph is obtained. In this knowledge graph, the nodes are registers / bit fields, and the edges are functional dependencies. For example, the node of enabling the timer depends on the function of setting the prescaler value.

[0029] In one embodiment of the present invention, static taint analysis is performed on the control flow graph to obtain taint propagation characteristics of multiple program points, including: marking external inputs such as serial port receive buffers, network data packets, and sensor registers as taint source variables; using a forward data flow analysis algorithm to propagate taint marking along the dynamic execution path of the control flow graph, including: if the right value of an assignment statement contains a taint source variable, then the left value of the assignment statement is also marked as a taint source variable; if the actual parameter of a function call is a taint source variable, then the formal parameter and return value of the function call are also marked as taint source variables; if the index of an array access is a taint source variable, then the array is marked as a taint source variable. Next, based on the dynamic execution path of the control flow graph, the propagation path of tainted source variables is traced, and the complete data flow path from the tainted source variables to sensitive operations such as memory allocation, pointer dereferencing, and system calls is recorded to identify key variable dependency chains. Based on the key variable dependency chains, taint propagation features are obtained as a taint propagation graph, where the nodes of the taint propagation graph are tainted source variables, and the edges are the data dependencies between tainted source variables. Based on the taint propagation features, this invention can obtain taint analysis reports for kernel modules such as the scheduler, memory management, and interrupt handling in embedded systems. The taint analysis report includes a list of tainted sources, taint propagation paths, and sensitive operations in the kernel module.

[0030] In one embodiment of the present invention, hardware correlation features corresponding to multiple program points are obtained based on the abstract syntax tree and hardware semantic model, including: traversing the abstract syntax tree to identify pointer dereference expressions of UnaryOperator or ArraySubscript; and extracting the address of the register for code segments with expressions of the form *(volatile uint32_t*)0xXXXXXXXX. Next, the hardware semantic model is queried to determine whether the address of the register belongs to the known register address range. If it belongs to the known register address range, the code snippet is marked as a hardware interaction point and associated with the corresponding register name, peripheral name, and function description. The operation modes of the registers are analyzed, including: For register-related code, it reads register values, modifies some bits, and then writes them back, identifying read-modify-write patterns, bit set / clear patterns using the |= or &= operators, and atomic operation patterns using atomic or LDREX / STREX instructions; for interrupt-related code, it identifies interrupt enable / disable operations such as PRIMASK operations, interrupt priority configuration operations such as NVIC register access, and interrupt service function definition operations such as ISR attributes or specific naming rules; for DMA-related code, it identifies DMA channel configuration operations such as DMA_CCR register access, DMA transfer start operations such as DMA_CNDTR write, and DMA interrupt handling operations such as DMA interrupt service functions. Finally, a hardware interaction annotation table is output, including code location, register address, operation mode, associated interrupt number, and operation type label (register / interrupt / DMA). Based on the hardware interaction annotation table, the hardware correlation characteristics corresponding to each program point are obtained. The hardware correlation characteristics of each program point include the number of register operations, the number of interrupt operations, and the number of DMA operations. Specifically, the number of register access annotation entries within the program point is taken as the number of register operations, the number of interrupt-related annotation entries within the program point is taken as the number of interrupt operations, and the number of DMA-related annotation entries within the program point is taken as the number of DMA operations.

[0031] In one embodiment of the present invention, annotation extraction is performed on the abstract syntax tree to generate constraints corresponding to multiple program points, including: extracting function comments such as Doxygen-style / ** * / or / / comments in the abstract syntax tree to obtain annotation text; preprocessing the annotation text by word segmentation, stop word removal, and part-of-speech tagging; and then using a pre-trained BERT model to perform semantic encoding on the preprocessed annotation text. Next, the following constraint extraction rules are used to extract constraints from the semantically encoded annotation text. The constraint extraction rules include: For numerical constraints, the constraint parameters, constraint values, and constraint relationships are extracted into constraint conditions expressed in mathematical logic expressions. For example, the semantically encoded annotation text "timeout should be less than 100ms" is extracted into the constraint condition timeout<100. For state constraints, the relationship between the constraint object and the context is extracted into constraints expressed as logical expressions. For example, the semantically encoded comment text "This function cannot be called in an interrupt" is extracted into the constraint condition that context != ISR. For timing constraints, the sequential relationship or pre-dependency of operations is extracted into constraints expressed by logical expressions. For example, the semantically encoded comment text "must be called after initialization" is extracted into the constraint precondition=init. For resource constraints, the resource requirements are extracted into constraints expressed as Boolean expressions. For example, the semantically encoded comment text "mutually exclusive access is required" is extracted into the constraint condition require_mutex=true. For fuzzy constraints, semantic reasoning is performed on the semantically encoded annotation text to extract the constraint conditions represented by risk labels, such as "use with caution" being inferred as high_risk=true; The extracted constraints are stored in a structured manner and associated with the corresponding program points to obtain the constraints corresponding to multiple program points.

[0032] In one embodiment of the present invention, the risk coefficients corresponding to multiple program points are determined based on the abstract syntax tree, control flow graph, taint propagation characteristics, hardware correlation characteristics, and constraints, including: acquiring historical test data of the embedded system to determine historical defect characteristics corresponding to multiple program points; determining static complexity characteristics corresponding to multiple program points based on the abstract syntax tree and control flow graph; determining constraint risk characteristics corresponding to multiple program points based on the constraints; and determining the risk coefficients corresponding to multiple program points based on the historical defect characteristics, static complexity characteristics, taint propagation characteristics, hardware correlation characteristics, and constraint risk characteristics.

[0033] In one embodiment of the present invention, acquiring historical test data of an embedded system and determining historical defect characteristics corresponding to multiple program points includes: reading historical test execution records from a time-series database, including but not limited to InfluxDB or SQLite; loading coverage data and aggregating it by function or file dimension, with coverage data types including statement coverage, branch coverage, and MC / DC coverage; loading defect reports and extracting defect location, defect type, defect severity, and trigger test case identifier ID to construct an inverted index between defects and code locations; loading execution time data and calculating the average execution time and peak memory usage for each test case. Historical test data is preprocessed, including filtering, normalizing numerical features, and calculating statistics such as mean, variance, and quantiles. The filtered execution records include invalid execution records such as timeouts and crashes. Based on the inverted index between defects and code locations, historical defect features are statistically analyzed for each program point. The historical defect features include the number of historical defects, the weighted average of defect severity, and the defect type distribution vector. The number of defect records associated with each program point is used as the historical defect count. Defect severity includes high-risk, severe, moderate, and minor. The weighted average score for high-risk defects is assigned 10 points, for severe defects it is assigned 7 points, for moderate defects it is assigned 4 points, and for minor defects it is assigned 1 point. The defect type distribution vector is obtained by statistically analyzing the number of defect types for each category. Defect types include, but are not limited to, memory leaks, null pointers, race conditions, and logical errors. Finally, the processed data is associated with the corresponding program points to obtain the historical defect characteristics for each program point.

[0034] In one embodiment of the present invention, the static complexity features include cyclomatic complexity, lines of code, nesting depth, and number of branches. Based on the abstract syntax tree and control flow graph, the static complexity features corresponding to multiple program points are determined, including: traversing the control flow graph, counting the number of edges in conditional branches (including but not limited to true conditional branches, false conditional branches, and loop back edges), and obtaining the weighted complexity based on the number of edges in the conditional branches, specifically, cyclomatic complexity = number of edges in the conditional branches + 1; extracting the source code location information from the function nodes of the abstract syntax tree, including the start line number and end line number, and obtaining the number of lines of code based on the location information, specifically, number of lines of code = end line number - start line number + 1; recursively traversing the function bodies of the abstract syntax tree, counting the maximum nesting level of control statements, and using this maximum nesting level as the nesting depth; traversing the control flow graph, counting the number of all conditional jump edges (including but not limited to if branches, switch-case branches, and loop branches), and using the number of conditional jump edges as the number of branches.

[0035] In one embodiment of the present invention, the constraint risk characteristics include the number of implicit constraint risks and the constraint complexity. Determining the constraint risk characteristics corresponding to multiple program points based on their respective constraints includes: determining the sum of the number of constraints corresponding to multiple program points as the number of implicit constraint risks; performing a count of the number of logical operators and constraint variables for constraints that are mathematical logical expressions to obtain the number of logical operators and constraint variables, wherein logical operators include, but are not limited to, AND, OR, and NOT; and then performing a weighted summation of the number of logical operators and constraint variables to obtain the constraint complexity, specifically, the weight corresponding to the number of logical operators is 0.5, and the weight corresponding to the number of constraint variables is 0.5.

[0036] In one embodiment of the present invention, risk coefficients are determined for each program point based on historical defect characteristics, static complexity characteristics, taint propagation characteristics, hardware correlation characteristics, and constraint risk characteristics. This includes: normalizing the historical defect characteristics, static complexity characteristics, taint propagation characteristics, hardware correlation characteristics, and constraint risk characteristics; calculating historical defect scores, complexity scores, taint risk scores, hardware correlation scores, and constraint risk scores based on the normalized historical defect characteristics, static complexity characteristics, taint propagation characteristics, hardware correlation characteristics, and constraint risk characteristics; assigning weights to the historical defect scores, complexity scores, taint risk scores, hardware correlation scores, and constraint risk scores using a logistic regression model to obtain the weights corresponding to each historical defect score, complexity score, taint risk score, hardware correlation score, and constraint risk score; and obtaining the risk coefficient for each program point based on the historical defect scores, complexity scores, taint risk scores, hardware correlation scores, constraint risk scores, and their corresponding weights.

[0037] Wherein, the historical defect score = normalized number of historical defects × 0.4 + normalized weighted average of defect severity × 0.4 + normalized defect type distribution vector × 0.2; Complexity score = Normalized cyclomatic complexity × 0.3 + Normalized lines of code × 0.25 + Normalized nesting depth × 0.25 + Normalized number of branches × 0.2; Leakage risk score = reciprocal of normalized taint source distance × 0.3 + normalized number of sensitive operations × 0.4 + normalized taint source propagation path length × 0.3; Hardware correlation score = Normalized number of register operations × 0.4 + Normalized number of interrupt operations × 0.4 + Normalized number of DMA operations × 0.2; Constraint risk score = Normalized number of implicit constraints × 0.5 + Normalized constraint complexity × 0.5.

[0038] The weighted logistic regression model uses program points with risk levels marked in historical data as training samples for the logistic regression model. After inputting historical defect scores, complexity scores, taint risk scores, hardware correlation scores, and constraint risk scores into the logistic regression model, the weights of each score are output.

[0039] This invention uses static complexity features to represent the structure of the source code, locating areas that are too complex to be covered by conventional testing, thus predicting potential logical problems. It uses hardware correlation features to implement hardware interaction annotation, identifying underlying hardware risks such as interrupt races, register configuration errors, and DMA conflicts, thereby locating physical failures. It uses taint propagation features to identify and analyze static taints, quantifying potential damage paths from external inputs to sensitive memory or critical control flow, thus identifying security boundaries. It uses historical defect features to identify risks caused by defect libraries / version history, using statistical patterns from historical test data to provide weighted warnings for error-prone areas, thus predicting risk trends. Finally, it uses constraint risk features to reveal deviations between the source code logic and documentation specifications such as timing and preconditions, thus enabling the pre-identification of implicit conflicts.

[0040] S4: Based on the risk profile, dynamically allocate computing resources corresponding to multiple program points, and generate test case sets corresponding to multiple program points based on the computing resources.

[0041] In one embodiment of the present invention, the computing resources corresponding to multiple program points are dynamically allocated according to the risk profile, including: determining the priority order and allocation weight of the multiple program points according to the risk coefficients of the multiple program points in the risk profile; determining the computing resources corresponding to the multiple program points according to the allocation weights of the multiple program points and in accordance with the priority order of the multiple program points; if the risk coefficient of a program point exceeds a preset risk threshold, the program point is regarded as a high-risk program point, and the GPU acceleration resources of the embedded system are used as the computing resources of the high-risk program point.

[0042] In one embodiment of the present invention, generating test case sets corresponding to multiple program points based on computing resources includes: generating initial test case sets corresponding to multiple program points based on computing resources; the embedded system executes the initial test case sets in a simulation environment, determines the crash rate of multiple initial test cases in the initial test case set, filters the initial test cases with crash rates greater than a preset crash rate, and obtains a filtered initial test case set; performing multi-objective iterative optimization on the filtered initial test case set to obtain test case sets corresponding to multiple program points; the number of iterations of the multi-objective iterative optimization is less than or equal to a preset number of iterations or equal to the dynamic number of iterations, the dynamic number of iterations is determined based on the dynamic termination criterion of Pareto front hypervolume, and the preset number of iterations is greater than or equal to the dynamic number of iterations.

[0043] In one embodiment of the present invention, generating initial test case sets corresponding to multiple program points based on computing resources includes: for each program point, generating initial test cases in parallel using a hybrid strategy, wherein the hybrid strategy includes a symbolic-hybrid execution strategy, a scenario template strategy, and a hardware-triggered timing perturbation strategy; the symbolic-hybrid execution strategy uses constraint solving on the pure logic source code to automatically generate boundary value test cases and illegal value test cases; the scenario template strategy is based on preset typical embedded scenarios, including priority inversion, interrupt nesting, and memory fragmentation accumulation, and uses a Markov chain model to generate task interaction sequences; the hardware-triggered timing perturbation strategy generates variant combinations of interrupt triggering timing, interrupt priority, and nesting depth for interrupt-related code based on a register model.

[0044] The symbolic-hybrid execution strategy performs symbolic analysis on program points. First, it extracts function input parameters, global variable dependencies, and return value types from the abstract syntax tree (CFG). Then, it symbolizes the input parameters, creating symbolic variables (such as x_sym, y_sym) and initializing the symbolic execution state. Next, it performs symbolic interpretation and execution along the CFG path: for arithmetic operations, it constructs symbolic expressions (such as x_sym+5); for conditional branches, it collects path constraints (such as x_sym>10); for function calls, it performs inline expansion or generates function summaries; and finally, it uses a constraint solver (such as Z3 or STP) to solve the path. Constraints are generated to produce specific input values ​​that meet the conditions. For boundary conditions, boundary value test cases are automatically generated: for numerical parameters, minimum value, maximum value, minimum value - 1, maximum value + 1, and zero value are generated; for pointer parameters, NULL pointer, valid pointer, and dangling pointer are generated; for array parameters, empty array, single-element array, and full-capacity array are generated; for illegal values, values ​​that are out of range, mismatched in type, and incorrectly formatted are generated; for hardware-related code that symbolic execution cannot handle (such as register access), a hybrid execution strategy is adopted: hardware operations are replaced with symbolic stubs to record hardware interaction constraints; when executing specific hardware operations, the legal value range of registers is obtained from the hardware semantic model and injected as constraint conditions; finally, a test case set generated by symbolic-hybrid execution is output, and each test case contains input values, expected outputs, and covered path constraints.

[0045] The scenario template strategy loads a pre-built library of typical embedded scenarios from the knowledge base. Each template includes a scenario name, triggering conditions, task interaction mode, and expected defect type. For priority inversion scenarios, the template definition is: high-priority task T1 waits for the mutex held by low-priority task T2, and T2 is preempted by medium-priority task T3. A Markov chain model is constructed: the state set S = {task ready, task running, task blocked, task completed}, and the transition probability matrix P is trained based on historical test data. A task interaction sequence is generated: starting from the initial state (all tasks ready), the next state is randomly selected according to the transition probability, and the state transition is recorded. Move paths; for each path, instantiate specific parameters: task priority value (1-255), mutex ID, critical section execution time, preemption time point; for nested interrupt scenarios, the template defines: interrupt service function ISR1 is preempted by higher priority interrupt ISR2 during execution, and ISR2 is preempted by ISR3 during execution; generate interrupt nesting sequences: define nesting depth (1-7 levels), interrupt number of each level, trigger time interval, and execution duration; for memory fragmentation accumulation scenarios, the template defines: repeatedly allocating and releasing memory blocks of different sizes, leading to memory fragmentation; generate memory operation sequences: define allocation size sequence (e.g., [64, 128, 32, 256, 64] bytes), release order (sequential release, reverse release, random release); perform constraint verification on the generated scenario sequences: check whether the priority configuration meets hardware limitations, whether the interrupt number is within the valid range, and whether the memory allocation exceeds the heap size; finally, output the test case set generated by the scenario template, each test case includes scenario type, task / interrupt sequence, parameter configuration, and expected defect type.

[0046] The hardware-triggered timing perturbation strategy identifies interrupt-related code segments from the risk profile, extracting the associated interrupt number, register operation sequence, and interrupt service function entry point. Based on the hardware semantic model, it obtains the configuration register information of the target interrupt: interrupt enable register (e.g., NVIC_ISER), interrupt priority register (e.g., NVIC_IPR), and interrupt suspend register (e.g., NVIC_ISPR). It defines the timing perturbation parameter space: interrupt triggering timing (before / during / after task execution, inside / outside the critical section), interrupt priority (0-255, smaller values ​​indicate higher priority), nesting depth (1-7 levels), and triggering interval (1μs-100ms). A mutation combination generation strategy is adopted: a single interrupt triggering at different times generates N basic mutations of timing variants; multiple interrupts triggering in different orders generate C(…). Combination mutations of M,2) combination variants; nested mutations of interrupt B triggered after interrupt A is triggered with a delay of t, generating a variant with a nesting depth of 2; extreme mutations of forcibly triggering interrupts in critical sections (during lock holding, interrupt disabled); for each mutation combination, generate a specific register operation sequence: set interrupt priority (write to NVIC_IPR register), enable interrupt (write to NVIC_ISER register), trigger interrupt (write to NVIC_ISPR register or call software interrupt instruction); verify the legality of mutation combinations: check whether the priority configuration violates hardware constraints (such as preemption priority and sub-priority bit limit) and whether the nesting depth exceeds the MCU's supported range; finally output the test case set generated by timing perturbation, each test case containing interrupt trigger sequence, register configuration value, and expected race condition type.

[0047] In one embodiment of the present invention, multi-objective iterative optimization is performed on the filtered initial test case set to obtain test case sets corresponding to multiple program points, including: First, a three-dimensional evaluation vector is established for each test case. The three-dimensional evaluation vector includes coverage improvement, defect trigger probability, and execution overhead, and a dynamic adaptive weight allocation strategy is used to allocate weights to the three-dimensional evaluation vector; the coverage improvement is determined by calculating the number of basic blocks or branches added after the execution of a new test case; the defect trigger probability is predicted using an ensemble learning model, such as a combination of random forest and long short-term memory network, based on the static and dynamic features of the input test case; the execution overhead is approximated by the number of instruction executions or basic block jumps counted in the simulation environment. In the early stages of the first 30% of iterations, to improve exploration capabilities, the weights for coverage improvement were set to 0.6, defect trigger probability to 0.2, and execution overhead to 0.2. In the later stages of the remaining 70% of iterations, to focus on deeper defect discovery and cost control, the weights were adjusted to 0.2 for coverage improvement, 0.6 for defect trigger probability, and 0.2 for execution overhead. In practical applications, users also customize weight preferences through configuration files to adapt to different testing objectives.

[0048] Next, during the optimization process, knowledge-based mutation operators are applied to evolve the use case population. Register boundary mutation prioritizes trying extreme values ​​for hardware registers, including critical values ​​such as all 0s, all 1s, and sign bit flips. Random bit flips are also used to simulate hardware fault scenarios such as electromagnetic interference or single-event upsets, thereby efficiently triggering the underlying logic defects of the embedded system.

[0049] The timing pattern crossover of multi-task test cases is performed. By performing dependency analysis and two-point crossover reorganization on the atomic operation sequences in the multi-task test cases, the task scheduling time slices in different parent test cases are swapped to generate new resource contention timing sequences. Random delays are inserted to correct for potential deadlock risks.

[0050] Defect patterns and trigger genes are extracted from a pre-established knowledge base. Specifically, the defect tracking system and version control system are used to mine code snapshots before historical fixes were committed. A mapping rule base is formed by subtree matching and clustering of abstract syntax trees. When the similarity between the current code and a certain defect pattern in the rule base exceeds a threshold, the corresponding trigger gene is adapted to the current context and injected into the test case to achieve targeted generation of high-risk test cases.

[0051] Finally, a dynamic termination criterion based on Pareto front hypervolume is used to determine the number of evolutionary rounds. The hypervolume value of the non-dominated solution set is calculated for each generation, and a sliding window is maintained to evaluate the relative growth rate of the hypervolume. When the growth rate of several consecutive generations (e.g., three generations) is lower than a preset threshold (e.g., 1%), the algorithm is considered to have converged and the evolution is terminated early; otherwise, it continues to iterate until the preset maximum number of rounds is reached.

[0052] In one embodiment of the present invention, after generating test case sets corresponding to multiple program points, the generation method further includes: the embedded system executing the test case sets in a physical simulation environment or a semi-physical simulation environment to generate an evaluation result of the test case sets; dynamically updating the risk profile according to the evaluation result to obtain an updated risk profile; and generating the next test case set based on the updated risk profile.

[0053] In one embodiment of the present invention, the risk profile is dynamically updated based on the evaluation results to obtain an updated risk profile. This includes maintaining the risk probability of each program point, determining whether a defect exists based on the evaluation results, and updating the posterior risk probability of the program point using a Bayesian formula. Specifically, if no defect is found in the test, the risk probability of the program point decreases accordingly; if a new defect is found, the risk probability increases significantly, and the risk values ​​of associated program points that have a calling relationship or data dependency relationship with the program point also increase synchronously. The present invention recalculates the risk coefficient of each program point through the above-mentioned Bayesian risk update, thereby generating an updated risk profile.

[0054] This invention updates the risk profile to achieve dynamic reallocation of test resources and adaptive evolution of test strategies, enabling subsequent test case generation to continuously focus on the program points with the highest current risk. This significantly improves defect discovery efficiency and test coverage growth rate. At the same time, by updating historical test experience through Bayesian methods, it enables the reuse of historical test experience, thereby achieving a closed-loop optimization effect of becoming more accurate with each test.

[0055] The present invention provides an architecture for generating test case sets for embedded systems, which applies the aforementioned method for generating test case sets for embedded systems, including: Analyzing intelligent agents for: Obtain the source code and hardware description file of the embedded system. When the source code is executed by the embedded system, there are multiple program points used to indicate the location of the code. An abstract syntax tree and a control flow graph are constructed based on the source code. The abstract syntax tree is used to represent the static structural information of multiple program points, and the control flow graph is used to represent the dynamic execution path of multiple program points. Generate modules for: Construct a risk profile based on the abstract syntax tree, control flow graph, and hardware description file; Based on the risk profile, computing resources are dynamically allocated to multiple program points, and test case sets corresponding to multiple program points are generated based on the computing resources. Evaluation agent, used by embedded systems to execute test case sets in physical or semi-physical simulation environments, and generate evaluation results for the test case sets; The updated agent is used to dynamically update the risk profile based on the assessment results, resulting in an updated risk profile.

[0056] In one embodiment of the present invention, the generation module includes generating an intelligent agent and optimizing an intelligent agent; Generate intelligent agents for: Generate initial test case sets corresponding to multiple program points based on computing resources; The embedded system executes an initial test case set in a simulation environment, determines the crash rate of multiple initial test cases in the initial test case set, filters out initial test cases with a crash rate greater than a preset crash rate, and obtains a filtered initial test case set. An optimized agent is used to perform multi-objective iterative optimization on the filtered initial test case set to obtain test case sets corresponding to multiple program points. The number of iterations for multi-objective iterative optimization is less than or equal to the preset number of iterations or the same as the dynamic number of iterations. The dynamic number of iterations is determined based on the dynamic termination criterion of the Pareto front hypervolume, and the preset number of iterations is greater than or equal to the dynamic number of iterations.

[0057] The computer device of the present invention includes a processor and a memory. The memory stores at least one instruction, at least one program, code set, or instruction set, wherein the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the above-described test case set generation method.

[0058] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0059] The memory can be used to store the computer program or module. The processor implements various functions of the test case set generation method by running or executing the computer program or module stored in the memory and calling data stored in the memory. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, etc.; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0060] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.< / nvic> < / field> < / register> < / peripheral>

Claims

1. A method for generating test case sets for an embedded system, characterized in that, include: Obtain the source code and hardware description file of the embedded system. When the embedded system executes the source code, there are multiple program points used to indicate the code location. An abstract syntax tree and a control flow graph are constructed based on the source code. The abstract syntax tree is used to represent the static structure information of multiple program points, and the control flow graph is used to represent the dynamic execution path of multiple program points. A risk profile is constructed based on the abstract syntax tree, the control flow graph, and the hardware description file. Based on the risk profile, computing resources are dynamically allocated to multiple program points, and test case sets corresponding to multiple program points are generated based on the computing resources.

2. The method for generating a test case set for an embedded system according to claim 1, characterized in that, Constructing an abstract syntax tree and a control flow graph based on the source code includes: The source code is parsed to construct the abstract syntax tree; The abstract syntax tree is traversed using a depth-first search algorithm to identify branch statements, sequential statements, function entry points, and jump targets. The control flow graph is constructed based on the branch statements, the sequential statements, the function entry points, and the jump targets.

3. The method for generating a test case set for an embedded system according to claim 1, characterized in that, The risk profile includes risk coefficients corresponding to multiple program points; Based on the abstract syntax tree, the control flow graph, and the hardware description file, a risk profile is constructed, including: Construct a hardware semantic model based on the hardware description file; Static taint analysis was performed on the control flow graph to obtain the taint propagation characteristics of multiple program points; Based on the abstract syntax tree and the hardware semantic model, hardware correlation features corresponding to multiple program points are obtained respectively; The abstract syntax tree is annotated and extracted to generate constraints corresponding to multiple program points. Based on the abstract syntax tree, the control flow graph, the taint propagation characteristics, the hardware correlation characteristics and constraints corresponding to multiple program points, the risk coefficients corresponding to multiple program points are determined.

4. The method for generating a test case set for an embedded system according to claim 3, characterized in that, Based on the abstract syntax tree, the control flow graph, the taint propagation characteristics, the hardware correlation characteristics and constraints corresponding to multiple program points, the risk coefficients corresponding to multiple program points are determined, including: Acquire historical test data of the embedded system and determine the historical defect characteristics corresponding to multiple program points; Based on the abstract syntax tree and the control flow graph, determine the static complexity features corresponding to multiple program points respectively; Based on the constraints corresponding to each of the multiple program points, determine the constraint risk characteristics corresponding to each of the multiple program points. Based on the taint propagation characteristics, historical defect characteristics, static complexity characteristics, hardware correlation characteristics, and constraint risk characteristics corresponding to multiple program points, the risk coefficients corresponding to multiple program points are determined.

5. The method for generating a test case set for an embedded system according to claim 3, characterized in that, Based on the risk profile, computing resources are dynamically allocated to multiple program points, including: Based on the risk coefficients corresponding to multiple procedure points in the risk profile, determine the priority order among the multiple procedure points and the allocation weights corresponding to each of the multiple procedure points. The computing resources corresponding to each program point are determined according to the weights assigned to each program point and the priority order among the program points. If the risk coefficient corresponding to a program point exceeds a preset risk threshold, the program point is designated as a high-risk program point, and the GPU acceleration resources of the embedded system are used as the computing resources for the high-risk program point.

6. The method for generating a test case set for an embedded system according to claim 1, characterized in that, Based on computing resources, generate test case sets corresponding to multiple program points, including: Generate initial test case sets corresponding to multiple program points based on computing resources; The embedded system executes the initial test case set in a simulation environment, determines the crash rate of multiple initial test cases in the initial test case set, filters out initial test cases with a crash rate greater than a preset crash rate, and obtains a filtered initial test case set. The filtered initial test case set is subjected to multi-objective iterative optimization to obtain test case sets corresponding to multiple program points respectively; the number of iterations of the multi-objective iterative optimization is less than or equal to the preset number of iterations or the same dynamic number of iterations, the dynamic number of iterations is determined based on the dynamic termination criterion of Pareto front hypervolume, and the preset number of iterations is greater than or equal to the dynamic number of iterations.

7. The method for generating a test case set for an embedded system according to claim 1, characterized in that, After generating test case sets corresponding to multiple program points, the generation method further includes: The embedded system executes the test case set in a physical simulation environment or a semi-physical simulation environment, and generates an evaluation result for the test case set; Based on the assessment results, the risk profile is dynamically updated to obtain the updated risk profile. Based on the updated risk profile, generate the next set of test cases.

8. A test case set generation architecture for an embedded system, employing the test case set generation method for an embedded system as described in any one of claims 1-7, characterized in that, include: Analyzing intelligent agents for: Obtain the source code and hardware description file of the embedded system. The source code contains multiple program points used to indicate code locations when executed by the embedded system. An abstract syntax tree and a control flow graph are constructed based on the source code. The abstract syntax tree is used to represent the static structure information of multiple program points, and the control flow graph is used to represent the dynamic execution path of multiple program points. Generate modules for: A risk profile is constructed based on the abstract syntax tree, the control flow graph, and the hardware description file. Based on the risk profile, computing resources corresponding to multiple program points are dynamically allocated, and test case sets corresponding to multiple program points are generated based on the computing resources. An evaluation agent is used by the embedded system to execute the test case set in a physical simulation environment or a semi-physical simulation environment, and to generate an evaluation result for the test case set. An updated agent is used to dynamically update the risk profile based on the evaluation results, resulting in an updated risk profile.

9. The test case set generation architecture for an embedded system according to claim 8, characterized in that, The generation module includes generating an intelligent agent and optimizing the intelligent agent; The generated intelligent agent is used for: Generate initial test case sets corresponding to multiple program points based on computing resources; The embedded system executes the initial test case set in a simulation environment, determines the crash rate of multiple initial test cases in the initial test case set, filters out initial test cases with a crash rate greater than a preset crash rate, and obtains a filtered initial test case set. The optimization agent is used to perform multi-objective iterative optimization on the filtered initial test case set to obtain test case sets corresponding to multiple program points respectively; the number of iterations of the multi-objective iterative optimization is less than or equal to the preset number of iterations or the same dynamic number of iterations, the dynamic number of iterations is determined based on the dynamic termination criterion of Pareto front hypervolume, and the preset number of iterations is greater than or equal to the dynamic number of iterations.

10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one instruction, at least one program, code set, or instruction set, wherein at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement a test case set generation method for an embedded system as described in any one of claims 1 to 7.

Images