METHOD FOR TESTING A SYSTEM

Description

[0001] The invention relates to computer-implemented methods for testing a system, in particular a computer program, a hardware system or an embedded system, as well as computer programs and test systems set up for this purpose. State of the art

[0002] A well-known method for dynamically testing systems for vulnerabilities is fuzz testing (also known as fuzzy testing or fuzzing). In this approach, a system under test (SUT) is executed, typically a computer program or a part of a computer program. Execution depends on input variables that the system receives from a fuzzer. While the system is running, i.e., while the software is being executed by a computer, the fuzzer observes the behavior of the system under test. It flags the provided input variables as relevant to errors if the system under test terminates during execution or exhibits other undesirable behavior.

[0003] Well-known, available fuzzers include Libfuzz, AFL-fuzz, and Hongfuzz.

[0004] Dynamic approaches to software testing, such as fuzzing, tend to provide superficial analyses, as they often fail to uncover deeper pathways through the tested computer program. Furthermore, the efficiency of fuzzing depends on the execution speed of the system under test. The more executions a system can perform, the more input variables can be checked for faulty system behavior.

[0005] Other approaches to testing computer programs for vulnerabilities include static methods such as symbolic execution, concolic execution, concolic-symbolic execution, abstract interpretation, model checking, and limited model checking. These approaches analyze the source code or an intermediate representation using mathematically formal methods. These techniques make it possible to provide guarantees about the types of errors contained in a piece of software.

[0006] An overview of symbolic and concolic execution and methods of abstract interpretation is provided by: Baldoni, Roberto, et al. "A survey of symbolic execution techniques." ACM Computing Surveys (CSUR) 51.3 (2018): 50.

[0007] Static analysis approaches for software depend on the often indecisive problem of whether, and to what extent, a particular computer program can be formally verified. To provide automatic, computer-implemented analysis tools, an over-approximation is usually necessary. Therefore, static analyses often produce many false positives. For example, they may report problems in the tested system that cannot be reproduced during actual execution, or they may report input variables that should lead to the execution of a specific program path, but which, during actual execution of the computer program, result in the execution of a different program path. The precision and execution time of static analyses can depend heavily on the size of the analyzed program, among other criteria.

[0008] A test-based static analysis is known from WO 2014 / 180107 A1. US 2009 / 2599989 A1 discloses a multi-layered static program analysis environment for software testing. A method for generating a weakness report for Java projects is described in US 2019 / 0205543 A1. A computer program for the automatic evaluation of user interfaces in software programs is presented in US 2015 / 317234 A1. US 2012 / 222013 A1 describes a model of software behavior.

[0009] A computer-implemented method for testing a system is presented, wherein the system under test includes or is, in particular, a computer program, a hardware system, or an embedded system.

[0010] In this process, a static analysis is used to examine the first part of an execution structure for the system to determine whether the system runs without errors when executed from the execution paths corresponding to the first part of the execution structure.

[0011] Static analysis comprises a computer-implemented investigation of the system without actual execution, preferably based on an execution structure and using a formal mathematical method. The following methods can preferably be used for static analysis: model testing, limited model testing, investigation using theorem provers, typification, abstract interpretation, symbolic execution, or conciliar execution.

[0012] If the static analysis shows that the first part of the execution structure executes without errors, the system is then examined using a dynamic analysis, which omits or specifically does not execute the execution paths corresponding to the first part of the execution structure.

[0013] Dynamic analysis is preferably used to investigate whether the system executes flawlessly for at least one specific input variable. It comprises a computer-implemented analysis of the system during actual system execution. Preferably, the dynamic analysis includes fuzzing, and in particular, the dynamic analysis is performed for at least one input variable generated by a fuzzer.

[0014] This paper presents a test procedure which, through its combination with static analysis, enables particularly efficient dynamic testing of a system. Specifically, the execution time of the dynamic analysis can be progressively reduced with advancing or repeated static analysis by gradually decreasing the number of execution paths to be tested in the dynamic analysis.

[0015] Additionally, the static analysis only considers a part of the execution structure, which also makes this investigation very efficient and increases the possible accuracy of the static investigation techniques used.

[0016] In a particularly preferred embodiment, the first part of the execution structure is omitted in a further static analysis if the static analysis reveals that the first part of the execution structure is error-free. The further static analysis of the execution structure thus takes place after the static analysis for its first part is complete. This ensures that the static analysis also runs efficiently and that a progressively smaller portion of the execution structure still needs to be examined with each repeated execution of the static analysis.

[0017] In a further preferred embodiment, a first input variable is calculated for the first part of the execution structure based on the static analysis, and this first input variable is stored in a set of input variables to be considered for a dynamic analysis if the static analysis reveals an execution with an error for the first part of the execution structure. In particular, the first input variable is calculated to be one for which the static analysis indicates that the execution with an error occurs.

[0018] This allows substructures identified as faulty in the static analysis to be examined again in a targeted manner during the dynamic analysis. For example, if a static analysis produces false positives, this can be detected in the dynamic analysis. Similarly, actual faults can be verified. This provides a comprehensive and advantageous testing procedure.

[0019] In a preferred embodiment, the steps of the static analysis and the step of the dynamic analysis are executed in parallel. This allows the advantages of the methods to be realized particularly quickly and efficiently. If, however, sufficient parallel computing capacity is not available, the advantages can also be realized in an alternative embodiment by executing the static analysis and the dynamic analysis sequentially. In particular, in both variants, repeated execution of dynamic and static analyses in loops is possible.

[0020] In preferred embodiments of the described methods, the system under test comprises a computer program, the execution structure is a tree structure representing the execution paths of the computer program, and the dynamic analysis includes the execution of program code from the computer program on a computer. For systems implemented by or containing computer programs, the described method is particularly efficient for automated system testing.

[0021] In a further preferred embodiment, the investigation of the first part of the system's execution structure is carried out using two different analysis methods in the static analysis. The first analysis method examines the first part of the execution structure from a root of the execution structure towards a leaf of the execution structure, and the second analysis method examines the first part of the execution structure from the leaf of the execution structure towards the root of the execution structure. The two analysis methods are preferably applied simultaneously in the static analysis of a subtree of the execution structure. This reduces the size of the part of the structure to be examined by each analysis method, thereby enabling faster and more precise static analysis.

[0022] In preferred embodiments, the errors for which the system is examined in the static and / or dynamic analysis include at least one runtime exception, a violated assertion, an impermissible system state, a system crash, an erroneous memory access, an erroneous resource access, or a hang, in particular a computer program failing to continue execution. By checking for these potential critical system errors, the safety and smooth operation of the system can be determined. Furthermore, in a particularly preferred embodiment, especially depending on the results of the dynamic analysis, an automated correction of detected errors, particularly for the error types described, is possible. This provides not only a computationally efficient method for investigating execution errors in a system, but also results in a system with improved execution.

[0023] Embodiments of the invention are explained in more detail below with reference to the accompanying drawings. The drawings show: Fig. 1 schematically, an execution branch of a computer program, Fig. 2 schematically illustrates an exemplary procedure for testing a computer program. Description of the exemplary implementations

[0024] The invention is described below primarily for cases where the system to be tested is a computer program or includes a computer program. The system to be tested can be a pure computer program or an embedded system with a computer program. However, the described methods are also suitable for pure hardware systems as the system to be tested.

[0025] Automated dynamic tests can be performed on a system under test by a computer-implemented test system. The test system generates input variables for the system under test, executes the system (or initiates its execution), and monitors the system to detect faulty behavior. The system under test receives the input variables and performs calculations based on them. When testing a computer program, this is specifically achieved by having a processor execute the program.

[0026] Dynamic tests of computer programs can create a log of input variables that cause the program to execute incorrectly (error set). They can also maintain a (e.g., partial) log of already executed test cases, particularly the corresponding input variables of these tests (input set). Furthermore, they can maintain a log of input variables that are relevant to the test system in order to calculate additional input variables for testing the system under test.

[0027] Figure 1Figure 1 schematically shows an exemplary execution tree structure, or tree 1, of a computer program, representing various execution paths of the program. The tree structure shown has nodes 10 to 19 and edges connecting the nodes along the execution paths. Node 10 is the root node, nodes 11, 12, and 13 are internal nodes, and nodes 14 to 19 are leaf nodes. A subtree 100 is also shown, comprising the internal node 11 and leaf nodes 14 and 15. Each path in the execution tree structure from the root node 10 to one of the leaf nodes 14 to 19 corresponds to an execution path of the executed computer program. An example execution path could be represented by the consecutive nodes 10, 11, and 15.

[0028] Fig. 2Figure 2 schematically shows an example of a procedure for testing a computer program. The procedure includes steps of a dynamic analysis, shown in Block 21, and steps of a static analysis, shown in Block 22.

[0029] In step 220 of the static analysis, a subtree of the execution tree structure of a computer program is identified or selected. The execution tree structure can be obtained as an input or created based on an input, such as source code or a binary file. In the case of a hardware system under test, an execution tree structure can also be created based on a hardware layout.

[0030] The tree structure can be created for the system or computer program under test using available technologies, for example symbolic execution, software theorem provers, or a combination of these methods.

[0031] In a subsequent step 222, a computer-implemented static analysis is performed on the identified or selected subtree to determine whether an error can occur during the execution of an execution path of the computer program contained or represented in this subtree. The analysis can preferably yield three different results: "no error can occur," "an error can occur," or "unknown," where "unknown" is the result if the test system cannot determine, based on the analysis, whether an error can occur or not.

[0032] The result of this analysis for error-free results can be performed using available technologies, in particular model checking, limited model checking, theorem provers, typing, abstract interpretation, symbolic execution, conciliar execution or combinations thereof.

[0033] After step 222, the procedure leads to a block 223, in which steps are carried out depending on the result in step 222.

[0034] For the result "no error can occur", the procedure branches from step 222 to step 224 of block 223. There, the system under investigation is modified so that the subtree found to be error-free is no longer tested.

[0035] In particular, the system under investigation is modified so that, in a dynamic analysis, execution of the subtree identified as error-free is no longer possible. This modification can be carried out, for example, by replacing the root directory in the source code of the part of the executable computer program corresponding to the error-free subtree with an exit statement (or terminating statement). Alternatively, a corresponding statement can be injected at the appropriate location into the binary code of the computer program.

[0036] In another modification variant, the path condition from the root of the entire tree to the root of the subtree can be calculated, and a test against this path condition can be added as the first instruction of the computer program under test. In this alternative, input variables that do not satisfy the path condition can, for example, be prevented from being executed, or it can be ensured that the dynamic analysis, particularly through a fuzzer, generates input variables that satisfy the negated path condition. This also prevents (further) dynamic testing of this subtree or the corresponding part of the computer program. This variant can be particularly helpful if the system under test runs on separate hardware where software cannot be easily or efficiently replaced automatically. Other methods for this are also possible.

[0037] The system modified in this way is fed into block 21 and there into step 210 of the dynamic analysis.

[0038] In step 224 of block 223, the tree for the static analysis is modified so that the subtree identified as error-free is no longer analyzed. The modified tree is fed to step 220 as a new input, which, as described above, corresponds to the start of the static analysis.

[0039] If it is not possible to determine that a subtree is error-free, but a condition can be extracted under which the execution of the corresponding part of the computer program leads to an error, this result can be treated similarly to the result "no error can occur." Instead of modifying the tree structure by removing the subtree, the subtree can be replaced with an assurance statement for the negated condition. This approach can be particularly useful if the method used to determine error-free operation provides precise results for calculating the condition.

[0040] For the result "unknown," step 222 branches to step 226. There, information can be stored indicating that the corresponding subtree has already been analyzed with the result "unknown." This information can also be used to prevent this subtree from being analyzed again in subsequent static analyses. An "unknown" result can occur, for example, if the calculation of the corresponding static analysis results in a timeout. In step 227, it can then be stored which subtree received the "unknown" result, so that it is not recalculated.

[0041] For the result "an error may occur," step 222 branches into step 225. In this step, the test system preferably calculates one or more input variables for the system under test, which trigger an execution of the system under test that leads to the root of the subtree identified as faulty. The calculation of such input variables can be performed, for example, using symbolic execution, conciliar execution, model checking, limited model checking, abstract interpretation, typing, test case generation, or theorem provers.

[0042] This at least one generated input variable is preferably transmitted to the dynamic analysis in step 225, in particular to block 216 of the dynamic analysis 21, which corresponds to a set of interesting input variables, i.e., to be considered in the further dynamic analysis.

[0043] Instead of adding the at least one generated input variable to the set of input variables to be considered, an alternative approach calculates a path condition for the subtree and starts a new test instance of the dynamic analysis in parallel, specifically a fuzzing instance. In this new test instance, only input variables that satisfy the path condition are generated. As a result, the new test instance focuses on finding errors in subtrees that were identified as (potentially) faulty by the static analysis. For example, such a new fuzzing instance can be added when the already running fuzzer(s) are restarted for a new iteration. Different fuzzing instances can also share their sets of relevant input variables.This approach is particularly useful when additional computing resources are available or when techniques using over-approximate statistical analysis are employed for static analysis, which may produce many false positive results.

[0044] After completion of each step in block 223, the static analysis 22 resumes with step 220. Specifically, for a branch from step 224 (result "no error can occur"), the static analysis is restarted based on the modified tree structure received as input. Alternatively, instead of restarting the static analysis with a modified tree structure, the analysis can be resumed or continued with the original, unmodified tree structure. In this case, information about already analyzed subtrees is stored and considered for further analysis to avoid repeated analysis of the same subtrees. This approach is particularly useful when calculating a modified tree structure is time-consuming or computationally intensive.

[0045] In preferred variants of the described static analysis, it is performed using at least two different analysis methods. A first static analysis method examines the execution structure from the root towards the leaves of the execution structure, and a second static analysis method examines the execution structure from the leaves towards the root. The two analysis methods are preferably applied simultaneously in the static analysis of a subtree of the execution structure. This reduces the size of the part of the structure to be examined by each analysis method, thereby enabling the static analysis to be performed faster and with higher precision.

[0046] The dynamic analysis in Block 21 can be implemented using a fuzzer. Fuzz testing (also known as fuzzy testing or fuzzing) is a well-known method for dynamically testing software for vulnerabilities. In this approach, a system under test (SUT), typically a computer program, is executed with input variables provided by a fuzzer. While the system is running, i.e., while the software is being executed by a computer, the fuzzer observes the behavior of the system under test. It flags the provided input variables as relevant to errors if the system under test terminates during execution or exhibits other undesirable behavior. Well-known, available fuzzers include Libfuzz, AFL-fuzz, and Hongfuzz.

[0047] Available fuzzing methods include white-box fuzzing, black-box fuzzing, and binary fuzzing, the latter requiring no source code, only a compiled executable file. Hardware fuzzing can also be used if the system under test is a hardware system that performs the functionality being tested.

[0048] The fuzzer used can run on the same hardware as the system under test. Alternatively, it can run on different hardware, with the input and output variables, or results and observations about the system under test, being communicated via suitable interfaces.

[0049] Block 21 in Fig. 2 This shows the steps of an automated dynamic analysis of a tested system. A fuzzer is started in step 210.

[0050] In the following step 211, the fuzzer generates at least one input variable for an execution of the tested system. The generation of the input variables is preferably based on heuristics and can also take white-box information into account, so that, for example, input variables that lead to new execution paths during system execution are preferred. The generation can be based on a previously created set of input variables, which may be extended in further analysis, and which is considered interesting or to be taken into account (interesting set). New input variables are generated based on these stored input variables by varying parameters and values.

[0051] Subsequently, at least one input variable, or information about it, is stored in a log of already executed or initiated test cases in step 212 and used in step 213 as an input variable for a test of the system under test by executing the system based on this input variable. If the system is a computer program or an embedded system containing a computer program, the execution corresponds to the computational steps of a processor based on the input variable. During execution, the system under test is monitored by the test system with regard to system behavior and output variables. For example, execution paths of a computer program under test can be observed by adding observers or software monitors during program compilation.

[0052] In the following step 214, a result of the observation is generated. Possible results include, in particular, "faulty execution" and "no faulty execution." Examples of faulty execution of a tested computer program are runtime exceptions, violated assertions, entering invalid system states, system crashes, faulty memory accesses (buffer overflow, access after memory release), faulty resource accesses, e.g., due to faulty synchronization in multi-stranded programs, or program hangs (e.g., livelocks, deadlocks, etc.).

[0053] After step 214, the program branches to step 215 for the result "faulty execution," where the input variable or information about the input variable that resulted in a faulty execution is stored. The goal is to create an error set or log of such input variables.

[0054] After step 214, if the result is "no faulty execution," the process branches to step 216, where the input variable or information about the input variable that did not result in a faulty execution is stored. The goal is a stored set of interesting input variables, i.e., those to be considered by the fuzzer for further dynamic analysis. These are considered as described in step 211, by the fuzzer generating input variables from this set for further analysis, depending on the input variables.

[0055] Steps 215 and 216 branch into step 210, in which the fuzzer again generates input values. In alternative versions, the process can also be terminated after the first detected malfunction.

[0056] After modifying the system under test in step 224 of block 22, a branch preferably occurs to step 210, thus restarting the fuzzer based on the modified system under test. Instead of restarting the fuzzer with every modification (i.e., with each subtree found to be error-free) in step 224, fuzzing can also be restarted only after several subtrees have been analyzed or found to be error-free. This approach is particularly useful if restarting the fuzzing would involve significant execution overhead or if subtree analyses are performed very quickly (e.g., at the beginning of the analysis).

[0057] In a preferred approach, dynamic and static analyses run in parallel. However, in an alternative approach, they can also run sequentially, for example, by pausing the dynamic analysis after a certain time, performing the static analysis, and then resuming the dynamic analysis depending on its result (i.e., with a potentially modified system under test). This can be particularly useful when insufficient parallel computing capacity is available. The pausing and starting of the dynamic and static analyses can each depend on heuristics, such as elapsed time or analysis progress.

[0058] The entire computer-implemented and automated test of the system, including static and dynamic analysis, can reliably and in a particularly time- and resource-efficient manner detect and identify execution errors.

[0059] The stored test results (in particular, the set of input variables that lead to faulty behavior, the set of input variables already used for dynamic analysis, the set of input variables still to be considered by the dynamic analysis (interesting set), or information about the subtrees identified as error-free in the static analysis) can be used to improve the system. Depending on the stored results, this can be used, for example, to debug errors, analyze potential consequences (e.g., for safety requirements), or release the system for product or safety.

Claims

1. Computer-implemented method for testing a system, wherein the tested system is in particular a computer program, a hardware system or an embedded system, characterized by the following steps: - a static analysis (22) is used to examine (222) a first part of an execution structure for the system in order to determine whether the system runs without errors when executing execution paths corresponding to the first part of the execution structure, with the errors comprising at least a runtime exception, a violated assertion, adoption of an inadmissible system state, a system abort, incorrect memory access or incorrect resource access or sticking, in particular a lack of further computing of a computer program, - if execution without errors is determined (224) for the first part of the execution structure in the static analysis (22), the system is examined with a dynamic analysis (21) which omits execution paths corresponding to the first part of the execution structure.

2. Method according to one of the preceding claims, characterized in that, in a further static analysis (22), the first part of the execution structure is omitted if execution without error is determined (224) for the first part of the execution structure in the static analysis (22).

3. Method according to one of the preceding claims, characterized in that a first input variable is calculated for the first part of the embodiment structure on the basis of the static analysis (22) and the first input variable is stored in a set of input variables to be taken into account for a dynamic analysis (21) if execution with an error is determined (225) for the first part of the execution structure in the static analysis (22).

4. Method according to Claim 3, characterized in that an input variable, for which the static analysis (22) reveals that the execution occurs with an error, is calculated as the first input variable.

5. Method according to one of the preceding claims, characterized in that the tested system comprises a computer program, in that the execution structure is a tree structure representing execution paths of the computer program, and in that the dynamic analysis (21) comprises execution of a program code of the computer program on a computer.

6. Method according to one of the preceding claims, characterized in that the static analysis (22) and the dynamic analysis (21) are carried out in parallel.

7. Method according to one of Claims 1 to 5, characterized in that the static analysis (22) and the dynamic analysis (21) are carried out sequentially.

8. Method according to one of the preceding claims, characterized in that the system is examined with the dynamic analysis (21) in order to determine whether the system is executed without errors for at least a certain input variable.

9. Method according to Claim 8, characterized in that the system is examined with the dynamic analysis (21) in order to determine whether a runtime exception, a violated assertion, adoption of an inadmissible system state, a system abort, incorrect memory access, incorrect resource access or sticking occurs during its execution.

10. Method according to either of Claims 8 and 9, characterized in that the system is improved on the basis of the dynamic analysis (21), in particular a detected error is corrected.

11. Method according to one of the preceding claims, characterized in that the static analysis (22) is used to examine whether a runtime exception, a violated assertion, adoption of an inadmissible system state, a system abort, incorrect memory access, incorrect resource access or sticking occurs when executing execution paths of the system that correspond to the first part of the execution structure.

12. Method according to one of the preceding claims, characterized in that the dynamic analysis (21) comprises fuzzing, in particular in that the dynamic analysis (21) is carried out for at least one input variable generated by a fuzzer.

13. Method according to one of the preceding claims, characterized in that the static analysis (22) comprises a model test, a limited model test, an examination by means of a theorem prover, typing, an abstract interpretation, symbolic execution or concolic execution.

14. Method according to one of the preceding claims, characterized in that the static analysis (22) comprises a computer-implemented examination of the system using an execution structure without actual execution of the system, in particular by means of a formal mathematical method.

15. Method according to one of the preceding claims, characterized in that the first part of the execution structure for the system is examined in the static analysis (22) with two different analysis methods, wherein the first analysis method examines the first part of the execution structure from a root of the execution structure in the direction of a leaf of the execution structure and the second analysis method examines the first part of the execution structure from the leaf of the execution structure in the direction of the root of the execution structure.

16. Method according to one of the preceding claims, characterized in that the dynamic analysis (21) comprises a computer-implemented examination of the system during actual execution of the system.

17. Computer program which is configured to carry out a method according to one of the preceding claims.

18. Machine-readable memory in which a computer program according to Claim 17 is stored.

19. Test system for testing a system, having a memory according to Claim 18, a processor for executing the computer program according to Claim 17 and at least one interface to the tested system.