Fault scene screening method and system, electronic equipment and medium

Abstract

The embodiment of the invention provides a fault scene screening method and system, electronic equipment and a medium, and the method comprises the steps: obtaining a fault scene screening parameter and a fault scene candidate set; performing constraint expression construction based on a preset constraint configuration grammar and the fault scene screening parameters to determine a first constraint expression corresponding to the fault scene screening parameters; and performing constraint solution according to the fault scene candidate set and the first constraint expression to determine a target fault scene matched with the fault scene screening parameter. Therefore, according to the embodiment of the invention, the automatic generation of the constraint expression and the standardized configuration rule are realized through the preset constraint configuration grammar, so that the constraint expression can be directly generated through the standardized configuration rule and the fault scene screening parameter, and a code development link is not needed; and the screening efficiency of the fault scene is effectively improved.

Description

Technical Field

[0001] This application relates to the field of fault injection testing technology, and in particular to a fault scenario screening method, system, electronic device and medium. Background Technology

[0002] In fault injection testing scenarios, to quickly filter the required target fault scenarios from the fault scenario library, the current approach primarily relies on building management constraints set by the test requirements to achieve rapid filtering and improve efficiency. While this method can replace manual fault scenario filtering, it still requires manual constraint development to handle frequently changing test requirements, thus maintaining low efficiency in fault scenario filtering. Summary of the Invention

[0003] To address the aforementioned issues and improve the efficiency of fault scenario screening in fault injection testing, this application provides a fault scenario screening method, system, electronic device, and medium.

[0004] The embodiments of this application disclose the following technical solutions:

[0005] In a first aspect, embodiments of this application provide a fault scenario screening method, including:

[0006] Obtain the fault scenario filtering parameters and the fault scenario candidate set;

[0007] Constraint expressions are constructed based on preset constraint configuration grammar and the fault scenario screening parameters to determine the first constraint expression corresponding to the fault scenario screening parameters.

[0008] Constraints are solved based on the candidate set of fault scenarios and the first constraint expression to determine the target fault scenario that matches the fault scenario screening parameters.

[0009] In one possible implementation, the step of constructing constraint expressions based on a preset constraint configuration grammar and the fault scenario screening parameters to determine a first constraint expression corresponding to the fault scenario screening parameters includes:

[0010] Based on the preset constraint configuration grammar and the fault scenario filtering parameters, construct multiple second constraint expressions;

[0011] An abstract syntax tree is constructed based on multiple second constraint expressions and a recursive descent algorithm.

[0012] Based on the abstract syntax tree, multiple second constraint expressions are normalized and optimized to obtain multiple third constraint expressions;

[0013] Multiple third constraint expressions are merged to obtain the first constraint expression.

[0014] In one possible implementation, the process of merging multiple third constraint expressions to obtain the first constraint expression includes:

[0015] At least two fourth constraint expressions are determined from a plurality of the third constraint expressions; the fourth constraint expressions have the same feature fields.

[0016] Based on the feature value ranges in each of the fourth constraint expressions, logical conflict detection is performed on all the fourth constraint expressions.

[0017] If the logical conflict detection passes, multiple fourth constraint expressions are merged into a fifth constraint expression, and the third constraint expression after removing the fourth constraint expression and the fifth constraint expression are used to determine the first constraint expression.

[0018] If the logic conflict detection fails, a logic conflict alarm signal is generated; the logic conflict alarm signal is used to indicate a logic error in the fault scenario screening.

[0019] In one possible implementation, the first constraint expression includes multiple first constraint conditions, and the fault scenario candidate set includes multiple fault scenarios;

[0020] The step of solving constraints based on the candidate set of fault scenarios and the first constraint expression to determine the target fault scenario matching the fault scenario screening parameters includes:

[0021] Traverse the first constraint expression and the candidate set of fault scenarios to establish a bidirectional mapping relationship between each fault scenario and each of the first constraint conditions;

[0022] The target fault scenario is determined based on the bidirectional mapping relationship between each fault scenario and each of the first constraints.

[0023] In one possible implementation, the bidirectional mapping relationship includes: a list of fault scenarios individually associated with each of the first constraints, and a list of constraints individually associated with each of the fault scenarios; the list of fault scenarios is used to characterize fault scenarios that match the first constraints; the list of constraints is used to characterize first constraints that match the fault scenarios.

[0024] Determining the target fault scenario based on the bidirectional mapping relationship between each fault scenario and each first constraint includes:

[0025] Recursively traverse each of the first constraints to determine whether there is a fault scenario that satisfies the first constraint.

[0026] If there is a fault scenario that satisfies any of the first constraints, then the list of constraints associated with the fault scenario and the list of fault scenarios in which it is located are updated by using a preset constraint propagation algorithm.

[0027] When all the constraints in the list associated with the fault scenario are met, the fault scenario is determined as the target fault scenario.

[0028] If any of the fault scenarios does not satisfy the associated list of constraints, then the preset constraint propagation algorithm is used to update the multiple lists of fault scenarios and the multiple lists of constraints.

[0029] In one possible implementation, before constructing the constraint expression based on the preset constraint configuration grammar and the fault scenario screening parameters to determine the first constraint expression corresponding to the fault scenario screening parameters, the method further includes:

[0030] The fault scenario screening parameters are standardized according to a preset configuration template to obtain standardized data.

[0031] The preset configuration template includes a data format template and a data item template. The data format template is used to define the parsing method of the standardized data, and the data item template is used to define the position of the target fault scenario in the returned data.

[0032] Secondly, embodiments of this application provide a fault scenario screening system, including:

[0033] The acquisition module is used to acquire fault scenario filtering parameters and a fault scenario candidate set.

[0034] The constraint expression construction module is used to construct constraint expressions based on a preset constraint configuration grammar and the fault scenario screening parameters, so as to determine the first constraint expression corresponding to the fault scenario screening parameters.

[0035] The constraint solving module is used to solve constraints based on the candidate set of fault scenarios and the first constraint expression to determine the target fault scenario that matches the fault scenario screening parameters.

[0036] In one possible implementation, the constraint expression construction module is specifically used for:

[0037] Based on the preset constraint configuration grammar and the fault scenario filtering parameters, construct multiple second constraint expressions;

[0038] An abstract syntax tree is constructed based on multiple second constraint expressions and a recursive descent algorithm.

[0039] Based on the abstract syntax tree, multiple second constraint expressions are subjected to normative verification to obtain multiple third constraint expressions;

[0040] Multiple third constraint expressions are merged to obtain the first constraint expression.

[0041] Thirdly, embodiments of this application provide an electronic device, the device including: a processor, a memory, and a system bus;

[0042] The processor and the memory are connected via the system bus;

[0043] The memory is used to store one or more programs, the one or more programs including instructions that, when executed by the processor, cause the processor to perform any of the possible fault scenario screening methods in the first aspect.

[0044] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any possible fault scenario screening method in the first aspect.

[0045] Compared to existing technologies, this application offers the following advantages: This application provides a fault scenario screening method, system, electronic device, and medium. The method involves obtaining fault scenario screening parameters and a fault scenario candidate set; constructing constraint expressions based on a preset constraint configuration grammar and the fault scenario screening parameters to determine a first constraint expression corresponding to the fault scenario screening parameters; and solving constraints based on the fault scenario candidate set and the first constraint expression to determine a target fault scenario matching the fault scenario screening parameters. Thus, this application achieves automated generation of constraint expressions through a preset constraint configuration grammar. By defining standardized configuration rules, constraint expressions can be directly generated using standardized configuration rules and fault scenario screening parameters, eliminating the need for code development. Similarly, when the requirements for fault injection testing fluctuate frequently, only the corresponding screening parameters or the preset constraint configuration grammar need to be modified, eliminating the need to repeatedly execute the constraint development and code modification process, effectively improving the efficiency of fault scenario screening. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 A flowchart illustrating a fault scenario screening method provided in an embodiment of this application;

[0048] Figure 2 A flowchart illustrating a method for generating a first constraint expression provided in an embodiment of this application;

[0049] Figure 3 A flowchart illustrating the merging process based on multiple third constraint expressions is provided for embodiments of this application.

[0050] Figure 4 A flowchart illustrating another fault scenario screening method provided in this application embodiment;

[0051] Figure 5 A flowchart illustrating another fault scenario screening method provided in this application embodiment;

[0052] Figure 6 This is a schematic diagram of the structure of a fault scenario screening system provided in an embodiment of this application;

[0053] Figure 7 This is a schematic diagram of the structure of an electronic device for screening fault scenarios provided in an embodiment of this application. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and accompanying drawings. It should be particularly noted that the embodiments described in this application 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 scope of protection of this application.

[0055] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0056] As described earlier, in fault injection testing scenarios, to quickly filter the required target fault scenarios from the fault scenario library, the current approach primarily relies on building management constraints set by the test requirements to achieve rapid filtering, thereby improving the efficiency of fault scenario filtering. While this method can replace manual screening of fault scenarios, when test requirements change frequently, it still requires manually developing constraints to cope with these changes, and the problem of low efficiency in fault scenario filtering persists.

[0057] Based on this, embodiments of this application provide a fault scenario screening method, system, electronic device, and medium. The method provided in this application involves obtaining fault scenario screening parameters and a fault scenario candidate set; constructing constraint expressions based on a preset constraint configuration grammar and the fault scenario screening parameters to determine a first constraint expression corresponding to the fault scenario screening parameters; and solving constraints based on the fault scenario candidate set and the first constraint expression to determine a target fault scenario matching the fault scenario screening parameters. Thus, embodiments of this application achieve automated generation of constraint expressions through a preset constraint configuration grammar. By defining standardized configuration rules, constraint expressions can be directly generated using standardized configuration rules and fault scenario screening parameters, without requiring code development. Similarly, when the requirements for fault injection testing fluctuate frequently, only the corresponding screening parameters or modifications to the preset constraint configuration grammar need to be made, eliminating the need to repeatedly execute the constraint development and code modification process, effectively improving the efficiency of fault scenario screening.

[0058] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0059] See Figure 1 The figure is a flowchart illustrating a fault scenario screening method provided in an embodiment of this application, which specifically includes the following steps:

[0060] S101: Obtain the fault scenario filtering parameters and the fault scenario candidate set.

[0061] The fault scenario screening method provided in this embodiment is applied to a platform for conducting fault injection testing. This platform includes a system library, a scenario library, and a case library. The system library stores various system modules that need to be tested, while the scenario library stores multiple fault scenarios (i.e., a candidate set of fault scenarios). Each fault scenario includes multiple attribute fields such as business steady-state assumptions, resource steady-state assumptions, fault type, fault phenomenon classification, fault impact level, and implementation priority. The case library stores historical cases of fault injection testing. Each case includes the fault scenario used in the fault injection test, the system module, and the test results. This library stores specific information related to each fault injection test project, essentially acting as a "test report," allowing business personnel to query historical fault injection test information.

[0062] The acquisition of fault scenario screening parameters mainly relies on the configurable input of management requirements and the standardized parsing mechanism of the system. In specific implementation, the system or platform used in this method can provide a visual configuration interface for business personnel to flexibly input screening parameters according to their fault injection testing requirements, such as module security level, fault impact scope, and experimental environment limitations. These parameters are presented in the form of "feature dimension + constraint conditions". For example, for the "fault impact level" dimension, the number of fault scenarios with an impact level of "high" in the same batch of experiments can be configured to not exceed two.

[0063] S102: Construct constraint expressions based on preset constraint configuration grammar and the fault scenario screening parameters to determine the first constraint expression corresponding to the fault scenario screening parameters.

[0064] To avoid repeatedly executing the constraint development process when business requirements change frequently, this application embodiment sets up a preset constraint configuration grammar for defining constraint expression generation logic and constraint expression format.

[0065] In this embodiment, the "preset constraint configuration grammar" is a set of formal language rules specifically designed for fault scenario screening. Its core function is to transform business-level management requirements into constraint expressions that the system can recognize, ensuring the accuracy and parsability of the requirement description through clear grammatical specifications. An example of the preset constraint configuration grammar is shown below:

[0066] <rule> ::= <expression> <expression>::= 'count(' <field> '=' <value> ')' <comparator> <number> <field> ::= <letter> { <letter> | <digit> | '_'} <value> ::= <character> <comparator> ::= '>' | '<' | '>=' | '<=' | '=' <number> ::= <digit> { <digit>} <letter>::= 'a'..'z' | 'A'..'Z' <digit> ::= '0'..'9' <character> ::= <letter> | <digit> | <special> <special> ::= '_' | '-' | '.' | ' ' | ':' | ' / ' | '@' | '&' | '%' | '#' | '(' | ')' < / special> < / special> < / digit> < / letter> < / character> < / digit> < / letter> < / digit> < / digit> < / number> < / comparator> < / character> < / value> < / digit> < / letter> < / letter> < / field> < / number> < / comparator> < / value> < / field> < / expression> < / expression> < / rule>

[0067] In the above example, <rule>A constraint rule is defined, and the rule is a constraint expression. <expression>The expression is defined as count(Field=Value) Comparator Number. count() is used to calculate the number of fault scenarios that meet the conditions. <field>The field name can be a combination of letters, numbers, or underscores. <value>For field values, the numerical value within single quotes represents the specific value of the feature. <comparator>This is a comparison operator used to compare quantities with specified numerical values. <number>The value being compared represents N or M in the choice between N to 1 or N to M. <letter>For letters, including uppercase and lowercase. <digit>The numbers are 0 to 9. <character>Can be letters, numbers, or special characters. <special>Special characters include underscores, hyphens, dots, spaces, colons, forward slashes, at symbols, ampersands, percent signs, hash symbols, parentheses, etc.

[0068] Therefore, the preset constraint configuration adopts a mathematical expression-like structure, defining the standard format of constraint rules as "count(feature field = feature value) comparison operator value". The "count()" function is used to count the number of fault scenarios that meet specific feature conditions. The feature field corresponds to the attributes of the fault scenario (such as fault type, implementation priority, impact level, etc.), the feature value is the specific value of the field (such as network interruption, high, 8), and the value is used to limit the quantity condition (such as "1" in N-choose-1 or "M" in N-choose-M). This structural design not only aligns with the intuitive understanding of "quantity constraints" by business personnel but also facilitates the system's rapid extraction of key elements through syntax parsing.

[0069] For example, the expression "count(implementation priority>=8) >= 3" clearly expresses the requirement of "filtering out failure scenarios with an implementation priority of not less than 8 and a number of not less than 3". Each component strictly follows the character rules defined by the grammar (such as field names can only contain letters, numbers and underscores, and values ​​can contain specific special characters such as "-" and "_"), avoiding the ambiguity of natural language description and providing a clear logical basis for subsequent constraint solving.

[0070] Meanwhile, this preset constraint configuration grammar is scalable, adapting to dynamic changes in testing requirements and ensuring the validity of expressions. In terms of scalability, the grammar uses a fixed paradigm definition, allowing for the support of new constraint types or feature dimensions through extended syntax rules. For example, when adding "fault recovery time" as a filtering dimension, only the valid identifier (e.g., fault recovery time) and its data type (e.g., time format constraint) of the field need to be added to the field definition section of the grammar. There is no need to modify the parsing logic of the "count()" function; the system can automatically recognize the field and incorporate it into the subsequent constraint validation process. This design allows the grammar to flexibly adapt to frequent changes in testing requirements—whether adding new fault features (e.g., the number of associated microservices, data consistency level), expanding comparison operators, or introducing composite constraint functions, all can be achieved by updating this preset constraint configuration grammar, thereby adapting to frequently fluctuating testing requirements and improving the efficiency of constraint expression generation.

[0071] Next, this application will describe, with reference to the accompanying drawings of specific embodiments, the process of constructing constraint expressions based on preset constraint configuration grammar and the fault scenario screening parameters in step S102, and then generating the first constraint expression. See also Figure 2 The figure is a flowchart illustrating a method for generating a first constraint expression according to an embodiment of this application, specifically including the following steps:

[0072] S1021: Construct multiple second constraint expressions based on the preset constraint configuration grammar and the fault scenario filtering parameters.

[0073] The process of constructing second constraint expressions based on preset constraint configuration grammar and fault scenario filtering parameters essentially transforms diverse fault scenario filtering requirements into a set of formal rules that the system can process. The preset constraint configuration grammar acts like a standardized language specification, defining how fields in expressions should be named (e.g., fault type, implementation priority), value formats (e.g., character-based high-availability faults, numeric 8), function structures (e.g., "count(feature field = feature value)"), and operator types (e.g., ">=" and "<="), ensuring that each expression is parseable at the grammatical level. When multiple fault filtering parameters are obtained, the system parses each parameter one by one and transforms them into corresponding formal expressions according to the grammar rules, thus forming multiple independent second constraint expressions. These expressions are not simply string concatenations but strictly adhere to the grammar definition. For example, field names must consist of letters, numbers, or underscores; character values ​​must be enclosed in single quotes; and comparison operators and values ​​must maintain logical matching. This ensures that each expression conforms to basic grammatical rules during the generation stage, laying the foundation for subsequent processing.

[0074] S1022: Construct an abstract syntax tree based on multiple second constraint expressions and a recursive descent algorithm.

[0075] After generating multiple second constraint expressions, the system uses a recursive descent algorithm to parse these expressions line by line, constructing an Abstract Syntax Tree (AST) to achieve a deep decomposition of the structures of multiple second constraint expressions. As a top-down parsing method, the recursive descent algorithm matches lexical units in the expression layer by layer according to grammatical rules—first identifying the keyword "count," then parsing the combination of feature fields and values ​​within parentheses, then processing comparison operators and numerical parts, and recursively calling sub-parsing functions when encountering nested structures. Finally, it transforms the linear expression string into a tree structure, where each node represents a grammatical unit (such as a function node, field node, or operator node).

[0076] The process of building an abstract syntax tree is not only a structural decomposition, but also a process of simultaneous preliminary syntax verification. The recursive descent algorithm checks whether the parentheses match (such as preventing errors such as unclosed parentheses like "count(impact level='high'")), whether there are illegal characters in the field (such as illegal connectors in "fault type-network"), and whether the operators are compatible with the field type (such as logical errors in using the ">" operator on character fields), thus capturing obvious syntax defects in advance.

[0077] S1023: Based on the abstract syntax tree, perform normalization optimization on multiple second constraint expressions to obtain multiple third constraint expressions.

[0078] When performing normalization optimization on the second constraint expression based on the abstract syntax tree, a deep check is required from three dimensions: lexical, syntactic, and semantic, ultimately resulting in a normalized third constraint expression. At the lexical level, the validation module scans the character composition of all nodes, checking for illegal characters in field names and format errors in value definitions (such as numeric values ​​containing letters). At the syntactic level, the expression is validated against grammatical rules based on the syntax tree structure; for example, it ensures that the "count" function is immediately followed by a valid feature condition, and that both sides of the comparison operator are of the correct data types. At the semantic level, the focus is on logical rationality checks, such as whether multiple constraints on the same field contradict each other (e.g., simultaneously requiring "count(influence level='high') ≤ 2" and "count(influence level='high') ≥ 3"). During the optimization process, any expression that does not conform to grammatical rules or has logical contradictions is marked and prompted for correction, while expressions that pass validation are normalized. This process not only ensures the syntactic correctness of the constraint rules, but also avoids logical loopholes through semantic verification. This ensures that each third constraint expression can be efficiently parsed and executed by the system, and accurately reflects the true intent of the business requirements, providing reliable input conditions for subsequent fault scenario screening and constraint solving.

[0079] S1024: Merge multiple third constraint expressions to obtain the first constraint expression.

[0080] The merging of multiple third constraint expressions essentially involves integrating scattered constraint rules that may target the same feature dimension to form a simpler and conflict-free filtering logic. See also Figure 3 The figure is a schematic diagram of a process for merging multiple third constraint expressions provided in an embodiment of this application, specifically including the following steps:

[0081] S1025: Determine at least two fourth constraint expressions from the plurality of the third constraint expressions; the fourth constraint expressions have the same feature fields.

[0082] After completing the normative verification, the system first iterates through all third constraint expressions and groups them according to feature fields—for example, all expressions involving the same field such as "fault type" are categorized separately, and at least two expressions with the same feature field are selected as fourth constraint expressions. This classification process is not a simple field matching, but is based on the feature dimensions defined by the grammar (such as the unique identifier of field names) to ensure that different expressions do indeed target the same business attribute. For example, if there are two expressions, "count(implementation priority>=8)>=3" and "count(implementation priority<=10)<=5", both of which have the feature field "implementation priority", they will be identified as fourth constraint expressions, while expressions involving different fields are temporarily kept in the unprocessed set.

[0083] S1026: Based on the feature value ranges in each of the fourth constraint expressions, perform logical conflict detection on all the fourth constraint expressions.

[0084] After determining the fourth constraint expression, the system performs logical conflict detection based on the feature value ranges in each expression. Here, "feature value range" includes both explicit numerical ranges (e.g., ">=8" and "<=10") and enumerated values ​​or character-type matching conditions (e.g., fault type = network interruption and fault type = disk failure can be considered mutually exclusive discrete values). The detection logic performs compatibility analysis on multiple constraints under the same feature field one by one. For numerical fields, if the value ranges of two expressions intersect (e.g., ">=5" and "<=10" can be merged into "5<=x<=10"), they are considered potentially mergeable conditions; if the ranges are completely mutually exclusive (e.g., ">=8" and "<=6"), they are determined to be logically conflicting.

[0085] S1027: If the logical conflict detection passes, the multiple fourth constraint expressions are merged into a fifth constraint expression, and the third constraint expression after removing the fourth constraint expression and the fifth constraint expression are used to determine the first constraint expression;

[0086] S1028: If the logic conflict detection fails, a logic conflict alarm signal is generated; the logic conflict alarm signal is used to indicate a logic error in the fault scenario screening.

[0087] If the conflict detection passes, multiple fourth constraint expressions need to be merged into a single fifth constraint expression. The merging rule follows the principle of "preserving valid intervals and simplifying logic": for numerical intervals, discrete ranges are merged into continuous or joint intervals (e.g., ">=8" and "<=10" are merged into "8<=x<=10"). After merging, the system removes the processed fourth constraint expressions from the original set of third constraint expressions and replaces them with the newly generated fifth constraint expressions, ultimately forming the integrated set of first constraint expressions.

[0088] Correspondingly, if the conflict detection fails (e.g., mutually exclusive intervals or contradictory conditions are found), a logical conflict alarm signal will be generated immediately. This signal will be fed back to the testers in the form of visual prompts or log records, clearly indicating the specific field, value, and constraint expression location of the conflict (e.g., "There is a conflict in the implementation priority field: constraint 1 requires >= 8, constraint 2 requires <= 6"), helping business personnel to quickly locate and correct filtering logic errors.

[0089] Specifically, in one possible implementation, before executing step S102, to ensure the standardization of the data format of the fault scenario screening parameters, the fault scenario screening parameters can be standardized according to a preset configuration template to obtain standardized data. The preset configuration template includes a data format template and a data item template. The data format template defines the parsing method for the standardized data, while the data item template defines the position of the target fault scenario in the returned data.

[0090] The core of this step is to transform raw parameters from different business systems, which may have different formats or chaotic structures, into standardized data that meets the system's parsing requirements by using a preset configuration template, thereby avoiding parsing errors or logical deviations caused by inconsistent data formats.

[0091] Taking JSON as the target format as an example, the corresponding preset configuration template is shown in Table 1 below:

[0092] Table 1

[0093]

[0094] The above is an introduction to the generation method of the "first constraint expression" in the embodiments of this application. Next, we will continue to combine... Figure 1 The fault scenario screening method provided in the embodiments of this application will be introduced.

[0095] S103: Solve the constraints based on the candidate set of fault scenarios and the first constraint expression to determine the target fault scenario that matches the fault scenario screening parameters.

[0096] In the application scenario of this application embodiment, the constraint solving process is completed by a pre-built constraint solver. The fault scenario candidate set and the first constraint expression serve as the input data of the constraint solver, which then selects fault scenarios that match the first constraint expression from the fault scenario candidate set. Next, with reference to the accompanying drawings of a specific embodiment, the process of performing constraint solving based on the fault scenario candidate set and the first constraint expression in step S103 to determine the target fault scenario will be described.

[0097] See Figure 4 The figure is a flowchart illustrating another fault scenario screening method provided in an embodiment of this application, which specifically includes the following steps:

[0098] S1031: Traverse the first constraint expression and the candidate set of fault scenarios to establish a bidirectional mapping relationship between each fault scenario and each of the first constraint conditions.

[0099] In the process of selecting target fault scenarios from the fault scenario candidate set according to the first constraint expression, the constraint solver first needs to set the seed of the random number generator and randomly sort the multiple fault scenarios contained in the fault scenario candidate set to ensure the diversity of subsequent results.

[0100] In the core process of constraint solving, establishing a bidirectional mapping relationship between fault scenarios and the first constraint condition is a key step in achieving accurate screening. This bidirectional mapping is not simply a record of matching conditions, but rather a dynamically corresponding dual-index structure established through systematic traversal and association between constraints and fault scenarios. Specifically, it includes two complementary mapping dimensions: a unidirectional list mapping from the first constraint condition to fault scenarios, where each first constraint condition has an associated list of fault scenarios that store the fault scenarios matching the first constraint condition; and a reverse list mapping from fault scenarios to first constraints, where each fault scenario has a separate associated list of constraints that store the constraints matching the fault scenario. The former addresses the question of "which scenarios correspond to each constraint condition," while the latter addresses the question of "which constraints each scenario meets." Together, they form the underlying framework for data interaction during the screening process.

[0101] The mapping from constraints to failure scenarios (i.e., the failure scenario list) essentially involves creating a dedicated candidate set for each constraint. When iterating through each first constraint in the first constraint expression, the core elements of each constraint are parsed out—for example, the condition "failure type = network interruption" has core elements including the field name "failure type", the operator "=", and the target value "network interruption". Subsequently, for each failure scenario in the candidate set, the actual values ​​of the corresponding fields need to be extracted (e.g., failure type "disk failure" for scenario A, and "network interruption" for scenario B). The unique identifiers (e.g., ID, index) of the scenarios that meet the condition are added to the dedicated list for that constraint. The advantage of this mapping is that when a constraint needs to be validated later, it is not necessary to repeatedly scan the entire dataset; simply retrieving this list can quickly obtain all scenarios that initially meet the condition, significantly reducing computational overhead.

[0102] The mapping from failure scenarios to constraints (i.e., the constraint list) involves creating a "condition file" for each scenario. When a failure scenario is generated, it iterates through all first constraint expressions, recording each condition it meets. For example, if scenario C has a high failure impact level and an implementation priority of 9, it will be recorded in the failure scenario list for the constraints "failure impact level = high" and "implementation priority >= 8," and its own constraint list will also include these two rules. The core value of this reverse mapping is that when verifying whether a scenario meets all constraints, it is not necessary to iterate through all rules; only its own constraint list needs to be checked to see if all effective constraints are included. This "scenario-condition" reverse index is particularly efficient when handling joint checks of multiple constraints: for example, when filtering scenarios that simultaneously meet three constraints, the system only needs to perform a completeness check on the constraint list of each scenario, rather than repeatedly checking the entire scenario for each constraint, avoiding the inefficient computational complexity of O(n*m) (where n is the number of scenarios and m is the number of constraints).

[0103] The advantages of this bidirectional mapping relationship are mainly in the following two aspects: First, it enables efficient single-condition filtering. By using a list of constraints to scenarios, the candidate range is quickly narrowed down, eliminating scenarios that clearly do not meet a single condition. Second, it provides accurate multi-condition joint verification. By using a list of scenarios to constraints, it ensures that each fault scenario satisfies all associated rules, avoiding filtering errors caused by missing conditions. For example, when filtering fault scenarios that are "high impact level and high priority, with no more than 5 similar scenarios," the list of fault impact level = high will first filter out all high impact scenarios, and the list of implementation priority >= 8 will further filter out the high priority scenarios within it. The constraint list of each retained scenario will ensure that it belongs to both lists simultaneously. Finally, by counting the length of the list of "high impact and high priority scenarios," it can be verified whether the quantity constraint is met. This bidirectional mapping mechanism essentially transforms complex constraint logic into an efficient data structure, enabling the system to handle both simple single-condition matching and complex rules requiring statistical aggregation, such as "count(field=value) comparison operator numerical value," thus laying the foundation for accurate subsequent screening of fault scenarios.

[0104] S1032: Determine the target fault scenario based on the bidirectional mapping relationship between each fault scenario and each of the first constraints.

[0105] See Figure 5 The figure is a flowchart illustrating another fault scenario screening method provided in this application embodiment, which specifically includes the following steps:

[0106] S1033: Recursively traverse each of the first constraints to determine whether there is a fault scenario that satisfies the first constraints;

[0107] S1034: If there is a fault scenario that satisfies any of the first constraint conditions, then the list of constraint conditions associated with the fault scenario and the list of fault scenarios in which it is located are updated by using a preset constraint propagation algorithm.

[0108] Based on the above bidirectional mapping relationship, the process of determining the target fault scenario starts with recursively traversing the first constraint condition. The system will check each first constraint condition one by one to determine whether there is a fault scenario that can satisfy the condition.

[0109] If a fault scenario matching any of the first constraints is found during the traversal, the pre-defined constraint propagation algorithm is triggered to dynamically update the list of constraints associated with that fault scenario and its own list of fault scenarios. The core function of the constraint propagation algorithm is that when a fault scenario is determined to meet a certain first constraint, the system synchronously updates the state of all constraints involved in that scenario along a bidirectional mapping relationship—for example, updating the range of constraints and marking which constraints have been satisfied. The update based on the pre-defined constraint propagation algorithm is not a single execution, but rather iterates continuously at each matching step as the recursive traversal deepens, ensuring that each considered fault scenario and its associated constraints are always in the latest verified state.

[0110] It is important to note that when a matching fault scenario cannot be found for a certain constraint during recursive traversal, the system will trigger a backtracking adjustment mechanism. This mechanism dynamically corrects the filtering logic of the first constraint to prevent the filtering from falling into a "no-solution" state. The specific process is as follows: First, the system backtracks along the recursive path to the nearest adjustable parent constraint, restoring the original state of the fault scenario list and constraint list associated with that constraint, ensuring the adjustment is based on the complete context. Then, the backtracked constraint is adjusted according to preset configurable rules, including relaxing comparison operators (e.g., changing "≤1" to "≤2").

[0111] S1035: When all the constraints associated with the fault scenario are met, the fault scenario is determined as the target fault scenario.

[0112] During constraint propagation, the system continuously checks whether all constraints associated with a fault scenario are met. When all associated constraints for a fault scenario pass verification, it means a target fault scenario meeting all constraints has been found and can be selected as the final filtering result. Conversely, if any fault scenario fails to meet its associated constraint list during the check, the system will update multiple fault scenario lists and constraint lists again using a preset constraint propagation algorithm. The update method may involve excluding scenarios that do not meet the conditions or adjusting the matching range of the constraints to avoid getting trapped in local optima.

[0113] S1036: If any fault scenario does not meet the associated constraint list, then the multiple fault scenario lists and multiple constraint list are updated using a preset constraint propagation algorithm.

[0114] When any failure scenario fails to meet its associated constraint list, the constraint propagation algorithm starts from this unmet condition and updates all related constraint lists and failure scenario lists in reverse. Specifically, the system finds the unmet constraint (such as "implementation priority >= 8") in the constraint list of that scenario, removes the index of that scenario from the corresponding "failure scenario list," and marks the scenario as "invalid." The value of this propagation mechanism lies in timely removal of invalid data, avoiding repeated processing of scenarios that cannot meet the conditions in subsequent checks, forming a two-way filtering from constraint to scenario and scenario to constraint, ensuring that the entire screening process is always carried out within the minimum range of valid data.

[0115] This application provides a method for screening fault scenarios. The method involves obtaining fault scenario screening parameters and a candidate set of fault scenarios; constructing constraint expressions based on a preset constraint configuration grammar and the fault scenario screening parameters to determine a first constraint expression corresponding to the fault scenario screening parameters; and solving constraints based on the candidate set of fault scenarios and the first constraint expression to determine a target fault scenario matching the fault scenario screening parameters. Thus, this application achieves automated generation of constraint expressions through a preset constraint configuration grammar. By defining standardized configuration rules, constraint expressions can be directly generated using standardized configuration rules and fault scenario screening parameters, without requiring code development. Similarly, when the requirements for fault injection testing fluctuate frequently, only the corresponding screening parameters or the preset constraint configuration grammar need to be modified, eliminating the need to repeatedly perform constraint development and code modification processes, effectively improving the efficiency of fault scenario screening.

[0116] The following describes a fault scenario screening system provided by an embodiment of this application. The fault scenario screening system described below can be referred to in correspondence with the fault scenario screening method described above.

[0117] See Figure 6 The figure is a schematic diagram of the structure of a fault scenario screening system provided in an embodiment of this application, which specifically includes the following modules:

[0118] Module 100 is used to acquire fault scenario filtering parameters and a fault scenario candidate set.

[0119] The constraint expression construction module 200 is used to construct a constraint expression based on a preset constraint configuration grammar and the fault scenario screening parameters, so as to determine a first constraint expression corresponding to the fault scenario screening parameters.

[0120] The constraint solving module 300 is used to solve constraints based on the candidate set of fault scenarios and the first constraint expression to determine the target fault scenario that matches the fault scenario screening parameters.

[0121] In one possible implementation, the constraint expression construction module 200 is specifically used for:

[0122] Based on the preset constraint configuration grammar and the fault scenario filtering parameters, construct multiple second constraint expressions;

[0123] An abstract syntax tree is constructed based on multiple second constraint expressions and a recursive descent algorithm.

[0124] Based on the abstract syntax tree, multiple second constraint expressions are subjected to normative verification to obtain multiple third constraint expressions;

[0125] Multiple third constraint expressions are merged to obtain the first constraint expression.

[0126] See Figure 7 The figure is a schematic diagram of the structure of a fault scenario screening electronic device provided in an embodiment of this application, including:

[0127] Memory 11 is used to store computer programs;

[0128] The processor 12 is used to implement the steps of the fault scenario screening method described in any of the above method embodiments when executing the computer program.

[0129] In this embodiment, the device can be an in-vehicle computer, a PC (Personal Computer), or a terminal device such as a smartphone, tablet computer, handheld computer, or portable computer.

[0130] The device may include a memory 11, a processor 12, and a bus 13.

[0131] The memory 11 includes at least one type of readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 11 may be an internal storage unit of the device, such as the hard disk of the device. In other embodiments, the memory 11 may be an external storage device of the device, such as a plug-in hard disk, SmartMedia Card (SMC), Secure Digital (SD) card, Flash Card, etc. Furthermore, the memory 11 may include both internal and external storage units of the device. The memory 11 can be used not only to store application software and various types of data installed on the device, such as program code executing fault scenario screening methods, but also to temporarily store data that has been output or will be output. In some embodiments, the processor 12 may be a central processing unit (CPU).

[0132] In some embodiments, processor 12 may be a central processing unit (CPU), controller, microcontroller, microprocessor or other data processing chip, used to run program code stored in memory 11 or process data, such as program code for executing a fault scenario screening method.

[0133] This bus 13 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0134] Furthermore, the device may also include a network interface 14, which may optionally include a wired interface and / or a wireless interface (such as a Wi-Fi interface, a Bluetooth interface, etc.), typically used to establish communication connections between the device and other electronic devices.

[0135] Optionally, the device may further include a user interface 15, which may include a display, an input unit such as a keyboard, and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the device and to display a visual user interface.

[0136] Figure 7 Only devices with components 11-15 are shown; those skilled in the art will understand that... Figure 7 The structure shown does not constitute a limitation on the device and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0137] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a computer-readable storage medium storing computer instructions for causing the computer to execute the fault scenario screening method as described in any of the above embodiments.

[0138] The computer-readable media in this application embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0139] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the fault scenario screening method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0140] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the system, method, electronic device, and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The system, method, electronic device, and medium embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated 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 modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0141] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / special> < / character> < / digit> < / letter> < / number> < / comparator> < / value> < / field> < / expression> < / rule>

Claims

1. A method for screening fault scenarios, characterized in that, include: Obtain the fault scenario filtering parameters and the fault scenario candidate set; Constraint expressions are constructed based on preset constraint configuration grammar and the fault scenario screening parameters to determine the first constraint expression corresponding to the fault scenario screening parameters. Constraints are solved based on the candidate set of fault scenarios and the first constraint expression to determine the target fault scenario that matches the fault scenario screening parameters.

2. The method according to claim 1, characterized in that, The step of constructing constraint expressions based on preset constraint configuration grammar and fault scenario screening parameters to determine the first constraint expression corresponding to the fault scenario screening parameters includes: Based on the preset constraint configuration grammar and the fault scenario filtering parameters, construct multiple second constraint expressions; An abstract syntax tree is constructed based on multiple second constraint expressions and a recursive descent algorithm. Based on the abstract syntax tree, multiple second constraint expressions are normalized and optimized to obtain multiple third constraint expressions; Multiple third constraint expressions are merged to obtain the first constraint expression.

3. The method according to claim 2, characterized in that, The process of merging multiple third constraint expressions to obtain the first constraint expression includes: At least two fourth constraint expressions are determined from a plurality of the third constraint expressions; the fourth constraint expressions have the same characteristic fields. Based on the feature value ranges in each of the fourth constraint expressions, logical conflict detection is performed on all the fourth constraint expressions. If the logical conflict detection passes, multiple fourth constraint expressions are merged into a fifth constraint expression, and the third constraint expression after removing the fourth constraint expression and the fifth constraint expression are used to determine the first constraint expression. If the logic conflict detection fails, a logic conflict alarm signal is generated; the logic conflict alarm signal is used to indicate a logic error in the fault scenario screening.

4. The method according to claim 1, characterized in that, The first constraint expression includes multiple first constraint conditions, and the fault scenario candidate set includes multiple fault scenarios; The step of solving constraints based on the candidate set of fault scenarios and the first constraint expression to determine the target fault scenario matching the fault scenario screening parameters includes: Traverse the first constraint expression and the candidate set of fault scenarios to establish a bidirectional mapping relationship between each fault scenario and each of the first constraint conditions; The target fault scenario is determined based on the bidirectional mapping relationship between each fault scenario and each of the first constraints.

5. The method according to claim 4, characterized in that, The bidirectional mapping relationship includes: a list of fault scenarios individually associated with each of the first constraints, and a list of constraints individually associated with each of the fault scenarios; the list of fault scenarios is used to represent fault scenarios that match the first constraints; the list of constraints is used to represent first constraints that match the fault scenarios. Determining the target fault scenario based on the bidirectional mapping relationship between each fault scenario and each of the first constraints includes: Recursively traverse each of the first constraints to determine whether there is a fault scenario that satisfies the first constraint. If there is a fault scenario that satisfies any of the first constraints, then the list of constraints associated with the fault scenario and the list of fault scenarios in which it is located are updated by using a preset constraint propagation algorithm. When all the constraints in the list associated with the fault scenario are met, the fault scenario is determined as the target fault scenario. If any of the fault scenarios does not satisfy the associated list of constraints, then the preset constraint propagation algorithm is used to update the multiple lists of fault scenarios and the multiple lists of constraints.

6. The method according to claim 1, characterized in that, Before constructing the constraint expression based on the preset constraint configuration grammar and the fault scenario screening parameters to determine the first constraint expression corresponding to the fault scenario screening parameters, the method further includes: The fault scenario screening parameters are standardized according to a preset configuration template to obtain standardized data. The preset configuration template includes a data format template and a data item template. The data format template is used to define the parsing method of the standardized data, and the data item template is used to define the position of the target fault scenario in the returned data.

7. A fault scenario screening system, characterized in that, include: The acquisition module is used to acquire fault scenario filtering parameters and a fault scenario candidate set. The constraint expression construction module is used to construct constraint expressions based on a preset constraint configuration grammar and the fault scenario screening parameters, so as to determine the first constraint expression corresponding to the fault scenario screening parameters. The constraint solving module is used to solve constraints based on the candidate set of fault scenarios and the first constraint expression to determine the target fault scenario that matches the fault scenario screening parameters.

8. The system according to claim 7, characterized in that, The constraint expression construction module is specifically used for: Based on the preset constraint configuration grammar and the fault scenario filtering parameters, construct multiple second constraint expressions; An abstract syntax tree is constructed based on multiple second constraint expressions and a recursive descent algorithm. Based on the abstract syntax tree, multiple second constraint expressions are subjected to normative verification to obtain multiple third constraint expressions; Multiple third constraint expressions are merged to obtain the first constraint expression.

9. An electronic device, characterized in that, The device includes: a processor, a memory, and a system bus; The processor and the memory are connected via the system bus; The memory is used to store one or more programs, the one or more programs including instructions that, when executed by the processor, cause the processor to perform the fault scenario screening method according to any one of claims 1-6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the fault scenario screening method as described in any one of claims 1-6.

Images