Simulation testing methods and related devices for target functions

Abstract

This application discloses a simulation testing method and related apparatus for a target function. The simulation testing method includes: obtaining test parameters and operating condition data of the target function from a configuration file and generating configuration data for the target function; generating and combining data values ​​of test parameters based on the target function to obtain an optimized parameter combination for simulating the target function; and performing simulation testing on the target function based on the optimized parameter combination and configuration data, generating and outputting test results. Through this method, this application can accurately simulate the real behavioral characteristics of equipment, significantly improving testing efficiency and result reliability.

Description

Technical Field

[0001] This application is applied to the field of embedded system testing technology, and in particular relates to a simulation testing method for a target function and related apparatus. Background Technology

[0002] In existing embedded controller testing systems, the parsing logic of communication protocols is usually hard-coded into the source code. Test scripts are highly coupled with business logic, and test parameters, simulation conditions, and constraints are directly written into the program code. System expansion depends on developers modifying the source code and recompiling and deploying it. In terms of virtual simulation, simple data simulation methods are often used to simplify the device response to fixed value playback or linear change curves.

[0003] However, protocol upgrades require developer intervention, are time-consuming and prone to errors, and are difficult to maintain with multiple versions. Expansion of test scenarios and adjustment of parameters both rely on code modifications, and constraints are difficult to express and change. Ultimately, this leads to low simulation accuracy, an inability to simulate device state machines, protection logic and disturbance scenarios, and poor reliability of results. Summary of the Invention

[0004] This application provides a simulation testing method for target functions, an electronic device, and a computer-readable storage medium. It can quickly adapt to multiple controller models and protocol versions without modifying the source code, automatically generate effective test cases that meet business logic constraints, and accurately simulate the real behavior characteristics of the device, significantly improving testing efficiency and result reliability.

[0005] The first aspect of this application provides a simulation test method, electronic device, and storage medium for a target function, comprising: obtaining test parameters and operating condition data of the target function from a configuration file and generating configuration data of the target function; generating data values ​​of test parameters based on the target function and combining them to obtain an optimized parameter combination for simulating the target function; performing simulation testing on the target function based on the optimized parameter combination and configuration data, and generating and outputting test results.

[0006] The step of generating test parameter data values ​​based on the target function and combining them to obtain an optimized parameter combination for simulating the target function includes: generating test parameter data values ​​based on the target function, and generating corresponding parameter combinations using a preset strategy algorithm; and selecting optimized parameter combinations from the parameter combinations according to preset conditions.

[0007] The steps of generating test parameter data values ​​based on the target function and generating corresponding parameter combinations using a preset strategy algorithm include: detecting whether the target function is a preset type; wherein the preset type includes at least one of boundary value test type and verification type; in response to the target function being a boundary value test type, using a third preset strategy algorithm to extract boundary values ​​from the data values ​​of each test parameter to generate multiple parameter combinations; wherein the multiple parameter combinations include at least the parameter combinations corresponding to the maximum and minimum values ​​of the data values ​​in the test parameters; in response to the target function being a verification type, using a fourth preset strategy algorithm to fill the test parameter data values ​​based on a preset orthogonal array template to generate parameter combinations; in response to the target function not belonging to any preset type and the number of parameters being less than or equal to a first set number, using a first preset strategy algorithm to perform a full combination of the test parameter data values, and using the result of the full combination as the parameter combination; in response to not belonging to any preset type and the number of parameters being greater than a first set number and less than or equal to a second set number, using a second preset strategy algorithm to process the test parameter data values ​​using a greedy algorithm and generate parameter combinations. The step of selecting an optimal parameter combination from the parameter combinations based on preset conditions includes: converting the preset conditions into a string expression and decomposing the string expression into a marker sequence; inputting the test parameters in the parameter combination into the corresponding marker sequence, recursively evaluating the string expression according to the priority of preset operators, and generating the evaluation result; and selecting the optimal parameter combination based on the evaluation mechanism and the evaluation result.

[0008] The step of selecting the optimal parameter combination based on the evaluation mechanism and the evaluation result includes: in response to the evaluation mechanism being a Boolean evaluation, selecting the parameter combination whose evaluation result is true as the optimal parameter combination; in response to the evaluation mechanism being a numerical evaluation, selecting the parameter combination whose evaluation result meets the expected value as the optimal parameter combination.

[0009] The preset operators include: logical OR, logical AND, set operations, comparison operations, addition and subtraction, and multiplication, division, and modulo operations, with the priority increasing in the following order: logical OR, logical AND, set operations, comparison operations, addition and subtraction, and multiplication, division, and modulo operations.

[0010] Before the steps of obtaining the test parameters and operating condition data of the target function from the configuration file and generating the configuration data of the target function, the process includes: setting the first protocol configuration file in a preset format in the protocol configuration directory; and loading the configuration file in the protocol configuration directory through a hot loading mechanism.

[0011] The hot-loading mechanism for loading configuration files in the protocol configuration directory includes: creating a second protocol configuration file when a change in the communication protocol is detected; the second protocol configuration file contains the status field of the changed communication protocol and the modified verification algorithm; setting the second protocol configuration file in the protocol configuration directory; and loading the configuration files in the protocol configuration directory through the hot-loading mechanism.

[0012] A second aspect of this application provides an electronic device comprising: a memory and a controller coupled to each other, the controller being used to execute program instructions stored in the memory to achieve a simulation test method for the target function as described above.

[0013] A third aspect of this application provides a computer-readable storage medium storing program data that can be executed to achieve the target function as described above, and a simulation test method thereof.

[0014] The beneficial effects of this application are as follows: This application provides a simulation testing method for a target function. It obtains test parameters and operating condition data of the target function from a configuration file and generates configuration data for the target function. Based on the target function, it generates and combines the data values ​​of the test parameters to obtain an optimized parameter combination for simulating the target function. Based on the optimized parameter combination and configuration data, it performs simulation testing on the target function, generates and outputs test results. This method can dynamically match the optimized parameter combination, effectively avoid invalid test scenarios, improve test efficiency, and finally perform simulation testing based on the configuration data to reproduce the real equipment operating state, making the test results more reliable. Attached Figure Description

[0015] Figure 1 This is a flowchart illustrating one implementation method of the simulation testing method for the target function provided in this application; Figure 2 This is a flowchart illustrating another implementation of the simulation testing method for the target function provided in this application; Figure 3 yes Figure 2 A flowchart illustrating a specific embodiment of S25; Figure 4 This is a schematic diagram of one embodiment of the electronic device provided in this application; Figure 5 This is a schematic diagram of an embodiment of the computer-readable storage medium provided in this application. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0017] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0018] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0019] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the simulation testing method for the target function provided in this application.

[0020] S11: Obtain the test parameters and operating condition data of the target function from the configuration file, and generate the configuration data of the target function.

[0021] The configuration file serves as a data storage medium, defining the value range of test parameters, constraints, and initial settings of operating parameters. The system establishes a data interaction relationship with the configuration file through parsing. The system can construct a configuration-driven test execution framework and virtual device state, obtain the test parameters and operating data of the target function, and generate configuration data based on this. The configuration parameters include not only the test parameters and operating data for test execution but also related data such as constraints, evaluation mechanisms, and test execution steps. Test parameters are the parameter data required to execute the target function. For example, if the target function is a basic function test in cooling mode, the test parameters will at least include the set temperature and fan speed. Operating data refers to the parameter data of the working environment during the execution of the target function, such as indoor and outdoor temperatures, AC voltage, humidity, or compressor delay protection time. The configuration-driven test execution framework includes at least a functional module configuration file, parameter template configuration file, step template configuration file, simulation operating condition configuration file, configuration loader, configuration verifier, and thermal reload mechanism. The virtual device state machine includes at least an operating condition library, state transition engine, parameter simulation model, protection logic simulation, and disturbance model. Furthermore, test parameters and operating parameters can be obtained directly from the configuration file with explicit parameter values, such as setting the temperature [20, 22, 24, 26]℃; or configuration data can be dynamically selected from the parameter template, and attention can be paid to whether the changes in the configuration data meet the expected results of the target function. For example, if the target function is to detect the overvoltage protection mechanism, configuration data such as overvoltage protection threshold, detection window time, protection action type, fault code, voltage recovery judgment threshold, and automatic recovery delay can be obtained from the parameter template.

[0022] Specifically, within the test execution framework, the functional module configuration file defines a hierarchical functional module tree. Through each module's unique identifier, name, description, and list of submodules, it fully defines the test scope and functional relationships. The parameter template configuration file defines detailed data for test parameters, including at least one or more parameters such as parameter name, parameter key, whether enabled, value type, numerical range (minimum / maximum / step size), typical value list, boundary value list, outlier list, and parameter unit. It also embeds constraints and assertion rules. Constraints consist of a unique identifier, description, and expression string to define dependencies or restrictions between parameters. Assertion rules, through trigger conditions and assertion expressions, combined with critical / normal severity levels, provide dynamic judgment criteria for test execution. The test step template configuration file defines reusable test step templates. Each template includes an identifier, description, applicable conditions (functional module, scenario type, tag), preconditions, and a step list. The applicable conditions automatically select the appropriate test step template, and the preconditions define the conditions that must be met before the target function test is executed, such as the temperature reaching a set value in environmental parameters, or normal communication connection and device shutdown in operating condition parameters. The step list defines the sequence of target function test steps, with each step including at least a step number, action type, step description, test parameters, waiting time, verification rules, and condition execution flags. The simulation operating condition configuration file defines simulation operating condition parameters for different test scenarios, including at least environmental parameters (indoor temperature, outdoor temperature, humidity), electrical parameters (voltage, frequency), time parameters (compressor delay time, stabilization waiting time, data recording duration), and one or more parameters from the disturbance list. Relevant simulation operating condition parameters can be obtained based on the virtual device state machine. The configuration loader loads configuration files from configuration files, databases, and remote services, obtains test parameters and operating condition parameters related to the target function simulation test, and generates configuration data. Then, based on the target function test requirements, it locates the specific functional module node and extracts the associated test cases, parameter templates, operating condition parameters, and step templates from the configuration data to achieve precise matching with the functional module. The configuration verifier verifies the integrity and correctness of the configuration file during loading. For example, field-level validation ensures the existence, correct type, and valid value range of required fields; reference-level validation checks whether the identifier associations between functional modules, parameter templates, and step templates are resolvable; and logic-level validation verifies the syntactic correctness and context computability of constraint expressions, assertion expressions, and conditional execution expressions. The hot reload mechanism continuously monitors changes to the configuration file. When a modification is detected, the configuration is automatically reloaded, and online adjustment of test parameters, operating condition parameters, or step templates is supported. Changes take effect immediately without restarting the system. For example, an incremental update strategy is used, only the changed parts are re-parsed and the configuration model in memory is dynamically refreshed, while maintaining the continuity of the runtime test context.Meanwhile, during the configuration data generation phase, the controller can traverse the matching step templates, dynamically inject actual parameter values ​​by combining parameter placeholders, and dynamically determine whether the steps are effective through conditional execution expressions, ultimately outputting a parameterized dataset that integrates test parameters and operational logic.

[0023] In the virtual device state machine, the operating condition library is used to predefine standard operating condition configurations, such as standard cooling operating condition, standard heating operating condition, high-load cooling operating condition, and low-temperature heating operating condition, supporting rapid switching of test scenarios. Each operating condition includes at least one or more parameters from the following categories: environmental parameters (temperature, humidity), electrical parameters (voltage, frequency), time parameters (delay, waiting time), and disturbance definitions (disturbance data such as grid voltage fluctuations, drastic changes in ambient temperature, or communication interference). The state transition engine is used to simulate the controller's state transition logic, such as simulating states like shutdown, standby, initialization, cooling operation, heating operation, dehumidification operation, air supply operation, protection state, and fault state, enabling command triggering for multiple state transitions. The state transition engine also includes at least compressor delayed start protection logic, ensuring that the compressor waits a specified delay after shutdown before restarting. The delay time can be set based on the compressor's safety specifications, for example, 2-4 minutes. Parametric simulation models can calculate the changing trends of parameters such as temperature, frequency, and current based on physical models. For example, temperature trend simulation calculates the rate of temperature change based on the difference between cooling / heating capacity and heat load, i.e., rate of temperature change = (cooling capacity - heat load) / heat capacity. The larger the cooling / heating capacity, the higher the compressor frequency, and the temperature change is directly proportional to the compressor frequency. Frequency regulation simulation dynamically adjusts the compressor frequency based on the difference between the set temperature and the actual temperature. The larger the temperature difference, the higher the compressor frequency. A first-order inertial element is used to achieve smooth frequency adjustment to simulate the real frequency response characteristics. Current simulation calculates the compressor current based on the compressor frequency and voltage. For example, since the compressor current and frequency are approximately linearly related, the current of 8A corresponding to a compressor frequency of 60Hz and a voltage of 22V is used as a benchmark. The compressor current is determined by linear interpolation based on the frequency, and ±5% uniformly distributed random fluctuations are superimposed to simulate the sensor noise and harmonic interference of the real measured value. Protection logic simulation is used to simulate various protection mechanisms, such as overvoltage / undervoltage protection, high temperature protection, overcurrent protection, and communication timeout protection. Overvoltage / undervoltage protection detects whether the compressor voltage exceeds the normal voltage range (e.g., 176~264V). If it exceeds the normal voltage range, it immediately shuts down and records a protection code. After a delay, it automatically resumes operation once the voltage returns to normal. High temperature protection detects whether the temperature exceeds a preset temperature. For example, if it exceeds the first preset temperature (e.g., 65℃), it uses derating protection; if it exceeds the second preset temperature (e.g., 70℃), it uses shutdown protection. The first and second preset temperatures can be set based on target functions and safety requirements. Overcurrent protection monitors the compressor current in real time. When the voltage reaches a preset current (e.g., 15A) consecutively a set number of times (e.g., 2~4 times), it performs shutdown protection and records a fault code. The set number of times and the preset current are set based on target functions and safety requirements. Communication timeout protection detects the communication status with the controller. When communication is interrupted for more than a set time, it triggers a protection mechanism, such as shutdown protection and recording a fault code.The disturbance model is used to inject disturbance data at specified time points to simulate abnormal test scenarios. The disturbance types include at least voltage step, temperature gradient, and communication interruption / recovery. Voltage step refers to setting the voltage to a preset voltage at a specified time point to simulate voltage change disturbance. Temperature gradient refers to changing the current temperature to a preset temperature at a specified time point according to a set gradient rate to simulate temperature change disturbance. Communication interruption / recovery refers to interrupting communication at a specified time point and automatically restoring the communication connection after a set recovery time to simulate communication disturbance.

[0024] Furthermore, a configurable JSON (JavaScript Object Notation) protocol parsing framework can be constructed. This framework defines the complete protocol structure of the communication protocol through a configuration file. When the hot-reloading mechanism detects a change in the protocol version, only the JSON configuration file needs to be modified or added; no modifications to the backend code are required, and the new protocol parsing rules will take effect immediately. The JSON configurable protocol parsing framework includes at least a protocol configuration file, a protocol registry, a dynamic frame extractor, a field parser, a field mapper, a checksum validator, and a hot-reloading mechanism. Specifically, the protocol configuration file defines the protocol structure in JSON format, including at least protocol information, frame type definitions, field definitions, and verification algorithms. The protocol information includes the version number, protocol description, and priority; the frame type definition includes the frame header sequence, command word, and length pattern; the field definitions include data type, byte offset, conversion formula, value mapping table, valid range, and target object mapping; and the verification algorithm supports multiple configurations such as Sum8 (8-bit Sum Check), CRC16 (16-bit Cyclic Redundancy Check), and XOR (Exclusive OR Check). The protocol registry manages multiple protocol versions and supports priority selection. For example, when multiple protocol versions exist, the controller automatically selects the version with the highest priority, or the protocol version can be manually specified. The dynamic frame extractor is used for searching and extracting multi-byte frame headers. It can handle both fixed-length and dynamic-length frame modes. In fixed-length frame mode, the dynamic frame extractor searches the data stream based on configured frame header features such as specific byte sequences 0xAA and 0x55. Once a match is found, it directly extracts the complete frame according to a preset fixed number of bytes, without dynamically calculating the length. In dynamic-length frame mode, the dynamic frame extractor stores frame length information based on a configured length byte index, such as 2 bytes off the frame header. It reads the value of this field from the data stream in real time, parses the actual length of the current frame, and then extracts the corresponding number of bytes of the complete data packet starting from the frame header. The field parser parses byte streams based on configured field definitions, supporting multiple data types such as byte, short, ushort, int, float, and double. It also provides big-endian / little-endian byte order switching configuration for multi-byte fields. Furthermore, it supports converting raw register values ​​into corresponding physical parameters such as temperature, pressure, and rotational speed using linear conversion formulas such as y=kx+b. It also supports value mapping tables to map specific numerical codes into readable string enumeration values, such as 0x01 → "cooling mode" and 0x02 → "heating mode", thus achieving decoding from binary data to business semantics.The field mapper matches parsed protocol fields with corresponding target object attributes. It uses reflection to dynamically scan the target object's attribute characteristics, matching and assigning values ​​based on the configured field names. The mapping process includes built-in automatic type conversion; when the protocol field type differs from the target attribute type (e.g., converting byte to int, string to enumeration), type adaptation is automatically performed. The checksum validator ensures the integrity and correctness of communication data. It verifies data integrity based on configured checksum algorithms, such as dynamically reading the checksum range definition (start index, end index) and checksum position index from the configuration file to locate the data range participating in the checksum and the field position storing the checksum result. It also supports plug-and-play multiple checksum algorithms, including Sum8, XOR, and CRC16, enabling hot switching of checksum logic by binding algorithm names to configuration. The hot-loading mechanism dynamically monitors changes to the protocol configuration file; when a change is detected, it supports loading the protocol configuration file at runtime without restarting the system.

[0025] In a specific application scenario, the target function is to test the basic function of the cooling mode. The configuration file defines the standard operating conditions for cooling as follows: indoor temperature 27℃, outdoor temperature 35℃, AC voltage 220V, humidity 50%, compressor delay protection time 180 seconds, and stabilization waiting time 300 seconds. The configuration constraint is that the set temperature in the forced cooling mode must be at least 2℃ lower than the current indoor temperature. The configuration assertion rule is that the compressor running current should be within the range of 2.0-15.0A and the indoor temperature should drop by at least 1℃ after running for 30 minutes. The test parameters are the set temperature set [20, 22, 24, 26]℃ and the fan speed set [low, medium, high, automatic].

[0026] In another specific application scenario, the target function is overvoltage protection testing. The configuration file defines the high-load cooling condition as an indoor temperature of 32℃, an outdoor temperature of 43℃, and an initial AC voltage of 220V. A voltage step disturbance is configured, with a disturbance trigger time of 300 seconds, a disturbance type of voltage step, and a preset voltage value of 280A, simulating a power grid overvoltage event. The assertion rule is configured such that after the voltage rises to 280V, the system should detect the overvoltage within 5 seconds, trigger overvoltage protection, stop the compressor, record the overvoltage protection code, and automatically resume normal operation after a 3-minute delay once the voltage returns to 220V. The test parameters are based on a protection function test template example, such as setting an initial voltage of 220V and a target voltage of 280V, starting the cooling mode, and focusing on verifying the overvoltage event detection delay, protection action execution, fault code recording, and the delayed restart mechanism after voltage recovery.

[0027] S12: Generate test parameter data values ​​based on the target function and combine them to obtain an optimized parameter combination for simulation testing of the target function.

[0028] The parameter combination selection based on constraints involves iterating through the parameter combinations, eliminating invalid combinations, and obtaining optimized parameter combinations. However, when there are many test parameters related to the target function and a large value space, directly selecting parameter combinations based on constraints may result in a large number of combinations, leading to excessive computation and reduced efficiency. Therefore, an initial parameter combination can be generated from the test parameters related to the target function in the configuration data according to a preset strategy algorithm, and then the parameter combinations can be selected based on constraints to generate optimized parameter combinations. Specifically, the constraints are converted into string expressions, and a multi-strategy parameter combination engine, an expression evaluation engine, and a condition evaluator are constructed. The multi-strategy parameter combination engine includes at least a strategy interface, five built-in strategies, a strategy selector, a parameter matrix, and a constraint filter. The expression evaluation engine includes at least a lexical analyzer, a syntax analyzer, an abstract syntax tree cache, a type system, and an operator implementation module. The condition evaluator includes at least evaluations of value comparison, time conditions, signal stability, and error detection.

[0029] In the multi-strategy parameter combination engine, the strategy interface defines a common parameter combination generation interface. All preset strategy algorithms implement this interface to ensure the substitutability and scalability of the preset strategy algorithms. Five built-in strategies include a full combinatorial strategy, a pairwise testing strategy, a boundary value strategy, an orthogonal array strategy, and an intelligent recommendation strategy. Specifically, the full combinatorial strategy generates all possible parameter combinations based on the test parameters and the Cartesian product; the pairwise testing strategy uses a greedy algorithm to ensure that all combinations of any two test parameters are covered by at least one parameter combination; the boundary value strategy sequentially identifies the boundary value and its neighborhood value for each test parameter and generates parameter combinations. These parameter combinations must at least contain the maximum and maximum values ​​of the data values ​​in the test parameters, and may also contain parameter combinations that increase the value upwards (e.g., maximum value + 1 or maximum value + 2) and / or parameter combinations that decrease the value downwards (e.g., minimum value - 1 or minimum value - 2). The range and step size can be adjusted based on the physical characteristics of the target function, safety redundancy requirements, and test coverage depth. The orthogonal array strategy selects a matching standard orthogonal array (e.g., L4, L8, L9, L16, L25) based on the number of test parameters and the number of levels for each parameter. Test parameters are then filled into the columns of the orthogonal array, and the actual value of each parameter is mapped to its corresponding level value, generating a fixed number of parameter combinations to achieve comprehensive coverage of parameter interactions across multiple scenarios. The intelligent recommendation strategy allows for autonomous selection from built-in strategies based on the number of test parameters, coverage requirements, and time constraints in the configuration data. One or more strategies can be selected to generate parameter combinations.The strategy selector automatically selects the most effective strategy based on the test scenario of the target function. For example, when the target function is detected as not belonging to any preset type, and the test parameters related to the target function are less than or equal to a first set number, a full combination strategy is adopted, where the first set number can be set to a small value, such as between 0 and 5. When the target function is detected as not belonging to any preset type, and the test parameters related to the target function are greater than the first set number and less than or equal to a second set number, a pairwise testing strategy is adopted, where the second set number can be set to a large value, such as between 6 and 20. When the target function is detected as a boundary value test type among the preset types, a boundary value strategy is adopted. When the target function is detected as a verification type among the preset types, a... Orthogonal array strategy: When the test parameters and / or the target function do not fall into any of the above categories, an intelligent recommendation strategy is adopted. Based on the coverage requirements of the target function, time constraints, and the number of parameters, one or more strategies are selected from the full combination strategy, pairwise testing strategy, boundary value strategy, and orthogonal array strategy. The parameter matrix is ​​used to provide a structured representation of multi-dimensional parameters, presenting test parameters in a standardized tabular form. It supports parameter grouping management, parameter enable / disable control, and flexible configuration of parameter value types, such as including typical values, boundary values, outliers, or full range values, providing a clear data foundation for parameter combination generation. The constraint filter is used to call the expression evaluation engine to filter invalid parameter combinations, evaluate the constraints of each parameter combination, and generate optimized parameter combinations.

[0030] In the expression evaluation engine, the lexical analyzer decomposes the string expression transformed by constraints into a token sequence, identifies basic elements such as variables, operators, literals, and lists in the token sequence, and lays the foundation for subsequent syntax analysis. The syntax analyzer uses a variety of parsing algorithms and constructs an abstract syntax tree based on operator precedence to adapt to different syntax complexity and performance requirements. Among them, the operator precedence from low to high is logical OR operation, logical AND operation, set operation, comparison operation, addition and subtraction operation, multiplication, division and modulo operation. The parsing algorithm can adopt recursive descent parsing algorithm, precedence climbing algorithm, etc. The abstract syntax tree cache is based on a concurrent dictionary structure, using the expression string as the key to cache the compiled abstract syntax tree node, realizes O(1) time complexity lookup reuse, avoids repeated parsing of the same expression, improves performance, and can also build a cache eviction policy to prevent unlimited memory growth and ensure stability under long-term operation. The type system supports four basic data types: Boolean, number, string and list and provides an intelligent type conversion mechanism to be compatible with the numerical format of different cultural settings and ensure cross-platform parsing consistency. The operator implementation module covers all the computational capabilities required for expressions, including at least arithmetic operations (addition, subtraction, multiplication, division, modulo), comparison operations (equal to, not equal to, less than, greater than, less than or equal to, greater than or equal to), logical operations (AND, OR, NOT), and set operations (contains, excludes, belongs to). It supports nested parentheses of arbitrary depth, correctly handles complex combined expressions, and reserves extension interfaces to allow for the addition of new operator types as needed. In the condition evaluator, value comparisons support operations such as equals, greater than, less than, and in_range, as well as comparisons of numerical, string, and boolean values. Time conditions support time_elapsed, used to determine whether a specified time length has elapsed since the start of the simulation test or at a specified moment. Signal stability supports signal_stable, which can calculate the variance or standard deviation based on data within a time window to determine if the signal is stable within the tolerance range. Error detection conditions support error_occurred, used to detect whether a specified type of error or fault occurs during the test, such as detecting conditional errors or protection faults. The condition evaluator can also incorporate historical data analysis capabilities, which can perform statistical analysis on the collected data based on a time window, calculating the maximum, minimum, average, variance, and trend, providing data support for condition judgment.

[0031] Furthermore, to ensure the accuracy of string expression evaluation and handle exceptional cases, the expression evaluation engine can introduce a null value handling mechanism and a dual-mode evaluation mechanism, as well as establish a test context manager. The test context manager provides at least variable storage, data history, time tracking, and variable substitution functionality. The null value handling mechanism provides comprehensive safety protection for expression evaluation. For example, when a variable in the expression is undefined, an object property does not exist, or a mathematical error such as division by zero occurs, the engine will not throw an exception causing a system crash. Instead, it will handle the situation according to predefined strategies, such as returning a default value, short-circuiting evaluation, or logging a warning before returning a safe result. The dual-mode evaluation mechanism provides two evaluation methods for the expression result: Boolean evaluation and numerical evaluation. Depending on the context requirements, expression evaluation can flexibly return different types of results. For example, in conditional judgment scenarios, the engine evaluates the expression as a Boolean logic, returning true or false, while in parameter calculation scenarios (such as formula calculation and dynamic assignment), the engine evaluates the same expression as a numerical expression, returning a specific numerical result. In the Test Context Manager, variable storage is used to save variables during the test process, supporting read, write, and delete operations. Variables include at least test parameters, precondition calculation results, and intermediate calculated values. History maintenance maintains the time series of collected data, recording device status data at each time point, and supports time window-based data analysis, such as calculating moving averages, variances, and rates of change. Time tracking records time information such as the start time of the simulation test, the duration of each stage, and the total simulation test runtime, and supports time-based conditional judgments, such as determining whether the runtime is greater than or equal to 30 minutes. Variable substitution is a dynamic parameter parsing function that replaces placeholders in step parameters with the actual values ​​of variables, supporting nested variable references and expression calculations. For example, if the step parameters are "Set the air conditioner temperature to ${target_temp}℃ and the fan speed to ${wind_speed}", based on the context variable data, the value of target_temp is 26, and the value of wind_speed is "high," the final step parameters are "Set the air conditioner temperature to 26 ℃ and the fan speed to high."

[0032] S13: Based on the optimized parameter combination and configuration data, perform simulation tests on the target function, generate and output the test results.

[0033] The system loads the selected optimized parameter combinations and configuration data, inputs them into the virtual device state machine for simulation testing, and outputs the simulation results. During simulation testing, action executors can also be built to dynamically register new action types and expand new simulation testing functions. These action executors adopt a plug-in architecture and include at least the following action types: environmental control actions (e.g., `set_temp` sets temperature, `set_humidity` sets humidity, used to configure simulation environment parameters and provide specified operating conditions for the device under test); device control actions (e.g., `set_mode` sets the operating mode, `set_power` sets the power status, `reset_controller` resets the controller, used to send control commands to the device under test and drive its state transitions); delay / wait actions (e.g., `wait` waits for a specified time, used to implement time intervals between test steps to ensure device stability or meet protection delay requirements); command sending actions (e.g., `send_command` sends custom commands, used to directly send protocol frames for low-level communication with the device under test); and assertion / verification actions (e.g., `assert` asserts, used to verify in real time whether device status, parameter values, or fault codes meet expectations, providing a basis for judging test results). Furthermore, the action executor also has a context-aware mechanism. Based on the test context manager, it can access the simulation test context during execution, such as reading stored variable values, writing intermediate calculation results, and triggering custom events, thereby realizing data transfer and state sharing between actions. When a test step is instantiated, the action executor parses the action type and parameters in the step definition, calls the corresponding action implementation, and feeds back the execution result to the test engine, forming a complete test execution closed loop.

[0034] Furthermore, in simulation testing, a data acquisition service can be built to comprehensively record the operating trajectory of the device under test (DUT) during the test process, ensure data consistency in a multi-threaded environment, transmit status change information in real time, and efficiently store historical data. This data acquisition service includes at least multi-dimensional status tracking, thread safety protection, event notification, and change logging functions. Specifically, multi-dimensional status tracking collects device status data such as compressor running time, cumulative power consumption calculation, fault / protection status changes, and frequency limiting status changes, comprehensively recording the device's dynamic response process during test execution. Thread safety protection protects the use of semaphores and shared data, preventing data contention and status inconsistency issues during multi-threaded concurrent acquisition. Event notification displays the device status in real time, triggering a StatusUpdated event the instant the device status changes, and pushing the latest status to the UI (User Interface) or other subscribed modules in real time. The change logging function records the actual changed status data, only recording the device status data that has actually changed. When the status value remains stable, redundant writes are skipped, significantly reducing the amount of log data while ensuring that critical information is not lost.

[0035] In a specific application scenario, the dynamic behavior of the virtual device state machine in cooling mode is simulated and tested, and the verification results are output. The operating conditions are loaded: indoor temperature 28℃, outdoor temperature 35℃, AC voltage 220V. Simultaneously, optimized parameter combinations are loaded, including key parameters such as set temperature 22℃, cooling mode, frequency, and temperature difference. During the simulation, the frequency adjustment module dynamically calculates the target frequency based on the temperature difference: the target frequency is 120Hz when the initial temperature difference is 6℃, and it is adjusted to 80Hz, 50Hz, and 30Hz as the room temperature decreases. The current simulation uses a reference of 8A at 220V and 60Hz, linearly scaled by the frequency and superimposed with ±5% random fluctuations. The output current fluctuates between 7.6A and 8.4A, replicating sensor measurement noise. Temperature changes are calculated based on the difference between cooling capacity and heat load. Assuming a cooling capacity of 2000W, heat load of 1500W, and heat capacity of 1000J / (kg·K) at 60Hz, the temperature change rate is 0.5℃ / min. After 600 seconds, the room temperature drops from 28℃ to 23℃, a decrease of 5℃. After the test, the simulation results showed that the compressor started and ran normally, with the frequency dynamically adjusted according to the temperature difference. The indoor temperature dropped from 28℃ to 23℃, a decrease of 5℃, which met expectations. The current fluctuated within the normal range, and the simulation accuracy reached more than 95% of that of the real equipment.

[0036] Through the above steps, this embodiment dynamically defines test parameters and operating condition data through configuration files, enabling the test system to quickly adapt to different controller models and protocol versions without modifying the source code. This significantly improves the system's scalability and multi-platform compatibility. At the same time, it intelligently filters configuration data based on constraint expressions, effectively avoiding invalid test scenarios and greatly improving test execution efficiency. Finally, through high-fidelity simulation test execution, it accurately reproduces the real operating characteristics of the equipment, making the test results more credible.

[0037] Please see Figure 2 , Figure 2 This is a flowchart illustrating another implementation of the simulation testing method for the target function provided in this application.

[0038] S21: Set the first protocol configuration file in the protocol configuration directory using the preset format.

[0039] Based on the JSON configurable protocol parsing framework, the first protocol configuration file is written according to the system's preset JSON structure. This configuration file fully defines the communication protocol's frame format, field positions, data types, byte order, verification algorithms, and parsing rules. After completion, the configuration file is placed in the system's designated protocol configuration directory.

[0040] S22: Load the configuration files of the protocol configuration directory via a hot-loading mechanism.

[0041] The hot-loading mechanism continuously monitors file changes in the protocol configuration directory. When no new or modified configuration files are detected, it automatically triggers the loading process, parsing and applying the first protocol configuration file, enabling the system to communicate with devices according to that protocol. When a change in the communication protocol is detected, such as the addition of status fields or modification of the verification algorithm, no source code modification is required. Only a second protocol configuration file needs to be created based on the changed protocol specifications and placed in the same protocol configuration directory. The hot-loading mechanism immediately detects the new file, automatically loads and updates the protocol parsing model in memory, including the definitions of newly added status fields (e.g., the addition of a "compressor exhaust temperature" field) and modified verification algorithms (e.g., changing Sum8 checksum to CRC16 checksum). Furthermore, when multiple protocol configuration files are detected, the protocol configuration file can be selected based on priority; manual specification of the protocol configuration file to use is also supported.

[0042] In a specific application scenario, to adapt to the new air conditioner controller communication protocol V2.0, the original V1.0 protocol could not parse the newly added status fields and the changed verification algorithm. Testers did not need to modify any source code; they only needed to create a new protocol configuration file, ac_protocol_v2.json, according to the preset JSON format. The protocol information section declared the version number as V2.0 and set the loading priority. The frame type definition specified the header bytes, command bytes, and dynamic length mode of the status query frame. A new SmartMode field was added to the field definition section, located at byte index 20, with a data type of byte. Value mapping tables mapped 0~3 to "Off," "Energy Saving Mode," "Comfort Mode," and "Powerful Mode," respectively, and bound it to the SmartMode property of the target object DeviceStatus. The verification algorithm was changed from Sum8 to CRC16, and the verification range was specified with a start index of 0, an end index of -3, and a checksum position of -2. After completing the new configuration file, it was placed in the protocol configuration directory, and the hot-loading mechanism automatically detected the new file and loaded it.

[0043] S23: Obtain the test parameters and operating condition data of the target function from the configuration file, and generate the configuration data of the target function.

[0044] This step is the same as step S11 above. Please refer to the relevant description of step S11 for details, which will not be repeated here.

[0045] S24: Generate test parameter data values ​​based on the target function, and generate corresponding parameter combinations using a preset strategy algorithm.

[0046] Based on the target function of the current test, relevant test parameters are extracted from the parameter template or directly generated according to the target function. This includes parameter name, data type, value range, typical value list, boundary value list, etc. Simultaneously, the number of parameters participating in the test and the type of target function are statistically analyzed as input for selecting a preset strategy algorithm. A multi-strategy parameter combination engine generates corresponding parameter combinations. The preset strategy algorithm library includes full combinatorial strategies, pairwise testing strategies, boundary value strategies, orthogonal array strategies, and intelligent recommendation strategies. The system automatically matches an appropriate algorithm based on the number of parameters, value range, and coverage requirements. For example, when the number of parameters is small and exhaustive verification is required, a full combinatorial strategy is used to generate all possible combinations; when the number of parameters is large, a pairwise testing strategy is recommended; when verifying interaction effects, an orthogonal array strategy is used to cover pairwise combinations with the fewest test cases; when focusing on boundary defects, a boundary value analysis strategy is used; and when none of the above applies, an intelligent recommendation strategy is used.

[0047] In a specific application scenario, the target function is to verify the cooling effect under different combinations of set temperature and fan speed. First, relevant test parameters are extracted from the parameter template: the set temperature is an integer with a value range of 16~30℃, a typical value list of [22, 24, 26]℃, and a boundary value list of [15, 16, 30, 31]℃; the fan speed is an enumeration with a value range of [low, medium, high, automatic]; and the swing mode is an enumeration with a value range of [fixed, left / right swing, up / down swing]. Each parameter has 10 possible values ​​for the set temperature, 4 for the fan speed, and 3 for the swing mode. Based on the target function of verifying type-matching orthogonal arrays, an L16 orthogonal array is selected to generate 16 test cases, covering all pairwise combinations of parameters with the fewest possible test cases. If subsequent tests focus on the impact of voltage boundaries on cooling, the system can switch to a boundary value strategy to extract the lower limit of 176V, the upper limit of 264V, and their neighboring values ​​of 177V and 263V to generate boundary test combinations.

[0048] S25: Select the optimal parameter combination from the parameter combinations based on preset conditions.

[0049] The generated initial parameter combinations are finely screened to produce optimized parameter combinations, ensuring that the final parameter combinations used for testing meet the constraints. Specifically, predefined constraints in the parameter template are loaded, and the expression evaluation engine is invoked to evaluate the constraint satisfaction of each candidate parameter combination, automatically discarding all invalid combinations that violate constraints and selecting optimized parameter combinations. Furthermore, the selected parameter combinations can be prioritized, for example, by prioritizing combinations that cover parameter value ranges that have not been tested, sensitive parameter combinations that are prone to defects in historical tests, lightweight test cases with short execution times or low resource consumption, and combinations that highly match the current operating environment. After constraint filtering and optimization, a set of optimized parameter combinations is output, which, while satisfying all constraints, achieves the most comprehensive and thorough simulation verification of the target function.

[0050] Please see Figure 3 , Figure 3 yes Figure 2 A flowchart illustrating a specific embodiment of S25.

[0051] S251: Convert the preset condition into a string expression and decompose the string expression into a sequence of markers.

[0052] Extract the preset conditions defined in the parameter template, such as constraint rules, assertion conditions, or filtering logic, in the form of string expressions. For example, the lexical analyzer converts "The set temperature in the cooling mode must be at least 2°C lower than the indoor temperature" into the string expression "Mode == 'Cool' && TargetTemp < IndoorTemp - 2". Subsequently, the lexical analyzer scans the string expression, decomposes it into a series of semantic token sequences, and identifies and classifies the variable names (such as Mode, TargetTemp), operators (such as ==, <, &&, -), literals (such as 'Cool', 2), and other syntactic elements like parentheses in the expression, generating a structured list of tokens.

[0053] S252: Input the test parameters in the parameter combination into the corresponding token sequence, recursively evaluate the string expression according to the priority of the preset operators, and generate an evaluation result.

[0054] The specific parameter values in the parameter combination, such as Mode = "Cool", TargetTemp = 22, IndoorTemp = 28, are substituted into the corresponding variable positions in the token sequence to achieve variable substitution. The syntax analyzer gradually calculates the expression according to the preset operator priority structure using recursive descent parsing or other evaluation algorithms. Among them, the operator priorities from low to high are logical or, logical and, set operations, comparison operations, addition and subtraction operations, multiplication, division, and modulo operations. For example, for 22 < 28 - 2, first calculate the subtraction to get 22 < 26, then calculate the comparison operation to get true, and finally combine the logical and operation to obtain the evaluation result of the entire expression. This process supports arbitrary-depth parentheses nesting and complex logical combinations, and finally generates a clear evaluation result for each candidate parameter combination, where the evaluation result can be converted between boolean and numeric values according to the type system.

[0055] S253: Screen out the optimized parameter combinations based on the evaluation mechanism and the evaluation result.

[0056] The evaluation mechanism can be divided into boolean evaluation and numeric evaluation. For boolean-type expressions (such as constraint conditions), the system only retains the combinations with an evaluation result of true and discards all invalid combinations that do not meet the conditions; for numeric-type expressions, the system sorts the combinations according to the evaluation result. Based on the dual-mode evaluation mechanism of the expression evaluation engine, flexibly switch between boolean and numeric evaluation modes, and output one or more optimized parameter combinations that meet all preset conditions and have the highest score.

[0057] In a specific application scenario, the constraint condition is the energy-saving effect score, and the string expression is Score = (TargetTemp - 20) * 10 + (WindSpeed == ‘High’? 5 : 0). Three initial parameter combinations are screened. For combination C001, the set temperature is 22°C and the wind speed is high, and the calculated score is (22 - 20) × 10 + 5 = 25 points; for combination C002, the set temperature is 24°C and the wind speed is low, and the score is (24 - 20) × 10 + 0 = 40 points; for combination C003, the set temperature is 26°C and the wind speed is medium, and the score is (26 - 20) × 10 + 0 = 60 points. After sorting by score from high to low, C003 is preferentially selected as the optimized parameter combination.

[0058] In another specific application scenario, the constraint condition is that when the mode is cooling, the set temperature is at least 2°C lower than the indoor temperature, and the supply voltage is within the safe range of 176V to 264V. The converted string expression is Mode == ‘Cool’ && TargetTemp < IndoorTemp - 2 && ACVoltage >= 176 && ACVoltage <= 264. A candidate parameter combination is loaded: the mode is set to Cool, the set temperature is 20°C, the indoor temperature is 26°C, and the AC voltage is 220V. The expression evaluation engine first performs lexical analysis on the constraint expression, decomposing it into a sequence of tokens such as variables, operators, and literals. Subsequently, the syntax analyzer constructs an abstract syntax tree according to the operator precedence and stores the tree structure in the abstract syntax tree cache for subsequent reuse to avoid repeated parsing. After filling in the variable values, the engine starts recursive evaluation: comparing Mode == ‘Cool’ gives true; calculating TargetTemp < IndoorTemp - 2, that is, 20 < 26 - 2 gives 20 < 24 which is true; verifying the voltage range ACVoltage >= 176 && ACVoltage <= 264, that is, 220 >= 176 && 220 <= 264 are both true. Finally, the logical AND result of the three sub-expressions is true, and this parameter combination passes the constraint verification and is recorded as the optimized parameter combination.

[0059] S26: Based on the optimized parameter combination and configuration data, perform a simulation test on the target function, and generate and output the test results.

[0060] This step is the same as the aforementioned step S13. For specific details, please refer to the relevant description of step S13 and will not be elaborated here.

[0061] Through the above steps, this embodiment enables the system to dynamically optimize the test case generation method according to the test parameter scale by automatically selecting a preset strategy algorithm, thereby improving the test case generation efficiency. Furthermore, by distinguishing between Boolean evaluation and numerical evaluation in constraint condition evaluation, the screening process can adapt to different business logic types, thereby automating condition verification and parameter optimization.

[0062] Based on the same concept, this application also proposes an electronic device capable of executing a simulation test method to achieve the target function of any of the above embodiments. Please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram of an embodiment of the electronic device provided in this application. The electronic device includes a controller 41 and a memory 42.

[0063] The controller 41 is used to execute the program instructions stored in the memory 42 to implement the steps of the simulation test method for any of the above-mentioned target functions. In a specific implementation scenario, the electronic device may include, but is not limited to, a microcomputer or a server. In addition, the electronic device may also include mobile devices such as laptops and tablets, which are not limited here.

[0064] Specifically, controller 41 controls itself and memory 42 to implement the steps of any of the above embodiments. Controller 41 may also be referred to as a CPU (Central Processing Unit). Controller 41 may be an integrated circuit chip with signal processing capabilities. Controller 41 may also be a general-purpose controller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose controller may be a microcontroller or any conventional controller. Furthermore, controller 41 may be implemented using integrated circuit chips.

[0065] The above solution provides personalized recommendations during the image selection process, reduces the time users spend selecting images, and automates the filtering of target images. Users do not need to manually filter each image, which greatly simplifies the image selection process, saves time, improves filtering efficiency, and thus helps to improve shooting efficiency.

[0066] Based on the same concept, this application also proposes a computer-readable storage medium, please refer to... Figure 5 , Figure 5This is a schematic diagram of an embodiment of the computer-readable storage medium provided in this application. The computer-readable storage medium 50 stores at least one program data 51, which is used to implement any of the methods described above. In one embodiment, the computer-readable storage medium 50 includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0067] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0068] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0069] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0070] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium.

[0071] The above are merely embodiments of this application and do not limit the scope of this patent application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

Claims

1. A simulation testing method for a target function, applicable to embedded control systems, characterized in that, The simulation testing method includes: The test parameters and operating condition data of the target function are obtained from the configuration file, and the configuration data of the target function is generated. Based on the target function, the data values ​​of the test parameters are generated and combined to obtain the optimized parameter combination for the simulation test of the target function; Based on the optimized parameter combination and the configuration data, the target function is simulated and tested, and the test results are generated and output.

2. The simulation testing method according to claim 1, characterized in that, The step of generating and combining the data values ​​of the test parameters based on the target function to obtain the optimized parameter combination for the target function simulation test includes: Based on the target function, the test parameter data values ​​are generated, and the corresponding parameter combinations are generated using a preset strategy algorithm; The optimized parameter combination is selected from the parameter combinations based on preset conditions.

3. The simulation testing method according to claim 2, characterized in that, The step of generating data values ​​for the test parameters based on the target function and generating corresponding parameter combinations using a preset strategy algorithm includes: Detect whether the target function is a preset type; wherein, the preset type includes at least one of boundary value test type and verification type; In response to the target function being the boundary value test type, a third preset strategy algorithm is used to extract boundary values ​​from the data values ​​of each test parameter, generating multiple sets of parameter combinations; wherein, the multiple sets of parameter combinations at least include the parameter combinations corresponding to the maximum and minimum values ​​of the data values ​​in the test data; In response to the target function being the verification type, the fourth preset strategy algorithm is used to fill the data values ​​of the test parameters based on a preset orthogonal array template to generate the parameter combination; In response to the fact that the target function does not belong to any preset type and the number of test parameters is less than or equal to the first preset number, the data values ​​of the test data are fully combined using the first preset strategy algorithm, and the result of the full combination is used as the parameter combination. In response to the fact that the target function does not belong to any preset type, and the number of parameters is greater than the first preset number and less than or equal to the second preset number, the second preset strategy algorithm is used to process the data values ​​of the test data using a greedy algorithm, and generate the parameter combination.

4. The simulation testing method according to claim 2, characterized in that, The step of selecting the optimized parameter combination from the parameter combinations according to preset conditions includes: The preset conditions are converted into string expressions, and the string expressions are decomposed into a sequence of markers; The test data in the parameter combination is input into the corresponding tag sequence, the string expression is recursively evaluated according to the priority of the preset operator, and the evaluation result is generated. The optimal parameter combination is selected based on the evaluation mechanism and the evaluation results.

5. The simulation testing method according to claim 4, characterized in that, The step of selecting the optimal parameter combination based on the evaluation mechanism and the evaluation results includes: Since the evaluation mechanism is a Boolean evaluation, the parameter combinations whose evaluation results are true are selected as the optimized parameter combinations; Since the evaluation mechanism is a numerical evaluation, the parameter combination whose evaluation result satisfies the expected value is selected as the optimized parameter combination.

6. The simulation testing method according to claim 4, characterized in that, The preset operators include: logical OR operation, logical AND operation, set operation, comparison operation, addition and subtraction operation, multiplication, division and modulo operation, and the priority of the logical OR operation, logical AND operation, set operation, comparison operation, addition and subtraction operation and multiplication, division and modulo operation increases in sequence.

7. The simulation testing method according to claim 1, characterized in that, Before the step of obtaining the test parameters and operating condition data of the target function from the configuration file and generating the configuration data of the target function, the following steps are included: Set the first protocol configuration file with the preset format in the protocol configuration directory; The configuration file in the protocol configuration directory is loaded using a hot-loading mechanism.

8. The simulation testing method according to claim 7, characterized in that, The process of loading the configuration file of the protocol configuration directory via a hot-loading mechanism includes: When a change in the communication protocol is detected, a second protocol configuration file is created; the second protocol configuration file contains the status field of the changed communication protocol and the modified verification algorithm; The second protocol configuration file is set in the protocol configuration directory, and the configuration file in the protocol configuration directory is loaded through the hot loading mechanism.

9. An electronic device, characterized in that, The electronic device includes a memory and a controller coupled to each other, the controller being used to execute program instructions stored in the memory to implement the simulation test method for the target function as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program data that can be executed to implement the simulation test method for the target function as described in any one of claims 1 to 8.

Images