CN114706748A

CN114706748A - Random test method and system for embedded software interface message test

Info

Publication number: CN114706748A
Application number: CN202210185626.9A
Authority: CN
Inventors: 陈硕豪; 熊坤鹏; 朱程辉; 刘锦峰
Original assignee: Casco Signal Ltd
Current assignee: Casco Signal Ltd
Priority date: 2022-02-28
Filing date: 2022-02-28
Publication date: 2022-07-05

Abstract

The invention relates to a random test method and a system for testing embedded software interface messages, wherein the method comprises the following steps: step 1: according to an interface message protocol of an embedded software object to be tested, describing an interface message body by a set script language, and determining an assignment strategy of each field in the message body; step 2: selecting a test working mode of a test interface message according to an input test strategy; and step 3: simulating a communication object to send a message sequence to the tested object according to the selected test working mode; and 4, step 4: and receiving and analyzing the message of the tested object, and recording the feedback of the message sent by the analog communication object as a decision factor for sending the message later. Compared with the prior art, the method has the advantages of no cost, quick switching back and forth among various different test strategies and the like.

Description

Random test method and system for embedded software interface message test

Technical Field

The invention relates to a testing technology of embedded software, in particular to a random testing method and a system for testing embedded software interface messages.

Background

The interface message test of the embedded software is a time-consuming and expensive work, and researches show that the test cost can reach more than 40% of the cost of the whole software development process. The message interface protocol of the embedded software is generally more, less, more, dozens, wherein the test of the message interface has the characteristics of long-time continuity, large generated data volume, poor testability and the like, and meanwhile, the embedded software has extremely high requirements on robustness and large requirements on fault simulation in the test. At present, interface message testing of embedded software is executed in ways of manually designing a fault scene, manually switching different testing strategies, manually checking a feedback result of a tested object and the like. Therefore, the labor and time overhead required to be invested in the interface message testing phase is extremely large. If a systematic and efficient random test solution for testing the embedded software interface messages can be established, a large amount of test labor and time can be saved.

In view of the above problems, how to implement an interface message testing method that enables a tester to conveniently describe messages, enables purposeful decision-making for each step output without the participation of the tester, enables rapid positioning of the feedback abnormality of a tested object, and enables non-cost and rapid switching back and forth between various different testing strategies has become a technical problem to be solved.

Disclosure of Invention

The invention aims to overcome the defects in the prior art, and provides a random testing method and a system for testing an embedded software interface message, which solve the problems that in the prior art, in the process of testing the embedded software interface message, the design of a fault scene is incomplete, the test strategy is inconvenient to switch, the feedback result is easy to careless and careless, and the labor and the time are consumed.

The purpose of the invention can be realized by the following technical scheme:

according to a first aspect of the present invention, there is provided a random test method for embedded software interface message testing, the method comprising the steps of:

step 1: according to an interface message protocol of an embedded software object to be tested, describing an interface message body by a set script language, and determining an assignment strategy of each field in the message body;

step 2: selecting a test working mode of a test interface message according to an input test strategy;

and step 3: simulating a communication object to send a message sequence to the tested object according to the selected test working mode;

and 4, step 4: and receiving and analyzing the message of the tested object, and recording the feedback of the message sent by the analog communication object as a decision factor for sending the message later.

As a preferred technical scheme, the tested embedded software in the random testing method works in an interconnected open environment, and the interface message communication works on an ISO/OSI protocol stack and is irrelevant to specific physical connection.

As a preferred technical solution, the set scripting language in step 1 includes XML, JSON, and configuration files in custom format.

As a preferred technical solution, the assignment policy of each field in the message body in step 1 includes three-level priority message field assignment policies, which are respectively:

the container level is the highest in priority, and the specific message field is modified in an off-line mode or forcibly modified in an on-line mode and used for injecting faults or simulating special scenes;

setting the level, wherein the priority is lower than the container level, namely, if the same field of the message is modified at the container level and the setting level, the modification at the container level is taken as the standard;

the default level, the priority level is lower than the setting level, and the definition of the priority level is the same as the description in the setting level; the initial values of the message fields are set directly at the default level and are maintained if no assignment is set at the level and container level.

As a preferred technical solution, the setting stage includes a plurality of field modification modes, specifically: directly using simple logic, using custom functions, using message references, and using project custom configurations.

As a preferred technical solution, the message reference of the setting level refers to fetching a specific field from a message returned by a tested object as a value for setting the specific field in a sending message.

As a preferred technical solution, the setting-level project-defined configuration refers to only setting parameters bound with a setting project without modifying other configurations and a simulator of a test platform, so as to achieve the purpose of testing a message interface.

As a preferred technical solution, the test operation mode in step 2 includes: a baking machine mode, a limit mode, a single-point fault mode, a random fault mode and a mixed mode;

the baking machine mode is to perform continuous interface message test on the tested object according to the longest working time of the tested object required in the superior requirement;

the limit mode is to carry out interface message test on the tested object according to the number of the tested objects required to be simultaneously communicated at most in the superior requirement;

the single-point fault mode is to set fault assignment of a single field through an assignment strategy of the field in the message body to test interface messages;

the random fault mode is that fault assignment of a single field or a plurality of fields is set through assignment strategies of the fields in the message body to test interface messages;

the mixed mode refers to that the testing working modes are combined pairwise or a plurality of testing working modes are combined to carry out interface message testing.

As a preferable technical solution, in the above-described toaster mode, a special process is required for the generated record.

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

step 31, confirming the test working mode;

step 32, recording the sent failure mode and recording the feedback information condition of the tested object;

and step 33, determining the random value of the next step according to the test working mode, the sent failure mode and the feedback message condition of the test object.

As a preferred technical solution, the receiving and analyzing the object under test in step 4 includes checking errors and capturing anomalies:

the error checking refers to checking whether each field in the message returned by the tested object is in a specified value range according to the superior requirement and the interface definition;

the abnormal capturing refers to checking whether the tested object returns alarm error information, whether the time interval for returning the information is abnormal, and whether a suspected downtime phenomenon that a heartbeat packet is not returned occurs.

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

the message definition module is used for describing a message body of the interface message by a set script language;

the receiving and sending module is used for receiving the message sent by the tested object, generating a response message according to the test working mode and the feedback strategy and sending the response message to the tested object;

the random generation module generates a random value for field assignment, random fault mode and mixed mode setting;

the feedback decision module is used for judging the feedback of the tested object and deciding the sending strategy of the next step;

and the message recording module is used for recording the generated message and the received message, and the recorded strategy can be configured according to the test working mode.

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

the container setting unit is used for modifying the specific message field offline or forcibly modifying the specific message field online, injecting a fault or simulating a special scene, and setting the field value to have the highest priority;

a value setting unit for setting a priority of a field value to be higher; the method comprises a plurality of field modification modes: using simple logic directly, using custom functions, using message references, and using project custom configurations;

and the default value setting unit is used for directly setting the initial value of the message field, if no assignment of the setting level and the container level exists, the default value setting unit continuously maintains the default value, and the priority of the setting field value is lowest.

As a preferred technical solution, the message reference of the value setting unit refers to capturing a setting field from a message returned by the tested object as a value for setting the setting field in the sending message.

As a preferred technical solution, the item custom configuration of the value setting unit is to set only specific parameters bound to a specific item without modifying other configurations and a simulator of a test platform, so as to achieve the purpose of testing a message interface.

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

the error checking unit is used for checking whether each field in the message returned by the tested object is in a specified value range according to the superior requirement and the interface definition;

the abnormity capturing unit is used for checking whether the tested object returns alarm error information, whether the time interval for returning the information is abnormal, and whether a suspected downtime phenomenon that a heartbeat packet is not returned occurs;

and the working mode unit is used for recording the fault mode of the sent fault message, judging the testing working mode and sending the output generated by the feedback decision module.

As a preferred technical solution, the failure mode includes: boundary values of fields, values except the values of the fields, illegal fields, error check values and repeated timestamps;

the test working mode comprises a baking machine mode, a limit mode, a single-point fault mode, a random fault mode and a mixed mode.

As a preferred technical solution, the random generation module uses a pseudo random number generation algorithm based on a finite state machine, which operates on three levels:

random value taking when fault of message body field value is injected;

in the random fault working mode, random combination of fault fields is carried out;

and in the mixed mode, a concurrent working mode and a random fault mode are mixed, and random combination selection of the fault simulation equipment is performed.

Preferably, the feedback decision module comprises a customized feedback system,

the inputs to the feedback system include: the feedback response message, the sent message and the working mode of the tested object;

the output of the feedback system is the generated message sequence;

the processing logic of the feedback system consists of the following strategy algorithms:

if the feedback response of the tested object is normal, continuing to send the message sequence according to the working mode;

if the feedback response of the tested object is abnormal, selecting different strategies according to the configuration, wherein the strategies comprise:

stopping the interface message test;

continuously sending the message sequence according to the working mode, if the current working mode is a fault working mode, continuously sending the message sequence, and checking whether the detected object is suspected to be down;

and no matter in which working mode, sending normal non-fault interface information first, checking whether the tested object is recovered; if the message sequence is recovered, continuing to send the message sequence according to the working mode; and if not, stopping the interface message test.

As a preferred technical solution, the message recording module comprises a plurality of compression strategies, including no compression, DEFLATE algorithm compression, LZMA2 algorithm compression, and difference storage; configuring a message record compression strategy when a test working mode is selected; the difference storage is used by default in the operating mode of the oven.

According to a third aspect of the invention, there is provided an electronic device comprising a memory having stored thereon a computer program and a processor implementing the method when executing the program.

According to a fourth aspect of the invention, a computer-readable storage medium is provided, on which a computer program is stored which, when being executed by a processor, carries out the method.

Compared with the prior art, the invention has the following advantages:

1) the invention realizes an interface message testing method which can facilitate testers to conveniently describe messages, can purposefully decide the output of each step without the participation of the testers, can quickly locate the feedback abnormity of a tested object, and can be switched back and forth between various testing strategies without cost;

2) the invention supports a plurality of sets of test working modes in the same system, and each working mode can be switched without cost, thereby overcoming the defects of time and labor consumption in switching test strategies and testing environments in the prior art;

3) the invention designs a self-feedback system and a random value mechanism, can purposefully decide the output of each step under the condition of no participation of testers, and overcomes the defect of incomplete design failure of workers in the prior art;

4) the invention designs automatic error correction and abnormal capturing and storing marks, and overcomes the defect that manual inspection feedback results are easy to careless and neglect in the prior art.

Drawings

FIG. 1 is a flow chart of a random testing method for testing messages of an embedded software interface according to the present invention;

FIG. 2 is a detailed flow chart of the random test for testing the message of the embedded software interface according to the present invention;

FIG. 3 is a schematic diagram of a random test feedback strategy for testing embedded software interface messages according to the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, not all, embodiments of the present invention. All other embodiments, which can be obtained by a person skilled in the art without any inventive step based on the embodiments of the present invention, shall fall within the scope of protection of the present invention.

The random test method for testing the embedded software interface message according to the present invention is further described in detail with reference to fig. 1, fig. 2 and fig. 3. The advantages and features of the present invention will become more apparent from the following description. It is to be noted that the drawings are in a very simplified form and are all used in a non-precise scale for the purpose of facilitating and distinctly aiding in the description of the embodiments of the present invention. To make the objects, features and advantages of the present invention comprehensible, reference is made to the accompanying drawings. It should be understood that the structures, ratios, sizes, and the like shown in the drawings and described in the specification are only used for matching with the disclosure of the specification, so as to be understood and read by those skilled in the art, and are not used to limit the implementation conditions of the present invention, so that the present invention has no technical significance, and any structural modification, ratio relationship change or size adjustment should still fall within the scope of the present invention without affecting the efficacy and the achievable purpose of the present invention.

In order to overcome the defects of the existing embedded software interface message testing method, the embodiment provides a random testing method for embedded software interface message testing, which comprises the following steps:

step S1: describing an interface message body by a script language according to an interface message protocol of the tested embedded software object, and determining an assignment strategy of each field in the message body; the script language can be any one of XML, JSON and configuration files with custom formats;

step S1.1: setting a default value for each field based on an interface message body described by a script language, wherein the default value is a necessary item and must be used during test initialization, otherwise, a system can report an error; the field assignment value set by the default value has the lowest priority;

step S1.2: configuring a set value for a field with a required value on the basis of an interface message body described by a scripting language with a field default value, wherein the required value refers to a certain logic function for automatic interface message testing and light interface simulation; the setting value can be null, and the normal operation of the system is not influenced when the setting value is null; the manner of configuring the setting values includes: using simple logic directly, using custom functions, using message references, and using project custom configurations; the priority of the setting value of the configuration field is higher;

step S1.3: setting a container value for a field with a need on the basis of an interface message body described by a scripting language with a field default value and a set value, wherein the need refers to a fault or special scene simulation required by a test requirement; the container value can be empty, and the normal operation of the system is not influenced when the container value is empty; the container value can be set off-line or forced on-line, and the priority of the container set field value is highest;

step S1.4: and configuring a check rule for each field in the message body, wherein the check rule refers to a value range of the field according to an interface protocol, so that the correctness of the field is checked when the message is received.

Step S2: selecting a test working mode of a test interface message according to an input test strategy;

step S2.1: selecting a test working mode according to actual test requirements and test strategies; the test operation mode here includes: a baking machine mode, a limit mode, a single-point fault mode, a random fault mode and a mixed mode;

step S2.2: configuring a compression policy for the message record, where the compression policy includes: .

Step S3: simulating a communication object to send a message sequence to the tested object according to the selected test working mode;

step S3.1: calling a feedback decision module to calculate a message sequence to be sent; the processing logic of the feedback decision module can be seen in fig. 3;

step S3.2: recording a message sequence which is generated by the feedback decision module and sent to the tested object; when fault injection occurs, simultaneously recording fault modes, wherein the fault modes comprise: faults such as boundary values of fields, values except the values of the fields, illegal fields, error check values, repeated timestamps and the like; as input for the next calculation by the feedback decision module.

Step S4: and receiving and analyzing the message of the tested object, and recording the message feedback of the tested object to the analog communication equipment as a decision factor for sending the message later.

Step S4.1: firstly, storing and recording a received feedback message responded by a tested object as the input of a feedback decision module;

step S4.2: meanwhile, checking whether the value of each field in the received message is in a specified range, wherein the specified source referred to here is the upper-level requirement and interface definition, and the checking rule can be pre-compiled when describing the message body;

step S4.3: meanwhile, whether the received message contains alarm error information, whether abnormal time intervals for returning the message occur or not, whether suspected downtime phenomena such as no heartbeat packet return occur or not are detected, and if the abnormal phenomena are captured, an abnormal identifier is added in the record of the step S4.1.

The above is a description of method embodiments, and the scheme of the present invention is further described below by way of system embodiments.

The random test system for testing the embedded software interface message is used for realizing the random test method for testing the embedded software interface message, and comprises the following steps:

the message definition module is used for describing a message body of the interface message in a specific script language;

the receiving and sending module is used for receiving the message sent by the tested object, generating a response message according to the test working mode, the feedback strategy and the like and sending the response message to the tested object;

the random generation module is used for generating random values for field assignment, random fault modes and mixed modes;

the feedback decision module is used for judging the feedback of the object to be tested and deciding the sending strategy of the next step;

The tested embedded software in the random test system works in an interconnected open environment, and the interface message communication works on an ISO/OSI protocol stack and is irrelevant to specific physical connection.

The message definition module comprises;

the container setting unit can modify the specific message field in an off-line way or in an on-line forced way, is used for injecting faults or simulating special scenes and sets the highest priority of the field value;

a value setting unit that sets a field value to have a higher priority; the method comprises a plurality of field modification modes: using simple logic directly, using custom functions, using message references, and using project custom configuration;

the default value setting unit can directly set the initial value of the message field, if no assignment of the setting level and the container level exists, the default value setting unit continuously keeps the default value, and the priority of the setting field value is lowest.

The message reference of the value setting unit refers to the value of a specific field in a message which is captured from a tested object and returned as a setting sending message;

the project self-defined configuration of the value setting unit is that only specific parameters bound with specific projects are set under the condition of not modifying other configurations, test platforms and simulators of the test platforms, so that the purpose of testing message interfaces is achieved;

the specific script language can be XML, JSON and configuration files with custom formats.

The receiving and sending module comprises;

the error checking unit is used for checking whether each field in the message returned by the tested object is in a specified value range or not according to the superior requirement and the interface definition;

and the abnormity capturing unit is used for checking whether the tested object returns alarm error information, whether the time interval for returning the information is abnormal or not and whether a suspected downtime phenomenon that the heartbeat packet is not returned occurs or not.

A working mode unit for recording the failure mode of the transmitted failure message, judging the testing working mode, and transmitting the output generated by the feedback decision module

The failure modes include: faults such as boundary values of fields, values except the values of the fields, illegal fields, error check values, repeated timestamps and the like;

The random generation module uses a finite state machine based pseudo random number generation algorithm that operates on three levels:

random value taking when fault injection of the message body field value occurs;

in a random fault working mode, randomly combining fault fields;

in the mixed mode, a concurrent working mode and a random fault mode are mixed, and random combination selection of fault simulation equipment is performed;

the feedback decision module consists of a customized feedback system:

the input of the feedback system comprises a feedback response message, a sent message and a working mode of the tested object;

the output of the feedback system is the generated message sequence;

stopping the interface message test;

and no matter in which working mode, sending normal non-fault interface information first, checking whether the tested object is recovered; and if the message sequence is recovered, continuing to send the message sequence according to the working mode.

The message recording module comprises a plurality of compression strategies:

including no compression, DEFLATE algorithm compression, LZMA2 algorithm compression, and differential storage; a message record compression strategy can be configured when a test working mode is selected;

the difference storage is used by default in the operating mode of the oven.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working process of the described module may refer to the corresponding process in the foregoing method embodiment, and is not described herein again.

The electronic device of the present invention includes a Central Processing Unit (CPU) that can perform 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 the operation of the device can also be stored. The CPU, ROM, and RAM are connected to each other via a bus. An input/output (I/O) interface is also connected to the bus.

A plurality of 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, and the like; storage units such as magnetic disks, optical disks, and the like; and a communication unit such as a network card, modem, wireless communication transceiver, etc. The communication unit allows the device to exchange information/data with other devices via a computer network such as the internet and/or various telecommunication networks.

The processing unit performs the various methods and processes described above, such as methods S1-S4. For example, in some embodiments, the methods S1-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 ROM and/or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more of the steps of methods S1-S4 described above may be performed. Alternatively, in other embodiments, the CPU may be configured to perform methods S1-S4 in any other suitable manner (e.g., by way of firmware).

The functions described herein above may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary 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), systems on a chip (SOCs), Complex Programmable Logic Devices (CPLDs), and the like.

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, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

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. The 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, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, 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.

While the invention has been described with reference to specific embodiments, the invention is not limited thereto, and various equivalent modifications and substitutions can be easily made by those skilled in the art within the technical scope of the invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A random test method for message testing of an embedded software interface is characterized by comprising the following steps:

2. The random testing method of claim 1, wherein the tested embedded software in the random testing method works in an open environment of interconnection, and the interface message communication works on top of the ISO/OSI protocol stack, independent of the specific physical connection.

3. The random test method for message testing of embedded software interface of claim 1, wherein the set script language in step 1 comprises XML, JSON and configuration files with custom format.

4. The random test method for the message test of the embedded software interface according to claim 1, wherein the assignment policy of each field in the message body in step 1 comprises three-level priority message field assignment policies, which are respectively:

the default level, the priority level is lower than the set level, and the definition of the priority level is the same as the description in the set level; the initial values of the message fields are set directly at the default level and are maintained if no assignment is set at the level and container level.

5. The random test method for the embedded software interface message test according to claim 4, wherein the setup stage includes a plurality of field modification modes, specifically: directly using simple logic, using custom functions, using message references, and using project custom configurations.

6. The random test method for the embedded software interface message test according to claim 4, wherein the message reference of the setting level refers to fetching a specific field from a message returned by the tested object as a value for setting the specific field in the sending message.

7. The random test method for the message test of the embedded software interface according to claim 4, wherein the setting level of the item custom configuration means that only setting parameters bound with setting items are set to achieve the purpose of testing the message interface without modifying other configurations and simulators of the test platform.

8. The random test method for message testing of embedded software interface according to claim 1, wherein the test operation mode in step 2 comprises: a baking machine mode, a limit mode, a single-point fault mode, a random fault mode and a mixed mode;

9. The random test method for embedded software interface message testing as recited in claim 8, wherein the bake mode requires special handling of the generated records.

10. The random test method for testing the embedded software interface message according to claim 1, wherein the message sending sequence in the step 3 specifically comprises the following steps:

step 31, confirming the test working mode;

step 32, recording the sent failure mode and recording the feedback message condition of the object to be tested;

11. The random test method for message testing of embedded software interfaces as claimed in claim 1, wherein said receiving and parsing the object under test in step 4 comprises checking for errors and catching exceptions:

12. A system for a random test method for embedded software interface message testing as recited in claim 1, the system comprising:

and the message recording module is used for recording the generated messages and the received messages, and the recorded strategy can be configured according to the test working mode.

13. The system of claim 12, wherein the message definition module comprises:

a value setting unit for setting a priority of a field value to be higher; the method comprises a plurality of field modification modes: using simple logic directly, using custom functions, using message references, and using project custom configuration;

14. The system according to claim 13, wherein the message reference of the value setting unit refers to a value obtained by grabbing a setting field from a message returned by the tested object as a setting field in a setting sending message.

15. The system of claim 13, wherein the item-defined configuration of the value setting unit is to set only specific parameters bound to a specific item without modifying other configurations and simulators of the test platform, so as to achieve the purpose of testing the message interface.

16. The system of claim 12, wherein the receiving and transmitting module comprises:

17. The system of claim 16, wherein the failure mode comprises: boundary values of fields, values except the values of the fields, illegal fields, error check values and repeated timestamps;

18. The system according to claim 12, wherein said random generation module uses a finite state machine based pseudo random number generation algorithm that operates at three levels:

19. The system of claim 12, wherein the feedback decision module comprises a customized feedback system,

the output of the feedback system is the generated message sequence;

stopping the interface message test;

20. The system of claim 12, wherein the message recording module contains a plurality of compression strategies including no compression, DEFLATE algorithm compression, LZMA2 algorithm compression, and differential storage; configuring a message record compression strategy when a test working mode is selected; the difference storage is used by default in the operating mode of the oven.

21. An electronic device comprising a memory and a processor, the memory having a computer program stored thereon, wherein the processor when executing the program performs the method of any of claims 1-11.

22. A computer-readable storage medium, on which a computer program is stored, which program, when being executed by a processor, carries out the method according to any one of claims 1 to 11.