Software test case generation method, electronic device and readable storage medium

Abstract

The embodiment of the present invention provides a software test case generation method, an electronic device and a readable storage medium, which relate to the field of software testing technology. The software test case generation method includes: performing safety analysis on safety-critical software according to a system theory process analysis method, obtaining unsafe control behaviors and software safety constraints corresponding to the unsafe control behaviors, and generating a set of mutation operators corresponding to the unsafe control behaviors; converting the software safety constraints into a software safety control model based on a random hybrid automaton, and using the software safety control model to generate a variant model corresponding to each variant operator in the mutation operator set; based on the variant model corresponding to each variant operator, generating the original test case corresponding to each variant model. In the present invention, the STPA method is combined with the random hybrid automaton, so as to assist in the construction of trusted software suitable for the development process itself to be provable.

Description

Technical Field

[0001] The present invention relates to the technical field of software testing, and in particular to a software testing case generating method, an electronic device and a readable storage medium. Background Art

[0002] How to improve software security and reliability in software-intensive and safety-critical systems such as rail transit train operation control systems, aerospace control systems, and nuclear power control systems is the key to improving the safety performance of such systems. Traditional safety analysis is performed by independent third-party safety analysis engineers, while system development is performed by software development engineers. After the system development is completed, they can only evaluate the safety of the existing design, but cannot guide the design to create early decisions. If major changes are made, it will be costly. This problem has prompted in-depth research on safety-driven design methods that combine safety analysis with formal methods.

[0003] Traditional event chain-based safety analysis methods are difficult to deal with hazards such as software errors without hardware failures and unexpected component interactions. Therefore, it is necessary to choose safety analysis methods that are more suitable for software, such as the System-Theoretical Process Analysis (STPA) method. The STPA analysis method also has the problem of over-reliance on manual analysis, which also prompted the combination of the STPA analysis method with formal methods.

[0004] Formal methods are based on rigorous mathematical theories and related reasoning. They are self-evidently correct and achieve the core goal of building a trusted system by ensuring the consistency of the refined relationship between various R&D activities. When modeling information-physical fusion systems, it is also necessary to consider how to effectively model hybrid behaviors, random behaviors, and highly reliable time constraints. However, the model checking method in traditional formal methods requires finite traversal of the state space, which is prone to the "state space explosion" problem when analyzing the model of complex systems, increasing the difficulty of system verification. Summary of the invention

[0005] The purpose of the present invention is to provide a software test case generation method, an electronic device and a readable storage medium, which combine the STPA method with a random hybrid automaton, so as to assist in the construction of trusted software that is applicable to the development process itself and can verify the safety constraints. The safety constraints have strong traceability and are formally verified, which reduces the cost problem caused by repeated modifications due to problems in the later stage of development. The original test case set based on faults is generated by mutation testing, which helps to find errors related to functional defects or specification misunderstandings. The mutation operator is generated by using unsafe control behavior, which is more objective and effective, and improves the efficiency of mutation testing.

[0006] To achieve the above-mentioned purpose, the present invention provides a method for generating software test cases, comprising: performing safety analysis on safety-critical software according to a system theory process analysis method to obtain unsafe control behaviors and software safety constraints corresponding to the unsafe control behaviors, and generating a set of mutation operators corresponding to the unsafe control behaviors; converting the software safety constraints into a software safety control model based on a random hybrid automaton, and using the software safety control model to generate a variant model corresponding to each variant operator in the variant operator set; and generating an original test case corresponding to each variant model based on the variant model corresponding to each variant operator.

[0007] The present invention also provides an electronic device, comprising: at least one processing chip; and a memory communicatively connected to the at least one processing chip; wherein the memory stores instructions executable by the at least one processing chip, and the instructions are executed by the at least one processing chip so that the at least one processing chip can execute the software test case generation method as described above.

[0008] The present invention also provides a computer-readable storage medium storing a computer program, wherein the computer program implements a software test case generation method when running.

[0009] The embodiment of the present invention provides a method for generating software test cases. The safety analysis method based on STPA regards safety as a dynamic control problem rather than a fault prevention problem. It evaluates the safety of a certain component from the perspective of the entire system rather than in isolation, and is suitable for the safety analysis of software-intensive systems. The SHA model supports accurate description of continuous behavior, discrete behavior, and random behavior. When the SHA model is further verified by a statistical model verification method, the system can be quantitatively analyzed by evaluating the probability interval satisfied by the system, thereby effectively solving the problem of too many states and difficult verification. The present invention combines the STPA method with a random hybrid automaton, so as to assist in the construction of trusted software that is suitable for the development process itself. The safety constraints have strong traceability and are formally verified, reducing the cost problem caused by repeated modifications due to problems in the later stage of development. At the same time, using mutation testing to generate a set of original test cases based on faults helps to discover errors related to functional deficiencies or specification misunderstandings. Using unsafe control behaviors to generate mutation operators is more objective and effective, and the efficiency of mutation testing is improved.

[0010] In one embodiment, the method of performing safety analysis on safety-critical software according to the system theory process analysis method to obtain unsafe control behaviors and software safety constraints corresponding to the unsafe control behaviors includes: determining system-level accidents, system-level hazards and system-level constraints corresponding to the safety-critical software, constructing a first hierarchical control structure of the system, and obtaining four types of unsafe control behaviors existing in the safety-critical software based on the constructed first hierarchical control structure; constructing a second hierarchical control structure with process model variables, and obtaining a set of process model variables that cause each of the unsafe control behaviors based on a provided scenario and the second hierarchical control structure; and generating software safety constraints corresponding to each of the unsafe control behaviors based on the set of process model variables for each of the unsafe control behaviors.

[0011] In one embodiment, generating a set of mutation operators corresponding to the unsafe control behaviors includes: establishing a mapping relationship between each of the unsafe control behaviors and a plurality of mutation operators based on the semantics of a random hybrid automaton and a set of process model variables corresponding to each of the unsafe control behaviors, and obtaining a set of mutation operators composed of mutation operators corresponding to each of the unsafe control behaviors.

[0012] In one embodiment, the four types of unsafe control actions include: unsafe control actions caused by providing control actions, unsafe control actions caused by not providing control actions, providing control actions at the wrong time or sequence, and control actions lasting too long or stopping too early.

[0013] In one embodiment, before generating the original test cases corresponding to each mutant model based on the mutant models corresponding to each mutant operator, it also includes: performing consistency check on the mutant models corresponding to each mutant operator with the software safety control model respectively, and obtaining non-equivalent mutant models in the mutant models corresponding to each mutant operator; generating the original test cases corresponding to each mutant model based on the mutant models corresponding to each mutant operator includes: generating the original test cases corresponding to each non-equivalent mutant model based on the non-equivalent mutant models in the mutant models corresponding to each mutation operator.

[0014] In one embodiment, after converting the software safety constraints into a software safety control model based on a random hybrid automaton, the method further includes: converting the software safety constraints into a computational tree temporal logic required by the random hybrid automaton, and performing security requirement verification on the temporal logic.

[0015] In one embodiment, the method of using the software safety control model to generate a mutant model corresponding to each mutation operator in the mutation operator set includes: for each mutation operator, applying the mutation operator to a position or transformation in the software safety control model to obtain a first-order mutant model corresponding to the mutation operator. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a specific flow chart of the method for generating software test cases according to the first embodiment of the present invention;

[0017] Figure 2 yes Figure 1 A specific flow chart of step 101 of the method for generating software test cases;

[0018] Figure 3 A schematic diagram of a first hierarchical control structure of a control system constructed according to a first embodiment of the present invention;

[0019] Figure 4 is a schematic diagram of a second hierarchical control structure with process model variables according to the first embodiment of the present invention;

[0020] Figure 5 is a schematic diagram of a software safety behavior model corresponding to a train component according to a first embodiment of the present invention;

[0021] Figure 6 is a schematic diagram of a software safety control model A1 based on a random hybrid automaton and its 12 first-order variant models according to the first embodiment of the present invention;

[0022] Figure 7 It is a specific flow chart of the method for generating software test cases according to the second embodiment of the present invention. DETAILED DESCRIPTION

[0023] The following will be described in detail with reference to the accompanying drawings to provide a clearer understanding of the purpose, features and advantages of the present invention. It should be understood that the embodiments shown in the accompanying drawings are not intended to limit the scope of the present invention, but are only intended to illustrate the essential spirit of the technical solution of the present invention.

[0024] In the following description, certain specific details are set forth for the purpose of illustrating various disclosed embodiments to provide a thorough understanding of the various disclosed embodiments. However, those skilled in the relevant art will recognize that the embodiments may be practiced without one or more of these specific details. In other cases, well-known devices, structures, and techniques associated with the present application may not be shown or described in detail to avoid unnecessarily obscuring the description of the embodiments.

[0025] Unless the context requires otherwise, throughout the specification and claims, the word "comprise" and variations such as "include" and "have" should be construed in an open, inclusive sense, ie, should be interpreted as "including, but not limited to."

[0026] References throughout the specification to "one embodiment" or "an embodiment" indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of "in one embodiment" or "in an embodiment" in various places throughout the specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any manner in one or more embodiments.

[0027] As used in this specification and the appended claims, the singular forms "a", "an", and "" include plural referents unless the context clearly dictates otherwise. It should be noted that the term "or" is generally employed in its sense including "or / and" unless the context clearly dictates otherwise.

[0028] In the following description, in order to clearly show the structure and working mode of the present invention, many directional words will be used for description, but the words "front", "back", "left", "right", "outside", "inside", "outward", "inward", "up", "down", etc. should be understood as convenient terms and should not be understood as restrictive terms.

[0029] The first embodiment of the present invention relates to a method for generating software test cases, which is applied to electronic devices, such as mobile phones, tablet computers, laptop computers, desktop hosts, etc. The electronic device can execute the software test case generation method in this embodiment to generate original test cases for safety-critical software. In this embodiment and subsequent embodiments, the safety-critical software is described as control software applied to a train door controller; the main function of the train door controller is to control the state of the door in different environmental conditions, which is an important function in the safety protection and automatic control of the rail transit signal on-board system.

[0030] The specific process of the software test case generation method in this embodiment is as follows Figure 1 shown.

[0031] Step 101 , performing safety analysis on the safety-critical software according to the system theory process analysis method, obtaining unsafe control behaviors and software safety constraints corresponding to the unsafe control behaviors, and generating a set of mutation operators corresponding to the unsafe control behaviors.

[0032] For an example, see Figure 2 , step 101 includes the following sub-steps:

[0033] Sub-step 1011, determining the system-level accidents, system-level hazards and system-level constraints corresponding to the safety-critical software, constructing the first hierarchical control structure of the system, and based on the constructed first hierarchical control structure, obtaining four types of unsafe control behaviors existing in the safety-critical software.

[0034] Specifically, the analysis foundation of safety-critical software is established, and system-level accidents, system-level hazards, and system-level constraints are formulated. System-level accidents related to the control software (safety-critical software) of the train door controller include: people being pinched (A-1), people falling (A-2), and people being trapped (A-3). System-level hazards include: people being pinched when the door is closed (H-1), doors opening when the train is running or not at the station (H-2), and people being unable to escape in an emergency (H-3). System-level constraints include: doors cannot be closed when someone is at the door (SC1), doors cannot be opened when the train is running or not at the station (SC2), and doors are allowed to be opened to let people out in an emergency (SC 3). The mapping relationship between system-level accidents, system-level hazards, and system-level constraints is shown in Table 1 below.

[0035] Table 1

[0036]

[0037] Based on the four types of program components, namely controller, actuator, controlled process, and sensor, and the five types of system behaviors, namely control behavior, feedback behavior, input, disturbance, and output, a hierarchical control structure of the control system (i.e., the first hierarchical control structure) can be constructed. The hierarchical control structure diagram is a functional model composed of multiple control loops. The hierarchical control structure of the system where the train door controller is located is shown in the figure. Figure 3 As shown, the actuator is a door actuator, and the door sensor is used to detect door-related conditions.

[0038] The train door controller receives external control commands (Control commands) and sends commands (Commands) to the door actuator, including the following two control actions: open door, stop closing door (Open door, stop closing door), close door, stop opening door (Close door, stop opening door).

[0039] Under the guidance of the four types of guide words, four types of unsafe control actions (UCA) in the above two control behaviors of safety-critical software are obtained. The four types of unsafe control actions include: unsafe control actions caused by providing control actions, unsafe control actions caused by not providing control actions, wrong time or sequence of providing control actions, and control actions lasting too long or stopping too early. Please refer to Table 2 below for the four types of unsafe control actions in the two control behaviors related to safety-critical software.

[0040] Table 2

[0041]

[0042]

[0043] Sub-step 1012, constructing a second hierarchical control structure with process model variables, and obtaining a set of process model variables that lead to each unsafe control behavior based on the provided scenario and the second hierarchical control structure.

[0044] Specifically, the train door controller is described using process model variables, thereby building a second hierarchical control structure with process model variables, which includes one or more process model variables (PMV) and variable values. Process model variables are divided into three types, including: internal variables that change the state of the software controller, interactive interface variables that receive and store data, commands, and feedback in the system, and environmental variables of environmental components that interact with or are controlled by the software controller. In this embodiment, the process model variables describe the second hierarchical control structure of the train door controller as shown in FIG. Figure 4 shown.

[0045] The train door controller includes five process model variables, including:

[0046] Door position, which is an environment variable, includes: Fully open, Fully closed, Partially open, and Unknown.

[0047] Door state is an environmental variable, including: Person in doorway, Person not in doorway, and Unknown.

[0048] Train position belongs to the interactive interface variables, including: Aligned with platform, Not aligned with platform, and Unknown.

[0049] Train motion status (Train motion), which belongs to the interactive interface variables, includes: Stopped, Train is moving, and Unknown.

[0050] Emergency, which belongs to the environmental variables, includes: No emergency, Evacuation required, and Unknown.

[0051] This embodiment provides two types of scenarios, namely providing dangerous control behaviors C1 = Providing CA, including three scenario types: any time, too late, and too early; and not providing dangerous control behaviors C2 = Not Providing CA.

[0052] In the process of formulating the scenario table, the process model variables are combined and evaluated to obtain a set of process model variables that are "hazardous", which can be called a refined UCA.

[0053] Taking opening the door and prohibiting closing the door (Open door, stop closing door) as an example, the following situation table can be obtained, where Table 3 is a situation table that provides control behaviors that lead to danger, and Table 4 is a situation table that does not provide control behaviors that lead to danger.

[0054] Table 3

[0055]

[0056] Table 4

[0057]

[0058]

[0059] Sub-step 1013, based on the process model variable set of each unsafe control behavior, generate the software safety constraint corresponding to each unsafe control behavior.

[0060] Specifically, based on the process model variable set (i.e., refined UCA) of each unsafe control behavior UCA obtained in the above process, the dangerous path RUCA in two scenarios and the safety requirement RSSR corresponding to each dangerous path are established. The safety requirement RSSR can be converted into software safety constraints.

[0061] RUCA is a four-tuple (CA, Cs, C, TC), where CA is the control action that leads to danger, Cs = ∪ (P1 = V1, ..., P n =V n ) is the combination of the corresponding PMV of CA, P represents PMV, V represents the variable value, C represents the situation in which it is dangerous to provide or not provide CA, and TC represents the type of situation in which CA is provided (any time, too early or too late).

[0062] Rule 1: Each RUCA i and RSSR i In Control Behavior CA i The "provided" context can be expressed as:

[0063] RUCA i = <ca>provided <tc>is hazardous when<Cs=∪(P1=v1,...,P n =v n >occurred。

[0064] RSSR i = <ca>must not provided <tc>when <Cs=∪(P1=v1,...,P n =v n >occurred.

[0065] RUCA i represents the ith dangerous path, RSSR i represents the i-th safety requirement.

[0066] Rule 2: Each RUCA i and RSSR i In Control Behavior CA i The "not provided" situation can be expressed as:

[0067] RUCA i = <ca>Not provided is hazardous when<Cs=∪(P1=v1,...,P n =v n >occurred。

[0068] RSSR i = <ca>must be provided when <Cs=∪(P1=v1,...,P n =v n >occurred.

[0069] RUCA i represents the ith dangerous path, RSSR i represents the i-th safety requirement.

[0070] Based on the above rules, the dangerous path RUCA of the unsafe control behavior of the train door controller in this embodiment and its corresponding software safety requirement RSSR can be obtained, as shown in Table 5 below.

[0071] Table 5

[0072]

[0073] Based on the above analysis, the software safety constraints of the safety-critical software applied to the train door controller in this embodiment include:

[0074] Close door, stop opening door command must not be provided any time when Door position is Fully open and Train motion is Train is moving and Emergency is Evacuation required and Train position is Not aligned with platform and Door state is Person not in doorway.

[0075] Close door, stop opening door command must not be provided too early when Door position is Fully open and Train motion is Train is moving and Emergency is Evacuation required and Train position is Not aligned with platform and Door state is Person not in doorway.

[0076] Close door,stop opening door command must not be provide too latewhen Door position is Fully open and Train motion is Train is moving andEmergency is Evacuation required and Train position is Not aligned withplatform and Door state is Person not in doorway。

[0077] Open door,stop closing door command must not be provide anytime whenTrain motion is Train is moving and Emergency is No emergency。

[0078] Open door,stop closing door command must not be provided too earlywhen Train motion is Train is moving and Emergency is No emergency。

[0079] Open door,stop closing door command must not be provided too latewhen Train motion is Train is moving and Emergency is No emergency。

[0080] Open door,stop closing door command must not be provided anytime whenTrain motion is Train is moving and Emergency is Evacuation required。

[0081] Open door,stop closing door command must not be provided too earlywhen Train motion is Train is moving and Emergency is Evacuation required。

[0082] Open door,stop closing door command must not be provided too latewhen Train motion is Train is moving and Emergency is Evacuation required。

[0083] Open door,stop closing door command must not be provided too latewhen Train motion is Stopped and Emergency is Evacuation required。

[0084] Open door,stop closing door command must not be provided anytime whenTrain motion is Stopped and Emergency is No emergency and Train position isNot aligned with platform。

[0085] Open door,stop closing door command must not be provided too earlywhen Train motion is Stopped and Emergency is No emergency and Train positionis Not aligned with platform。

[0086] Open door, stop closing door command must not be provided too late when Train motion is Stopped and Emergency is No emergency and Train position is Not aligned with platform.

[0087] Open door, stop closing door command must be provided when Trainmotion is Stopped and Emergency is Evacuation required.

[0088] Open door, stop closing door command must be provided when Trainmotion is Stopped and Emergency is No emergency and Train position is Alignedwith platform and Door state is Person in doorway.

[0089] Sub-step 1014, based on the semantics of the random hybrid automaton and the set of process model variables corresponding to each unsafe control behavior, establish a mapping relationship between each unsafe control behavior and multiple mutation operators, and obtain a mutation operator set composed of the mutation operators corresponding to each unsafe control behavior.

[0090] Specifically, based on the process model variable set corresponding to the unsafe control behavior, the semantics of the stochastic hybrid automata (SHA) are used to express each unsafe control behavior; the reference mutation operator set of the stochastic hybrid automata is listed, and the application position, required parameters, time correlation and typical meaning of each mutation operator in the reference mutation operator set are described, please refer to Table 6 below. Then, according to the unsafe control behavior and the meaning of the mutation operator in the stochastic hybrid automata, a mapping relationship can be established between each unsafe control and the corresponding mutation operator, please refer to Table 7 below, so that the mutation operator set composed of the mutation operator corresponding to each unsafe control behavior can be obtained, so that the mutation operator set applied to the stochastic hybrid automata is the minimum set obtained by simplification, making the mutation more targeted.

[0091] Table 6

[0092]

[0093]

[0094] Table 7

[0095]

[0096] Step 102: Convert the software safety constraints into a software safety control model based on a random hybrid automaton, and use the software safety control model to generate a mutant model corresponding to each mutation operator in the mutation operator set.

[0097] Specifically, the random hybrid automaton is an octet M = (L, l, CAct, inv, enab, prob, F); where L represents a finite set of positions, l represents the initial position, l∈L; C represents a finite set of clocks; Act represents a finite set of transitions, inv: L→CC(C) represents a finite set of invariants, CC represents a clock constraint function; enab: L×Act→CC(C) represents the condition for triggering the transition; prob: L×Act→Dist(2 C ×L) represents the probability transfer function; F: L→2 AP represents a labeling function that maps each position to a set of atomic propositions.

[0098] When constructing the SHA network model of the train door controller, the SHA sub-model is used to correspond to each component of the train door controller system, and the position, channel, guard, update, and invariant are used to correspond to the input / output, control behavior, and feedback information; then the UPPAAL-SMC tool is used to form a network control structure by combining the SHA models in parallel, synchronize the channel to send and receive input or output behaviors, and use shared discrete and clock variables; in summary, the software safety constraints can be converted into a software safety control model. In this example, the automatic door controller and the train model can be combined in parallel. The SHA model of the train door controller is as follows: Figure 5 shown.

[0099] In one example, after the software safety control model is constructed, the safety requirements of the constructed software safety control model need to be verified to ensure the consistency of the constructed model with the corresponding specification. The process of safety requirements verification includes: converting the software safety constraints into the temporal logic required by the random hybrid automaton, and verifying the safety requirements of the temporal logic.

[0100] Among them, the CTL grammar based on Backus-Naur form converts the software safety constraints into the temporal logic required by the random hybrid automaton, and the temporal logic is the CTL statement.

[0101] Specifically, the CTL syntax in Backus-Naur form is as follows:

[0102] Φ::=T|⊥|p|ㄱΦ|Φ∧Φ|Φ∨Φ|Φ→Φ|AXΦ|EXΦ|AFΦ|EFΦ|AGΦ|EGΦ|A[ΦUΦ]|E[ΦUΦ]

[0103] Among them, P is an atomic proposition, ⊥ represents the permanent false form, T represents the permanent true form, A represents along all paths, E represents along at least one path, X represents the next state, F represents a future state, and G represents all future states; A and E represent path quantifiers, X, F and G represent tense operators, and the path quantifier must appear with one of the tense operators.

[0104] After the temporal logic of the CTL statement is converted, the security requirements of the temporal logic can be verified using the verifier provided by the UPPAAL-SMC tool.

[0105] Based on the mutation operator set determined in step 101, each mutation operator is applied to the constructed software safety control model to obtain a variant model. According to the number of single grammar modifications to the software safety control model, it can be divided into first-order variants and high-order variants. In this implementation, the first-order mutation of the software safety control model is taken as an example, that is, the variant models obtained are all first-order variant models.

[0106] Specifically, for each mutation operator, the mutation operator is applied to a position or transformation in the software safety control model to obtain the first-order mutant model corresponding to the mutation operator, that is, the first-order mutant model only covers a specific defect. Figure 6 Taking the software safety control model A1 shown in FIG. 1 as an example, after applying the above 12 mutation operators to the software safety control model A1, 12 first-order mutant models can be obtained, namely: Figure 6 M1 to M 12 The meaning of software safety control model A1 is that the initial position of the system is q0. If the input behavior input is received and the variable constraint of V≤3 is satisfied, it will migrate to the position q1 (there is an invariant constraint x≤4 on q1), and x will always be set to 0. At q1, if the clock constraint of x<3 is satisfied, the output behavior output will migrate to the position q2, and the variable v will be set to 2.

[0107] Step 103: Based on the mutant models corresponding to the mutation operators, original test cases corresponding to the mutant models are generated.

[0108] Specifically, based on the preset test case generation algorithm and each variant model, the original test cases corresponding to each variant model are created; the original test cases are generally in English, which can be converted into Chinese test cases, and the similar test cases and test cases that do not match the actual logic are screened out and removed, and the test cases are merged according to function.

[0109] The present embodiment provides a method for generating software test cases. For safety-critical software, a safety analysis is performed on the safety-critical software according to a system theory process analysis method to obtain unsafe control behaviors and software safety constraints corresponding to the unsafe control behaviors, and a set of mutation operators corresponding to the unsafe control behaviors is generated. Subsequently, the software safety constraints are converted into a software safety control model based on a random hybrid automaton, and a mutant model corresponding to each mutation operator in the mutation operator set is generated using the software safety control model. Then, based on the mutant model corresponding to each mutation operator, an original test case corresponding to each mutant model is generated. The safety analysis method based on STPA regards safety as a dynamic control problem rather than a fault prevention problem. It evaluates the safety of a certain component from the perspective of the entire system rather than in isolation, and is suitable for the safety analysis of software-intensive systems. The SHA model supports accurate descriptions of continuous behavior, discrete behavior, and random behavior. When the SHA model is further verified by a statistical model verification method, the system can be quantitatively analyzed by evaluating the probability interval satisfied by the system, thereby effectively solving the problem of too many states and difficult verification. The present invention combines the STPA method with a random hybrid automaton, so that it can assist in the construction of trusted software that is suitable for the development process itself. The safety constraints have strong traceability and have been formally verified, reducing the cost of repeated modifications caused by problems in the later stages of development. At the same time, using mutation testing to generate a set of original test cases based on faults helps to discover errors related to functional deficiencies or specification misunderstandings. Using unsafe control behaviors to generate mutation operators is more objective and effective, and improves the efficiency of mutation testing.

[0110] The second embodiment of the present invention relates to a method for generating software test cases. Compared with the first embodiment, this embodiment adds a consistency comparison between a variant model and a software safety control model.

[0111] The specific process of the software test case generation method of this embodiment is as follows Figure 7 shown.

[0112] Step 201, safety analysis is performed on the safety-critical software according to the system theory process analysis method, unsafe control behaviors and software safety constraints corresponding to the unsafe control behaviors are obtained, and a set of mutation operators corresponding to the unsafe control behaviors is generated. This is substantially the same as step 101 in the first embodiment and will not be described in detail here.

[0113] Step 202: Convert the software safety constraint into a software safety control model based on a random hybrid automaton, and use the software safety control model to generate a mutant model corresponding to each mutation operator in the mutation operator set. This is substantially the same as step 102 in the first embodiment and will not be described in detail here.

[0114] Step 203 , respectively check the consistency relationship between the variant models corresponding to each mutation operator and the software safety control model, and obtain non-equivalent variant models in the variant models corresponding to each mutation operator.

[0115] Specifically, after generating the variant models corresponding to each mutation operator, each variant model is respectively checked for input-output time consistency relationship with the software safety control model (or K-bound model check); for each variant model, input enabling characteristics are added to the variant model and the software safety control model at the same time, and the variant model and the software safety control model are checked for input-output time consistency relationship; if the variant model is consistent with the software safety control model, it means that the variant model does not introduce new behaviors relative to the original model, and the variant model is an equivalent variant of the original software safety control model and can be discarded; if the variant model is inconsistent with the software safety control model, it means that the variant model introduces a real-time path that does not exist relative to the original model, that is, the variant model is a non-equivalent variant model of the original software safety control model. Based on the above process, non-equivalent variant models relative to the software safety control model in the variant models corresponding to each mutation operator can be obtained, and these non-equivalent variant models are variant models that can be converted into test cases.

[0116] Step 204 : Based on the non-equivalent variant models in the variant models corresponding to the mutation operators, generate original test cases corresponding to the non-equivalent variant models.

[0117] Specifically, based on the preset test case generation algorithm and each non-equivalent variant model, the original test case corresponding to each non-equivalent variant model is created; the original test case is generally in English, which can be converted into Chinese test cases, and the similar test cases and test cases that do not match the actual logic are screened out and removed, and the test cases are merged according to function.

[0118] In this embodiment, the mutant models corresponding to each mutation operator are respectively checked for consistency with the software safety control model to obtain non-equivalent mutant models in the mutant models corresponding to each mutation operator. The non-equivalent mutant models are mutant models that can be converted into test cases, thereby generating a more accurate test case set.

[0119] The third embodiment of the present invention relates to an electronic device, such as a mobile phone, a tablet computer, a laptop computer, a desktop host, etc. The edge terminal includes at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the software test case generation method of any one of the first to third embodiments.

[0120] Among them, the memory and the processor are connected in a bus manner, and the bus may include any number of interconnected buses and bridges, and the bus connects various circuits of one or more processors and memories together. The bus can also connect various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be one element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices on a transmission medium. The data processed by the processor is transmitted on a wireless medium via an antenna, and further, the antenna also receives data and transmits the data to the processor.

[0121] The processor is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory can be used to store data used by the processor when performing operations.

[0122] A fourth embodiment of the present invention relates to a computer-readable storage medium storing a computer program, which implements the above method embodiment when executed by a processor.

[0123] Preferred embodiments of the present invention have been described above in detail, but it should be understood that aspects of the embodiments can be modified, if necessary, to employ aspects, features and concepts of the various patents, applications and publications to provide further embodiments.

[0124] These and other changes can be made to the embodiments in light of the above detailed description.In general, in the claims, the terms used should not be considered limited to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which these claims are entitled.< / ca> < / ca> < / tc> < / ca> < / tc> < / ca>

Claims

1. A software test case generation method, It is characterized in that include: Perform safety analysis on safety-critical software according to the system theory process analysis method to obtain unsafe control behaviors and software safety constraints corresponding to the unsafe control behaviors; Generate a set of mutation operators corresponding to the unsafe control behavior, including: based on the process model variable set corresponding to the unsafe control behavior, using the semantics of the random hybrid automaton to express each unsafe control behavior; list the reference mutation operator set of the random hybrid automaton, and describe the application position, required parameters, time correlation and typical meaning of each mutation operator in the reference mutation operator set in the random hybrid automaton; according to the unsafe control behavior and the meaning of the mutation operator in the random hybrid automaton, establish a mapping relationship between each unsafe control and the corresponding mutation operator, and obtain a mutation operator set composed of the mutation operators corresponding to each unsafe control behavior; The software safety constraint is converted into a software safety control model based on a random hybrid automaton, and a mutant model corresponding to each mutation operator in the mutation operator set is generated by using the software safety control model; Based on the mutant models corresponding to the mutation operators, original test cases corresponding to the mutant models are generated.

2. The software test case generation method according to claim 1, It is characterized in that The safety analysis of the safety-critical software is performed according to the system theory process analysis method to obtain unsafe control behaviors and software safety constraints corresponding to the unsafe control behaviors, including: Determine system-level accidents, system-level hazards, and system-level constraints corresponding to the safety-critical software, construct a first hierarchical control structure of the system, and obtain four types of unsafe control behaviors existing in the safety-critical software based on the constructed first hierarchical control structure; Constructing a second hierarchical control structure with process model variables, and obtaining a set of process model variables that cause each of the unsafe control behaviors based on the provided scenario and the second hierarchical control structure; Based on the process model variable set of each of the unsafe control behaviors, a software safety constraint corresponding to each of the unsafe control behaviors is generated.

3. The software test case generation method according to claim 2, It is characterized in that The four types of unsafe control behaviors include: unsafe control behaviors that result from providing control behaviors, unsafe control behaviors that result from not providing control behaviors, control behaviors that are provided at the wrong time or in the wrong sequence, and control behaviors that last too long or stop too early.

4. The software test case generation method according to claim 1, It is characterized in that Before generating original test cases corresponding to the variant models based on the variant models corresponding to the variant operators, the method further includes: Perform consistency check on the variant models corresponding to each of the variant operators and the software safety control model, respectively, to obtain non-equivalent variant models in the variant models corresponding to each of the variant operators; The generating of original test cases corresponding to the variant models based on the variant models corresponding to the variant operators includes: Based on the non-equivalent variant models in the variant models corresponding to the mutation operators, original test cases corresponding to the non-equivalent variant models are generated.

5. The software test case generation method according to claim 1, It is characterized in that After converting the software safety constraint into a software safety control model based on a random hybrid automaton, the method further includes: The software safety constraints are converted into computation tree temporal logic required by a random hybrid automaton, and the temporal logic is verified for safety requirements.

6. The software test case generation method according to claim 1, It is characterized in that The step of using the software safety control model to generate a mutant model corresponding to each mutation operator in the mutation operator set includes: For each of the mutation operators, the mutation operator is applied to a position or transformation in the software safety control model to obtain a first-order mutant model corresponding to the mutation operator.

7. An electronic device, It is characterized in that include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the software test case generating method according to any one of claims 1 to 6.

8. A computer-readable storage medium, It is characterized in that A computer program is stored, and when the computer program is run, the method for generating software test cases according to any one of claims 1 to 6 is implemented.

Images