A test case generation method and system

Abstract

The application discloses a test case generation method and system, and belongs to the technical field of functional safety testing. The test case generation method automatically extracts structured data by performing semantic analysis on a functional safety requirement document, the structured data includes an ASIL level, a functional parameter threshold boundary and a safety target, and automatically determines a test method set based on the ASIL level and a preset rule, and automatically generates a test data set based on the ASIL level and the functional parameter threshold boundary, and then automatically generates a test case set in combination with the test method set, the test data set and the safety target, so that manual checking of standards or manual writing of cases are not needed in the whole process, and therefore, the generation time of functional safety test cases can be shortened, and the efficiency of test case generation can be improved.

Description

Technical Field

[0001] This application relates to the field of functional safety testing technology, and in particular to a test case generation method and system. Background Technology

[0002] Functional safety testing in the automotive industry must meet the ISO 26262 standard, which requires the design of differentiated test cases based on different ASIL (Automotive Safety Integrity Level) levels. Currently, the design of functional safety test cases mainly relies on consulting the standard and combining it with engineers' experience, making the generation of functional safety test cases time-consuming. Summary of the Invention

[0003] This application provides a test case generation method and system, which aims to improve the efficiency of functional safety test case generation.

[0004] In a first aspect, embodiments of this application provide a test case generation method, the method comprising: Based on the functional safety requirements document, the structured data corresponding to the safety requirements is determined through semantic parsing methods; the structured data includes ASIL level, functional parameter threshold boundaries, and safety objectives. Based on ASIL levels and preset rules, determine the test method set corresponding to security requirements; Based on ASIL level and functional parameter threshold boundaries, determine the test dataset corresponding to the security requirements; Based on the test method set, test dataset, and security objectives corresponding to the security requirements, a test case set corresponding to the security requirements is generated.

[0005] In some embodiments, based on the functional safety requirements document, the structured data corresponding to the safety requirements is determined through semantic parsing methods, including: Based on the functional safety requirements document, the structured data corresponding to the safety requirements is determined by using a pre-set natural language processing model.

[0006] In some embodiments, based on ASIL levels and preset rules, a set of test methods corresponding to security requirements is determined, including: Based on ASIL levels and preset rules, a set of test methods corresponding to security requirements is determined through a preset knowledge graph.

[0007] In some embodiments, the test dataset corresponding to the security requirements is determined based on the ASIL level and functional parameter threshold boundaries, including: The number of test cases is determined based on a preset base number of test cases, combined with the weighting factor corresponding to the ASIL level and the security mechanism complexity factor. Based on the weighting factors corresponding to the ASIL level, the threshold boundaries of the functional parameters are expanded to determine the expanded threshold boundaries of the functional parameters. Based on the number of test cases, sampling is performed from the functional parameter extended threshold boundary to determine the test dataset corresponding to the security requirements.

[0008] In some embodiments, the weighting factor corresponding to the ASIL level is positively correlated with the ASIL level, and the weighting factor corresponding to the ASIL level D is 4 times that corresponding to the ASIL level A.

[0009] In some embodiments, the security mechanism complexity factor is determined by a weighted sum of the diagnostic coverage factor, the fault tolerance mechanism complexity factor, and the security state complexity factor; wherein, the diagnostic coverage factor is determined based on the actual diagnostic coverage and the target diagnostic coverage; the fault tolerance mechanism complexity factor is determined based on the number of redundant components; and the security state complexity factor is determined based on the number of security states.

[0010] In some embodiments, the method further includes: Based on the structured data corresponding to security requirements, the executable instruction data corresponding to the security requirements is determined through the pre-set security dictionary technology. After generating the test case set corresponding to the security requirements based on the test method set, test dataset, and security objectives, the method also includes: Based on the test case set corresponding to the security requirements and the executable instruction data corresponding to the security requirements, test result data and test documents are generated through a preset test platform.

[0011] In some embodiments, after generating test result data and test documents based on the test case set corresponding to the security requirements and the executable instruction data corresponding to the security requirements through a preset test platform, the method further includes: Based on the test results data, determine the weight score corresponding to each test case; If the weight score is lower than the first preset threshold, the weight of the corresponding test case will be reduced by a first percentage. If the weight score is higher than or equal to the first preset threshold, the weight of the corresponding test case will be increased by a second ratio; if the second ratio is less than the first ratio. Test cases with weights less than the preset weight threshold are removed, and the same number of new test cases are generated. The steps of generating test result data and test documentation are repeated.

[0012] In some embodiments, after generating test result data and test documents based on the test case set corresponding to the security requirements and the executable instruction data corresponding to the security requirements through a preset test platform, the method further includes: If no defects are detected after a test case has been executed a preset number of times, the weight of the test case will be reduced to the third percentage. If a test case detects at least two defects in a single execution, the weight of the test case is increased to the fourth proportion; the fourth proportion is greater than the third proportion. Test cases with weights less than the preset weight threshold are removed, and the same number of new test cases are generated. The steps of generating test result data and test documentation are repeated.

[0013] Secondly, embodiments of this application also provide a test case generation system, the system comprising: The first module is used to determine the structured data corresponding to the safety requirements based on the functional safety requirements document through semantic parsing methods; the structured data includes ASIL level, functional parameter threshold boundaries, and safety objectives; The second module is used to determine the test method set corresponding to security requirements based on ASIL level and preset rules; The third module is used to determine the test dataset corresponding to the security requirements based on the ASIL level and functional parameter threshold boundaries. The fourth module is used to generate test case sets corresponding to security requirements based on the test method set, test dataset, and security objectives.

[0014] This application provides a test case generation method. This application automatically extracts structured data by semantically parsing functional safety requirements documents. The structured data includes ASIL level, functional parameter threshold boundaries, and safety objectives. Based on the ASIL level and preset rules, the test method set is automatically determined. At the same time, a test dataset is automatically generated based on the ASIL level and functional parameter threshold boundaries. Then, the test case set is automatically generated by combining the test method set, the test dataset, and the safety objectives. The entire process does not require manual reference to standards or manual writing of test cases. Therefore, it can shorten the generation time of functional safety test cases and improve the efficiency of test case generation.

[0015] This application also provides a test case generation system. The test case generation system is applied to the test case generation method in the above embodiments. Therefore, the test case generation system can have all the technical features and beneficial effects of the test case generation method, which will not be repeated here. Attached Figure Description

[0016] Figure 1 A flowchart illustrating a test case generation method provided in an embodiment of this application; Figure 2 A topological schematic diagram of a preset knowledge graph provided in an embodiment of this application; Figure 3A flowchart illustrating another test case generation method provided in this application embodiment; Figure 4 This is a flowchart illustrating another test case generation method provided in an embodiment of this application. Detailed Implementation

[0017] 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 a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0018] In the embodiments of this application, "at least one" refers to one or more; "multiple" refers to two or more. In the description of this application, the terms "first," "second," "third," etc., are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying order.

[0019] References such as “one embodiment” or “some embodiments” as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the terms “comprising,” “including,” “having,” and variations thereof, as used in this specification, mean “including, but not limited to,” unless otherwise specifically emphasized.

[0020] It should be noted that in the embodiments of this application, "and / or" describes the relationship between associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. In addition, the character " / ", unless otherwise specified, generally indicates that the associated objects before and after it are in an "or" relationship.

[0021] It should be noted that in the embodiments of this application, "connection" can be understood as electrical connection. The connection between two electrical components can be a direct or indirect connection between the two electrical components. For example, the connection between A and B can be a direct connection between A and B, or an indirect connection between A and B through one or more other electrical components.

[0022] Functional safety testing in the automotive industry must meet the ISO 26262 standard. Part 4 requires the design of differentiated test cases based on different ASIL levels (Automotive Safety Integrity Levels), ranging from ASILA to ASILD. Currently, the design of functional safety test cases mainly relies on consulting the standard and combining it with engineers' experience. Designing a single test case typically takes more than two hours and is difficult to systematically cover the standard requirements. Statistics show that the test case design cycle accounts for approximately 40% of the total project cycle. Especially for ASILD level requirements, manual coverage verification is time-consuming and highly dependent on individual engineers' experience, resulting in overall low efficiency in generating functional safety test cases.

[0023] In related technologies, model-based security testing frameworks lack a dynamic weight allocation mechanism for ASIL levels, have fixed test intensity, and lack a quantitative mapping model between ASIL levels and the number and coverage of test cases, which may result in insufficient fault injection coverage for high-level security requirements. Meanwhile, ISO 26262 standard verification tools use predefined test templates, lacking intelligently driven dynamic parameter generation and closed-loop optimization based on test result feedback. Fixed test templates cannot dynamically adjust test cases based on historical test results, easily leading to redundant tests and test omissions.

[0024] Therefore, it is evident that the related technologies cannot quantify the relationship between ASIL level and test intensity (such as the number of test cases and coverage), resulting in insufficient fault injection coverage for high-level security requirements. In addition, the lack of a test result feedback and optimization mechanism leads to a high proportion of redundant test cases and may result in the omission of key test scenarios.

[0025] In view of this, embodiments of this application provide a test case generation method, which aims to solve at least one of the above-mentioned technical problems.

[0026] Please see Figure 1 , Figure 1 This is a flowchart illustrating a test case generation method provided in an embodiment of this application.

[0027] This application provides a test case generation method, the method including: Step S1: Based on the functional safety requirements document, determine the structured data corresponding to the safety requirements through semantic parsing methods; the structured data includes ASIL level, functional parameter threshold boundaries, and safety objectives.

[0028] The functional safety requirements document (FSR) is prepared in accordance with the ISO 26262 standard. The document content is derived layer by layer from the overall vehicle safety objectives. The test objects corresponding to the document can be the vehicle's electrical architecture, the on-board electronic control assembly (such as BMS, VCU, MCU, etc.), or discrete components within the assembly (such as sampling chips, temperature sensors, high-voltage relays, etc.). The FSR can be in formats such as DOORS, Excel, and TXT, but is not limited to these. The FSR serves as the original data source for automatically generating test cases. A single FSR can include multiple safety requirements corresponding to the test object. Each safety requirement is written in natural language, including ASIL safety level, safety objective, functional parameters, functional parameter threshold boundaries, timing constraints, and other natural language descriptive information. For example, a safety requirement for a Battery Management System (BMS) with an ASILD safety level could be: "When the cell temperature is ≥48℃ for 1000ms, liquid cooling is activated, requiring ASILD compliance, with a cell temperature range of -20℃ to 65℃." Therefore, the ASIL safety level of this safety requirement is ASILD; the safety objective is to activate liquid cooling when the cell temperature is ≥48℃; the functional parameter is the cell temperature; the functional parameter threshold boundary is -20℃ to 65℃; and the timing constraint is 1000ms.

[0029] For other safety requirements, functional parameters can also be fault parameters such as individual cell voltage, battery pack current, cell temperature, insulation resistance, overvoltage threshold, response time, hysteresis range, number of retries, and ambient temperature, which are determined according to the actual implementation plan requirements.

[0030] In some examples, the threshold boundaries of functional parameters can be further expanded to generate subsequent test datasets. For different types of functional parameters, different expansion rules can be set according to the requirements of different ASIL levels. The purpose of expansion is to enable test cases to cover scenarios such as sensor drift, signal offset, extreme operating conditions, and fault injection, thereby verifying the robustness of the system under different safety levels.

[0031] As shown in Table 1, Table 1 provides an extended example of sensor measurement parameters at the ASILD level. The functional parameters measured by the sensor refer to analog quantities directly acquired by the physical sensor, such as cell voltage, battery current, battery temperature, and insulation resistance.

[0032] Table 1: Extended Examples of Sensor Measurement Parameters at ASILD Level

[0033] As shown in Table 2, Table 2 is an extended example of control logic parameters at the ASILD level. The functional parameters of control logic refer to the numerical values ​​such as thresholds, times, and intervals used for judgment and execution in the system.

[0034] Table 2: Extended Examples of Control Logic Parameters at ASILD Level

[0035] As shown in Table 3, Table 3 is an extended example of environmental parameters under the ASILD level. The environmental parameters mainly consider the external environmental conditions of the system operation, such as ambient temperature.

[0036] Table 3: Extended Examples of Environmental Parameters at ASILD Level

[0037] It should be noted that the threshold boundaries of the above functional parameters can be determined from the clauses of the ISO26262 standard or from historical experience.

[0038] It should also be noted that during the compilation process, the original archived requirements documents may contain redundant non-requirement text such as version revision notes, compilation instructions, cell comments, and draft supplements. This unstructured text can interfere with the accuracy of feature extraction by the subsequent natural language model. Therefore, a standardized preprocessing workflow is set up before sending it to the semantic parsing step. Preprocessing includes data cleaning and keyword annotation. The preprocessed functional safety requirements documents are then used to determine the structured data corresponding to each safety requirement through semantic parsing methods. For example, data cleaning may include removing non-requirement content such as comments and version numbers. Keyword annotation includes marking key fields such as ASIL security level, security objectives, functional parameters, functional parameter threshold boundaries, and temporal constraints.

[0039] For each security requirement, based on the functional safety requirements document, structured data corresponding to each security requirement is determined using semantic parsing methods. Semantic parsing refers to the process of extracting machine-readable structured data from unstructured text using natural language processing techniques. Structured data refers to a set of machine-readable information with predefined fields and formats extracted from the security requirements described in natural language. Structured data is typically represented in JSON format. The structured data uses entity field descriptions, relation field descriptions, and semantic role field descriptions to represent the previously described ASIL security level, security objectives, functional parameters, functional parameter threshold boundaries, and timing constraints.

[0040] In some embodiments, based on the functional safety requirements document, structured data corresponding to the safety requirements is determined using a pre-set natural language processing (NLP) model. This pre-trained NLP model can employ Bidirectional Encoder Representations from Transformers (BERT), which identifies key information entities and their semantic roles in the functional safety requirements text and converts them into structured data output. This allows the acquisition of structured data corresponding to each safety requirement.

[0041] Step S2: Based on the ASIL level and preset rules, determine the test method set corresponding to each security requirement.

[0042] It is known that, according to the ISO 26262 standard, different ASIL levels correspond to different recommended test method requirements. Therefore, in some examples, for each security requirement, based on the ASIL level in the corresponding structured data, an initial set of test methods corresponding to that level can be determined first. Then, the initial set of test methods is filtered according to corresponding preset rules to obtain the final set of test methods. In other embodiments, the test method set for each security requirement can also be determined simultaneously based on the ASIL level and preset rules. The test method set includes at least one test method.

[0043] The preset rules are used to eliminate inapplicable test methods based on the specific information features contained in the structured data. Preset rules automatically select applicable test methods based on the data type of the functional parameters in the safety target. For example, taking the safety target "liquid cooling is activated when the cell temperature ≥ 48℃" as an example, during the semantic parsing stage, the functional parameter "cell temperature" and the numerical threshold "48℃" are identified from this safety target. Since this safety target has a clear numerical threshold, its data type is inferred to be integer. For parameters of integer data type, their values ​​have a continuous numerical range and clear boundary values; therefore, boundary value testing, equivalence class partitioning testing, and parameter numerical range expansion are all applicable. If a safety target does not contain a numerical threshold (e.g., "reporting fault when CAN signal is lost"), its data type can be inferred to be Boolean. Boolean parameters only have two states (triggered / not triggered) and do not have numerical boundaries or equivalence intervals; therefore, boundary value testing, equivalence class partitioning testing, and parameter numerical range expansion are not applicable. The security dictionary tags the data type indicated by each security target, and preset rules automatically filter applicable test methods based on these tags, thereby ensuring that the generated test cases match the data type. Preset rules can be implemented in the form of conditional logic or a rule base.

[0044] Please see Figure 2 , Figure 2 This is a topological diagram of a preset knowledge graph provided in an embodiment of this application.

[0045] In some embodiments, based on ASIL levels and preset rules, a set of test methods corresponding to security requirements is determined through a preset knowledge graph.

[0046] In this embodiment, a knowledge graph based on the ISO26262 standard is pre-constructed to solidify the association rules between standard clauses, security levels, test methods, and functional safety requirements, enabling automatic mapping and matching of test methods. This knowledge graph uses a graph database (e.g., Neo4j) as its storage and management tool, containing various types of nodes and connecting edges between them.

[0047] The nodes of this knowledge graph are shown in Table 4, which provides examples of each node in the preset knowledge graph.

[0048] Table 4: Examples of nodes in the pre-defined knowledge graph

[0049] This knowledge graph includes at least the following node types, each with corresponding key attributes: Standard nodes, storing the standard name and version information, such as "ISO26262" and "2018". Part nodes, storing the identifier and title of a standard section, such as "Part4" and "Product Development System Level". Clause nodes, storing the identifier, title, and description of a specific clause in the standard, such as "8.4.3", "Fault Injection Test", and a detailed description of the clause. ASIL Level nodes, storing the vehicle safety integrity level and corresponding compliance requirements, such as "D" and "Single Point of Failure Coverage ≥ 99%". Test Method nodes, storing the name, coverage, and complexity of various test methods recommended by the standard, such as "Boundary Value Test", "Coverage 0.97", and "Medium Complexity". The Safety Requirement node stores the identifier (id) and description attributes of a single functional safety requirement, such as "Req_ES_01" and "Voltage Over-Limit Protection". It should be noted that the above is merely an example; the nodes in the knowledge graph are set according to the content of the standard. The standard is existing technology, and therefore those skilled in the art will understand it clearly, so it will not be elaborated further here. In practical applications, nodes can be added or adjusted according to specific standards.

[0050] Data links are established between nodes through various logical relationships. Standard nodes are connected to some nodes, some nodes are connected to clause nodes, and clause nodes are connected to requirement nodes through association relationships. Clause nodes point to test method nodes through recommendation relationships, and clause nodes point to safety level nodes through requirement relationships. Safety requirement nodes point to test method nodes through constraint relationships, and test method nodes point to safety level nodes through applicable relationships, thereby solidifying the various matching rules within the ISO 26262 standard.

[0051] In practical applications, the knowledge graph uses the structured data output from semantic parsing as the mapping basis, completes the mapping matching according to the preset logical relationships between nodes, automatically filters out all test methods applicable to the current security requirement, and finally outputs the corresponding test method set. Specifically, starting with the ASIL level (e.g., "ASILD") extracted from the structured data of the security requirement, it traverses the "applicable" edges to find all test method nodes connected to that ASIL level, thus obtaining the initial test method set. Subsequently, it is filtered using preset rules extracted from the structured data of the security requirement to obtain the final test method set.

[0052] The knowledge graph described above can transform the text content of the ISO 26262 standard into a machine-queryable graph structure, enabling automated mapping and matching of testing methods. The knowledge graph content can be maintained according to standard version updates, ensuring the accuracy and timeliness of test method selection.

[0053] For example, as in the aforementioned example when the cell temperature is ≥48℃, a pre-defined knowledge graph can be used to map and match the corresponding set of test methods, including fault injection test methods.

[0054] It should be noted that testing methods may include requirements-based testing, fault injection testing, boundary value testing, equivalence class partitioning testing, performance testing, error guessing testing, testing based on field experience, external interface testing, internal interface testing, interface consistency checking, communication and interaction testing, resource usage testing, stress testing, state machine testing, parameter scanning testing, and operational testing. The above testing methods are common existing technologies in the industry, which can be directly understood by those skilled in the art based on the standard text. The ISO 26262 standard has detailed definitions, applicable scenarios, testing procedures, and matching rules with security levels. All of these are based on the standard text, which can be directly obtained by those skilled in the art, and will not be elaborated here.

[0055] Step S3: Based on the ASIL level and functional parameter threshold boundaries, determine the test dataset corresponding to each test method in the test method set. In this application, each safety requirement corresponds to a test dataset, which is a matrix containing multiple data values. Each data value in the matrix corresponds to the input data of a test case. It should be noted that each functional safety requirement corresponds to the implementation requirement of a safety mechanism (i.e., fault detection). Therefore, each requirement corresponds to only one functional parameter threshold boundary, and this range is unique for integer data types. The parameter value range extension only applies to integer data types. Although different test methods all select test data from this functional parameter threshold boundary, the specific value selection rules and focuses of each method are different, so the corresponding test data may not be the same. For example, taking the safety requirement "If the single-unit voltage ≥ 4.25V and lasts for 2s, then cut off the high-voltage circuit, the safety level is ASIL D, and the parameter range is 1.0V~4.5V" as an example, this requirement corresponds to an integer data type, and the parameter range can be extended to 1.0V~4.7V. After determining the test method set based on ASIL D level, the parameter values ​​for each test method are determined as follows: Requirements-based tests can take any value within a range that meets the trigger condition (≥4.25V) and does not exceed the upper limit of the parameter range (4.5V), such as 4.25V or 4.4V; boundary value tests require selecting lower and upper boundary values ​​near the trigger threshold, such as 4.245V (lower boundary) and 4.25V or 4.255V (upper boundary); equivalence class partitioning tests require selecting at least one valid equivalence class value (e.g., 4.25V or 4.4V) and one invalid equivalence class value (e.g., 4.6V, within the extended range of 4.7V but exceeding the normal range of 4.5V); other test methods also follow their respective rules, taking parameter values ​​within the trigger value range or randomly selecting them.

[0056] Step S4: Based on the test method set, test dataset, and security objectives, generate a test case set corresponding to the security requirements.

[0057] In this embodiment of the application, the test case set corresponding to each security requirement includes each test data, the test method corresponding to each test data, and the expected action corresponding to each test data. The expected action is determined based on the security objective.

[0058] For example, as in the aforementioned example where the cell temperature is ≥48℃, the safety objective is to activate liquid cooling when the cell temperature is ≥48℃. Therefore, the expected action is: liquid cooling is activated when the cell temperature is ≥48℃, and not activated when the cell temperature is <48℃. Taking the fault injection test method corresponding to the test case as an example, as shown in Table 5, Table 5 contains partial examples of test case sets, where the test case ID can be automatically generated by the test case generation system.

[0059] Table 5: Partial Examples of Test Case Sets

[0060] Through the above technical solution, this application provides a test case generation method. This application automatically extracts structured data by semantically parsing functional safety requirements documents. The structured data includes ASIL levels, functional parameter threshold boundaries, and safety objectives. Based on the ASIL levels and preset rules, a test method set is automatically determined. Simultaneously, based on the ASIL levels and functional parameter threshold boundaries, a test dataset corresponding to each test method in the test method set is automatically generated. Then, by combining the test method set, test dataset, and safety objectives, a test case set is automatically generated. The entire process eliminates the need for manual standard review or manual test case writing, thus shortening the generation time of functional safety test cases and improving the efficiency of test case generation. Furthermore, since the structured data includes ASIL levels, and the determination of the test dataset and test method set depends on these ASIL levels, for high-security requirements such as ASILC or ASILD, the system automatically generates more comprehensive test datasets and matches more complete test method sets. This improves upon potential oversights during manual design and enhances fault injection coverage for high-security requirements.

[0061] In some embodiments, based on ASIL level and functional parameter threshold boundaries, the test dataset corresponding to each test method in the test method set is determined, including: Step S31: Based on the preset base number of test cases, combined with the weight factor corresponding to the ASIL level and the security mechanism complexity factor, determine the number of test cases.

[0062] In this embodiment of the application, the number of test cases is determined based on a preset base number of test cases, a weighting factor corresponding to the ASIL level, and a security mechanism complexity factor.

[0063] The preset base number of test cases (denoted as K) is the pre-set number of basic test cases. In this embodiment, K can be 10, or other numbers such as 1, 2, 3, 4, 5, 6 or 7, etc. The specific number is set according to the actual implementation requirements, and this application does not limit it.

[0064] The weighting factor (denoted as W) corresponding to the ASIL level ASIL This is used to reflect the differences in the requirements for test intensity for different safety levels.

[0065] In some embodiments, the weighting factor corresponding to the ASIL level is positively correlated with the ASIL level, and the weighting factor corresponding to the ASIL level D is at least three times that corresponding to the ASIL level A.

[0066] For example, the weighting factor corresponding to the ASIL level is positively correlated with the ASIL level. Specifically, the weighting factor corresponding to the ASIL level increases non-linearly as the ASIL level increases. According to the classification of ASIL levels in the ISO26262 standard, in this embodiment, the weighting factor can be set to 1.0 for ASILA, 1.8 for ASILB, 2.5 for ASILC, and 4.0 for ASILD.

[0067] Understandably, the higher the ASIL level, the more stringent the security requirements, and the more intensive the testing should be. From ASILA to ASILD, the weighting factor increases non-linearly. In particular, ASILD requires at least three times the testing intensity of ASILA, and the weighting factor for each ASIL is greater than or equal to 1. This non-linear growth relationship reflects that the testing intensity requirements for higher security levels are much higher than those for lower levels.

[0068] It should be noted that the specific values ​​mentioned above are merely examples. In practical applications, the specific values ​​of the weighting factors can be adjusted according to the safety objectives and engineering experience of different projects, but the basic rule that the weighting factors increase non-linearly with the increase of ASIL level should be maintained, and the multiple relationship between ASILD and ASILA should be at least 3 times. Those skilled in the art should understand that as long as the above-defined characteristics are met, they all fall within the protection scope of this application.

[0069] Security mechanism complexity factor (denoted as C) SM C is used to reflect the complexity of the security mechanism of the object under test. SM The larger the value, the more complex the security mechanism, and consequently, the more test cases need to be generated.

[0070] In some embodiments, the security mechanism complexity factor is determined by a weighted sum of the diagnostic coverage factor, the fault tolerance mechanism complexity factor, and the security state complexity factor; wherein, the diagnostic coverage factor is determined based on the actual diagnostic coverage and the target diagnostic coverage; the fault tolerance mechanism complexity factor is determined based on the number of redundant components; and the security state complexity factor is determined based on the number of security states.

[0071] Specifically, in this embodiment, C SM Calculate using the following formula: C SM =a*C DC +b*C FT +c*C SS .

[0072] Among them, C DC For diagnostic coverage factor, C FT As a complexity factor for fault tolerance mechanisms, C SSThe safety status complexity factor is represented by a, b, and c, which are preset weighting coefficients, set to 0.6, 0.3, and 0.1 respectively in this embodiment. It should be noted that the specific values ​​of a, b, and c can be adjusted based on actual engineering experience, but the sum of the three should always be 1.

[0073] Diagnostic coverage factor C DC The diagnostic coverage is determined based on the ratio of actual diagnostic coverage to target diagnostic coverage. Diagnostic coverage (DC) refers to the percentage of faults that a safety mechanism can detect out of all faults. In ISO 26262, it is used to measure the effectiveness of a safety mechanism. Actual diagnostic coverage is obtained through testing and verification during the previous iteration, while the target diagnostic coverage is determined by the ASIL level (e.g., if ASILD requires ≥99%, then the target diagnostic coverage is 99%). Diagnostic coverage factor C DC The calculation formula is: C DC = Actual diagnostic coverage / Target diagnostic coverage.

[0074] For example, based on the test results data of the previous test case set, if the actual action of a test case is consistent with the expected action of that test case, then the corresponding fault is considered to be detectable by the security mechanism; if the actual action is inconsistent with the expected action, then the corresponding fault is considered not to be detectable. The total number of faults is taken as the total number of test cases in the test case set. This ratio can quantify the actual diagnostic capability of the security mechanism in the current test iteration, i.e., the actual diagnostic coverage, which in turn affects the calculation of the security mechanism complexity factor in the next iteration. It should be noted that before the first test iteration, since no tests have been executed, the initial diagnostic coverage factor C is... DC The default setting is 100%. As testing progresses, C... DC Updated dynamically based on actual test results. It should be noted that C is limited. DC The upper limit of C, if C DC If the value is greater than 1, then the value is 1.

[0075] Fault tolerance mechanism complexity factor C FT The number of redundant components is determined based on the number of redundant components. Redundant components refer to the number of additional hardware or software components added to achieve fault tolerance. For example, a dual-redundant system has one redundant component (primary + backup, totaling two, with a redundancy count of 1), and a triple-redundant system has two redundant components (primary + two backups, with a redundancy count of 2). C FT The calculation formula is: C FT =1 + 0.2 × number of redundant components. The number of redundant components can be obtained from the system design document or by analyzing the system architecture diagram (e.g., Fault Tree Analysis (FTA), Failure Mode and Effects Analysis (FMEA)).

[0076] For example, the battery pack current detection function in the battery management system (BMS) has an ASIL C / D safety level, and the corresponding safety requirements require the current detection to adopt a dual redundancy design: the main component is a shunt, and the backup component is a Hall sensor.

[0077] Safety state complexity factor C SS Determined based on the number of safe states. The number of safe states refers to the number of predefined safe states that a system can enter when a fault is detected. For example, a simple system may only have one safe state, "shutdown" (safety state number = 1); while a complex system may have multiple safe states such as "degraded operation," "restricted operation," and "complete shutdown" (safety state number = 3). SS The calculation formula is: C SS =log2(number of safe states + 1). The number of safe states can be obtained from the system's state machine design document or security requirements specification.

[0078] For example, different safety levels in a Battery Management System (BMS) correspond to different numbers of safety states for functional safety requirements. For ASIL C / D level functional safety requirements, such as handling overcurrent faults, there are two safety states: the first safety state is to alert the entire vehicle; the second safety state is complete shutdown; that is, sending an alarm signal to the entire vehicle and disconnecting the high-voltage contactor to cut off the high-voltage circuit. For ASIL B level functional safety requirements, for handling high-voltage interlock open-circuit faults, there are three safety states: the first safety state is to alert the entire vehicle; the second safety state is degraded operation; and the third safety state is complete shutdown; that is, sending an alarm signal to the entire vehicle, slowly reducing the output power, and then entering complete shutdown, disconnecting the high-voltage contactor to cut off the high-voltage circuit. It should be noted that a safety state refers to the specific state specified in the safety objectives that should be entered to ensure safety after a fault is detected.

[0079] In some examples, when the number of safe states = 1, C SS =log2(2)=1; When the number of safe states is 2, C SS =log2(3)≈1.58; When the number of safe states = 3, C SS =log2(4)=2; When the number of safe states is 7, C SS =log2(8)=3 (but will be limited to 2.5); when the number of safe states = 0, C SS=log2(1)=0 (but will be limited to 0.5). If the CSS value is too small (e.g., below 0.5), it means that the number of safe states is too small (may be 0), which will make the factor value too low, resulting in insufficient test intensity. But in fact, the number of safe states is at least 1 (because entering a safe state is a basic requirement), so we set a lower limit of 0.5 to ensure that even if the number of safe states is 0 (theoretically it should not exist), there is still a basic value. If the CSS value is too large (e.g., above 2.5), it means that the number of safe states is too large (more than 7), which may lead to excessive test intensity and waste of resources. Therefore, we set an upper limit of 2.5 to avoid an unreasonable increase in test intensity due to too many safe states. Therefore, limiting the value range is to balance the test intensity and avoid insufficient or excessive testing due to too few or too many safe states. In order to avoid excessive influence, C SS The value range is limited to [0.5, 2.5].

[0080] Therefore, the formula for calculating the number of test cases N, i.e., the ASIL-test intensity quantification model formula, is: N=K*W ASIL *C SM .

[0081] Step S32: Based on the weighting factor corresponding to the ASIL level, the threshold boundary of the functional parameters is expanded to determine the expanded threshold boundary of the functional parameters.

[0082] Specifically, in order to cover scenarios such as sensor drift and extreme operating conditions, the threshold boundaries of the original functional parameters need to be expanded according to the ASIL level.

[0083] For example, the expansion factor (expandsion_factor) is calculated using the following formula: expansion factor (expandsion_factor) = 0.05 * weight factor corresponding to ASIL level. The original minimum value of the functional parameter threshold boundary is min_val; the original maximum value is max_val; and the original range width is range_size = max_val - min_val. The expanded new minimum value (new_min) = min_val - expansion_factor × range_size; the expanded new maximum value (new_max) = max_val + expansion_factor × range_size. The 0.05 in the expansion factor can also be set using other values, depending on the specific implementation requirements.

[0084] Understandably, by expanding the threshold boundaries of functional parameters, test cases can cover potential risk areas such as sensor drift, signal offset, and extreme operating conditions, thereby improving the sufficiency of testing and fault detection capabilities under high-level safety requirements.

[0085] Step S33: Based on the number of test cases and the test methods, sample from the functional parameter extended threshold boundary to determine the test dataset corresponding to each test method in the test method set.

[0086] Specifically, within the functional parameter extension threshold boundary, N test data points are extracted using Monte Carlo random sampling based on the determined number of test cases N. Monte Carlo sampling is a statistical simulation method based on random numbers, which approximates the distribution characteristics of the entire parameter space by randomly selecting sample points within a specified range according to a uniform or specific distribution. Constraints corresponding to each test method are added during the sampling process. For example, boundary value tests must include the threshold and its nearby points (e.g., 79℃, 81℃), equivalence class partitioning tests must cover representative values ​​of valid and invalid equivalence classes, and fault injection tests must match preset fault type parameters. Conditions for not extracting duplicate data can also be set to avoid redundant sampling. It should be noted that the specific implementation algorithm of Monte Carlo sampling is known in this field and will not be elaborated here.

[0087] It is understood that the embodiments of this application quantify the number of test cases by introducing a weighting factor and a security mechanism complexity factor corresponding to the ASIL level, and adaptively expand the threshold boundary of functional parameters according to the ASIL level weighting factor. Then, test cases are generated by parameter sampling, so that the number of test cases and the parameter coverage can automatically increase with the increase of security level. This effectively improves the coverage sufficiency and fault detection capability of parameter boundaries under high-level security requirements (such as ASIL C / D) while ensuring the testing efficiency of low-level requirements.

[0088] Please see Figure 3 , Figure 3 This is a flowchart illustrating another test case generation method provided in an embodiment of this application.

[0089] In some embodiments, the method further includes: determining executable instruction data corresponding to security requirements based on structured data corresponding to security requirements using a preset security dictionary technique.

[0090] It's important to understand that safety dictionary technology refers to a pre-built mapping knowledge base used to convert semantic information in structured data into instructions that the test platform can directly understand, recognize, and execute. The safety dictionary can be stored as a key-value table, configuration file, or database, and can be customized according to the target controller and test platform. Executable instruction data refers to a set of operation sequences that the test platform (e.g., ECUTest, NIVeriStand) can directly parse and execute.

[0091] The security dictionary is used to map semantic role information in structured data obtained by semantic parsing methods. The semantic role information, condition / action, corresponds to the security dictionary's write / read operation, respectively. Examples of action transformations in the security dictionary are shown in Table 6. Table 6 provides examples of action transformations mapped from the security dictionary.

[0092] Table 6: Examples of Action Conversions in Security Dictionary Mapping

[0093] The safety dictionary acts as a bridge connecting the intermediate semantic layer and the test platform instruction layer. Upon receiving structured data (containing semantic role information such as condition and action) from the semantic parsing module, it transforms the data according to preset mapping rules. For entries with the semantic role of "condition," the safety dictionary maps them to the test platform's Write operation, used to set the input parameters of the object under test or inject fault conditions. For entries with the semantic role of "action," the safety dictionary maps them to the test platform's Read operation, used to read the output signal of the object under test and compare it with the expected value for verification. For example, when the intermediate semantic layer contains the condition "single cell voltage > 4.25V," the safety dictionary maps it to a Write operation, corresponding to the test platform interface parameter Cell3Volt_mV, data type uint16, and a write value of 4300 (corresponding to 4.3V). When the intermediate semantic layer contains the action "cut off charging circuit," the safety dictionary maps it to a Read operation, reading the current value of the interface parameter BMS_RHighVolts_NU (Boolean, 0 indicates relay disconnection) to verify whether the action has been executed. Through the aforementioned mapping mechanism, the security dictionary transforms abstract requirement semantics into a sequence of read and write instructions that the test platform can recognize and execute, thereby driving the execution of automated tests. A complete one-to-one correspondence is established between intermediate semantic logic and underlying hardware interaction interface parameters, achieving standardized conversion of intermediate semantics into executable interface variables. It should be noted that intermediate semantics refers to the structured data output by the semantic parsing method.

[0094] After generating the test case set corresponding to the security requirements based on the test method set, test dataset, and security objectives, the method also includes: Based on the test case set corresponding to the security requirements and the executable instruction data corresponding to the security requirements, test result data and test documents are generated through a preset test platform.

[0095] Specifically, after generating the test case set and obtaining the executable instruction data, this embodiment further sends the test case set and executable instruction data to a preset test platform for testing. The test case set provides the input parameters for each test case, while the executable instruction data describes the specific operation steps for each test case (e.g., how to set the input channel, what fault to inject, which signal to observe, and how to determine the test result). A format converter transforms the test case set and corresponding executable instruction data into a pkg format test case sequence supported by the target platform. This sequence contains both parameter stimulus information and operation instructions and judgment rules. This pkg format test case sequence is integrated into the ECU Test (Electronic Control Unit Test Software) automated test software, while VeriStand (Real-Time Test and Simulation Software) is deployed on the NI HIL (Hardware-in-the-Loop Simulation Test System based on the National Instruments platform) bench. During test execution, ECU Test automatically calls VeriStand in NI HIL, loads and executes the pkg format test sequence, and drives the test execution according to the operation steps described in the executable instruction data, thereby completing the automated test. After all test cases have been executed, the testing platform summarizes the input parameters, expected actions, actual results, and judgment conclusions for each test case, generating test result data. Simultaneously, the system automatically generates a test document, i.e., a test report, that conforms to the ISO26262 Part 4 certification requirements based on the test result data.

[0096] Please see Figure 4 , Figure 4 This is a flowchart illustrating another test case generation method provided in an embodiment of this application.

[0097] In some embodiments, after generating test result data and test documents based on the test case set corresponding to the security requirements and the executable instruction data corresponding to the security requirements through a preset test platform, the method further includes: Based on the test results data, determine the weight score corresponding to each test case in the test case set; If the weight score is lower than the first preset threshold, the weight of the corresponding test case will be reduced by a first percentage. If the weight score is higher than or equal to the first preset threshold, the weight of the corresponding test case will be increased by a second ratio; if the second ratio is less than the first ratio. Test cases with weights less than the preset weight threshold are removed, and the same number of new test cases are generated. The steps of generating test result data and test documentation are repeated.

[0098] It should be noted that this application also includes a closed-loop optimization process for dynamically adjusting test cases based on test result data. This process is an iterative loop: after each round of testing, the test case weights are updated according to the test results, inefficient test cases are eliminated and new test cases are added, and then the next round of testing begins, until the preset stopping conditions are met (such as the defect detection rate stabilizing or the maximum number of iterations being reached).

[0099] In this embodiment, the weighted score is used to quantify the effectiveness of each test case during the testing process. A higher score indicates a greater contribution of the test case to discovering defects or verifying security mechanisms. In this embodiment, the weighted score combines two factors: defect detection rate and diagnostic coverage.

[0100] Specifically, the weighted score is calculated as follows: score = (Defect score) found / Defect total )*(Coverage actual / Coverage target ), Defect found The actual number of defects is the number of defects detected by the current test case, i.e., the number of discrepancies between the actual and expected actions in the current test. Note that the actual number of defects is the sum of the number of defects across multiple test iterations. total The total number of defects can be obtained from at least one of the following sources: discrepancies with expected behavior discovered during test execution, issues found through static analysis (such as code review and model inspection), abnormal behavior triggered during fault injection testing, and on-site fault data; Coverage actual Coverage represents the actual diagnostic coverage rate. target The target diagnostic coverage rate is described in detail above and will not be repeated here.

[0101] The first preset threshold is a pre-defined weight score threshold used to determine whether a test case needs to have its weight reduced. In this embodiment, the first preset threshold is set to 0.6.

[0102] The first percentage is the percentage by which the weight is reduced. In this embodiment, the first percentage is 40%, meaning the weight is reduced to 60% of its original value. Specifically, if the score is less than 0.6, the current weight of the test case is reduced by the first percentage (40%). That is, the new weight = current weight × 0.6.

[0103] The second ratio is the percentage increase in weight. In this embodiment, the second ratio is 10%, meaning the weight is increased to 110% of its original value, and the second ratio is less than the first ratio. Specifically, if the Score ≥ 0.6, the current weight of the test case is increased by the second ratio (10%). That is, new weight = current weight × 1.1.

[0104] The second ratio being smaller than the first ratio can accelerate the reduction of the weight score of inefficient test cases, thereby accelerating the elimination of inefficient test cases, and slowly increasing the weight score of effective test cases, thereby enabling the screening and aggregation of a large number of effective test cases.

[0105] A preset weight threshold is used to determine the lower limit of the weight for whether a test case is an inefficient test case. In this embodiment, the preset weight threshold is set to 30% of the initial weight.

[0106] Test cases with weights below a preset weight threshold (e.g., 30% of the initial weight) are marked as inefficient and removed. This reduces the total number of test cases in the test case set. To maintain adequate test coverage, the same number of new test cases need to be added. These new test cases are generated using the same method as the initial ones (i.e., through Monte Carlo random sampling) and assigned the initial weight (100%).

[0107] After adding new test cases, return to the step of generating test result data (i.e., re-execute the test) to enter the next iteration. Through repeated iterations, the weight of test cases in the test case set will gradually shift towards efficient test cases, while inefficient test cases will be eliminated, thereby continuously improving testing efficiency.

[0108] In some embodiments, after generating test result data based on the test method, the test cases corresponding to the test method, and structured data through a preset test platform, the method further includes: If no defects are detected after a test case has been executed a preset number of times, the weight of the test case will be reduced to the third percentage. If a test case detects at least two defects in a single execution, the weight of the test case is increased to the fourth proportion; the fourth proportion is greater than the third proportion. Test cases with weights less than the preset weight threshold are removed, and the same number of new test cases are generated. The steps of generating test result data and test documentation are repeated.

[0109] It should be noted that, in this embodiment, a detected defect refers to a situation where the actual result action differs from the expected result action during the execution of a test case. When a test case contains multiple expected actions, the defect count is performed on a per-action basis. For example, the expected result actions of a test case may include: sending an alarm signal, lighting the MIL light, and cutting off high voltage. If any two of the above three actions do not meet expectations in the actual execution, it is considered that two defects have been detected.

[0110] It should also be noted that in functional safety requirement design, the expected outcome typically includes at least two anticipated actions: a fault indication and the sending of an alarm signal to the vehicle. Therefore, the judgment rule for detecting at least two defects in this embodiment is mainly applicable to test case scenarios that include multiple anticipated actions. For test cases that only include a single anticipated action, the above steps are not performed.

[0111] In this embodiment, the preset number of consecutive tests refers to the threshold number of times the same test case fails to detect a defect in multiple consecutive test iterations. In this embodiment, the preset number of tests is set to 5, but in actual applications, it can be adjusted according to the project cycle and testing resources.

[0112] The third ratio refers to the percentage reduction in weight when a test case fails to detect a defect for a preset number of consecutive tests. In this embodiment, the third ratio is 40%, meaning the weight is reduced to 60% of the previous weight.

[0113] Specifically, 0 defects were detected in the first round of execution, 0 defects were detected in the second round, and 0 defects were detected in the third, fourth, and fifth rounds. At this point, the test case has been executed five times consecutively without detecting any defects. Therefore, the current weight of the test case is reduced by a third percentage (40%), i.e., the new weight = current weight × 60%. Assuming the current weight is 100%, the adjusted weight is 60%.

[0114] The fourth ratio refers to the percentage increase in weight when a test case detects at least two defects in a single execution. In this embodiment, the fourth ratio is 50%, meaning the weight is increased to 150% of the previous weight, and the fourth ratio is greater than the third ratio.

[0115] Similarly, the fourth ratio is greater than the third ratio, which accelerates the increase in the weight score of efficient test cases and accelerates the decrease in the weight score of inefficient test cases. This helps to quickly filter and aggregate efficient test cases and eliminate inefficient test cases in subsequent judgments.

[0116] Specifically, if two defects are detected simultaneously in a single execution, the current weight of that test case will be increased by a fourth percentage (50%), i.e., the new weight = current weight × 150%. If the current weight is 100%, the adjusted weight will be 150%.

[0117] Similarly, after the above adjustments, test cases with weights below a preset weight threshold (e.g., 30% of the initial weight) are marked as inefficient and removed. After removal, the total number of test cases decreases. To maintain adequate test coverage, the system uses the same method as the initial generation (i.e., Monte Carlo random sampling) to supplement the test cases with the same number of new ones. The initial weight of the new test cases is set to 100%.

[0118] After adding new test cases, the system returns to the step of generating test result data (i.e., re-executing the test) and enters the next iteration. Through repeated iterations, inefficient test cases that are continuously defect-free can be gradually eliminated, while efficient test cases that can detect multiple defects in a single test are strengthened, thereby continuously improving defect detection efficiency with limited testing resources.

[0119] In some embodiments, after determining the weight score corresponding to each test case in the test case set based on the test result data, and adjusting the weight of the test cases based on the weight scores, the following steps are performed: if no defects are detected after a test case is executed for a preset number of consecutive times, the weight of the test case is reduced by a third proportion; if at least two defects are detected in a single execution of the test case, the weight of the test case is increased by a fourth proportion; if the fourth proportion is greater than the third proportion; test cases with weights less than a preset weight threshold are removed, and the same number of new test cases are generated to supplement them, and the steps of generating test result data and test documents are repeated. It should be noted that the implementation of the method in this embodiment relies on the following hardware environment and software foundation. Hardware-wise, it includes a GPU accelerator for running natural language processing models and a graph database server for storing ISO26262 knowledge graphs. Software-wise, it includes a security requirements library consisting of ISO26262:2018 Parts 1 to 12, and algorithm libraries such as PyTorch (for NLP models), Neo4j (for knowledge graph management), and SciPy (for Monte Carlo sampling). Those skilled in the art will understand that the above hardware and software configurations are merely examples, and other alternative solutions that can achieve the same function may also be adopted.

[0120] Furthermore, the Monte Carlo random sampling method used in this embodiment can be replaced by reinforcement learning methods. For example, optimizing the parameter combination through the Q-learning algorithm can also achieve dynamic optimization of the test dataset. Similarly, the BERT-NLP model used for semantic parsing in this embodiment can be replaced by knowledge graph technology. For example, by constructing a demand-standard association graph, it is also possible to complete the identification of ASIL levels and the extraction of structured data. The above-mentioned alternatives are all reasonable variations of the technical concept of this application and fall within the protection scope of this application.

[0121] Through the aforementioned intelligent collaborative architecture and ASIL quantification model, this embodiment achieves fully automated generation and dynamic optimization of automotive functional safety test cases, which can meet the certification requirements of the highest safety level ASILD of ISO26262.

[0122] In summary, compared to traditional solutions that rely on fixed test templates, manual review of the ISO 26262 standard, and manual boundary value design, this application establishes an ASIL-test intensity quantification model. It dynamically adjusts the number of test cases using ASIL weighting factors and incorporates security mechanism complexity factors for correction, ensuring a strict match between test intensity and security level. For high-level requirements such as ASIL C / D, fault injection coverage is significantly improved, and ASIL D requirement coverage can reach over 99%, contributing to ISO 26262 certification. Furthermore, this application implements closed-loop dynamic optimization based on test results. By calculating weight scores and automatically adjusting test case weights according to test execution history, it can quickly eliminate inefficient test cases and strengthen efficient ones, thereby significantly reducing invalid tests, saving test resources, and shortening the project development cycle by approximately 40%. In addition, this application uses knowledge graphs to automatically match test methods in the ISO 26262 standard, replacing the manual standard review process and increasing test case generation efficiency by tens of times. It also uses the Monte Carlo algorithm to automatically generate parameter combinations within an expanded parameter range, replacing manual boundary value design and significantly improving requirement coverage and the ability to detect extreme conditions. In summary, this application achieves fully automated generation and optimization of automotive functional safety test cases through intelligent collaborative architecture and ASIL quantitative model, which can meet the certification requirements of the highest safety level ASILD of ISO26262.

[0123] This application also provides a test case generation system, the system comprising: The first module, based on the functional safety requirements document, uses semantic parsing to determine the structured data corresponding to the safety requirements; the structured data includes ASIL level, functional parameter threshold boundaries, and safety objectives. The second module is used to determine the test method set corresponding to security requirements based on ASIL level and preset rules; The third module determines the test dataset corresponding to the security requirements based on ASIL level and functional parameter threshold boundaries. The fourth module generates a set of test cases corresponding to the security requirements, based on the test method set, test dataset, and security objectives.

[0124] It should be noted that the specific process of each module in the above test case generation system has been described in detail in the aforementioned method embodiments, and will not be repeated here.

[0125] The modules described above can be integrated into the same computing device or distributed across different servers; this embodiment does not impose any limitations on this. This system can automatically complete the process from requirements documents to test case sets, reducing manual intervention and improving the efficiency of test case generation. In the above embodiments, the descriptions of each embodiment have their own emphasis; parts not described in detail in a particular embodiment can be referred to in the relevant descriptions of other embodiments.

[0126] The above are merely preferred embodiments of this application and are not intended to limit this application in any way. Although this application has disclosed preferred embodiments as above, it is not intended to limit this application. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the technical solution of this application. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of this application without departing from the scope of the technical solution of this application shall still fall within the scope of the technical solution of this application.

Claims

1. A test case generation method, characterized in that, include: Based on the functional safety requirements document, the structured data corresponding to the safety requirements is determined through semantic parsing methods; The structured data includes ASIL level, functional parameter threshold boundaries, and security objectives; Based on the ASIL level and preset rules, determine the test method set corresponding to the security requirements; Based on the ASIL level and the functional parameter threshold boundaries, determine the test dataset corresponding to each test method in the test method set; Based on the test method set, the test dataset, and the security objective, a test case set corresponding to the security requirements is generated.

2. The test case generation method according to claim 1, characterized in that, The structured data corresponding to the safety requirements, determined from the functional safety requirements document using semantic parsing methods, includes: Based on the functional safety requirements document, the structured data corresponding to the safety requirements is determined by using a preset natural language processing model.

3. The test case generation method according to claim 1, characterized in that, The step of determining the test method set corresponding to the security requirement based on the ASIL level and preset rules includes: Based on the ASIL level and preset rules, the set of test methods corresponding to the security requirements is determined through a preset knowledge graph.

4. The test case generation method according to claim 1, characterized in that, The determination of the test dataset corresponding to each test method in the test method set based on the ASIL level and the functional parameter threshold boundary includes: The number of test cases is determined based on a preset base number of test cases, combined with the weighting factor corresponding to the ASIL level and the security mechanism complexity factor. Based on the weighting factor corresponding to the ASIL level, the threshold boundary of the functional parameter is expanded to determine the expanded threshold boundary of the functional parameter. Based on the number of test cases and the test methods, sampling is performed from the functional parameter extended threshold boundary to determine the test dataset corresponding to each test method in the test method set.

5. The test case generation method according to claim 4, characterized in that, The weighting factor corresponding to the ASIL level is positively correlated with the ASIL level, and the weighting factor corresponding to the ASIL level D is at least 3 times the weighting factor corresponding to the ASIL level A.

6. The test case generation method according to claim 4, characterized in that, The security mechanism complexity factor is determined by a weighted sum of the diagnostic coverage factor, the fault tolerance mechanism complexity factor, and the security state complexity factor; wherein, the diagnostic coverage factor is determined based on the actual diagnostic coverage and the target diagnostic coverage; the fault tolerance mechanism complexity factor is determined based on the number of redundant components; and the security state complexity factor is determined based on the number of security states.

7. The test case generation method according to claim 1, characterized in that, The method further includes: Based on the structured data corresponding to the security requirements, the executable instruction data corresponding to the security requirements is determined by using a preset security dictionary technology. Based on the test case set corresponding to the security requirements and the executable instruction data corresponding to the security requirements, test result data and test documents are generated through a preset test platform.

8. The test case generation method according to claim 7, characterized in that, After generating the test result data and test documents, the method further includes: Based on the test result data, determine the weight score corresponding to each test case in the test case set; If the weight score is less than a first preset threshold, the weight of the corresponding test case will be reduced by a first percentage. If the weight score is greater than or equal to a first preset threshold, the weight of the corresponding test case will be increased by a second ratio; the second ratio is less than the first ratio. The test cases with weights less than the preset weight threshold are removed, and the same number of new test cases are generated. The steps of generating test result data and test documents are repeated.

9. The test case generation method according to claim 7, characterized in that, After generating the test result data and test documents, the method further includes: If no defect is detected after the test case has been executed a preset number of times, the weight of the test case will be reduced by a third percentage. If a test case detects at least two defects in a single execution, the weight of the test case is increased by a fourth ratio; the fourth ratio is greater than the third ratio. The test cases with weights less than the preset weight threshold are removed, and the same number of new test cases are generated. The steps of generating test result data and test documents are repeated.

10. A test case generation system, characterized in that, include: The first module is used to determine the structured data corresponding to the safety requirements based on the functional safety requirements document through semantic parsing methods. The structured data includes ASIL level, functional parameter threshold boundaries, and security objectives; The second module is used to determine the test method set corresponding to the security requirements based on the ASIL level and preset rules. The third module is used to determine the test dataset corresponding to the security requirements based on the ASIL level and the functional parameter threshold boundaries. The fourth module is used to generate a set of test cases corresponding to the security requirements based on the test method set, the test dataset, and the security objectives.

Images