A Random Testing Method and System for Embedded Software Interface Message Testing

Abstract

The present invention relates to a random testing method and system for embedded software interface message testing. The method includes the following steps: Step 1: According to the interface message protocol of the embedded software object to be tested, describe the interface message body in a set scripting language, and determine the assignment strategy for each field in the message body; Step 2: According to the input test strategy, select a test working mode for testing the interface message; Step 3: According to the selected test working mode, simulate a communication object to send a message sequence to the object to be tested; Step 4: Receive and parse the message of the object to be tested, and record the feedback on the message sent by the simulated communication object as a decision factor for sending messages later. Compared with the prior art, the present invention has the advantages of cost-free and rapid switching back and forth between various different test strategies, etc.

Description

Technical Field

[0001] The present invention relates to the testing technology of embedded software, and in particular, to a random testing method and system for testing the interface messages of embedded software. Background Art

[0002] The interface message testing of embedded software is a time-consuming and costly task. Research shows that the testing cost can reach more than 40% of the total software development process cost. Generally, there are many message interface protocols for embedded software, ranging from several to dozens. Among them, the testing of message interfaces has the characteristics of long-term continuity, large data generation, and poor testability. At the same time, embedded software has extremely high requirements for robustness and a large demand for fault simulation in testing. Currently, the interface message testing of embedded software is mainly carried out by manually designing fault scenarios, manually switching different testing strategies, and manually checking the feedback results of the object under test. Therefore, a huge amount of human and time costs need to be invested in the interface message testing stage. If a systematic and efficient random testing solution for embedded software interface message testing can be established, a large amount of testing manpower and time can be saved.

[0003] In view of the above problems, how to implement an interface message testing method that enables testers to easily describe messages, make purposeful decisions on the output of each step without the participation of testers, quickly locate the anomalies in the feedback of the object under test, and switch between various different testing strategies without cost and quickly has become a technical problem to be solved. Summary of the Invention

[0004] The purpose of the present invention is to overcome the above-mentioned defects existing in the prior art and provide a random testing method and system for testing the interface messages of embedded software, which solves the problems of incomplete design of fault scenarios, inconvenient switching of testing strategies, easy mistakes in checking feedback results, and high consumption of manpower and time in the process of interface message testing of embedded software in the prior art.

[0005] The purpose of the present invention can be achieved by the following technical solutions:

[0006] According to the first aspect of the present invention, a random testing method for testing the interface messages of embedded software is provided. The method includes the following steps:

[0007] Step 1: According to the interface message protocol of the embedded software object to be tested, describe the interface message body in a set scripting language, and determine the assignment strategy for each field in the message body;

[0008] Step 2: Select a test working mode for testing the interface message according to the input test strategy;

[0009] Step 3: According to the selected test working mode, simulate the communication object to send a message sequence to the object under test;

[0010] Step 4: Receive and parse the messages of the object under test, and record the feedback on the messages sent to the simulated communication object as a decision factor for sending messages later.

[0011] As a preferred technical solution, the embedded software under test in this random test method works in an interconnected open environment, and its interface message communication works on top of the ISO / OSI protocol stack, independent of the specific physical connection.

[0012] As a preferred technical solution, the set scripting languages in Step 1 include XML, JSON, and configuration files in a custom format.

[0013] As a preferred technical solution, the assignment strategy for each field in the message body in Step 1 includes a three-level priority message field assignment strategy, namely:

[0014] Container level, with the highest priority, modify specific message fields offline or forcefully modify specific message fields online to inject faults or simulate special scenarios;

[0015] Setting level, with a lower priority than the container level, that is, if the same field of a message is modified at both the container level and the setting level, the modification at the container level shall prevail;

[0016] Default level, with a lower priority than the setting level, and the definition of the priority is the same as that described in the setting level; directly set the initial value of the message field at the default level, and if there is no assignment at the setting level and the container level, it shall be maintained continuously.

[0017] As a preferred technical solution, the setting level includes multiple field modification methods, specifically: directly using simple logic, using custom functions, using message references, and using project custom configurations.

[0018] As a preferred technical solution, the message reference at the setting level refers to grabbing specific fields from the messages returned by the object under test as the values of specific fields in the messages to be sent for setting.

[0019] As a preferred technical solution, the project custom configuration at the setting level refers to setting only the set parameters bound to the set project without modifying other configurations and the simulator of the test platform, so as to achieve the purpose of testing the message interface.

[0020] As a preferred technical solution, the test working modes in Step 2 include: burn-in mode, extreme mode, single-point fault mode, random fault mode, and hybrid mode;

[0021] The described baking machine mode refers to continuously performing interface message testing on the object under test according to the longest working time of the object under test required in the superior's requirements.

[0022] The described extreme mode refers to performing interface message testing on the object under test according to the maximum number of concurrent communications required for the object under test in the superior's requirements.

[0023] The described single-point failure mode refers to performing interface message testing by setting the failure assignment of a single field through the value assignment strategy of the fields in the message body.

[0024] The described random failure mode refers to performing interface message testing by setting the failure assignment of a single field or multiple fields through the value assignment strategy of the fields in the message body.

[0025] The described hybrid mode refers to combining two or more of the above test working modes in pairs or in multiple combinations to perform interface message testing.

[0026] As a preferred technical solution, during the baking machine mode, special processing needs to be performed on the generated records.

[0027] As a preferred technical solution, the sending message sequence in step 3 specifically includes the following steps:

[0028] Step 31, confirm the test working mode being in.

[0029] Step 32, record the sent failure mode and record the feedback message situation of the object under test.

[0030] Step 33, determine the next random value according to the test working mode being in, the sent failure mode, and the feedback message situation of the object under test.

[0031] As a preferred technical solution, receiving and parsing the message of the object under test in step 4 includes checking for errors and catching exceptions:

[0032] The described checking for errors refers to checking whether each field in the message returned by the object under test is within the specified value range according to the superior's requirements and the interface definition.

[0033] The described catching exceptions refers to checking whether the object under test returns an alarm error message, whether there is an abnormal time interval for the returned message, and whether there is a suspected downtime phenomenon of not returning a heartbeat packet.

[0034] According to the second aspect of the present invention, there is provided a system for the random test method for embedded software interface message testing, and the system includes:

[0035] A message definition module, which is used to describe the message body of the interface message in a set scripting language;

[0036] A receiving and sending module, which is used to receive the messages sent by the object under test, generate response messages according to the test working mode and feedback strategy, and send them to the object under test;

[0037] A random generation module, which generates random values for field assignment, random fault mode, and hybrid mode setting;

[0038] A feedback decision module, which is used to judge the feedback of the object under test and determine the next sending strategy;

[0039] A message recording module, which is used to record the generated messages and the received messages, and the recording strategy can be configured according to the test working mode.

[0040] As a preferred technical solution, the message definition module includes:

[0041] A container setting unit, which is used to modify specific message fields offline or forcefully modify specific message fields online to inject faults or simulate special scenarios, and has the highest priority for setting field values;

[0042] A value setting unit, which has the second highest priority for setting field values; includes multiple field modification methods: directly using simple logic, using custom functions, using message references, and using project custom configurations;

[0043] A default value setting unit, which is used to directly set the initial values of message fields. If there is no assignment at the level and container level, it will be continuously maintained, and has the lowest priority for setting field values.

[0044] As a preferred technical solution, the message reference of the value setting unit refers to capturing a set field from the message returned by the object under test as the value of the set field in the message to be sent.

[0045] As a preferred technical solution, the project custom configuration of the value setting unit refers to setting specific parameters bound to a specific project without modifying other configurations and the simulator of the test platform, so as to achieve the purpose of testing the message interface.

[0046] As a preferred technical solution, the receiving and sending module includes:

[0047] An error correction unit, which is used to check whether each field in the message returned by the object under test is within the specified value range according to the superior requirements and interface definition;

[0048] An exception capture unit, which is used to check whether the object under test returns alarm error messages, whether there are abnormal time intervals of returned messages, and whether there is a suspected downtime phenomenon of not returning heartbeat packets;

[0049] A working mode unit, which is used to record the fault mode of the sent fault message, judge the current test working mode, and send the output generated by the feedback decision module.

[0050] As a preferred technical solution, the fault modes include: boundary values of fields, values outside the value range of fields, illegal fields, error checking values, and duplicate timestamps;

[0051] The test working modes include a burn-in mode, an extreme mode, a single-point fault mode, a random fault mode, and a mixed mode.

[0052] As a preferred technical solution, the random occurrence module uses a pseudo-random number generation algorithm based on a finite state machine, and it works at three levels:

[0053] Random value selection during fault injection of message body field values;

[0054] Random combination of fault fields in the random fault working mode;

[0055] In the mixed mode, it is a mixture of the concurrent working mode and the random fault mode, and a random combination of fault simulation devices is selected.

[0056] As a preferred technical solution, the feedback decision module consists of a customized feedback system.

[0057] The inputs of the feedback system include: the feedback response message of the object under test, the sent messages, and the working mode.

[0058] The output of the feedback system is the generated message sequence.

[0059] The processing logic of the feedback system consists of the following policy algorithms:

[0060] If the feedback response of the object under test is normal, continue to send the message sequence according to the working mode;

[0061] If the feedback response of the object under test is abnormal, select different policies according to the configuration, including:

[0062] Stop the interface message test;

[0063] Continue to send the message sequence according to the working mode. If currently in the fault working mode, continuously send the message sequence to check whether the object under test has a suspected crash;

[0064] And regardless of the working mode, first send normal non-fault interface messages to check whether the object under test recovers; if it recovers, continue to send the message sequence according to the working mode; if it does not recover, stop the interface message test.

[0065] As an optimal technical solution, the message recording module includes multiple compression strategies, including no compression, DEFLATE algorithm compression, LZMA2 algorithm compression and differential storage; the message recording compression strategy is configured when the test working mode is selected; and differential storage is used by default in the baking working mode.

[0066] According to a third aspect of the present invention, there is provided an electronic device, comprising a memory and a processor, wherein a computer program is stored in the memory, and the method described above is implemented when the processor executes the program.

[0067] According to a fourth aspect of the present invention, there is provided a computer-readable storage medium having a computer program stored thereon, wherein the program implements the method described when executed by a processor.

[0068] Compared with the prior art, the present invention has the following advantages:

[0069] 1) The present invention realizes an interface message testing method that can facilitate testers to describe messages conveniently, can purposefully decide the output of each step without the participation of testers, can quickly locate the abnormalities fed back by the tested object, and can switch back and forth between various test strategies without cost and quickly;

[0070] 2) The present invention supports multiple test working modes in the same system, and each working mode can be switched at no cost, thus overcoming the drawbacks of switching test strategies and test environments in the prior art, which is time-consuming and labor-intensive;

[0071] 3) The present invention designs a self-feedback system and a random value mechanism, which can purposefully decide the output of each step without the participation of testers, overcoming the defect of incomplete fault design by workers in the prior art;

[0072] 4) The present invention designs automatic error correction and abnormal capture and storage marks, which overcomes the defect of manual inspection feedback results in the prior art that are prone to errors. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] Figure 1 It is a flow chart of a random testing method for embedded software interface message testing of the present invention;

[0074] Figure 2 A schematic diagram of a detailed flow of a random test for an embedded software interface message test according to the present invention;

[0075] Figure 3 The diagram is a schematic diagram of a random test feedback strategy for embedded software interface message testing according to the present invention. DETAILED DESCRIPTION

[0076] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0077] The following will further describe in detail the random test method for embedded software interface message testing proposed by the present invention in conjunction with the attached Figure 1 , the attached Figure 2 and the attached Figure 3 For the random test method for embedded software interface message testing proposed by the present invention, it will be further described in detail. According to the following description, the advantages and features of the present invention will be clearer. It should be noted that the attached drawings are in a very simplified form and all use non-precise scales, only for the purpose of conveniently and clearly assisting in explaining the embodiments of the present invention. In order to make the purpose, features, and advantages of the present invention more obvious and understandable, please refer to the attached drawings. It should be noted that the structures, scales, sizes, etc. shown in the drawings of this specification are only used to cooperate with the content disclosed in the specification for those who are familiar with this technology to understand and read, and are not used to limit the limiting conditions for the implementation of the present invention. Therefore, they do not have technical substance significance. Any modification of the structure, change of the proportional relationship, or adjustment of the size, without affecting the effects that the present invention can produce and the purposes that can be achieved, should still fall within the scope covered by the technical content disclosed by the present invention.

[0078] To overcome the deficiencies existing in the existing embedded software interface message testing methods, this embodiment provides a random test method for embedded software interface message testing, including:

[0079] Step S1: According to the interface message protocol of the embedded software object to be tested, describe the interface message body in a scripting language, and determine the assignment strategy for each field in the message body; the scripting language can be any one of XML, JSON, and configuration files in a custom format;

[0080] Step S1.1: Based on the interface message body described in the scripting language, set a default value for each field. This default value is a required item and must be used during test initialization, otherwise the system will report an error; the field assignment value set by the default value has the lowest priority;

[0081] Step S1.2: Based on the interface message body described in the scripting language with the field default values set, configure set values for the fields that need them. Here, "need them" means for automated interface message testing to make the lightweight interface simulation have certain logical functions; this set value can be empty, and when it is empty, it does not affect the normal operation of the system; the methods for configuring set values include: directly using simple logic, using custom functions, using message references, and using project custom configurations; the priority of configuring field set values is the second highest;

[0082] Step S1.3: Based on the interface message body described in the scripting language with field default values and set values configured, set container values for fields in need, where "in need" refers to the faults or special scenario simulations required by the test requirements; the container value can be empty, and when it is empty, it does not affect the normal operation of the system; the container value can be set offline or the container value can be forced online, and the priority of setting the field value of the container is the highest;

[0083] Step S1.4: Configure the check rules for each field in the message body. Here, the check rules refer to the value range of this field according to the interface protocol for verifying its correctness when receiving the message.

[0084] Step S2: Select a test working mode for testing the interface message according to the input test strategy;

[0085] Step S2.1: Select a test working mode according to the actual test requirements and test strategy; the test working modes here include: burn-in mode, extreme mode, single-point fault mode, random fault mode, and hybrid mode;

[0086] Step S2.2: Configure the compression strategy for message records;

[0087] Step S3: According to the selected test working mode, simulate the communication object to send a message sequence to the object under test;

[0088] Step S3.1: Call the feedback decision module to calculate the message sequence to be sent; for the processing logic of the feedback decision module, please refer to the appendix Figure 3 ;

[0089] Step S3.2: Record the message sequence sent to the object under test calculated by the feedback decision module; when a fault injection occurs, record the fault mode at the same time. The fault modes here include: boundary values of fields, values outside the value range of fields, illegal fields, error check values, duplicate timestamps, and other faults; as the input for the next calculation of the feedback decision module.

[0090] Step S4: Receive and parse the message of the object under test, and record the feedback of the object under test to the message sent by the simulated communication device as a decision factor for sending messages later.

[0091] Step S4.1: First store and record the feedback message of the response received from the object under test as the input for the feedback decision module;

[0092] Step S4.2: At the same time, verify whether the value of each field in the received message is within the specified range. Here, the specified source for reference is the superior requirements and interface definition, and the verification rules can be pre-compiled when describing the message body;

[0093] Step S4.3: Meanwhile, check whether the received message contains an alarm error message, whether there is an abnormal time interval for the return message, and whether there is a suspected downtime phenomenon such as not returning a heartbeat packet. If any of the above anomalies are detected, append an anomaly identifier to the record in Step S4.1.

[0094] The above is the introduction of the method embodiment. The following further illustrates the solution of the present invention through a system embodiment.

[0095] A random test system for embedded software interface message testing, used to implement the above-mentioned random test method for embedded software interface message testing, includes:

[0096] A message definition module, used to describe the message body of the interface message in a specific scripting language;

[0097] A receive and send module, used to receive the message sent by the object under test, generate a response message according to the test working mode, feedback strategy, etc., and send it to the object under test;

[0098] A random generation module, which generates random values for field assignment, random failure modes, and hybrid modes;

[0099] A feedback decision module, used to judge the feedback of the object under test and determine the next sending strategy;

[0100] A message recording module, used to record the generated messages and the received messages, and the recording strategy can be configured according to the test working mode.

[0101] In the described random test system, the embedded software under test works in an interconnected open environment, and its interface message communication works above the ISO / OSI protocol stack and is independent of the specific physical connection.

[0102] The described message definition module includes;

[0103] A container setting unit, which can modify specific message fields offline or forcefully modify specific message fields online, used to inject faults or simulate special scenarios, and has the highest priority for setting field values;

[0104] A value setting unit, which has the second highest priority for setting field values; includes multiple field modification methods: directly using simple logic, using custom functions, using message references, and using project custom configurations;

[0105] A default value setting unit, which can directly set the initial value of the message field, and if there is no assignment at the level and container level, it will be continuously maintained, and has the lowest priority for setting field values.

[0106] The message reference of the value setting unit refers to grabbing a specific field from the message returned by the object under test as the value for setting a specific field in the sent message;

[0107] The item custom configuration of the value setting unit refers to setting only the specific parameters bound to a specific project without modifying other configurations, the test platform, or the simulator of the test platform, for the purpose of testing the message interface;

[0108] The specific scripting language mentioned above can be XML, JSON, and configuration files in custom formats.

[0109] The receiving and sending module includes;

[0110] An error correction unit that checks whether each field in the message returned by the object under test is within the specified value range according to the superior requirements and interface definitions;

[0111] An exception capture unit that checks whether the object under test returns alarm error messages, whether there are abnormal time intervals in the returned messages, and whether there is a suspected downtime phenomenon of not returning heartbeat packets.

[0112] A working mode unit that records the fault modes of the sent fault messages, determines the current test working mode, and sends the output generated by the feedback decision module.

[0113] The fault modes mentioned above include: boundary values of fields, values outside the field value range, illegal fields, error checking values, duplicate timestamps, and other faults;

[0114] The test working modes include burn-in mode, extreme mode, single-point fault mode, random fault mode, and hybrid mode.

[0115] The random occurrence module uses a pseudo-random number generation algorithm based on a finite state machine, and it works at three levels:

[0116] Random value selection during fault injection of message body field values;

[0117] Random combination of fault fields in the random fault working mode;

[0118] In the hybrid mode, it is a hybrid of the concurrent working mode and the random fault mode, and a random combination of fault simulation devices is selected;

[0119] The feedback decision module consists of a customized feedback system:

[0120] The inputs of the feedback system mentioned above include the feedback response message of the object under test, the sent messages, and the working mode;

[0121] The output of the feedback system is the generated message sequence;

[0122] The processing logic of the feedback system consists of the following policy algorithms:

[0123] If the feedback response of the object under test is normal, continue to send the message sequence according to the working mode;

[0124] If the feedback response of the object under test is abnormal, select different policies according to the configuration, including:

[0125] Stop the interface message test;

[0126] Continue to send the message sequence according to the working mode. If it is currently in the fault working mode, continuously send the message sequence to check whether the object under test has a suspected crash;

[0127] And regardless of the working mode, first send normal non-fault interface messages to check whether the object under test has recovered; if it has recovered, continue to send the message sequence according to the working mode.

[0128] The message recording module includes a variety of compression policies:

[0129] Including no compression, compression by the DEFLATE algorithm, compression by the LZMA2 algorithm, and differential storage; the message recording compression policy can be configured when selecting the test working mode;

[0130] Differential storage is used by default in the burn-in working mode.

[0131] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working process of the described module can refer to the corresponding process in the foregoing method embodiment and will not be elaborated herein.

[0132] The electronic device of the present invention includes a central processing unit (CPU), which can execute various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) or computer program instructions loaded from a storage unit into a random access memory (RAM). In the RAM, various programs and data required for device operation can also be stored. The CPU, ROM, and RAM are connected to each other through a bus. An input / output (I / O) interface is also connected to the bus.

[0133] Multiple components in the device are connected to the I / O interface, including: an input unit, such as a keyboard, a mouse, etc.; an output unit, such as various types of displays, speakers, etc.; a storage unit, such as a disk, an optical disc, etc.; and a communication unit, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit allows the device to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0134] The processing unit executes the various methods and processes described above, such as methods S1 to S4. For example, in some embodiments, methods S1 to S4 may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed onto the device via the ROM and / or the communication unit. When the computer program is loaded into the RAM and executed by the CPU, one or more steps of methods S1 to S4 described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute methods S1 to S4 by any other suitable means (e.g., by means of firmware).

[0135] The functions described above herein can be performed at least in part by one or more hardware logic components. By way of example and not limitation, the types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system on a chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0136] The program code for implementing the methods of the present invention may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, a special purpose computer, or other programmable data processing device, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on the machine, partially on the machine, as a stand-alone software package partially on the machine and partially on a remote machine, or entirely on the remote machine or server.

[0137] In the context of the present invention, a machine-readable medium may be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0138] As described above, it is only the specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of various equivalent modifications or substitutions, and these modifications or substitutions should all be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A random testing method for embedded software interface message testing, characterized in that, The method includes the following steps: Step 1: According to the interface message protocol of the embedded software object to be tested, describe the interface message body in a set scripting language, and determine the assignment strategy for each field in the message body; Step 2: Select a test working mode for testing the interface message according to the input test strategy; Step 3: According to the selected test working mode, simulate the communication object to send a message sequence to the object to be tested; Step 4: Receive and parse the message of the object to be tested, and record the feedback on the message sent to the simulated communication object as a decision factor for sending messages later; The assignment strategy for each field in the message body in Step 1 includes a three-level priority message field assignment strategy, namely: Container level, with the highest priority, modify specific message fields offline or forcefully modify specific message fields online to inject faults or simulate special scenarios; Setting level, with a lower priority than the container level, that is, if the same field of the message is modified at both the container level and the setting level, the modification at the container level shall prevail; Default level, with a lower priority than the setting level, and the definition of the priority is the same as that described in the setting level; directly set the initial value of the message field at the default level, and keep it continuously if there is no assignment at the setting level and the container level; The test working modes in Step 2 include: burn-in mode, extreme mode, single-point fault mode, random fault mode, and mixed mode; The so-called burn-in mode refers to continuously testing the interface messages of the object to be tested according to the longest working time required for the object to be tested in the superior requirements; The so-called extreme mode refers to testing the interface messages of the object to be tested according to the maximum number of concurrent communications required for the object to be tested in the superior requirements; The so-called single-point fault mode refers to setting the fault assignment of a single field through the assignment strategy of the fields in the message body to perform interface message testing; The so-called random fault mode refers to setting the fault assignment of a single or multiple fields through the assignment strategy of the fields in the message body to perform interface message testing; The so-called mixed mode refers to combining two or more of the above test working modes in pairs to perform interface message testing; The specific steps of the message sequence sent in Step 3 include the following steps: Step 31, confirm the test working mode; Step 32, record the sent fault mode and record the feedback message situation of the object to be tested; Step 33, determine the next random value according to the test working mode, the sent fault mode, and the feedback message situation of the object to be tested.

2. The random test method for embedded software interface message testing according to claim 1, characterized in that The embedded software to be tested in this random test method works in an interconnected open environment, and its interface message communication works above the ISO / OSI protocol stack and has nothing to do with the specific physical connection.

3. A random testing method for embedded software interface message testing according to claim 1, characterized in that, The set scripting language in Step 1 includes XML, JSON, and configuration files in a custom format.

4. A random testing method for embedded software interface message testing according to claim 1, characterized in that The setting level includes multiple field modification methods, specifically: directly using simple logic, using custom functions, using message references, and using project custom configurations.

5. A random testing method for embedded software interface message testing according to claim 1, characterized in that, The message reference at the setting level refers to capturing specific fields from the messages returned by the object under test as the values of specific fields in the setting send messages.

6. A random testing method for embedded software interface message testing according to claim 1, characterized in that The item custom configuration at the setting level means that without modifying other configurations and the simulator of the test platform, only the setting parameters bound to the set items are set to achieve the purpose of testing the message interface.

7. A random testing method for embedded software interface message testing according to claim 1, characterized in that In the burn-in mode, special processing needs to be done on the generated records.

8. A random testing method for embedded software interface message testing according to claim 1, characterized in that Receiving and parsing the messages of the object under test in step 4 includes error checking and exception catching: The error checking mentioned above refers to checking whether each field in the message returned by the object under test is within the specified value range according to the superior requirements and interface definitions. The exception catching mentioned above refers to checking whether the object under test returns alarm error messages, whether there are abnormal time intervals for the returned messages, and whether there is a suspected downtime phenomenon of not returning heartbeat packets.

9. A system for the random testing method of the embedded software interface message test according to claim 1, characterized in that, The system includes: A message definition module for describing the message body of the interface message in a set scripting language. A receive and send module for receiving the messages sent by the object under test, generating response messages according to the test working mode and feedback strategy, and sending them to the object under test. A random generation module that generates random values for field assignment, random failure mode, and hybrid mode setting. A feedback decision module for judging the feedback of the object under test and determining the next sending strategy. A message recording module for recording the generated messages and the received messages, and the recording strategy can be configured according to the test working mode.

10. The system according to claim 9, wherein The message definition module includes: A container setting unit for offline modifying specific message fields or online forcibly modifying specific message fields to inject faults or simulate special scenarios, and the priority of setting field values is the highest. A value setting unit for setting the field value with the second highest priority; it includes various field modification methods: directly using simple logic, using custom functions, using message reference, and using item custom configuration. A default value setting unit for directly setting the initial values of message fields, which will be continuously maintained if there is no assignment at the setting level and container level, and the priority of setting field values is the lowest.

11. The system according to claim 10, wherein The message reference of the value setting unit refers to capturing the set fields from the messages returned by the object under test as the values of the set fields in the setting send messages.

12. The system according to claim 10, wherein The item custom configuration of the value setting unit means that without modifying other configurations and the simulator of the test platform, only the specific parameters bound to specific items are set to achieve the purpose of testing the message interface.

13. The system according to claim 9, wherein The receive and send module includes: An error checking unit for checking whether each field in the message returned by the object under test is within the specified value range according to the superior requirements and interface definitions. An exception catching unit for checking whether the object under test returns alarm error messages, whether there are abnormal time intervals for the returned messages, and whether there is a suspected downtime phenomenon of not returning heartbeat packets. A working mode unit for recording the failure mode of the sent failure messages, judging the current test working mode, and sending the output generated by the feedback decision module.

14. The system according to claim 13, wherein, The fault modes include: boundary values of fields, values outside the value range of fields, illegal fields, error check values, and duplicate timestamps; The described test working modes include a burn-in mode, an extreme mode, a single-point fault mode, a random fault mode, and a mixed mode.

15. The system according to claim 9, wherein The random occurrence module uses a pseudo-random number generation algorithm based on a finite state machine, and it works at three levels: Random value selection during fault injection of message body field values; Random combination of fault fields in the random fault working mode; In the mixed mode, it is a mixture of the concurrent working mode and the random fault mode, and a random combination of fault simulation devices is selected.

16. The system according to claim 9, wherein The feedback decision module consists of a customized feedback system, The inputs of the described feedback system include: the feedback response message of the object under test, the messages that have been sent, and the working mode; The output of the described feedback system is the generated message sequence; The processing logic of the described feedback system consists of the following policy algorithms: If the feedback response of the object under test is normal, continue to send the message sequence according to the working mode; If the feedback response of the object under test is abnormal, select different policies according to the configuration, including: Stop the interface message test; Continue to send the message sequence according to the working mode. If it is currently in the fault working mode, continuously send the message sequence and check whether the object under test has a suspected crash; And regardless of the working mode, first send normal non-fault interface messages to check whether the object under test recovers; if it recovers, continue to send the message sequence according to the working mode; if it does not recover, stop the interface message test.

17. The system according to claim 9, characterized in that The message recording module includes various compression strategies, including no compression, compression by the DEFLATE algorithm, compression by the LZMA2 algorithm, and differential storage; the message recording compression strategy is configured when selecting the test working mode; differential storage is used by default in the burn-in working mode.

18. An electronic device, comprising a memory and a processor, wherein a computer program is stored on the memory, characterized in that, When the processor executes the program, it implements the method described in any one of claims 1 to 8.

19. 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 method described in any one of claims 1 to 8.

Images