Methods for testing a computer program

Abstract

According to various embodiments, a method for testing a computer program is described, comprising performing several test iterations, wherein for each test iteration a reference test input and a mutation for the reference test input are selected according to a selection strategy (201), and a test input for the computer program is generated by applying the selected mutation to the selected reference test input, wherein for each test iteration a test run of the computer program is performed with the respective generated test input for the computer program, wherein for each test iteration a test coverage increase (209) is determined which is achieved by the test run, and wherein the selection strategy (201) is trained by means of reinforcement learning, wherein the test coverage increases (209) are used as rewards (204).

Description

[0001] The present disclosure relates to methods for testing a computer program.

[0002] Testing is an essential component of software application development. In particular, errors that cause application failure should be identified and corrected. An example of software testing is the dynamic software testing technique known as fuzzing.

[0003] Mutation-based fuzzers such as AFL, Honggfuzz, or Libfuzzer use mutation-based, coverage-driven fuzzing to test software with minimal effort. For each fuzzing iteration (i.e., each test run), a "seed" test input (hereafter referred to as the reference test input) is selected from a so-called (input) corpus, randomly mutated, and sent as input to the computer program under test. If the newly generated input triggers previously unseen behavior (such as executing previously unexecuted code paths or crashing), it is added to the corpus. In this way, the input space of a computer program can be explored with little or no knowledge of the input format, based only on the initially available reference test inputs.

[0004] With the "Havoc" mutation strategy, the mutation applied to the respective reference test input for each fuzzing iteration is randomly generated from a sequence of basic mutations (such as inverting individual bits for different bit positions). Good results can be achieved with the Havoc mutation strategy. Nevertheless, approaches that can further increase the efficiency and / or effectiveness of computer program testing, especially using fuzzing, are desirable.

[0005] According to various embodiments, a method for testing a computer program is provided, comprising carrying out a plurality of test iterations, wherein for each test iteration a reference test input and a mutation for the reference test input are selected according to a selection strategy and a test input for the computer program is generated by applying the selected mutation to the selected reference test input, wherein for each test iteration a test run of the computer program is carried out with the respective generated test input for the computer program, wherein for each test iteration a test coverage increase achieved by the test run is determined and wherein the selection strategy is trained by means of reinforcement learning, wherein, for example, the test coverage increases are used as rewards. The coverage (orThe test coverage (or its increase) can be evaluated using various metrics that capture test coverage, such as code coverage (branch coverage, line coverage, number of triggered program crashes (i.e. coverage with regard to processing paths that lead to the crash)), memory coverage, etc.

[0006] The method described above enables higher efficiency and / or effectiveness of coverage-driven fuzzing compared to random selection of the reference test input (also called "seed") that is mutated for a current fuzzing iteration and random selection of the mutation (e.g., in the form of a sequence of base mutations).

[0007] For reinforcement learning (RL), any RL method can be used, for example, one based on the optimization of an objective function that incorporates the efficiency and / or effectiveness (e.g., in the form of an evaluation of the achieved coverage) of fuzzing. Various machine learning models can be used for reinforcement learning. For example, the selection strategy can be represented by a neural network trained during reinforcement learning. The element that implements the selection strategy can be considered the RL agent (i.e., the training or learning of the selection strategy can also be considered training this RL agent).

[0008] The selection strategy can be trained individually for each of several computer programs to be tested. For example, a base selection strategy is used in each case, which is trained during the fuzzing of the respective computer program (thus improving its suitability for testing the respective computer program).

[0009] It should be noted that a mutation of a reference test input can also consist of combining it with another reference test input. The selection of the other reference test input can then be considered part of the selection of the mutation.

[0010] Various examples of implementation are given below.

[0011] Embodiment 1 is a method for testing a computer program as described above.

[0012] Embodiment 2 is the method of embodiment 1, wherein for at least some of the test iterations, the selection of the mutation comprises a selection of a sequence of base mutations.

[0013] Thus, the agent can generate more complicated mutations by concatenating different basic mutations (from a given set, e.g., of “simple” mutations).

[0014] Embodiment 3 is the method of embodiment 1, wherein for at least some of the test iterations, the selection of the mutation comprises a selection of a sequence of base mutations that continues a sequence of base mutations with which the test input for a previous test iteration was generated.

[0015] The agent can therefore, for example, in successive test iterations (e.g., fuzzing iterations), continue to mutate a reference test input (until, for example, it decides to switch to another reference test input).

[0016] Embodiment 4 is the method according to embodiment 2 or 3, wherein the base mutations are one or more of: inverting a single bit for a particular bit position, setting a data item at a particular position to a predetermined value, adding or subtracting a predetermined number to / from a data item at a particular position, setting a data item at a particular position to a random value, removing a data item at a particular position, duplicating a data item at a particular position.

[0017] These basic mutations allow the agent high flexibility in selecting the mutation.

[0018] Embodiment 5 is the method according to one of the embodiments 1 to 4, wherein for each test iteration the reference test input and the mutation are selected according to the selection strategy depending on the test input of a previous test iteration.

[0019] In other words, the state entering the RL agent contains the test input from a previous (e.g., the last) test iteration. This allows the RL agent (or the selection strategy) to learn, in particular, which test inputs are worth pursuing (e.g., which should be further mutated).

[0020] Embodiment 6 is the method according to any one of embodiments 1 to 5, wherein the computer program is a control program for a robot device and the robot device is controlled with the computer program depending on a result of testing the computer program.

[0021] Embodiment 7 is a test arrangement which is configured to carry out a method according to one of the embodiments 1 to 6.

[0022] Embodiment 8 is a computer program including instructions that, when executed by a processor, cause the processor to perform a method according to any one of embodiments 1 to 6.

[0023] Embodiment 9 is a computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform a method according to any one of embodiments 1 to 6.

[0024] In the drawings, like reference characters generally refer to the same parts throughout the several views. The drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings. Fig. 1 shows a computer for developing and / or testing software applications. Fig. 2 illustrates the training of a selection strategy for fuzzing according to one embodiment. Fig. 3 shows a flowchart illustrating a method for testing a computer program according to an embodiment.

[0025] The following detailed description refers to the accompanying drawings, which, by way of illustration, show specific details and aspects of this disclosure in which the invention may be practiced. Other aspects may be utilized, and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure may be combined with one or more other aspects of this disclosure to form new aspects.

[0026] Various examples are described in more detail below.

[0027] Fig. 1 shows a computer 100 for developing and / or testing software applications.

[0028] The computer 100 has a CPU (Central Processing Unit) 101 and a random access memory (RAM) 102. The RAM 102 is used to load program code, e.g., from a hard disk 103, and the CPU 101 executes the program code.

[0029] In this example, it is assumed that a user intends to use computer 100 to develop and / or test a software application.

[0030] To do this, the user executes a software development environment 104 on the CPU 101.

[0031] The software development environment 104 enables the user to develop and test an application (i.e., software) 105 for various devices 106, i.e., target hardware, such as embedded systems for controlling robotic devices, including robot arms and autonomous vehicles, or even for mobile (communication) devices. For this purpose, the CPU 101, as part of the software development environment 104, can execute an emulator to simulate the behavior of the respective device 106 for which an application is or was developed. If it is used only for testing software from another source, the software development environment 104 can also be viewed or configured as a software test environment.

[0032] The user can distribute the finished application to corresponding devices 106 via a communications network 107. Instead of via a communications network 107, this can also be done in another way, for example, using a USB stick.

[0033] Before doing so, however, the user should test the application 105 to avoid distributing a malfunctioning application to the devices 106.

[0034] One testing technique is called fuzzing. Fuzzing, or fuzz testing, is an automated software testing technique in which invalid, unexpected, or random data is fed as input to a computer program under test. The program is then monitored for exceptions such as crashes, missing failed built-in code assertions, or potential memory leaks.

[0035] Typically, fuzzers (i.e., test programs that use fuzzing) are used to test programs that process structured inputs. This structure is specified, for example, in a file format or protocol and distinguishes between valid and invalid inputs. An effective fuzzer generates semi-valid inputs that are "valid enough" not to be rejected outright by the input parser of the program under test, but "invalid enough" to reveal unexpected behaviors and edge cases that are not properly handled in the program under test.

[0036] The following describes terminology used in connection with fuzzing: • Fuzzing or fuzz testing is the automated testing process of sending randomly generated inputs to a target program (the program under test) and observing its response. • A fuzzer or fuzzing engine is a program that automatically generates input. It is therefore not linked to the software under test (e.g., through instrumentation). However, the fuzzer has the ability to instrument code, generate test cases, and execute the programs under test. Well-known examples are afl and libfuzzer. • A fuzz target is a software program or function to be tested through fuzzing. A key characteristic of a fuzz target is that it accepts potentially untrusted inputs generated by the fuzzer during the fuzzing process. • A fuzz test is the combined version of a fuzzer and a fuzz target. A fuzz target can then be instrumented code, where a fuzzer is linked to (i.e., provides) its inputs. A fuzz test is executable. A fuzzer can also start, observe, and stop multiple fuzz tests—that is, perform multiple test runs (usually hundreds or thousands per second), each with a slightly different input generated by the fuzzer. • A test case is a specific (test) input and a specific test run from a fuzz test. Typically, interesting runs (finding new code paths or crashes) are saved for reproducibility. This allows a specific test case with the corresponding input to be executed on a fuzz target that is not connected to a fuzzer, e.g., the release version of a program. • Coverage-guided fuzzing uses code coverage information as feedback during fuzzing to detect whether an input has caused the execution of new code paths or blocks. • Generation-based fuzzing uses prior knowledge about the target program (fuzz target) to generate test inputs. An example of such prior knowledge is a grammar that conforms to the fuzz target's input specification, i.e., the input grammar of the fuzz target (i.e., the program under test). • Static instrumentation is the insertion of statements into a program (under test) to obtain feedback about its execution. It is usually implemented by the compiler and can, for example, indicate the code blocks reached during execution. • Dynamic instrumentation is the control of the execution of a program (under test) during runtime to generate feedback from the execution. It is usually implemented through operating system functionalities or through the use of emulators.

[0037] A test input for a test case (i.e., a test pass or test iteration) can be generated from a test input of a previous test case by mutation, i.e., a mutator generates a current test input from a previous test case from a set of reference test cases called a corpus.

[0038] For example, a coverage-driven fuzzer may incorporate a random search mechanism called Havoc. In contrast to using only one "base" mutator (i.e., a mutator that performs a base mutation, such as flipping (i.e., inverting) a bit) to generate a test input for a fuzzing iteration, Havoc randomly selects multiple such base mutators, each performing a base mutation, such as flipping (i.e., inverting) a single bit for different bit positions, and applies them sequentially to a test case (from the corpus), i.e., selects a sequence of base mutations that constitute the mutation for the current fuzzing operation.

[0039] The efficiency and / or effectiveness of fuzzing, i.e. in particular the coverage achieved by the test program after a certain number of fuzzing iterations (i.e. test iterations), depends on which mutation is applied per fuzzing iteration (e.g. which and how many base mutations are applied to the test input of a test case in order to generate a current test input) and also on which reference test case it is applied. The selection of the mutation and the reference test case can be random. It can also be specified that the reference test case is selected randomly and a fixed number of base mutations (which themselves can be randomly selected) are applied to the test input of the reference test case. The selection of the reference test cases and determining how many mutations should be applied to each of them is also referred to as the "power schedule".

[0040] According to various embodiments, both the selection of the reference test case to be mutated for a current fuzzing iteration (i.e., the "power schedule") and which mutation (i.e., which base mutations, their number, and / or their order) to apply to the selected reference test case are learned by an agent using reinforcement learning (RL) (or equivalently: a selection strategy implemented (or pursued) by the agent is trained). The agent is trained to optimize the efficiency and / or effectiveness of the fuzzing.

[0041] Examples of basic mutations are as follows: - Single-bit flips, i.e. flipping (inverting) a single bit for a specific bit position of the test input - Placing an "interesting" (i.e., predefined) block, e.g., bytes, words, or double words (in big-endian or little-endian) in the test input. What is "interesting" can be based on expert knowledge or on previous fuzzing results. - Addition or subtraction of a small integer to a specific byte, word, or double word (in big-endian or little-endian) in the test input, - Setting a random byte at a specific position in the test input - Removing a block (e.g. byte, word or double word) at a specific position from the test input - The duplication of a block (e.g. byte, word or double word) at a specific position in the test input by overwriting the subsequent block or inserting (i.e. moving the subsequent block),

[0042] Setting a block can be done, for example, using a block memset.

[0043] By concatenating (i.e., sequencing) base mutations, mutations and thus test inputs can be generated that cannot be generated by a single base mutation.

[0044] With each applied base mutation, the mutated test input deviates more and more from the reference test input from which it is generated. This is illustrated by Table 1 for a simple (short) test input. Table 1 Anzahl angewendeter Basis-Mutationen Testeingabe 0 http: / / www.google.com / search?q=fuzzing 5 http: / L / www.googlej.com / seaRchq=fuz:ing 10 http: / L / www.ggoWglej.com / seaRchqfu:in 15 http: / L / wwggoWglej.com / seaR3hqf,u:in 20 htt: / / wwggoVgle"j.som / seaR3hqf,u:in 25 htt: / / fwggoVgle"j.som / eaRd3hqf,u^:in 30 htv: / / >fwggoVgle"j.qom / ea0Rd3hqf,u^:i 35 htv: / / >fwggozVIe"Bj.qom / eapRd[3hqf,u^:i 40 htv: / / >fwgeo6zTle"Bj.\'qom / eapRd[3hqf,tu^:i 45 htv: / / >fwgeo]6zTle"BjM.\'qom / eaR[3hqf,tu^:i

[0045] The efficiency and / or effectiveness of fuzzing can refer to various fuzzer evaluation metrics, e.g., different measures of code coverage or the number of bugs found.

[0046] For reinforcement learning with regard to this optimization goal (efficiency and / or effectiveness), a reward and a representation of a subsequent state are derived from an action that the agent selects and executes in an “environment”, which is then fed back to the RL agent for the selection of the next action.

[0047] Fig. 2 illustrates the training of a selection strategy for fuzzing according to one embodiment.

[0048] The selection strategy is implemented by an agent 201. For each fuzzing iteration, the agent 201 selects an action 202 for the fuzzer 203 and receives a reward 204 and a subsequent state 205. The agent's goal is to maximize the rewards for the actions it performs. In doing so, it can follow an RL algorithm that realizes a trade-off between exploration (discovering new parts of the input space about which the agent has little or no information) and exploiting the knowledge (prioritization and mutation of test cases that performed best in previous fuzzing iterations) that the agent has acquired so far.

[0049] For example, the elements of reinforcement learning for a current fuzzing iteration are as follows: - The state of the environment (or the system to be controlled) is expressed as the encoding of the reference test case selected for the last fuzzing iteration, i.e., the reference test input from corpus 208 that was mutated to generate the test input for the last fuzzing iteration, and as an array of bytes representing the test input of the last fuzzing iteration (i.e., the mutated selected reference test input). It should be noted that when deep reinforcement learning (Deep RL, e.g., deep Double-Q learning) is used, explicit modeling of the state space can be omitted. - Each action A involves selecting the reference test input that will be mutated to generate the test input 206 for the computer program 207 for the current fuzzing iteration, and the mutation used to perform this mutation. The selection of the mutation can include selecting a sequence of base mutations (see examples above). Thus, at each fuzzing iteration, the agent 201 is faced with the decision of whether to modify the same reference test input as in the last fuzzing iteration (e.g., to continue mutating it) or to mutate a different reference test input. - The reward function R a(s, s'), a ∈ A, s, s' ∈ S, where s is the state in which action a is executed and s' is the achieved subsequent state, is designed such that agent 201 is rewarded if the selected action increases the overall code coverage achieved so far in testing. Various measures of code coverage can be used here (e.g., line coverage, path coverage, edge coverage). Testing can start with test runs for an initial set of reference test inputs (with which corpus 208 is initialized), so that a certain coverage is achieved thereafter, which can then be successively increased through the actions of agent 201. - Any standard RL method that can handle discrete action and state spaces can be used as the RL algorithm, such as various versions of Q-learning, SARSA (State Action Reward State Action), deep reinforcement learning, etc.

[0050] The fuzzing of the computer program 207 is thus carried out, for example, as follows: 1) The fuzzer 203 is initialized, ie the observations of the fuzzer 203 are empty or are set to the results of test runs for the reference test inputs (seeds) initially contained in the corpus 208. 2) At each fuzzing iteration, the RL agent 201 selects which reference test input from the corpus should be mutated and which mutations should be applied to generate the test input for the current fuzzing iteration. As mentioned above, this includes the possibility of applying further mutations to an already modified reference test input from the previous fuzzing iteration. 3) A test run is executed with the test input generated for the current fuzzing iteration, and a reward 209 is calculated (e.g., the achieved coverage (or its increase by the current fuzzing iteration) is observed and evaluated). The agent receives its reward based on this observation. If the coverage has increased, the test input is added to the fuzzer's corpus 208 as a reference test input. 4) Steps 2) and 3) are repeated. 5) The testing process stops when, for example, the user decides to do so or when a certain termination criterion is met (e.g. a certain time has elapsed or a certain coverage has been achieved).

[0051] In summary, according to various embodiments, a method is provided as described in Fig. 3 shown.

[0052] Fig. 3 shows a flowchart 300 illustrating a method for testing a computer program according to one embodiment.

[0053] Several test iterations are carried out, where - in 301, for each test iteration, a reference test input and a mutation for the reference test input are selected according to a selection strategy, and a test input for the computer program is generated by applying the selected mutation to the selected reference test input; - in 302, for each test iteration, a test run of the computer program is carried out with the respective generated test input for the computer program (ie, the computer program is executed with the respective generated test input); - in 303, a test coverage increase is determined for each test iteration, which is achieved by the test run - in 304, the selection strategy is trained using reinforcement learning, using the test coverage increases as rewards.

[0054] The multiple test runs need not include all the test runs performed for testing the computer program; for example, additional test runs may also be performed for the reference test inputs themselves. Furthermore, it should be noted that, even if Fig. 3 is shown in such a way that a training step does not have to be performed for each test iteration, but several test iterations can be combined into one training step (ie training can be done on the basis of batches of test iterations).

[0055] The procedure of Fig.3 can be performed by one or more computers having one or more data processing units. The term “data processing unit” can be understood as any type of entity that enables the processing of data or signals. The data or signals can, for example, be treated according to at least one (i.e., one or more than one) specific function performed by the data processing unit. A data processing unit can comprise or be formed from an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array (FPGA) integrated circuit, or any combination thereof.Any other way of implementing the respective functions described in more detail herein may also be understood as a data processing unit or logic circuit arrangement. One or more of the method steps described in detail herein may be performed (e.g., implemented) by a data processing unit through one or more specific functions performed by the data processing unit.

[0056] According to various embodiments, the method is therefore particularly computer-implemented. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited non-patent literature

[0000] http: / / www.google.com / search?q=fuzzing

[0044] http: / L / www.googlej.com / seaRchq=fuz:ing

[0044] http: / L / www.ggoWglej.com / seaRchqfu:in

[0044] http: / L / wwggoWglej.com / seaR3hqf,u:in

[0044]

Claims

[1] A method for testing a computer program (105), comprising: Performing a plurality of test iterations, wherein for each test iteration a reference test input and a mutation for the reference test input are selected according to a selection strategy (201), and a test input for the computer program (105) is generated by applying the selected mutation to the selected reference test input; wherein for each test iteration a test run of the computer program (105) is performed with the respective generated test input for the computer program (105); wherein for each test iteration a test coverage increase (209) achieved by the test run is determined; and wherein the selection strategy (201) is trained by means of reinforcement learning, wherein the test coverage increases (209) are used as rewards (204). [2] The method of claim 1, wherein for at least some of the test iterations, the selection of the mutation comprises a selection of a sequence of base mutations. [3] The method of claim 1, wherein for at least some of the test iterations, the selection of the mutation comprises a selection of a sequence of base mutations that continues a sequence of base mutations with which the test input was generated for a previous test iteration. [4] The method of claim 2 or 3, wherein the base mutations are one or more of: inverting a single bit for a particular bit position, setting a data item at a particular position to a predetermined value, adding or subtracting a predetermined number to / from a data item at a particular position, setting a data item at a particular position to a random value, removing a data item at a particular position, duplicating a data item at a particular position. [5] Method according to one of claims 1 to 4, wherein for each test iteration the reference test input and the mutation are selected according to the selection strategy (201) depending on the test input of a previous test iteration. [6] Method according to one of claims 1 to 5, wherein the computer program (105) is a control program for a robot device and the robot device is controlled with the computer program (105) depending on a result of the testing of the computer program (105). [7] Test arrangement (100) which is arranged to carry out a method according to one of claims 1 to 6. [8] A computer program comprising instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 6. [9] A computer-readable medium storing instructions which, when executed by a processor, cause the processor to perform a method according to any one of claims 1 to 6.

Images