Operating system robustness test method, device, equipment, medium and product

Abstract

The invention discloses an operating system robustness test method and device, equipment, a medium and a product, and relates to the technical field of operating systems. The operating system robustness test method comprises the following steps: injecting invalid input with time delay into a kernel of a first operating system; when the time delay time point is reached, executing a test case for testing the robustness of the first operating system to obtain an execution result of the test case; and determining the robustness of the first operating system according to the execution result. According to the embodiment of the invention, the reliability of the test result of the robustness of the operating system can be improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of operating systems, and particularly relates to an operating system robustness testing method, device, equipment, medium and product. BACKGROUND

[0002] Robustness is the degree to which a system can operate correctly in the presence of incorrect or contradictory inputs, and is used to reflect the ability of a system to maintain stable operation of its functions in the face of changes in internal structure or external environment. The operating system occupies a major position in a complete system, and therefore, the robustness of the operating system is undoubtedly important to the entire system. Robustness testing is to evaluate the robustness behavior of a system under abnormal input conditions, and the purpose is to activate faults or vulnerabilities in the system that cause incorrect operation.

[0003] In related technologies, the influence of time delay on the operating system is ignored when the operating system is tested for robustness, resulting in unreliable test results of the robustness of the operating system. SUMMARY

[0004] The embodiments of the application provide an operating system robustness testing method, device, equipment, medium and product, which can solve the problem of unreliable test results of the robustness of the operating system.

[0005] In a first aspect, the embodiments of the application provide an operating system robustness testing method, comprising: injecting invalid input with a time delay into a kernel of a first operating system; at a time point of the time delay, executing a test case for testing the robustness of the first operating system to obtain an execution result of the test case; determining the robustness of the first operating system according to the execution result.

[0006] In a second aspect, the embodiments of the application provide an operating system robustness testing device, comprising: an invalid input injection module configured to inject invalid input with a time delay into a kernel of a first operating system; a test case execution module configured to, at a time point of the time delay, execute a test case for testing the robustness of the first operating system to obtain an execution result of the test case; a robustness determination module configured to determine the robustness of the first operating system according to the execution result.

[0007] In a third aspect, the embodiments of the application provide an electronic device, which comprises a processor and a memory storing computer program instructions; and the processor implements the operating system robustness testing method provided by the embodiments of the application when executing the computer program instructions.

[0008] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, and the computer readable storage medium stores computer program instructions. The computer program instructions are executed by a processor to implement the operating system robustness testing method provided by the embodiments of the present application.

[0009] In a fifth aspect, an embodiment of the present application provides a computer program product. Instructions in the computer program product are executed by a processor of an electronic device to cause the electronic device to perform the operating system robustness testing method provided by the embodiments of the present application.

[0010] In the embodiments of the present application, invalid input with a time delay is injected into the kernel of the first operating system. At the time point of the time delay, a test case for testing the robustness of the first operating system is executed to obtain an execution result of the test case. The robustness of the first operating system is determined according to the execution result. The influence of the time delay on the system application is evaluated by injecting the time delay into the kernel of the operating system. The introduction of the time delay makes the test more close to the actual application scenario, can effectively find the potential problems of the operating system in the time delay aspect, and can improve the reliability of the operating system robustness test result. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments of the present application. Those skilled in the art can obtain other drawings according to these drawings without any creative labor.

[0012] Figure 1 is a flowchart of the operating system robustness testing method provided by the embodiments of the present application; Figure 2 is a structural diagram of the operating system robustness testing device provided by the embodiments of the present application; Figure 3 is a structural diagram of the electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0013] The features and exemplary embodiments of each aspect of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application more clear, the following will further describe the present application in combination with the drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, but not to limit the present application. The present application can be implemented without some of these specific details by those skilled in the art. The following description of the embodiments is only to provide a better understanding of the present application by showing examples of the present application.

[0014] It should be noted that, in this document, the terms such as first and second are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between such entities or operations. Also, the terms "comprises", "comprising", or any other variations thereof are intended to cover a non-exclusive inclusion, so that a process, method, article, or apparatus that comprises a list of elements does not include only those elements recited, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more limitations, an element defined by the statement "comprising" does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0015] It should be noted that the acquisition, storage, use and processing of data in the embodiments of the present application comply with the relevant provisions of national laws and regulations.

[0016] It should be noted that in the embodiments of the present application, some industry existing solutions such as software, components, models, etc. may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0017] The operating system robustness testing method, device, equipment, medium and product provided by the embodiments of the present application will be described in detail below in combination with the accompanying drawings, specific embodiments and application scenarios.

[0018] Figure 1 is a flowchart of the operating system robustness testing method provided by the embodiments of the present application. As shown in Figure 1 , the operating system robustness testing method can include: Step 101: injecting invalid input with time delay into the kernel of the first operating system; In some embodiments of the present application, the first operating system in the embodiments of the present application is an operating system that needs to be tested for robustness.

[0019] In some embodiments of the present application, in step 101, invalid input with time delay can be injected into the kernel of the first operating system in different states of the first operating system, and each test is performed under the same working conditions as the initial stage.

[0020] In some embodiments of the present application, in step 101, invalid input injection can be performed when the first operating system reaches the predefined state of the behavior model with time automaton.

[0021] In some embodiments of this application, in step 101, invalid input with a time delay can be injected into the kernel of the first operating system by a test driver.

[0022] Step 102: When the time delay is reached, execute the test cases used to test the robustness of the first operating system and obtain the execution results of the test cases; In some embodiments of this application, a timer can be set for state transitions in a behavioral model with a time automaton. When the timer reaches the time point corresponding to the set delay time, the state transition is triggered, and test cases are executed to simulate the time delay in actual operation.

[0023] In some embodiments of this application, before step 101, the operating system robustness testing method provided in this application may further include: acquiring behavioral data of the first operating system running under fault-free conditions; wherein the behavioral data includes input and output interactions between various modules of the first operating system; and generating the test cases based on the behavioral data.

[0024] In some embodiments of this application, when the first operating system is running under fault-free conditions, behavioral data of the first operating system can be collected, mainly the interaction information between different tested modules.

[0025] In some embodiments of this application, the input and output interactions between modules can be recorded in detail during the execution of local functions of the module under test, ensuring that all key data flows and state changes can be captured. Precise timestamps are added to the start and end times of each interaction, with the time unit predefined according to testing requirements. Considering that different execution paths may affect the interaction time, multiple sets of data are collected by repeatedly executing the same task to improve the reliability and accuracy of the data.

[0026] In some embodiments of this application, generating test cases based on behavioral data may include: converting each interaction into a sequence; combining sequences corresponding to the same event to obtain sequence combinations; grouping sequence combinations with similarity greater than or equal to a similarity threshold into a group to obtain sequence combination clusters; generating a behavioral model with a time automaton for each sequence combination cluster; and using each injectable fault state transition in the behavioral model as a test case.

[0027] In some embodiments of this application, a sequence is defined as a set of temporally ordered events occurring during the execution of a single kernel function call. A sequence is a collection of temporally ordered events. These events are unique and non-concurrent within the sequence; that is, if events x and y occur in the sequence, either x precedes y, or y precedes x. A set of sequences resulting from the occurrence of a particular event belongs to only one sequence combination. A sequence combination is obtained by merging a set of sequences occurring at a certain time under different states. These combinations, incorporating all relevant events occurring under different states, construct diverse sequence combinations, with the diversity reflecting the behavioral characteristics of the system under different states.

[0028] A similarity function is defined to determine whether sequence combinations share similar behavioral characteristics by analyzing whether there is an intersection between events in different sequence combinations. Therefore, this similarity function can be used to quantify the similarity between event sequences in different sequence combinations, and cluster analysis can be performed on the generated sequence combinations to form sequence combination clusters with similar behavioral characteristics. This step helps simplify subsequent analysis processes and improve testing efficiency. Sequence combination clusters not only describe the system's state transitions but also associate the time and event relationships related to these state transitions. Event records containing timestamps are collected from the sequence combination clusters, and time dimension features, such as year, month, day, hour, minute, and second, are extracted from the timestamped event data. A finite set of states is defined based on the behavioral characteristics of the sequence combination clusters. By comparing the order of timestamps and event types, the transition conditions between states (i.e., event triggering conditions and time constraints) are identified. Using the extracted states and transition conditions, a behavioral model in the form of a time automaton is constructed. Furthermore, the case of time delays can be considered, thus more accurately reflecting the system's time characteristics in actual operation. Delays can also be calibrated and adjusted based on the timestamp information in the event sequences.

[0029] In some embodiments of this application, by generating test cases based on a time automata model, it can be ensured that the test cases can cover all possible states of the operating system.

[0030] In some embodiments of this application, a state setter can be used to generate state transitions. The state transitions are set as S = {s1, s2, ..., s...}. n}, where S is the set of states of the module being tested. i This is the i-th state of the model under test. To execute test cases, the state setter sets the state of the module under test to any one of the states in S. When testing a state, the state setter sets the state of the module under test to the state that needs to be tested.

[0031] In some embodiments of this application, the entity item of the module under test includes commonly used typical attributes, such as read / write permissions, execute permissions, and size. Combinations of different attribute identifiers inherited from the item constitute different types of sub-modules of the module under test, such as different types of files in a file system. The module under test typically uses resources such as caches and locks to manage the items. These resources are part of the internal state of the module under test and are not easily controlled, depending on the internal state, such as the number of tasks and CPU usage.

[0032] In the embodiments of this application, by simulating different states and abnormal inputs, the stability and reliability of the operating system under various conditions can be comprehensively evaluated.

[0033] Step 103: Determine the robustness of the first operating system based on the execution results.

[0034] In some embodiments of this application, after obtaining the execution results from the test user, the robustness of the operating system can be determined based on the execution results of the test cases.

[0035] In this embodiment, invalid input with a time delay is injected into the kernel of the first operating system. At the time point of the time delay, test cases for testing the robustness of the first operating system are executed, and the execution results of the test cases are obtained. Based on the execution results, the robustness of the first operating system is determined. By injecting a time delay into the operating system kernel to evaluate the impact of latency on system applications, the introduction of time delay makes the test closer to real-world application scenarios, effectively discovering potential latency issues in the operating system and improving the reliability of the operating system robustness test results.

[0036] In some embodiments of this application, the operating system robustness testing method provided in this application further includes: determining the time delay range corresponding to the time delay of the next injection of invalid input into the kernel by using a binary search method based on the first time of obtaining the execution result and the current injection deadline.

[0037] In some embodiments of this application, the step of determining the time delay range corresponding to the time delay of the next injection of invalid input into the kernel using a binary search method based on the first time of obtaining the execution result and the deadline corresponding to the current injection includes: if the first time is after the deadline corresponding to the current injection, determining the time delay range as the time delay from the start time corresponding to the current injection to the time delay corresponding to the current injection; if the first time is before the deadline corresponding to the current injection, determining the time delay range as the time delay from the time delay corresponding to the current injection to the deadline corresponding to the current injection.

[0038] In some embodiments of this application, the worst-case execution time of a test case is considered as the deadline for that test case. Changing the execution path of the program does not necessarily increase the execution time; the important thing is not to miss the deadline. Assuming x is a deadline for executing a test case in microseconds, the possible delay range is [0, x].

[0039] Let T2 be the start time for the i-th injection, T1 be the time delay for the i-th injection, and T3 be the end time for the i-th injection.

[0040] When the initial injection time is delayed, T2=0, T3=x, and the initial injection time delay is T1=x / 2.

[0041] When the injection time is delayed for the (i+1)th time, if the execution result of the i-th test case is obtained after the deadline corresponding to the i-th injection, then the range of the injection time delay for the (i+1)th time is from the start time T2 corresponding to the i-th injection to the time delay T1 corresponding to the i-th injection; if the execution result of the i-th test case is obtained before the deadline corresponding to the i-th injection, then the range of the injection time delay for the (i+1)th time is from the time delay T1 corresponding to the i-th injection to the deadline T3 corresponding to the i-th injection.

[0042] In some embodiments of this application, the operating system robustness testing method provided in this application further includes: when the first time is after the deadline corresponding to the current injection, determining the average of the start time corresponding to the current injection and the time delay corresponding to the current injection as the time delay for the next injection of invalid input into the kernel; when the first time is before the deadline corresponding to the current injection, determining the average of the time delay corresponding to the current injection and the deadline corresponding to the current injection as the time delay for the next injection of invalid input into the kernel.

[0043] In some embodiments of this application, when the (i+1)th injection time is delayed, if the execution result of the i-th test case is obtained after the deadline corresponding to the i-th injection, the start time corresponding to the (i+1)th injection is assigned the same as the start time corresponding to the i-th injection, and the deadline corresponding to the (i+1)th injection is assigned the same as the time delay corresponding to the i-th injection. The time delay corresponding to the (i+1)th injection is the average of the start time corresponding to the i-th injection and the time delay corresponding to the i-th injection. If the execution result of the i-th test case is obtained before the deadline corresponding to the i-th injection, the start time corresponding to the (i+1)th injection is assigned the same as the time delay corresponding to the i-th injection, and the deadline corresponding to the (i+1)th injection is assigned the same as the deadline corresponding to the i-th injection. The time delay corresponding to the (i+1)th injection is the average of the time delay corresponding to the i-th injection and the deadline corresponding to the i-th injection.

[0044] This application also provides an operating system robustness testing device, such as... Figure 2 As shown. Figure 2 This is a schematic diagram of the structure of the operating system robustness testing device provided in this application embodiment. The operating system robustness testing device 200 may include: Invalid input injection module 201 is used to inject invalid input with time delay into the kernel of the first operating system; The test case execution module 202 is used to execute test cases for testing the robustness of the first operating system when the time delay point is reached, and obtain the execution results of the test cases; The robustness determination module 203 is used to determine the robustness of the first operating system based on the execution results.

[0045] In this embodiment, invalid input with a time delay is injected into the kernel of the first operating system. At the time point of the time delay, test cases for testing the robustness of the first operating system are executed, and the execution results of the test cases are obtained. Based on the execution results, the robustness of the first operating system is determined. By injecting a time delay into the operating system kernel to evaluate the impact of latency on system applications, the introduction of time delay makes the test closer to real-world application scenarios, effectively discovering potential latency issues in the operating system and improving the reliability of the operating system robustness test results.

[0046] In some embodiments of this application, the operating system robustness testing apparatus provided in this application further includes: The first determining module is used to determine the time delay range corresponding to the time delay of the next injection of invalid input into the kernel, based on the first time of obtaining the execution result and the current injection deadline, using a binary search method.

[0047] In some embodiments of this application, the determining module is specifically used for: If the first time is after the deadline corresponding to the current injection, the time delay range is determined to be from the start time corresponding to the current injection to the time delay corresponding to the current injection. If the first time is before the deadline corresponding to the current injection, the time delay range is determined to be from the time corresponding to the current injection to the deadline corresponding to the current injection.

[0048] In some embodiments of this application, the operating system robustness testing apparatus provided in this application further includes: The first determining module is configured to, when the first time is after the deadline corresponding to the current injection, determine the average of the start time and the time delay corresponding to the current injection as the time delay for the next injection of invalid input into the kernel; and when the first time is before the deadline corresponding to the current injection, determine the average of the time delay and the deadline corresponding to the current injection as the time delay for the next injection of invalid input into the kernel.

[0049] In some embodiments of this application, the operating system robustness testing apparatus provided in this application further includes: The acquisition module is used to acquire behavioral data of the first operating system when it is running under fault-free conditions; wherein, the behavioral data includes input and output interactions between various modules of the first operating system; The generation module is used to generate the test cases based on the behavioral data.

[0050] In some embodiments of this application, the generation module is specifically used for: Convert each interaction into a sequence; Combining sequences corresponding to the same event yields a sequence combination; Sequence combinations with a similarity greater than or equal to a similarity threshold are grouped together to obtain sequence combination clusters; Generate a behavioral model with a time automaton for each sequence combination cluster; Each injectable fault state transition in the behavioral model is used as a test case.

[0051] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application.

[0052] Electronic device 300 may include processor 301 and memory 302 storing computer program instructions.

[0053] Specifically, the processor 301 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0054] Memory 302 may include mass storage for data or instructions. For example, and not limitingly, memory 302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where suitable, memory 302 may include removable or non-removable (or fixed) media. Where suitable, memory 302 may be internal or external to an electronic device. In some specific embodiments, memory 302 is a non-volatile solid-state memory.

[0055] In some specific embodiments, the memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the operating system robustness testing method provided according to embodiments of this application.

[0056] The processor 301 reads and executes computer program instructions stored in the memory 302 to implement the operating system robustness testing method provided in this application embodiment.

[0057] In some embodiments of this application, the electronic device may further include a communication interface 303 and a bus 310. For example... Figure 3 As shown, the processor 301, memory 302, and communication interface 303 are connected through bus 310 and complete communication with each other.

[0058] The communication interface 303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0059] Bus 310 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0060] The electronic device can execute the operating system robustness testing method provided in the embodiments of this application, thereby achieving the corresponding technical effects of the operating system robustness testing method provided in the embodiments of this application.

[0061] In addition, in conjunction with the operating system robustness testing method in the above embodiments, this application also provides a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement the operating system robustness testing method provided in this application. Examples of computer-readable storage media include non-transitory computer-readable media, such as ROM, RAM, magnetic disks, or optical disks.

[0062] This application provides a computer program product. When the instructions in the computer program product are executed by the processor of an electronic device, the electronic device executes the operating system robustness testing method provided in this application and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0063] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0064] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0065] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0066] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0067] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method of operating system robustness testing, the method comprising: The method comprises: injecting invalid input with a time delay into a kernel of a first operating system; at a time point of reaching the time delay, executing a test case for testing robustness of the first operating system, to obtain an execution result of the test case; determining robustness of the first operating system according to the execution result.

2. The method of claim 1, wherein, The method further comprises: determining a time delay range corresponding to a time delay of next injection of invalid input into the kernel according to a first time of obtaining the execution result and a deadline corresponding to current injection, by using a dichotomy.

3. The method of claim 2, wherein, The determining a time delay range corresponding to a time delay of next injection of invalid input into the kernel according to a first time of obtaining the execution result and a deadline corresponding to current injection, by using a dichotomy, comprises: in a case that the first time is after the deadline corresponding to current injection, determining that the time delay range is from a start time corresponding to current injection to the time delay corresponding to current injection; in a case that the first time is before the deadline corresponding to current injection, determining that the time delay range is from the time delay corresponding to current injection to the deadline corresponding to current injection.

4. The method of claim 3, wherein, The method further comprises: in a case that the first time is after the deadline corresponding to current injection, determining the time delay of next injection of invalid input into the kernel as an average of the start time corresponding to current injection and the time delay corresponding to current injection; in a case that the first time is before the deadline corresponding to current injection, determining the time delay of next injection of invalid input into the kernel as an average of the time delay corresponding to current injection and the deadline corresponding to current injection.

5. The method of claim 1, wherein, Before the injecting invalid input with a time delay into a kernel of a first operating system, the method further comprises: obtaining behavior data of the first operating system running under a fault-free condition; wherein the behavior data comprises input and output interaction between each module of the first operating system; generating the test case according to the behavior data.

6. The method of claim 5, wherein, The generating the test case according to the behavior data comprises: converting each interaction into a sequence; combining sequences corresponding to a same event to obtain sequence combinations; dividing sequence combinations with a similarity greater than or equal to a similarity threshold into a group to obtain sequence combination clusters; generating a behavior model with a time automaton for each sequence combination cluster; taking each state transition of each injectable fault in the behavior model as a test case.

7. An operating system robustness testing apparatus, characterized by, The apparatus comprises: an invalid input injection module configured to inject invalid input with a time delay into a kernel of a first operating system; a test case execution module configured to execute a test case for testing robustness of the first operating system at a time point of reaching the time delay, to obtain an execution result of the test case; a robustness determination module configured to determine robustness of the first operating system according to the execution result.

8. An electronic device, comprising: The electronic device comprises a processor and a memory storing computer program instructions; The processor reads and executes the computer program instructions to implement the operating system robustness testing method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer program instructions are stored on the computer readable storage medium and are executed by the processor to implement the operating system robustness testing method according to any one of claims 1-6.

10. A computer program product, characterised in that, The instructions in the computer program product are executed by the processor of the electronic device to enable the electronic device to perform the operating system robustness testing method according to any one of claims 1-6.

Images