Method for testing computer program

Abstract

To provide a method that tests a computer program.SOLUTION: A method for testing a computer program includes the steps of: setting one or more breakpoints on one or more string output instructions in a computer program; executing the computer program; when one of the breakpoints is triggered, determining whether the string to be provided for outputting to a string output function called by each string output instruction includes one or more format designation about a computer program (105) as to more values than that to be provided to respective string output functions as an argument; and, in response to determining that the string includes the one or more format designation as to the more values than that to be provided to respective string output functions as the argument, triggering a display indicative of the computer program having an error.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present disclosure relates to a method for testing a computer program. [Background technology]

[0002] An important component in the development of software applications is testing and, if errors are found, the appropriate resolution of errors. In particular, errors that lead to the failure of the application need to be identified and fixed. Here, a key aspect is testing that critical memory areas are not accessed unintentionally (or by an attacker), i.e. with memory monitoring done by so-called (memory) sanitizers. Compiling and testing software on common desktop and server hardware, such as x86, with various sanitizers is one way that errors that have remained undiscovered for a long time, such as the Heartbleed bug, can be found.

[0003] Such comprehensive testing, including memory monitoring, is particularly important for computer programs on embedded systems, such as, for example, controls for vehicles, which are often safety critical. However, sanitizers used for desktop and server hardware are not available or are only available poorly for such systems because embedded systems typically have limited resources available, and such sanitizers have significant resource demands and therefore cannot be used or may even affect the execution of the computer program, causing errors to occur or remain undiscovered. Summary of the Invention

[0004] Therefore, a method for testing computer programs that allows memory monitoring and is suitable for embedded systems is desired. According to various embodiments, there is provided a method for (automatically) testing a computer program comprising the steps of setting one or more breakpoints on one or more string output instructions in the computer program; executing the computer program; determining, when one of the set breakpoints is triggered, whether a string provided for output to a string output function called by a respective string output instruction includes one or more formatting specifications related to the computer program for more values ​​than are provided as arguments to the respective string output function; and in response to determining that the string provided for output to the string output function includes one or more formatting specifications related to the computer program for more values ​​than are provided as arguments to the respective string output function, triggering an indication that the computer program has an error.

[0005] This may be done for each string output instruction occurring within the computer program, or at least for multiple string output instructions (eg, depending on the number of available breakpoints).

[0006] The above method allows to detect and test dangerous Strings (or Zeichenketten) on embedded systems using a debugger, which is particularly suitable for testing using fuzzing, since fuzzing can also be implemented under debugger control and thus effectively used for embedded systems.

[0007] Sanitizers can be implemented using code instrumentation. However, this requires that the source code is available or requires command set specific instrumentation based on binary files (binary instrumentation), which is very brittle. Emulator based instrumentation alternatives are similarly very platform specific, with each embedded platform needing its own emulator. The above method allows testing with debugger controlled sanitizers, does not require instrumentation or emulation, and is therefore applicable in many cases.

[0008] Various exemplary implementations are presented below. Exemplary embodiment 1 is a method for testing a computer program as described above.

[0009] Exemplary embodiment 2 is a method according to exemplary embodiment 1, comprising triggering an indication that the computer program has an error in response to determining that the string provided for output to the string output function contains one or more formatting specifications for the computer program for more values ​​than are provided as arguments to the respective string output function by triggering an interruption (i.e., a crash) of the computer program.

[0010] Thus, for example, in a fuzzing framework, a computer program may be marked as erroneous because execution of the computer program causes the computer program to abort (i.e., crash), and the fuzzer indicates an error. It may also, for example, issue a warning on the STDERR stream, or monitor a debugger on the host side (i.e., a test system that tests the computer program on the execution system with a debugger).

[0011] Exemplary embodiment 3 is a method according to exemplary embodiment 1 or 2, in which a string for at least one of the string output instructions is provided for output as a pointer to a called string output function, and the contents of the memory area to which the pointer points are checked for whether they include one or more formatting specifications for the computer program (and possibly the number of formatting specifications is determined and compared with the number of values ​​provided as arguments to the string output function), thereby determining whether the string includes one or more formatting specifications for the computer program for more values ​​than are provided as arguments to the respective string output function.

[0012] Strings that are not specified explicitly, but rather using pointers, increase the risk of errors (and possibly security leaks) that can be detected in this way. Exemplary embodiment 4 is the method of any one of exemplary embodiments 1 to 3, wherein a string output function called by a string output instruction is stepped through and the string provided thereto is determined to determine whether the string provided for output to the called string output function includes one or more formatting specifications for the computer program for more values ​​than are provided as arguments to the respective string output function.

[0013] This may allow better or easier determination of the string depending on the memory output capabilities. Exemplary embodiment 5 is a method according to any one of exemplary embodiments 1 to 4, wherein a string to the called string output function is provided, at least in part, by a stack for at least one of the string output instructions, and the stack is checked for whether the string provided to the called string output function includes one or more formatting specifications for the computer program (and possibly the number of formatting specifications is determined and compared to the number of values ​​provided as arguments to the string output function) to determine whether the string includes one or more formatting specifications for the computer program for more values ​​than are provided as arguments to the respective string output function.

[0014] For example, the stack may have one or more pointers to the strings being checked, allowing checking even when there are so many arguments that the argument registers are not sufficient.

[0015] Exemplary embodiment 6 is a method according to any one of exemplary embodiments 1 to 5, comprising performing multiple test runs (e.g., fuzzing test runs, i.e., fuzzing iterations) and setting breakpoints on different string output instructions for each test run.

[0016] This makes it possible to cover a large number of character string output commands. Exemplary embodiment 7 is a method according to any one of exemplary embodiments 1 to 6, comprising executing the computer program on an embedded system, setting breakpoints, and determining whether each string includes one or more formatting specifications for the computer program for more values ​​than are provided as arguments to each string output function, and optionally triggering an indication by a test system connected to the embedded system (via a debug interface) that the computer program has an error.

[0017] Various embodiments enable testing of computer programs for embedded systems, particularly on the embedded system itself, including memory monitoring. Exemplary embodiment 8 is a method according to any one of exemplary embodiments 1 to 7, wherein the computer program is a control program for a robotic device, and the robotic device is controlled by the computer program depending on the results of tests of the computer program.

[0018] Exemplary embodiment 9 is a test configuration designed to implement the method described in any one of exemplary embodiments 1 to 8. Exemplary embodiment 10 is a computer program comprising instructions which, when executed by a processor, cause the processor to perform the method according to any one of exemplary embodiments 1 to 8.

[0019] Exemplary embodiment 11 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 exemplary embodiments 1-8.

[0020] In the drawings, like reference numbers generally refer to the same parts throughout the different views. The drawings are not necessarily to scale, with emphasis generally being placed upon illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings: [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 illustrates a computer for developing and / or testing software applications. [Diagram 2] 1 is a flow diagram illustrating a method for testing a computer program according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] The following detailed description refers to the accompanying drawings, which are used to describe specific details and aspects of the present disclosure that can implement the present invention. Other aspects can be used and structural, logical, and electrical changes can be made without departing from the scope of protection of the present invention. Various aspects of the present disclosure are not necessarily mutually exclusive, since some aspects of the present disclosure can be combined with one or more other aspects of the present disclosure to form a new aspect.

[0023] Various examples are described in more detail below. FIG. 1 shows a computer 100 for developing and / or testing software applications.

[0024] The computer 100 includes a CPU (Central Processing Unit) 101 and a working memory (RAM) 102. The working memory 102 is used to load program code, for example, from a hard disk 103, and the CPU 101 executes the program code.

[0025] In this example, it is assumed that a user intends to use computer 100 to develop and / or test a software application. To this end, a user runs a software development environment 104 on the CPU 101 .

[0026] The software development environment 104 allows users to develop and test applications 105 for various devices 106, i.e. target hardware, such as embedded systems for the control of robotic devices, including robotic arms and autonomous vehicles, or also for mobile (communication) devices. For this purpose, the CPU 101 can run emulators as part of the software development environment 104 to simulate the behavior of the respective device 106 for which an application is being or has been developed. When used only for testing software from another source, the software development environment 104 can also be considered or configured as a software testing environment.

[0027] The user can distribute the completed application to a suitable device 106 via a communications network 107. Distribution can also be done in other ways than via a communications network 107, for example using a USB stick.

[0028] Before doing this, however, the user should test the application 105 to avoid distributing a non-functioning application to the device 106 .

[0029] One testing method is so-called fuzzing. Fuzzing or fuzz testing is an automated software testing method 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, failed built-in code assertions, and potential memory leaks.

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

[0031] The following explains the terms used in relation to fuzzing. Fuzzing or fuzz testing is an automated testing process that involves sending randomly generated inputs to a target program (the program under test) and observing the program's response.

[0032] A fuzzer or fuzzing engine is a program that generates inputs automatically. Thus, a fuzzer is not linked to or instrumented by the software under test, but has the ability to instrument the code, generate test cases, and run the program under test. Known examples are afl and libfuzzer.

[0033] A fuzz target is a software program or function that is to be tested by fuzzing. The main characteristic of a fuzz target is that it accepts potentially untrusted inputs generated by a fuzzer during the fuzzing process.

[0034] A fuzz test is a hybrid version of a fuzzer and a fuzz target. A fuzz target can be an instrumented piece of code to which a fuzzer is linked (i.e. provides input) and on which a fuzz test can be run. A fuzzer can also start, monitor, and stop multiple fuzz tests (usually hundreds or thousands per second), each containing slightly different inputs generated by the fuzzer.

[0035] A test case is a specific input and a specific test run from a fuzz test. Usually, interesting runs (discovery of new code paths or crashes) are remembered for reproducibility. In this way, a specific test case with the corresponding input can be run even against a fuzz target that is not connected to a fuzzer, e.g. a release version of a program.

[0036] Coverage-guided fuzzing uses code coverage information as feedback during fuzzing to recognize if an input causes a new code path or block to be executed.

[0037] Generation-based fuzzing uses prior knowledge about the target program (the fuzz target) to generate test inputs. An example of such prior knowledge is a grammar that corresponds to the input specification of the fuzz target, i.e. the input grammar of the fuzz target (i.e. the program under test).

[0038] Static instrumentation is the insertion of commands into a program (under test) to get feedback on its execution. This is mostly achieved by the compiler, which can for example show which code blocks were reached during execution.

[0039] Dynamic instrumentation is the control of the execution of a program (under test) during run-time to generate feedback from the execution. This is often achieved by system facilities of the operating system or by the use of an emulator.

[0040] A debugger is a device or program that can control a target device or a target program and can provide facilities, for example, for accessing register or memory values ​​and for pausing and stepping through the target program.

[0041] Breakpoints are set by the debugger in the target program or device commands, and when a breakpoint is reached, execution stops and the controlling process is notified.

[0042] A (data) watchpoint is set by the debugger at a memory address in the target program or device, and stops execution when the memory address is accessed, notifying the controlling process by triggering an interrupt.

[0043] Embedded systems typically utilize a microcontroller that processes inputs and responds with outputs to accomplish certain tasks. Although microcontrollers use the same memory model and are programmed in the same programming language as normal user programs, microcontroller programs are much harder to test. To allow debugging, microcontrollers typically provide the ability to halt a program with breakpoints (stop points), step through the program's commands, and set watchpoints on memory addresses. Watchpoints trigger interrupts when the corresponding memory regions are accessed. Hardware breakpoints and watchpoints are typically implemented as physical registers in the microcontroller's debug unit, and therefore their number is limited and depends on the respective system. For example, the maximum number for a typical microcontroller is four breakpoints and two data watchpoints. Usually, watchpoints can distinguish between read and write accesses.

[0044] Breakpoints and watchpoints can be used specifically to achieve debugger-controlled fuzzing, without the need for instrumentation. Fuzzing (as well as debugger-controlled fuzzing) is very efficient at finding errors that cause observable behavior, e.g. crashes or reboots. However, since the program only fails silently in the case of an error, it does not allow for observation of entire classes of errors. One example is the Heartbleed Bug. The essence of the Heartbleed Bug is that only reads beyond the bounds of an array, while write operations result in a segmentation fault that can be easily observed.

[0045] The Heartbleed bug was first discovered by Address Sanitizer (ASan), which inserts additional commands, metadata and checks during program compilation to avoid memory corruption errors. If such sanitizer commands are available in a program, more errors can be found when debugging the program than if the sanitizer were not present. In particular, automated testing such as fuzzing is more effective when sanitizers are provided to the program under test (i.e., the fuzz target) to find additional errors.

[0046] For embedded systems, such as data processing devices with ARM architecture, such sanitizers are not as readily available as for standard platforms, such as x86 platforms. There are several reasons for this.

[0047] Embedded systems are too resource-constrained to implement sanitizers. For example, Asan requires twice as much memory, MSan (MemorySanitizer) requires 2.5 times as many resources, and UBSan (UndefinedBehaviorSanitizer) requires 3 times the working memory of the program.

[0048] Sanitizers increase the size of the compiled binary file. In the automotive industry, the size of such binary files is usually close to the available flash memory of the target hardware. Therefore, the additional instrumentation of the sanitizers does not fit into the flash memory.

[0049] Due to the additional instrumentation of the sanitizers, as well as the collection and tracking of metadata, the use of the sanitizers slows down the runtime of the binary program on the respective hardware. Embedded systems rely heavily on asynchronous events, e.g. interrupts, and therefore the sanitizers may cause time-based false positive errors, i.e. the sanitizers may introduce new errors during runtime.

[0050] Embedded systems usually do not have a user interface to display run-time errors (e.g., on x86 systems, a segmentation fault is forwarded to STDERR so the user can see the crash), whereas embedded systems fail silently, i.e. without the user noticing, and reboot after such a crash).

[0051] Thus, according to various embodiments, an approach is provided that enables the use of memory monitoring (i.e., sanitizer functionality) for embedded systems, and in particular enables the use of memory monitoring for debugger-controlled fuzzing, where the memory monitoring itself is enabled by the debugger (or the debugger used for fuzzing) (without having to run on the execution system).

[0052] In debugger-based fuzzing, the interaction between the system performing the test (e.g. corresponding to the computer 100) and the target system (target hardware, e.g. an embedded system, e.g. the target device 106) takes place via a debug connection (i.e. a debug interface) provided, for example, by a dedicated debugger hardware device. Test input data, in the form of input vectors, are transmitted to the target system 106, for example via WiFi or a CAN bus (depending on the type of the target device 106), i.e. during this test, the communication network 107 is such a debug connection (during distribution of the tested software, the communication network can be any other communication network). The system performing the test (hereinafter also referred to as the test system 100) controls the execution of the target program (i.e. the program to be tested) in the target system via the debug connection, i.e. starting the execution and resuming the execution after an interrupt (in particular an interrupt triggered by a data watchpoint).

[0053] Debugger-controlled sanitizers do not require instrumentation or emulation, only a debug interface to the target system (e.g., the embedded system on which the software runs) with the ability to set breakpoints and watchpoints. These types of debug interfaces and debug features are versatile and widely available, which leads to wide and easy applicability of the approach described below. Furthermore, since most or all of the sanitizer-related information is collected and stored on the debugger host side (i.e., the system under test 100), there is a small burden on the memory of the target system, e.g., for metadata, and the embedded system can also be tested in its finished version (e.g., as sold). The size of the compiled binary file of the target program is not increased, since it can be used during testing as intended for use for the target system 106.

[0054] The debugger stops the target system when a breakpoint is hit. Therefore, the approach described below rarely results in time-based monitoring alarms. These false alarms can also be ruled out by other testing techniques, e.g. by verifying the found errors later on in the target system. Furthermore, the use of a debugger also provides a good insight into the internal structure of the target system.

[0055] The approach described below is used to detect dangerous strings (i.e. strings with dangerous formatting) in string output commands (i.e. printf-like commands), e.g. printf, sprintf, vprintf, etc. A dangerous formatting string is, in C, e.g. a string containing a "%" as shown in the following example: const char*someString=bar.c_str(); printf(someString); For example, if someString contains "%x_%x_%x", the printf instruction will output the current value of the argument register (of the executing processor), which may contain sensitive information, where instead of %x other formatting specifications could also be used, e.g. %f, %d, %c, %i (and corresponding formatting specifications in other programming languages).

[0056] By adding more "%x"s in the string, you can also print the current value of the stack. Table 1 shows a typical structure of a stack frame for a called subprogram. Each row represents a memory location.

[0057] [Table 1]

[0058] If a string has a sufficiently large number of "%x"s (especially if more are provided as arguments than the values ​​printed to the printf function), the output may reach through subprogram call parameters and into local variables, or even beyond. The "%n" format specification can also be used by an attacker to overwrite the stack, allowing the attacker to take control of the running system.

[0059] According to various embodiments, to avoid such attacks and leaking of sensitive information, the string (i.e. the contents of the pointer) is checked for dangerous characters or character combinations (corresponding to the format specification), and if such dangerous characters or character combinations are detected, security measures are triggered (e.g. a crash is triggered and the test program is recognized as erroneous during fuzzing) unless a sufficient value is provided for output in the respective string output function. An exemplary embodiment in this regard is described below. Here, as mentioned above, it is assumed that the test system 100 is connected to an execution system (e.g. an embedded system) 106 by a debug connection and tests the execution of the computer program to be tested on the execution system by a debugger.

[0060] For example, test system 100 performs the following (although specifically directed to the printf function here, the following can be applied to any string output command or function):

[0061] 1. Setting one or more breakpoints in the printf functions (i.e. in their calls, i.e. string output instructions) of the computer program under test. To select the printf functions in which the breakpoints are set, different strategies can be used (e.g. randomly or according to a list that is processed in several fuzzing iterations, i.e. each printf function is provided with a breakpoint in e.g. at least one fuzzing iteration, i.e. in order to test all printf functions, the same test case can be performed for different arrangements of breakpoints if there are not enough breakpoints to be used for all printf functions).

[0062] 2. During execution of the computer program, when one of the set breakpoints is triggered, i.e., when printf is called, the test system 100 reads the contents of the string (i.e., pointer) provided (as an argument) at the time of the call.

[0063] 3. If the content contains dangerous formatting specifications, such as "%x" or "%n", and sufficient values ​​are not provided as arguments to the respective string output functions for these formatting specifications, a warning will be issued or a crash will occur. For example, the test system 100 may trigger a crash by triggering a reset through the debugger or by setting the program counter to an error handler routine.

[0064] Alternatively, test system 100 does the following (again with particular reference to the printf function, but the following can be applied to any string output command): 1. Set a breakpoint on the printf function (i.e., its call) in the computer program under test, as described above.

[0065] 2. When the computer program is executed, when a breakpoint is triggered, i.e., when printf is called, the test system 100 uses a debugger to step into or through the printf function (e.g., by single-step debugging) and read what is output.

[0066] 3. If the content contains dangerous formatting specifications, such as "%x" or "%n", and sufficient values ​​are not provided as arguments to the respective string output functions for these formatting specifications, a warning will be issued or a crash will occur. For example, the test system 100 may trigger a crash by triggering a reset through the debugger or by setting the program counter to an error handler routine.

[0067] Stepping into or through a printf function means stepping through the assembler instructions of the printf function. For example, in the above example printf(someString) is translated into the following assembler instruction: pushq %rbp movq %rsp, %rbp movq someString(%rip), %rax movq %rax, %rdi movl $0, %eax call printf@PLT If the printf function is given multiple parameters and all pointers are passed via the stack, then as a further alternative, test system 100 performs the following (again with specific reference to the printf function, but the following can be applied to any string output command):

[0068] 1. Set a breakpoint on (i.e., on) the printf function (i.e., its call) in the computer program under test, as described above (here specifically, the printf function with multiple parameters passed to it by the stack).

[0069] 2. When the computer program is executed, when the breakpoint is triggered, ie, when printf is called, the test system 100 uses the debugger to inspect the stack (and the memory area pointed to by the passed pointer).

[0070] 3. If the checked memory range, i.e. the content to be output, contains dangerous formatting specifications, e.g. "%x" or "%n", and the respective string output function is not provided with sufficient values ​​as arguments for these formatting specifications, a warning is issued or a crash occurs. For example, the test system 100 may trigger a crash by triggering a reset by the debugger or by setting the program counter to an error handler routine.

[0071] In summary, according to various embodiments, a method is provided as shown in FIG. FIG. 2 shows a flow diagram 200 illustrating a method for testing a computer program according to one embodiment.

[0072] At 201, one or more breakpoints are set at one or more string output instructions in a computer program. At 202, the computer program is executed, and at 203, when one of the established breakpoints is triggered, it is determined whether the string provided for output to the string output function called by the respective string output instruction includes one or more formatting specifications for the computer program for more values ​​than are provided as arguments to the respective string output function.

[0073] At 204, in response to determining that the string provided for output to the string output functions includes one or more formatting specifications for the computer program for more values ​​than are provided as arguments to the respective string output functions, an indication that the computer program has an error is triggered (i.e., "triggered").

[0074] The method of FIG. 2 can be implemented by one or more computers with one or more data processing units. The term "data processing unit" can be understood as any type of entity that allows processing of data or signals. For example, data or signals can be processed according to at least one (i.e., one or more) special functions performed by the data processing unit. The data processing unit can include or be formed from analog circuits, digital circuits, logic circuits, microprocessors, microcontrollers, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable gate array integrated circuits (FPGAs), or any combination thereof. Any other manner of implementing the respective functions described in more detail herein can also be understood as a data processing unit or logic circuitry. One or more of the method steps individually described herein can be executed (e.g., implemented) by the data processing unit according to one or more special functions performed by the data processing unit.

[0075] The approach of Fig. 2 is used to test programs, e.g. control software for robotic devices. The term "robotic device" can be understood to relate to any technical system, e.g. computer-controlled machines, vehicles, household appliances, power tools, manufacturing machines, personal assistants, access control systems, etc. Control software can also be used in data processing systems, e.g. navigation devices.

[0076] The method of FIG. 2 is performed, for example, by a test arrangement (eg, computer 100 and target device 106 of FIG. 1). Although specific embodiments have been shown and described herein, those skilled in the art will recognize that the specific embodiments shown and described may be replaced with various alternative and / or equivalent implementations without departing from the scope of protection of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that the present invention be limited only by the claims and their equivalents. [Explanation of symbols]

[0077] 100 Computers, test systems 101 CPU 102 Working Memory 103 Hard Disk 104 Software Development Environment 105 Applications, computer programs 106 Devices, Embedded Systems 107 Communication Network

Claims

1. A method for testing a computer program (105), comprising the steps of: setting one or more breakpoints on one or more string output instructions in the computer program (105); Executing the computer program (105); determining, when one of the established breakpoints is triggered, whether a string provided for output to a string output function invoked by a respective string output instruction includes one or more formatting specifications for the computer program (105) for more values ​​than are provided as arguments to the respective string output function; in response to determining that the string provided for output to the string output functions includes one or more formatting specifications for the computer program (105) for more values ​​than are provided as arguments to each of the string output functions, triggering an indication that the computer program (105) has an error; The method includes:

2. 2. The method of claim 1, further comprising: in response to determining that the string provided for output to the string output function contains one or more formatting specifications for the computer program (105) for more values ​​than are provided as arguments to each of the string output functions, triggering an interruption of the computer program (105) to trigger an indication that the computer program (105) has an error.

3. 3. The method of claim 1, wherein the string for at least one of the string output instructions is provided for output as a pointer to a called string output function, and the contents of a memory area to which the pointer points are checked to determine whether the string contains one or more formatting specifications for the computer program (105) for more values ​​than are provided as arguments to the respective string output function.

4. 4. The method of claim 1, wherein a string output function called by the string output instruction is stepped through and the provided string is evaluated to determine whether the string provided for output to the called string output function includes one or more formatting specifications for the computer program (105) for more values ​​than are provided as arguments to the respective string output function.

5. 5. The method of claim 1, wherein the string to the called string output function is provided, at least in part, by a stack for at least one of the string output instructions, and wherein the stack is checked to determine whether the string provided to the called string output function includes one or more formatting specifications for the computer program (105) for more values ​​than are provided as arguments to the respective string output function.

6. 6. A method according to claim 1, comprising the step of performing multiple test runs and setting breakpoints at different string output instructions for each test run.

7. executing said computer program (105) on an embedded system (106), setting breakpoints, and determining whether each said string includes one or more format specifications for said computer program (105) for more values ​​than are provided as arguments to each said string output function; Optionally, triggering an indication by a test system (100) connected to said embedded system (106) that said computer program (105) has an error. The method according to any one of claims 1 to 6, comprising:

8. 8. The method according to claim 1, wherein the computer program (105) is a control program for a robotic device, the robotic device being controlled by the computer program (105) depending on the results of the tests of the computer program (105).

9. A test setup designed to implement the method according to any one of claims 1 to 8.

10. A computer program comprising instructions which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 8.

11. A computer readable medium storing instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 8.

Images