Method for testing computer program

Abstract

According to various embodiments, a method for testing a computer program is described, the method comprising: setting one or more breakpoints onto one or more string output instructions in the computer program; executing a computer program; upon triggering one of the set breakpoints, determining whether a character string provided for output to a character string output function invoked by a corresponding character string output instruction contains one or more format specifications for the computer program (105) for more values than provided as an argument to the corresponding character string output function; and triggering a display that the computer program has an error in response to determining that a character string provided to a character string output function for output contains one or more format specifications for the computer program (105) for more values than provided to the respective character string output function as an argument.

Description

Technical Field

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

[0002] An important part of developing software applications is testing and the corresponding error clearing when errors are found. In particular, errors that lead to application failures should be identified and corrected. An important aspect here is testing with the view that important memory areas are not accessed accidentally (or by an attacker), i.e. using memory monitoring such as that performed by so-called (memory) sanitizers. Compiling and testing software on common desktop and server hardware such as x86 with the help of various sanitizers is a measure that can discover errors such as the Heartbleed bug that previously remained undiscovered for a long time.

[0003] Comprehensive testing that also includes such memory monitoring is particularly important for computer programs on often safety-relevant embedded systems, such as control devices for vehicles. However, sanitizers for desktop and server hardware cannot be used or can only be used poorly for such systems, since embedded systems typically have restricted resources and such sanitizers have a huge resource requirement and therefore cannot be used or can even affect the execution of the computer program so that errors occur in the first place or remain undetected. Summary of the invention

[0004] Therefore, a method for testing a computer program that can implement memory monitoring and is applicable to embedded systems is desirable.

[0005] According to various embodiments, a method for (automatically) testing a computer program is provided, the method comprising: setting one or more breakpoints to one or more string output instructions in the computer program; executing the computer program; when one of the set breakpoints is triggered, determining whether a string provided to a string output function called by the corresponding string output instruction for output contains one or more format specifications for the computer program for more values ​​than provided to the corresponding string output function together with an independent variable; and in response to determining that the string provided to the string output function for output contains one or more format specifications for the computer program for more values ​​than provided to the corresponding string output function together with an independent variable, triggering a display that the computer program has an error.

[0006] This can be done for each or at least a plurality of character string output instructions occurring in the computer program (eg depending on how many breakpoints are available).

[0007] The above method enables testing with detection of dangerous strings on embedded systems with the aid of a debugger. This is particularly applicable when testing with fuzz testing, since fuzz testing can also be implemented in a debugger-controlled manner and can be effectively used on embedded systems in this way.

[0008] Sanitizers can be implemented with the aid of code instrumentation. However, for this purpose either the source code must be available or command set-specific instrumentation based on binaries (binary instrumentation) is required, which is very susceptible. The alternative emulator-based instrumentation is also very platform-specific, and each embedded platform requires its own emulator. The method described above enables testing with a debugger-controlled sanitizer without the need for instrumentation or emulation, and can therefore be applied in many cases.

[0009] Various embodiments are described below.

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

[0011] Embodiment 2 is a method according to embodiment 1, including, in response to determining that a string provided to a string output function for output contains one or more format specifications for the computer program for more values ​​than provided to the corresponding string output function as an independent variable, triggering a display that the computer program has an error by triggering the termination (i.e., crash) of the computer program.

[0012] Thus, for example, within the scope of fuzz testing, a computer program can be marked as faulty because its execution causes an abort (i.e. a crash) of the computer program, whereupon the fuzzifier displays an error. For example, a warning can also be output on the STDERR stream or the debugger can be monitored on the host side (i.e. on a test system that tests the computer program on the execution system with the aid of a debugger).

[0013] Embodiment 3 is a method according to embodiment 1 or 2, wherein a string for at least one of the string output instructions is provided as a pointer to the called string output function for output, and it is determined whether the string contains one or more format specifications for a computer program for more values ​​than those provided to the corresponding string output function as an independent variable, by checking whether the content of the storage area pointed to by the pointer contains one or more format specifications for a computer program (and determining their number if necessary and comparing them with the number of values ​​provided to the string output function as an independent variable).

[0014] In particular, character strings which are not explicitly specified but rather specified by means of pointers increase the risk of errors (and therefore security holes) which can be detected in this way.

[0015] An embodiment is a method according to any one of exemplary embodiments 1 to 3, wherein it is determined whether a string provided to a called string output function for output contains one or more format specifications for a computer program for more values ​​than are provided to the corresponding string output function together as an independent variable, by traversing the string output function called by the string output instruction in individual steps and determining the provided string in the process.

[0016] This may depend on whether the memory output function better or simpler implements the determination of the string.

[0017] Embodiment 5 is a method according to any one of embodiments 1 to 4, wherein a string is provided to a called string output function for at least one of the string output instructions at least in part with the aid of a stack, and it is determined whether the string contains one or more format specifications for a computer program for more values ​​than those provided to the corresponding string output function as an independent variable, by checking the stack to determine whether the string provided to the called string output function contains one or more format specifications for the computer program (and, if necessary, determining their number and comparing it with the number of values ​​provided to the string output function as an independent variable).

[0018] For example, the stack may have one or more pointers to the symbolic chain being checked. This allows checking to be done even if the number of arguments is so high that the argument registers are insufficient for said arguments.

[0019] Embodiment 6 is a method according to any one of embodiments 1 to 5, comprising executing multiple test passes (eg, fuzz test passes, i.e., fuzz test iterations) and setting breakpoints to different string output instructions for different test passes.

[0020] This covers a large number of string output instructions.

[0021] Embodiment 7 is a method according to any one of embodiments 1 to 6, comprising executing a computer program on an embedded system, and performing the following steps through a test system connected to the embedded system (via a debugging interface): setting breakpoints, determining whether the corresponding string contains one or more format specifications for the computer program for more values ​​than are provided to the corresponding string output function as independent variables, and triggering a display if necessary: ​​the computer program has an error.

[0022] According to various embodiments, in particular, testing of a computer program for an embedded system, including memory monitoring, is enabled on the embedded system itself.

[0023] Embodiment 8 is a method according to any one of Embodiments 1 to 7, wherein the computer program is a control program for a robotic device, and the robotic device is controlled using the computer program based on a result of a test of the computer program.

[0024] Embodiment 9 is a testing device configured to perform the method according to any one of embodiments 1 to 8.

[0025] Embodiment 10 is a computer program having instructions, which, when executed by a processor, cause the processor to perform the method according to any one of embodiments 1 to 8.

[0026] Embodiment 11 is a computer-readable medium storing instructions, and when the instructions are executed by a processor, the instructions cause the processor to perform the method according to any one of embodiments 1 to 8. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In the accompanying drawings, similar reference numerals generally refer to the same parts throughout the various views. The accompanying drawings are not necessarily drawn to scale, with emphasis instead generally being placed on illustrating the principles of the invention. In the following description, various aspects are described with reference to the following drawings.

[0028] Figure 1 A computer used to develop and / or test software applications is shown.

[0029] Figure 2 A flow chart is shown which illustrates a method for testing a computer program according to one embodiment. DETAILED DESCRIPTION

[0030] The following detailed description relates to the attached drawings, which illustrate specific details and aspects of the present disclosure that can perform the present invention for the purpose of illustration. Other aspects may be used and structural, logical and electrical changes may be made without departing from the scope of protection of the present invention. Because some aspects of the present disclosure may be combined with one or more other aspects of the present disclosure to form new aspects, the various aspects of the present disclosure are not necessarily mutually exclusive.

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

[0032] Figure 1 A computer 100 is shown for use in developing and / or testing software applications.

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

[0034] In the present example it is assumed that a user intends to utilize computer 100 to develop and / or test a software application.

[0035] To this end, the user executes the software development environment 104 on the CPU 101 .

[0036] The software development environment 104 enables users to develop and test applications 105 for various devices 106, i.e., for target hardware (such as embedded systems for controlling robotic devices including robot arms and autonomous vehicles) or for mobile (communication) devices. To this end, the CPU 101 can execute an emulator as part of the software development environment 104 to simulate the behavior of the corresponding device 106 for which the application is to be or has been developed. If the software development environment 104 is only used to test software from other sources, the software development environment 104 can also be regarded as or designed as a software testing environment.

[0037] The user can distribute the finished application to the corresponding device 106 via the communication network 107. Instead of via the communication network 107, this can also be done in other ways, for example by means of a USB stick.

[0038] Before this occurs, however, the user should test the application 105 to avoid distributing an application to the device 106 that does not function as specified.

[0039] One testing method is so-called fuzz testing. Fuzz testing (Fuzzing or Fuzz-Testing) is an automated software testing method in which invalid, unexpected or random data is fed as input to the computer program to be tested. The program is then monitored for anomalies such as crashes, lack of failed built-in code assertions or potential memory leaks.

[0040] Typically, fuzzers (i.e., test programs using fuzz testing) are used to test programs that process structured inputs. The structure is specified, for example, in a file format or file format or protocol and distinguishes between valid and invalid inputs. An effective fuzzer produces 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 reveal unexpected behavior and edge cases that are not properly handled in the program under test.

[0041] The following describes the terminology used in conjunction with fuzz testing:

[0042] Fuzz testing (Fuzzing or Fuzz-Testing) is an automated testing process that sends randomly generated inputs to a target program (the program under test) and observes its responses.

[0043] A fuzzer or fuzz testing engine is a program that automatically generates input. Therefore, the fuzzer or fuzz testing engine is not associated with the software under test and does not perform instrumentation. However, the fuzzer or fuzz testing engine has the ability to instrument code, generate test cases and execute the program under test. Known examples are afl and libfuzzer.

[0044] A fuzz target is a software program or function that should be tested by fuzz testing. The main feature of a fuzz target should be that it takes potentially untrusted inputs generated by the fuzzer during the fuzz testing process.

[0045] A fuzz test is a combined version of a fuzzer and a fuzz target. Thus, a fuzz target can be instrumented code, where the fuzzer is associated with its input (i.e., provides the input). Fuzz tests are executable. A fuzzer can also start, observe, and stop multiple fuzz tests (typically hundreds or thousands per second), each with slightly different inputs generated by the fuzzer.

[0046] A test case is a specific input and a specific test run from a fuzz test. Usually, the runs that are of interest for reproducibility (finding new code paths or crashes) are stored. In this way, a specific test case with the corresponding input can also be executed on a fuzz target that is not connected to the fuzzer, such as a released version of the program.

[0047] Coverage-guided fuzzing uses code coverage information as feedback during fuzz testing to identify whether an input causes the execution of new code paths or blocks.

[0048] Generator-based fuzz testing (English: generation-based fuzzing) uses prior knowledge about the target program (fuzz target) to create test inputs. An example of such prior knowledge is the grammar corresponding to the input specification of the fuzz target, i.e. the input grammar of the fuzz target (i.e. the program to be tested).

[0049] Static instrumentation is the insertion of commands into a program (to be tested) to obtain feedback about the execution. The static instrumentation is mostly implemented by the compiler and can, for example, describe the code blocks reached during execution.

[0050] Dynamic instrumentation is controlling the execution of a program (to be tested) during runtime to generate feedback from the execution. The dynamic instrumentation is mostly implemented by operating system functionality or by using an emulator.

[0051] A debugger is a device or a program that can control a target device or a target program and can provide functions such as for calling register values ​​or memory values ​​and for pausing and executing a target program in individual steps.

[0052] ·Breakpoints are set by the debugger on commands of the target program or device so that execution stops when they are reached and the controlling process is notified of this.

[0053] Setting a (data) watchpoint by the debugger at a memory address of the target program or target device, so that execution is halted when the memory address is accessed, and the controlling process is informed of this by triggering an interrupt.

[0054] Embedded systems usually have a microcontroller that processes inputs and responds with outputs to perform specific tasks. Although microcontrollers use the same memory model as conventional user programs and are programmed using the same programming language, microcontroller programs are significantly more difficult to test. In order to enable debugging, microcontrollers usually provide the following possibilities: interrupting the program using breakpoints (stop points), traversing the commands of the program in individual steps, and setting watchpoints on storage addresses. When accessing the corresponding storage area, the watchpoint triggers an interrupt. Hardware breakpoints and watchpoints are typically implemented as physical registers in the debugging unit of the microcontroller, and therefore their number is limited and depends on the corresponding system. For example, for a typical microcontroller, the maximum number is four breakpoints and two data watchpoints. Usually watchpoints can be distinguished between read access and write access.

[0055] In particular, breakpoints and watchpoints can be used to implement debugger-controlled fuzz testing, eliminating the need for instrumentation.

[0056] Fuzz testing (and debugger-controlled fuzz testing) is very effective at finding bugs that trigger observable behavior, such as crashes or reboots. However, not all classes of bugs can be observed because the program silently fails on them. An example is the Heartbleed vulnerability. The core of the Heartbleed vulnerability is that Heartbleed only reads out of bounds of an array, while writes result in segmentation faults that are easily observable.

[0057] The Heartbleed vulnerability was only found with the help of Address Sanitizer (ASan). ASan inserts additional commands, metadata, and checks during the compilation of a program to prevent errors when memory is corrupted. When such Sanitizer commands are available in a program, more errors can be found when debugging the program than without the Sanitizer. Automated testing (such as fuzz testing) is particularly interesting when a Sanitizer is set up in the program to be tested (i.e. in the fuzz target) to find additional errors.

[0058] For embedded systems (such as data processing devices with ARM architecture), such sanitizers are not as easy to use as for standard platforms (such as x86 platforms). There are many reasons for this:

[0059] Embedded systems are too resource-constrained to implement a Sanitizer. For example, Asan requires double the memory, MSan (MemorySanitizer) requires 2.5 times the resources, and UBSan (UndefinedBehaviorSanitizer) even requires three times the working memory of the program.

[0060] The Sanitizer increases the size of the compiled binary. In the automotive industry, the size of such binaries often almost corresponds to the available flash memory of the target hardware. Therefore, the additional instrumentation of the Sanitizer does not fit in the flash memory.

[0061] The use of Sanitizers results in slower runtime of binaries on the corresponding hardware due to the Sanitizer's additional instrumentation and metadata collection and tracking. Embedded systems strongly depend on asynchronous events, such as interrupts, and thus Sanitizers may cause timing-based false positive errors, i.e., Sanitizers may introduce new errors during runtime.

[0062] Embedded systems usually do not have a user interface for displaying runtime errors. On x86 systems, for example, segmentation faults are forwarded to STDERR so that the user sees the crash. Instead, embedded systems fail silently, i.e. without the user noticing this, and restart after such a crash.

[0063] Therefore, according to various embodiments, a method is provided that enables memory monitoring (i.e., Sanitizer functionality) to be used for embedded systems, in particular, enables memory monitoring to be used for debugger-controlled fuzz testing. Here, the memory monitoring itself can be implemented with the aid of a debugger (or a debugger for fuzz testing) (the debugger does not need to be running on the execution system).

[0064] In debugger-based fuzz testing, the interaction between the system executing the test (and corresponding to, for example, the computer 100) and the target system (target hardware, such as an embedded system, such as the target device 106) is carried out via a debug connection (i.e., a debug interface), which is provided, for example, by a dedicated debugger hardware device. The test input data is transmitted to the target system 106 in the form of an input vector, for example, via WiFi or a CAN bus (depending on the type of the target device 106), that is, the communication network 107 is such a debug connection during this test (then when distributing the tested software, the communication network can be any other communication network). The system executing 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, that is, starts the execution and resumes the execution after an interrupt (especially an interrupt triggered by a data monitoring point).

[0065] The debugger-controlled Sanitizer does not require plugging or emulation, but only requires a debug interface with the target system (e.g., an embedded system on which the software is executed) with the possibility of setting breakpoints and monitoring points. This type of debug interface and debugging capabilities are universal and also available, which leads to the wide and simple applicability of the method described below. In addition, since most or all of the information related to the Sanitizer is collected and stored on the host side of the debugger (i.e., in the test system 100), the embedded system can also be tested with its completed version (e.g., the sold version), so the memory of the target system is only slightly loaded, for example, for metadata. The size of the compiled binary file of the target program does not increase, because the binary file is used during testing as if it were set for the target system 106.

[0066] When a breakpoint is reached, the debugger halts the target system. Therefore, the approach described below only leads to time-based monitoring alarms in rare cases. These false alarms can also be eliminated by other testing techniques, such as by subsequently verifying the errors found on the target system. Using a debugger also provides a good view of the internal affairs of the target system.

[0067] The method described below is used to detect dangerous strings (i.e., strings with dangerous format specifications) in string output instructions (i.e., instructions similar to printf), such as printf, sprintf, and vprintf. A string with a dangerous format specification is, for example, a string containing "%" in C, as illustrated in the following example.

[0068] const char*someString=bar.c_str();

[0069] printf(someString);

[0070] If someString contains, for example, "%x_%x_%x", the printf instruction outputs the current value in the argument register (the argument register of the execution processor), which may contain secret information, where other format specifications such as %f, %d, %c, %i (and corresponding format specifications in other programming languages) can also be used instead of %x here.

[0071] In case of a higher number of "%x" in the string, it is even possible to output the current value of the stack:

[0072] Table 1 shows the typical structure of a stack frame for a called subroutine. Each row represents a storage location.

[0073]

[0074] Table 1

[0075] If the string has a high enough number of "%x"s (especially more than the values ​​provided as arguments to the printf function), the output can extend past the subroutine call parameters to local variables, or even extend beyond the local variables. An attacker can even overwrite the stack using the format specification "%n", making it possible for the attacker to take over the execution system.

[0076] According to various embodiments, in order to avoid such attacks and leakage of secret information, it is checked whether the string (i.e., the content of the pointer) has a dangerous symbol or a combination of dangerous symbols (corresponding to the format specification), and as long as the corresponding string output function is not provided with enough values ​​for output, a safety measure is triggered when such a dangerous symbol or a combination of dangerous symbols is detected (for example, a crash is triggered so that the test program is identified as having an error during fuzz testing). An embodiment of this is described below. As described above, it is assumed here that the test system 106 is connected to the execution system (e.g., embedded system) 106 by means of a debug connection, and the execution of the computer program to be tested on the execution system is tested by means of a debugger.

[0077] For example, the test system 100 executes the following (specifically targeting the printf function here, but the following can be applied to any string output instruction or string output function):

[0078] 1. Set one or more breakpoints to the printf function in the computer program to be tested (i.e., call the printf function, i.e., string output instruction). In order to select the printf function to which the breakpoint in the printf function is set, various strategies can be used (e.g., randomly or based on a list processed in multiple fuzz testing iterations, so that each printf function is, for example, already equipped with a breakpoint in at least one fuzz testing iteration, i.e., in order to test all printf functions, if there are not enough breakpoints available for all printf functions, the same test case can be executed for different placements of breakpoints.).

[0079] 2. When executing the computer program, if one of the set breakpoints is triggered, ie, printf is called, the test system 100 reads the content of the string (ie, the pointer) provided together with the call (as an argument).

[0080] 3. If the content contains dangerous format specifications, such as "%x" or "%n", and insufficient values ​​are provided to the corresponding string output function as arguments for these format specifications, a warning is output or a crash is caused. For example, the test system 100 can trigger a crash by triggering a reset via a debugger or setting a program counter to an error handling routine.

[0081] Instead, the test system 100 executes the following (again specifically targeting the printf function here, but the following can be applied to any string output instruction):

[0082] 1. As above, set the breakpoint to the printf function in the computer program to be tested (that is, call the printf function).

[0083] 2. When executing a computer program, if a breakpoint is triggered, ie, printf is called, the test system 100 uses a debugger to enter the printf function (eg, by means of single-step debugging) or pass through the printf function and read out the content to be output.

[0084] 3. If the content contains dangerous format specifications, such as "%x" or "%n", and insufficient values ​​are provided to the corresponding string output function as arguments for these format specifications, a warning is output or a crash is caused. For example, the test system 100 can trigger a crash by triggering a reset via a debugger or setting a program counter to an error handling routine.

[0085] For example, entering ("stepping into") or stepping through the printf function is stepping through the individual steps of the assembler instructions of the printf function.

[0086] printf(someString)

[0087] Translates to the following assembler instructions:

[0088] pushq %rbp

[0089] movq %rsp,%rbp

[0090] movq someString(%rip),%rax

[0091] movq %rax,%rdi

[0092] movl$0,%eax

[0093] call printf@PLT

[0094] For the case where multiple parameters are given to (one or more) printf functions, so that all pointers are transferred via the stack, as another alternative, the test system 100 performs the following (again specifically for the printf function here, but the following can be applied to any string output instruction):

[0095] 1. As above, in the computer program to be tested, a breakpoint is set to the printf function (i.e., the printf function is called) (here, it specifically refers to the printf function, and multiple parameters are transferred to the printf function by means of a stack).

[0096] 2. When executing the computer program, if a breakpoint is triggered, ie, printf is called, the test system 100 uses a debugger to check the stack (and the storage area pointed to by the transferred pointer).

[0097] 3. If the checked storage area, i.e. the content to be output, contains dangerous format specifications, such as "%x" or "%n", and no sufficient values ​​are provided as arguments for these format specifications to the corresponding string output function, a warning is output or a crash is caused. For example, the test system 100 can trigger a crash by triggering a reset via a debugger or setting a program counter to an error handling routine.

[0098] In summary, according to various embodiments, there is provided Figure 2 The method shown in .

[0099] Figure 2 A flow chart 200 is shown which represents a method for testing a computer program according to one specific embodiment.

[0100] In 201 , one or more breakpoints are set in a computer program to one or more string output instructions.

[0101] In 202, a computer program is executed, wherein in 203, when one of the set breakpoints is triggered, it is determined whether a string provided to a string output function called by a corresponding string output instruction for output contains one or more format specifications for the computer program for more values ​​than are provided to the corresponding string output function together with the arguments.

[0102] At 204, in response to determining that a string provided to a string output function for output contains one or more format specifications for a computer program for more values ​​than provided as arguments to the corresponding string output function, a display is triggered (ie, "initiated") that the computer program has an error.

[0103] Figure 2The method 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 processing of data or signals. For example, data or signals can be processed according to at least one (i.e., one or more) specific functions performed by the data processing unit. The data processing unit may include an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array integrated circuit (FPGA), or any combination thereof, or may be composed of an analog circuit, a digital circuit, a logic circuit, a microprocessor, a microcontroller, a central unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable gate array integrated circuit (FPGA), or any combination thereof. Any other means for implementing the corresponding functions described in more detail herein may also be understood as a data processing unit or a logic circuit device. One or more of the method steps described in detail here may be performed (e.g., implemented) by a data processing unit through one or more specific functions performed by the data processing unit.

[0104] Figure 2 The control software can be used in a test program in a manner such as control software for a robotic device. The term "robotic device" may be understood to refer to any technical system, such as a computer-controlled machine, a vehicle, a household appliance, a power tool, a manufacturing machine, a personal assistant or an access control system. The control software can also be used for data processing systems, such as navigation equipment.

[0105] Figure 2 The method is for example performed by a test device (e.g. Figure 1 computer 100 and target device 106) to execute.

[0106] Although specific embodiments have been shown and described herein, it is recognized by those skilled in the art that the specific embodiments shown and described may be replaced by various alternatives and / or equivalent implementations without departing from the scope of protection of the present invention. The present application should encompass any adaptation or variation of the specific embodiments discussed herein. Therefore, the present invention is intended to be limited only by the claims and their equivalents.

Claims

1. A method for testing a computer program (105), the method comprising: Setting one or more breakpoints at one or more string output instructions in the computer program (105); Executing the computer program (105); determining, upon triggering one of the set breakpoints, whether a string supplied to a string output function called by a corresponding string output instruction for output contains one or more format specifications for the computer program (105) for more values ​​than were supplied to the corresponding string output function as arguments; as well as In response to determining that a string provided to the string output function for output contains one or more format specifications for the computer program (105) for more values ​​than were provided as arguments to the corresponding string output function, triggering a display that the computer program (105) has an error.

2. The method of claim 1 , comprising triggering the display that the computer program (105) has an error by triggering termination of the computer program (105) in response to determining that a string provided to the string output function for output contains one or more format specifications for the computer program (105) for more values ​​than are provided to the corresponding string output function as an independent variable.

3. A method according to claim 1 or 2, wherein a string for at least one of the string output instructions is provided as a pointer to the called string output function for output, and it is determined whether the string contains one or more format specifications for the computer program (105) for more values ​​than are provided to the corresponding string output function as an independent variable, by checking whether the content of the storage area pointed to by the pointer contains one or more format specifications for the computer program (105).

4. A method according to any one of claims 1 to 3, wherein it is determined whether a string provided to a called string output function for output contains one or more format specifications for the computer program (105) for more values ​​than are provided to the corresponding string output function as an independent variable, by traversing the string output function called by the string output instruction in individual steps and determining the provided string in the process.

5. A method according to any one of claims 1 to 4, wherein the string is provided to a string output function called for at least one of the string output instructions at least in part with the aid of a stack, and a determination is made as to whether the string contains one or more format specifications for the computer program (105) for more values ​​than are provided to the corresponding string output function as an independent variable, by checking the stack to determine whether the string provided to the called string output function contains one or more format specifications for the computer program (105). 6 . The method according to claim 1 , comprising executing a plurality of test passes and setting breakpoints at different string output instructions for different test passes.

7. The method according to any one of claims 1 to 6, comprising: The computer program (105) is executed on an embedded system (106) and the following steps are performed by a test system (100) connected to the embedded system (106): setting breakpoints, determining whether the corresponding string contains one or more format specifications for the computer program (105) for more values ​​than are provided as arguments to the corresponding string output function; and, if necessary, triggering a display that the computer program (105) has an error.

8. The method according to any one of claims 1 to 7, wherein the computer program (105) is a control program for a robotic device, and the robotic device is controlled by using the computer program (105) based on the results of the test of the computer program (105). 9 . A testing device configured to carry out the method according to claim 1 .

10. A computer program having 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 according to any one of claims 1 to 8.

Images