System testing method, system, device and medium

Abstract

The present invention discloses a system testing method, comprising the following steps: obtaining preset test parameters, test strategies and configuration files; initializing a pod in one of the nodes according to the configuration files; migrating the pod to several initial nodes to be tested according to the test parameters and the test strategies, so as to test the initial nodes to be tested using the pod; in response to the completion of the tests on several initial nodes to be tested, migrating the pod to several nodes to be tested for the next test according to the parameters and the test strategies, so as to test the several nodes to be tested for the next test using the pod. The present invention also discloses a system, a computer device and a readable storage medium. The solution proposed by the present invention can realize decentralized automated fault injection, thereby testing the system, solving the problems of the current automated fault injection design being cumbersome to implement, highly dependent on the server, and unable to recover automatically.

Description

Technical Field

[0001] The present invention relates to the field of testing, and in particular to a system testing method, system, equipment and storage medium. Background Art

[0002] With the rapid development of cloud computing, systems are using more and more components, with characteristics such as API communication, microservice architecture, and large node scale. This increases system complexity and the probability of errors, making it difficult to fully verify the system's fault tolerance mechanisms. Even a small change, due to an unforeseen scenario, can cause widespread system chaos, failures, and service interruptions. Therefore, developing comprehensive chaos experiment scenarios and solutions can significantly improve the fault tolerance of the system architecture, increase emergency response efficiency, expose online problems earlier, and reduce the recurrence rate of failures. One of the core elements of chaos experimentation is fault injection.

[0003] Fault injection can be performed manually or automatically. In this solution, we will focus only on the automatic method. Currently, there are two common methods for automatic injection: one is to execute commands remotely, and the other is to start a daemon process (hereinafter referred to as the client) on the test device and wait for instructions from a central management service (hereinafter referred to as the server) before executing the operation.

[0004] Remote command execution, due to operating system security restrictions, limits the types of fault injection that can be implemented. The daemon process approach consumes resources on the tested machine for a long time and is cumbersome to implement, requiring frequent communication between the client and server and a strong reliance on a central server. Furthermore, if the client program freezes, manual intervention is required, which is extremely inefficient. Summary of the Invention

[0005] In view of this, in order to overcome at least one aspect of the above problems, an embodiment of the present invention provides a system testing method, comprising the following steps:

[0006] Obtain preset test parameters, test strategies and configuration files;

[0007] Initialize a pod on one of the nodes according to the configuration file;

[0008] Migrating the pod to several initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod;

[0009] In response to completion of the tests on the initial plurality of nodes to be tested, the pod is migrated to the plurality of nodes to be tested next time according to the parameters and the test strategy so as to test the plurality of nodes to be tested next time using the pod.

[0010] In some embodiments, obtaining preset test parameters, test strategies, and configuration files further includes:

[0011] The preset test parameters, test strategy and configuration file are saved in a shared storage.

[0012] In some embodiments, testing the initial node to be tested using the pod further includes:

[0013] The pod is used to perform fault injection on the node to be tested.

[0014] In some embodiments, it further includes:

[0015] Store the test results of each node in shared storage.

[0016] In some embodiments, obtaining preset test parameters further includes:

[0017] Get the test parameters including bounds on the number of test nodes.

[0018] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0019] The maximum number of nodes to be tested for each test is determined according to the test node quantity limit.

[0020] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0021] The number of nodes to be tested for each test is determined according to the test strategy.

[0022] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a system testing system, comprising:

[0023] An acquisition module configured to acquire preset test parameters, test strategies, and configuration files;

[0024] An initialization module, configured to initialize a pod in one of the nodes according to the configuration file;

[0025] a testing module configured to migrate the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod;

[0026] A migration module is configured to migrate the pod to the several nodes to be tested next time according to the parameters and the test strategy in response to the completion of the test of the several initial nodes to be tested, so as to use the pod to test the several nodes to be tested next time.

[0027] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a computer device, including:

[0028] at least one processor; and

[0029] A memory storing a computer program executable on the processor, wherein the processor executes the following steps when executing the program:

[0030] Obtain preset test parameters, test strategies and configuration files;

[0031] Initialize a pod on one of the nodes according to the configuration file;

[0032] Migrating the pod to several initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod;

[0033] In response to completion of the tests on the initial plurality of nodes to be tested, the pod is migrated to the plurality of nodes to be tested next time according to the parameters and the test strategy so as to test the plurality of nodes to be tested next time using the pod.

[0034] In some embodiments, obtaining preset test parameters, test strategies, and configuration files further includes:

[0035] The preset test parameters, test strategy and configuration file are saved in a shared storage.

[0036] In some embodiments, testing the initial node to be tested using the pod further includes:

[0037] The pod is used to perform fault injection on the node to be tested.

[0038] In some embodiments, it further includes:

[0039] Store the test results of each node in shared storage.

[0040] In some embodiments, obtaining preset test parameters further includes:

[0041] Get the test parameters including bounds on the number of test nodes.

[0042] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0043] The maximum number of nodes to be tested for each test is determined according to the test node quantity limit.

[0044] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0045] The number of nodes to be tested for each test is determined according to the test strategy.

[0046] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the following steps are performed:

[0047] Obtain preset test parameters, test strategies and configuration files;

[0048] Initialize a pod on one of the nodes according to the configuration file;

[0049] Migrating the pod to several initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod;

[0050] In response to completion of the tests on the initial plurality of nodes to be tested, the pod is migrated to the plurality of nodes to be tested next time according to the parameters and the test strategy so as to test the plurality of nodes to be tested next time using the pod.

[0051] In some embodiments, obtaining preset test parameters, test strategies, and configuration files further includes:

[0052] The preset test parameters, test strategy and configuration file are saved in a shared storage.

[0053] In some embodiments, testing the initial node to be tested using the pod further includes:

[0054] The pod is used to perform fault injection on the node to be tested.

[0055] In some embodiments, it further includes:

[0056] Store the test results of each node in shared storage.

[0057] In some embodiments, obtaining preset test parameters further includes:

[0058] Get the test parameters including bounds on the number of test nodes.

[0059] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0060] The maximum number of nodes to be tested for each test is determined according to the test node quantity limit.

[0061] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0062] The number of nodes to be tested for each test is determined according to the test strategy.

[0063] The present invention has the following beneficial technical effects: The proposed solution enables decentralized automated fault injection for system testing, resolving the current issues of automated fault injection, which are cumbersome to implement, heavily dependent on the server, and unable to automatically recover. Through a decentralized design, only a single service is required to perform functions currently required by both the client and server, simplifying design and implementation while avoiding a strong dependency on the server. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other embodiments can be obtained based on these drawings without paying any creative work.

[0065] Figure 1 A schematic diagram of a flow chart of a system testing method provided by an embodiment of the present invention;

[0066] Figure 2 A schematic diagram of the structure of a system testing system provided by an embodiment of the present invention;

[0067] Figure 3 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention;

[0068] Figure 4 A schematic structural diagram of a computer-readable storage medium provided for an embodiment of the present invention. DETAILED DESCRIPTION

[0069] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the embodiments of the present invention are further described in detail below in conjunction with specific embodiments and with reference to the accompanying drawings.

[0070] It should be noted that all expressions using "first" and "second" in the embodiments of the present invention are for distinguishing two non-identical entities with the same name or non-identical parameters. It can be seen that "first" and "second" are only for the convenience of expression and should not be understood as limitations on the embodiments of the present invention. Subsequent embodiments will not explain this one by one.

[0071] According to one aspect of the present invention, an embodiment of the present invention provides a system testing method, such as Figure 1 As shown, it may include the steps of:

[0072] S1, obtain preset test parameters, test strategies and configuration files;

[0073] S2, initializes the pod in one of the nodes according to the configuration file;

[0074] S3: Migrating the pod to several initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod;

[0075] S4, in response to the completion of the test of the several initial nodes to be tested, migrating the pod to the several nodes to be tested next time according to the parameters and the test strategy so as to use the pod to test the several nodes to be tested next time.

[0076] The proposed solution enables decentralized automated fault injection for system testing, resolving the current challenges of automated fault injection, which are cumbersome to implement, heavily dependent on the server, and unable to recover automatically. Through a decentralized design, only a single service is required to perform functions currently required by both the client and server, simplifying implementation while avoiding a strong dependency on the server.

[0077] In some embodiments, obtaining preset test parameters, test strategies, and configuration files further includes:

[0078] The preset test parameters, test strategy and configuration file are saved in a shared storage.

[0079] In some embodiments, obtaining preset test parameters further includes:

[0080] Get the test parameters including bounds on the number of test nodes.

[0081] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0082] The maximum number of nodes to be tested for each test is determined according to the test node quantity limit.

[0083] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0084] The number of nodes to be tested for each test is determined according to the test strategy.

[0085] Specifically, the set test parameters, test strategies, and configuration files can be saved in advance to the shared storage. Among them, the test parameters may include the limit of the number of test nodes, that is, the maximum number of nodes that can be tested simultaneously in each test. The test strategy can include the number of nodes to be tested each time and the adjustment strategy, that is, the number of nodes to be tested to be tested simultaneously in the next test is determined based on the number of nodes to be tested simultaneously in the previous test, until the number of nodes to be tested to be tested simultaneously reaches the limit of the number of test nodes. In this way, by recording the test parameters and test strategies through shared storage, access to the shared storage can be achieved regardless of which node the pod is on, thereby realizing decentralized fault injection testing.

[0086] For example, if the environment is a 5-node high-availability cluster deployed based on K8S, the test parameter can be 2, that is, a maximum of 2 nodes fail each time. The initial strategy can be set to a fault injection strategy for 1 node, with 1 node failing each time until all nodes are tested. Then adjust the test strategy based on the feedback from the test analysis. For example: after the last 1-node fault test, the environment was stable, and this test execution was adjusted to perform a fault injection test on 2 nodes. In this way, the test strategy is adjusted based on the test results to see if there are further test plans (such as the test strategy requires covering 1 node per test and 2 nodes per test). If so, adjust the current strategy to be executed and start a new round of testing. If not, generate a test report and provide it to the testers for review and analysis.

[0087] In some embodiments, testing the initial node to be tested using the pod further includes:

[0088] The pod is used to perform fault injection on the node to be tested.

[0089] Specifically, pods can be used to perform fault injection testing based on test strategies. For example, pods can be used to implement fault injection testing, and fault types can be managed in a fault library, such as 60% CPU usage, 100% disk usage, device downtime, and 30 millisecond network delay.

[0090] In some embodiments, it further includes:

[0091] Store the test results of each node in shared storage.

[0092] Specifically, the test results of each node can be saved to shared storage, meaning that no matter which node the pod is on, it can access the shared storage. This allows for archiving test results for analysis by testers and for automatic adjustment of test strategies based on test results.

[0093] In some embodiments, in step S4, in response to the completion of testing of several of the initial nodes to be tested, the pod is migrated to several nodes to be tested next time according to the parameters and the test strategy, so that the pod can be used to test the several nodes to be tested next time. Specifically, according to the test strategy, the pod replicas can be expanded and reduced in size, and the pod is only started on the nodes that need to be tested, and the pod is deleted on the nodes that do not need to be tested, so as to minimize the consumption of test resources. In this way, policy-based self-management adjusts the number of replicas of the own pod, the target node, and other attributes according to the test strategy and plan, and realizes on-demand expansion and reduction, and directional drift.

[0094] The proposed solution enables decentralized automated fault injection for system testing, resolving the current challenges of automated fault injection, which are cumbersome to implement, heavily dependent on the server, and unable to recover automatically. Through a decentralized design, only a single service is required to perform functions currently required by both the client and server, simplifying implementation while avoiding a strong dependency on the server.

[0095] Based on the same inventive concept, according to another aspect of the present invention, an embodiment of the present invention further provides a system testing system 400, such as Figure 2 As shown, including:

[0096] Acquisition module 401, configured to acquire preset test parameters, test strategies and configuration files;

[0097] An initialization module 402 is configured to initialize a pod in one of the nodes according to the configuration file;

[0098] A testing module 403 is configured to migrate the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod;

[0099] The migration module 404 is configured to migrate the pod to the several nodes to be tested next time according to the parameters and the test strategy in response to the completion of the test of the several initial nodes to be tested, so as to use the pod to test the several nodes to be tested next time.

[0100] In some embodiments, obtaining preset test parameters, test strategies, and configuration files further includes:

[0101] The preset test parameters, test strategy and configuration file are saved in a shared storage.

[0102] In some embodiments, testing the initial node to be tested using the pod further includes:

[0103] The pod is used to perform fault injection on the node to be tested.

[0104] In some embodiments, it further includes:

[0105] Store the test results of each node in shared storage.

[0106] In some embodiments, obtaining preset test parameters further includes:

[0107] Get the test parameters including bounds on the number of test nodes.

[0108] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0109] The maximum number of nodes to be tested for each test is determined according to the test node quantity limit.

[0110] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0111] The number of nodes to be tested for each test is determined according to the test strategy.

[0112] The proposed solution enables decentralized automated fault injection for system testing, resolving the current challenges of automated fault injection, which are cumbersome to implement, heavily dependent on the server, and unable to recover automatically. Through a decentralized design, only a single service is required to perform functions currently required by both the client and server, simplifying implementation while avoiding a strong dependency on the server.

[0113] Based on the same inventive concept, according to another aspect of the present invention, Figure 3 As shown, an embodiment of the present invention further provides a computer device 501, including:

[0114] at least one processor 520; and

[0115] The memory 510 stores a computer program 511 that can be run on the processor. When the processor 520 executes the program, the following steps are performed:

[0116] S1, obtain preset test parameters, test strategies and configuration files;

[0117] S2, initializes the pod in one of the nodes according to the configuration file;

[0118] S3: Migrating the pod to several initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod;

[0119] S4, in response to the completion of the test of the several initial nodes to be tested, migrating the pod to the several nodes to be tested next time according to the parameters and the test strategy so as to use the pod to test the several nodes to be tested next time.

[0120] In some embodiments, obtaining preset test parameters, test strategies, and configuration files further includes:

[0121] The preset test parameters, test strategy and configuration file are saved in a shared storage.

[0122] In some embodiments, testing the initial node to be tested using the pod further includes:

[0123] The pod is used to perform fault injection on the node to be tested.

[0124] In some embodiments, it further includes:

[0125] Store the test results of each node in shared storage.

[0126] In some embodiments, obtaining preset test parameters further includes:

[0127] Get the test parameters including bounds on the number of test nodes.

[0128] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0129] The maximum number of nodes to be tested for each test is determined according to the test node quantity limit.

[0130] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0131] The number of nodes to be tested for each test is determined according to the test strategy.

[0132] The proposed solution enables decentralized automated fault injection for system testing, resolving the current challenges of automated fault injection, which are cumbersome to implement, heavily dependent on the server, and unable to recover automatically. Through a decentralized design, only a single service is required to perform functions currently required by both the client and server, simplifying implementation while avoiding a strong dependency on the server.

[0133] Based on the same inventive concept, according to another aspect of the present invention, Figure 4 As shown, an embodiment of the present invention further provides a computer-readable storage medium 601, which stores computer program instructions 610. When the computer program instructions 610 are executed by a processor, the following steps are performed:

[0134] S1, obtain preset test parameters, test strategies and configuration files;

[0135] S2, initializes the pod in one of the nodes according to the configuration file;

[0136] S3: Migrating the pod to several initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod;

[0137] S4, in response to the completion of the test of the several initial nodes to be tested, migrating the pod to the several nodes to be tested next time according to the parameters and the test strategy so as to use the pod to test the several nodes to be tested next time.

[0138] In some embodiments, obtaining preset test parameters, test strategies, and configuration files further includes:

[0139] The preset test parameters, test strategy and configuration file are saved in a shared storage.

[0140] In some embodiments, testing the initial node to be tested using the pod further includes:

[0141] The pod is used to perform fault injection on the node to be tested.

[0142] In some embodiments, it further includes:

[0143] Store the test results of each node in shared storage.

[0144] In some embodiments, obtaining preset test parameters further includes:

[0145] Get the test parameters including bounds on the number of test nodes.

[0146] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0147] The maximum number of nodes to be tested for each test is determined according to the test node quantity limit.

[0148] In some embodiments, migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes:

[0149] The number of nodes to be tested for each test is determined according to the test strategy.

[0150] The proposed solution enables decentralized automated fault injection for system testing, resolving the current challenges of automated fault injection, which are cumbersome to implement, heavily dependent on the server, and unable to recover automatically. Through a decentralized design, only a single service is required to perform functions currently required by both the client and server, simplifying implementation while avoiding a strong dependency on the server.

[0151] Finally, it should be noted that a person skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods.

[0152] Furthermore, it should be appreciated that the computer-readable storage media (eg, memory) herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory.

[0153] It will also be appreciated by those skilled in the art that the various exemplary logic blocks, modules, circuits and algorithmic steps described in conjunction with the disclosure herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, a general description has been given of the functions of various schematic components, blocks, modules, circuits and steps. Whether this function is implemented as software or hardware depends on specific applications and the design constraints imposed on the entire system. Those skilled in the art can implement the function in various ways for each specific application, but this implementation decision should not be interpreted as causing a departure from the disclosed scope of the embodiments of the present invention.

[0154] The above are exemplary embodiments disclosed in the present invention, but it should be noted that various changes and modifications may be made without departing from the scope of the embodiments disclosed in the claims. The functions, steps and / or actions of the method claims according to the disclosed embodiments described herein do not need to be performed in any particular order. In addition, although the elements disclosed in the embodiments of the present invention may be described or required in individual form, they may also be understood as multiple unless expressly limited to the singular.

[0155] It should be understood that, as used herein, the singular forms "a" and "an" are intended to include the plural forms as well, unless the context clearly supports an exception. It should also be understood that, as used herein, "and / or" is intended to include any and all possible combinations of one or more of the associated listed items.

[0156] The serial numbers of the embodiments disclosed in the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments.

[0157] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or may be accomplished by a program instructing the relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk, or an optical disk, etc.

[0158] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the disclosure of the embodiments of the present invention (including the claims) is limited to these examples. Within the spirit of the embodiments of the present invention, the technical features of the above embodiments or different embodiments may be combined, and there are many other variations of different aspects of the above embodiments of the present invention, which are not provided in detail for the sake of simplicity. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present invention should be included in the scope of protection of the embodiments of the present invention.

Claims

1. A system testing method, characterized in that: The following steps are involved: Obtaining preset test parameters, test strategies, and configuration files, wherein the test parameters include a test node number boundary, and the test strategy includes determining the number of test nodes to be tested simultaneously in the next test based on the number of test nodes tested simultaneously in the previous test, until the number of test nodes tested simultaneously reaches the test node number boundary; Initialize a pod on one of the nodes according to the configuration file; Migrating the pod to several initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod; In response to completion of the tests on the initial plurality of nodes to be tested, the pod is migrated to the plurality of nodes to be tested next time according to the parameters and the test strategy so as to test the plurality of nodes to be tested next time using the pod.

2. The method according to claim 1, wherein Get preset test parameters, test strategies, and configuration files, including: The preset test parameters, test strategy and configuration file are saved in a shared storage.

3. The method according to claim 1, wherein Testing the initial node to be tested using the pod further includes: The pod is used to perform fault injection on the node to be tested.

4. The method according to claim 1, wherein Also includes: Store the test results of each node in shared storage.

5. The method according to claim 1, wherein Obtaining preset test parameters further includes: Get the test parameters including bounds on the number of test nodes.

6. The method according to claim 5, wherein Migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes: The maximum number of nodes to be tested for each test is determined according to the test node quantity limit.

7. The method according to claim 6, wherein Migrating the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy further includes: The number of nodes to be tested for each test is determined according to the test strategy.

8. A system testing system, characterized in that: include: an acquisition module configured to acquire preset test parameters, a test strategy, and a configuration file, wherein the test parameters include a test node number boundary, and the test strategy includes determining the number of test nodes to be tested simultaneously in the next test based on the number of test nodes tested simultaneously in the previous test, until the number of test nodes tested simultaneously reaches the test node number boundary; An initialization module, configured to initialize a pod in one of the nodes according to the configuration file; a testing module configured to migrate the pod to a plurality of initial nodes to be tested according to the test parameters and the test strategy, so as to test the initial nodes to be tested using the pod; A migration module is configured to migrate the pod to the several nodes to be tested next time according to the parameters and the test strategy in response to the completion of the test of the several initial nodes to be tested, so as to use the pod to test the several nodes to be tested next time.

9. A computer device comprising: at least one processor; as well as A memory storing a computer program executable on the processor, wherein the processor executes the steps of the method according to any one of claims 1 to 7 when executing the program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are performed.

Images