EP4470162A1 - Eine testanordnung und ein verfahren zum testen eines testobjekts, und ein computerprogramm zur durchführung des verfahrens - Google Patents

Eine testanordnung und ein verfahren zum testen eines testobjekts, und ein computerprogramm zur durchführung des verfahrens

Info

Publication number
EP4470162A1
EP4470162A1 EP23702250.4A EP23702250A EP4470162A1 EP 4470162 A1 EP4470162 A1 EP 4470162A1 EP 23702250 A EP23702250 A EP 23702250A EP 4470162 A1 EP4470162 A1 EP 4470162A1
Authority
EP
European Patent Office
Prior art keywords
test
arrangement
designed
cases
test arrangement
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23702250.4A
Other languages
English (en)
French (fr)
Inventor
Anne Borcherding
Steffen Pfrang
Christian Haas
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
Original Assignee
Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV filed Critical Fraunhofer Gesellschaft zur Foerderung der Angewandten Forschung eV
Publication of EP4470162A1 publication Critical patent/EP4470162A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3668—Testing of software
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases

Definitions

  • test arrangement and a method for testing a test object, and a computer program for carrying out the method
  • the invention relates to a test arrangement for testing a test object.
  • the invention can be used, for example, to examine test objects or technical devices for weak points. These include industrial automation components, Internet of Things devices (Internet of Things devices, loT devices, lloT devices) and medical devices.
  • the invention relates to model-based security testing for technical devices.
  • Tests can prevent or prevent the technical devices from performing their tasks. Attacks, such as virtual attacks or attacks via the network/internet, exploit weaknesses in the technical device. In order to prevent the attacks, the vulnerabilities can be discovered and eliminated. Security tests are used to discover vulnerabilities.
  • a test environment or a "test environment” (TE) tests the technical device automatically as a device under test or test object or "subject under test” (SUT).
  • test case generation and/or monitoring are also summarized, for example, in the joint patent US Pat. No. 9,400,725 B2.
  • US 9,400,725 B2 generally relates to automated testing of a system with software and/or hardware components.
  • the test framework generates test cases for a system to be tested based on a grammar.
  • the test framework checks the system with the test case and receives an answer to the test case from the system under test.
  • the inputs and outputs are then compared to the expected results to determine if the system under test is functioning correctly.
  • the system under test can be analyzed to determine whether it is capable of properly processing control instructions and input signals and/or producing expected output control signals and additional control/feedback information.
  • the data can then be interpreted in the grammar system and/or used as input to an error isolation system to detect anomalies in the system under test.
  • the object of the present invention is to create a concept for testing test objects that provides an improved compromise between test effort and test scope or test reliability.
  • test arrangement or test environment (TE) according to claim 1
  • method according to claim 43 or by a computer program according to claim 44.
  • Embodiments of the invention provide a test arrangement for testing a test object, such as. B. for testing a technical device or an industrial device or a component of a device or a component with a communication interface, for example with a wired or wireless network interface and / or with a web interface.
  • the TE creates an initial model of the SUT using interactions with the SUT. For example, TE creates test cases based on the initial model. The TE For example, runs the test cases against the SUT to generate real test results. For example, the model is improved based on the test results. For example, new test cases are continuously created using the new model and the model of the SLIT is continuously updated, for example.
  • the effect of an automated derivation of a model of the SLIT is that knowledge about the SUT is derived that was not previously explicitly available.
  • TE can, for example, generate new test cases more efficiently and in a more targeted manner. This means that the entire test of the SUT can be carried out more efficiently and in a more targeted manner.
  • this knowledge can be used, for example, to decide whether the behavior of the SUT shows an anomaly. This can be an indication of a vulnerability in the SUT.
  • the most important advantage is, for example, that the automatically generated model can be used to test automation components more efficiently and in a more targeted manner.
  • the test arrangement thus creates more and more test cases that test the test object for weak points as comprehensively as possible.
  • the test arrangement is designed to predict or estimate the test results of the test cases using the model, or e.g. B. to approximate.
  • the test arrangement can use the model to predict the test results of a test case and thus the quality of the test case without executing the test case against the SUT. This means that test time can be saved, for example, by selecting the test cases that are actually executed appropriately.
  • test arrangement is designed to provoke and/or identify one or more status changes based on the specified status.
  • model of the SUT is supplemented by the newly identified status changes and/or by the newly identified statuses.
  • the test arrangement is designed to identify state-changing test cases that lead to a state change of the test object and to update the model based on this.
  • test arrangement is designed to use a mutation algorithm when generating the test cases, which algorithm generates new test cases on the basis of old test cases.
  • test cases can be developed successively or step by step, for example by only changing part of a test case in the event of a mutation.
  • the test arrangement is designed to discover weak points in the test object using selected intermediate test cases.
  • the intermediate test cases are evaluated based on their (e.g. expected) ability to cause the test object to malfunction (which is described, for example, by the fitness value). In this way, as many vulnerabilities as possible are discovered.
  • the test arrangement is configured to use one or more machine learning algorithms in determining the fitness value.
  • the test arrangement is configured to use one or more machine learning algorithms, such as support vector machine algorithms, or support vector machine algorithms and/or random tree algorithms, or random tree algorithms and/or neural network algorithms.
  • machine learning algorithms such as support vector machine algorithms, or support vector machine algorithms and/or random tree algorithms, or random tree algorithms and/or neural network algorithms.
  • the test arrangement is designed to retrain the machine learning algorithm or machine learning algorithms using the test results of the test cases that have been executed.
  • test arrangement is designed to execute a sequence of test cases and to use their test results as an observation sequence for training a hidden Markov model (Hidden Markov Model), and to determine states of a state machine with the Hidden Markov Model (HMM) based on an observation sequence to estimate or approximate.
  • Hidden Markov Model hidden Markov model
  • HMM Hidden Markov Model
  • HMM is well suited, for example, for modeling states and transitions with different probabilities between the states, for example in the case of a test object with unknown behavior.
  • the test arrangement is designed to bring the test object into the individual states of the Hidden Markov model and to generate several test cases per state, which bring the test object into the other states of the Hidden Markov model, starting from the current state, in order to obtain a good achieve path coverage of the Hidden Markov Model.
  • the Viterbi algorithm can be used in an HMM to calculate the path that was most likely taken through the model when a test case was executed. This path approximates the execution path of the SLIT and is used to quantify the behavior of the SLIT, which in turn is used to generate new test cases.
  • the path coverage can also be used, for example, as a criterion or as a measure of the quality of the test or test case or for the test coverage.
  • the test arrangement is designed to continue to refine the model and/or the generated test cases.
  • the test arrangement thus creates, for example, a positive feedback loop in which the new test cases improve the model and new test cases are in turn generated on the basis of the improved model.
  • the test arrangement can test different test objects, such as web applications, network protocols or network interfaces. These concrete examples are explained below.
  • the test arrangement is designed to generate one or more test cases for a web application and to receive and/or evaluate the response of the web application.
  • the test arrangement can be designed to receive and/or evaluate the response of the web application.
  • the web application's response may be in the form of activating or deactivating one or more input fields of the web application and/or activating or deactivating one or more buttons of the web application and/or activating or deactivating one or more links of the web application and/or adding or removing from one or more input fields and/or one or more buttons and/or one or more links, and/or changing one or more texts or numbers.
  • the test arrangement is configured to generate one or more test cases for a device under test using a network protocol and to receive and/or evaluate the response of the device under test.
  • the test arrangement may be arranged to generate the test case or test cases in the form of one or more inputs in a sequence of one or more network packets.
  • the test arrangement can be designed to receive and/or evaluate the response of the test object in the form of a sequence of one or more network packets and/or in the form of information regarding a code coverage of the input.
  • Code coverage is, for example, the ratio of statements actually made in a test to statements that are theoretically possible, or the proportion of software blocks that have been run through (and thus tested).
  • the test arrangement can be designed to set up a state machine based on the test cases and code coverage based thereon, to calculate a value for a state of the test object using a hash function, and to identify the state with the calculated value.
  • the test arrangement can be designed to calculate the most probable execution path of a test case in the Hidden Markov Model using a Viterbi algorithm and to calculate the path coverage of the test cases based thereon.
  • the test arrangement is designed to generate test cases in the form of inputs of a network packet or a sequence of network packets for a network interface of a test object, and to evaluate the operability of the test object or the operability of one or more functions of the test object using monitors.
  • FIG. 3 shows a flow diagram of an embodiment of a network protocol with access to information regarding code coverage
  • the model 107 of the SLIT 104 is or was created, for example, by the TE 101 on the basis of an interaction 108 or an initial interaction 108 with the test object 104 .
  • the test arrangement 101 uses the test cases 102 to simulate virtual attacks in order to discover weaknesses in the test object 104 and also logs the test cases 102 that led to an anomaly in the behavior of the SUT 104 .
  • the decision as to whether an anomaly is present is made on the basis of model 107, for example.
  • the security tests security tests
  • model 107 is created and updated automatically without the need for manual intervention or having to analyze the internal functionality of the SUT 104 .
  • security tests security tests
  • the model 107 is created and updated automatically without the need for manual intervention or having to analyze the internal functionality of the SUT 104 .
  • security tests can be carried out with less effort. This enables higher test coverage to discover or eliminate multiple vulnerabilities and thus increase resilience to virtual attacks.
  • the test arrangement creates a positive feedback loop in which the new test cases 102 improve the model 107 and use the improved model 107 to in turn generate new improved test cases 102 .
  • This feedback loop will be explained further in FIG.
  • FIG. 2 shows a flow chart of an exemplary embodiment of a positive feedback loop 200, which can be used, for example, optionally in test arrangements according to exemplary embodiments of the present invention.
  • the feedback loop 200 has five steps.
  • the third step 230 includes identification of state changing requests or test cases.
  • the third step 230 is linked to the second step 220 and to the fourth step 240, for example.
  • the SUT is regarded as a so-called "black box" (i.e., for example, as a closed system neglecting the internal structure), so no information about the internals of the SUT is known.
  • a test case consists of an HTTP request, for example.
  • the cycle continues. More and more possible queries are selected and the state machine is constantly being refined. Are they through the website? accessible hyperlinks, input fields and buttons are exhausted, the robustness test algorithm or fuzzing algorithm takes over the selection of the next request. For this purpose, for example, available URL parameters and input values are now tried out a large selection of values. For example, the reaction of the web application is compared with the state machine. For example, if the web application behaves differently than the model, this is evaluated as an anomaly that can indicate a vulnerability.
  • a test case consists of a sequence of one or more network packets.
  • this implementation assumes access to information regarding the code coverage of a particular input. In concrete terms, this means that after entering a specific sequence of network packets, the TE or the algorithm receives information about which code blocks the SUT ran through in response to this sequence of network packets. This information is used to evaluate the quality of a test case. For example, a test case that triggers many new places in the code is rated with a high quality. The course of this example is illustrated in FIG.
  • FIG. 3 shows a flow diagram 300 of an implementation of a network protocol with access to information regarding code coverage.
  • the flow chart 300 has a loop with, for example, four steps.
  • the first step 310 includes, for example, providing or executing a sequence of network packets or a test case, such as e.g. B. the test case 102 in Figure 1 on.
  • the first step 310 is linked to the second step 320 and the fourth step 340 .
  • the second step 320 includes, for example, a calculation of the behavior of the SUT or a code coverage analysis.
  • the second step 320 is linked to the first step 310 and to the third step 330, for example.
  • the concrete procedure of the example is shown in FIG.
  • the cycle also begins here at the top left.
  • the initial sequence of network packets is specified by a start value or a so-called "seed".
  • This can be, for example, a single valid network packet, a sequence of network packets, or an empty set. So, for example, this beginning is sent to the SUT and the code coverage information is preserved.
  • a value for the behavior of the SUT is calculated using a hash function, for example.
  • a state machine for example, is now set up on the basis of this behavior. For example, it is assumed that the system is in a certain state until behavior that contradicts this is observed. This is based on an L* algorithm, for example.
  • the decision between exploitation and exploration i. H. whether known states should be further investigated or whether new states should be found, are modeled as a multi-armed bandit problem.
  • established reinforcement learning methods such as the Upper Confidence Bound (UCB) algorithm can be used to make this decision.
  • UFB Upper Confidence Bound
  • the SUT is constantly monitored. If, for example, a program crash is detected during the tests, this information is saved together with the previously sent test case.
  • Figure 3 may also illustrate another implementation of the invention in which code coverage is illustrated based on a Hidden Markov Model (HMM).
  • HMM Hidden Markov Model
  • the latter implementation assumed that access to code coverage information was possible.
  • the behavior of the SUT can be quantified and used to build a state machine.
  • An alternative to this is the implementation described below.
  • the objective, the SUT, the algorithm for creating the state machine, and the mutation and selection of the next sequence of network packets remain the same.
  • the calculation of the behavior of the SUT is different.
  • the code coverage information is no longer directly available. This information is therefore also approximated using a model.
  • a hidden Markov model Hidden Markov model (HMM)
  • HMM hidden Markov model
  • a good choice for the number of internally used states can be made, for example, by repeatedly training the HMMs with a different number of nodes and a subsequent quality assessment, e.g. B. can be made via the Bayesian information criterion.
  • the trained HMM now represents, for example, a model of the internal processes of the SUT and can therefore be used, for example, as follows to approximate the code coverage.
  • the most likely path taken by the model in the last execution can be computed (or estimated) by the Viterbi algorithm. For example, this path approximates the execution path of the SUT. This allows this information to be used, for example, as the code coverage information was used in the previous implementation. For example, it is again used to quantify the behavior of the SUT, which in turn is used to create or update the state machine.
  • the selection of the next sequence of network packets is also based on the so-called seed selection algorithm.
  • This selection also includes, for example, a mutation algorithm that generates and/or executes new test cases based on the old test cases. This algorithm is explained below.
  • FIG. 4 shows a schematic representation of an embodiment of an evolutionary algorithm 400, which can be used, for example, alone or in connection with the embodiments described herein.
  • a population of test cases 420 of algorithm 400 is associated with SUT 410, for example.
  • the algorithm includes, for example, a machine learning algorithm 460 and a loop from the population of test cases 420, a mutation 430, offspring test cases or "offsprings" 440 and a selection 450.
  • a population of the test cases can be generated in the loop, for example, and a mutation can then take place, so offspring test cases can be obtained and a selection or selection can then take place.
  • the machine learning algorithm 460 is associated with the population of test cases 420, mutation 430, and selection 450.
  • the population of test cases 420 are run against the SUT 410, for example, to collect test results, for example using monitors.
  • the machine learning algorithm 460 for example, is trained on the basis of the test cases 420 and the test results.
  • the machine learning algorithm 460 will use the population of test cases 420 to create new test cases, called “offsprings” 440.
  • each test case is scored by the machine learning algorithm 460 using a fitness score.
  • a new population of test cases is selected 450, which in turn is run against the SUT 410 to collect test results.
  • the evolutionary algorithm is used, for example, to create new test cases.
  • a starting value seed
  • New individuals are then created from the individuals in this population by mutation. These are called “offspring” or offspring.
  • a fitness value is then assigned to each of these individuals in the “offspring” (e.g. to the offspring) using a fitness function.
  • those individuals with the highest fitness values are included in the new generation of the population.
  • each individual corresponds to a test case for the test method.
  • the new generation of test cases is executed against the SUT, for example, and the reaction is observed, for example, by monitors.
  • This implementation of the invention consists, for example, of a combination of an evolutionary algorithm and a machine learning algorithm (machine learning (ML) algorithm).
  • machine learning (ML) algorithm For example, a support vector machine (SVM), a random tree (RT) or a neural network (NN) can be used as the ML algorithm.
  • SVM support vector machine
  • RT random tree
  • NN neural network
  • the network interface of an automation component can be tested.
  • the test cases consist of a network packet (or several network packets).
  • a test case consists of a sequence of network packets.
  • the model of the automation component is represented by the respective ML algorithm, for example, and models the behavior of the automation component in response to a test case, for example. The behavior is described, for example, by the failed monitors.
  • these monitors consist, for example, of checking whether the automation component is still responding to ping requests and/or whether the web server of the automation component is still reachable.
  • the selected ML algorithm can be used, for example, in the above-mentioned evolutionary algorithm for determining the fitness value.
  • the ML algorithm is trained in such a way that it approximates a function that maps a test case to the outputs of the monitors. For example, it estimates which monitors are likely to fail in a given test case.
  • a possible result of the estimation could be that the automation component still reacts to ping after the test case has been executed, but the web server is no longer accessible.
  • This estimate can be used, for example, to determine the quality, i.e. the fitness, of a test case or an "individual". The more monitors fail due to the test case (or the more failures are determined to be probable), the higher the quality. In this way, a prediction can be made as to whether (or with what expected probability) the test case will lead to a failure of the monitors. This makes sense, for example, in the case of automation components, since the execution of a test case takes a relatively long time. The estimation of the ML algorithm for the probable reaction of the automation component can, for example, be calculated much more quickly.
  • the ML algorithm is first trained on the reaction of the SUT to the test cases, which are reflected in the initial values or in the "Seed” are located. It is then, for example, continuously retrained on the test cases that have actually been executed.
  • the necessary evaluations or markings or “labels” for the test cases are also available through the subsequently measured behavior of the monitors.
  • the ML algorithm also affects the mutation of the test cases, for example. What this effect actually looks like depends, for example, on the selected ML algorithm.
  • the gradient can be calculated that points in the direction of a (local) maximum of the approximated function. This local maximum then corresponds, for example, to a test case that will affect as many monitors as possible.
  • new test cases can be generated, for example, which have a high probability of causing many monitors to fail.
  • vectors can be calculated that point to the test cases that cause a large number of monitors to fail.
  • the entire process begins with a starting value or “seed”, which is used, for example, as an initial population.
  • the test cases of this population are executed against the SUT and the reactions of the monitors, for example, are recorded. This is how the algorithm receives the ratings or markings or “labels” for the test cases in the population.
  • the combination of test cases and associated labels are now used, for example, to carry out initial training of the ML algorithm. This is then used, for example, to carry out the mutation and the selection. For example, a new population is created that in turn executed against the SUT. For example, the reactions of the monitors are recorded again and the ML algorithm is retrained, for example, with the data set newly generated in this way.
  • test case generation is supported by mutation, for example, and the selection of the test cases generated is supported by an ML algorithm.
  • this ML algorithm represents a model of the SUT by approximating a function that describes the behavior of the SUT in response to a test case.
  • test assembly be limited only by the scope of the following claims and not by the specific details presented in the description and explanation of the exemplary embodiments herein.
  • embodiments of the invention may be implemented in hardware or in software. Implementation can be performed using a digital storage medium such as a floppy disk, DVD, Blu-ray Disc, CD, ROM, PROM, EPROM, EEPROM or FLASH memory, hard disk or other magnetic or optical memory can be carried out on which electronically readable control signals are stored, which can interact with a programmable computer system in such a way or interact that the respective method is carried out. Therefore, the digital storage medium can be computer-readable.
  • a digital storage medium such as a floppy disk, DVD, Blu-ray Disc, CD, ROM, PROM, EPROM, EEPROM or FLASH memory, hard disk or other magnetic or optical memory
  • the digital storage medium can be computer-readable.
  • some embodiments according to the invention comprise a data carrier having electronically readable control signals capable of interacting with a programmable computer system in such a way that one of the methods described herein is carried out.
  • embodiments of the present invention can be implemented as a computer program product with a program code, wherein the program code is operative to perform one of the methods when the computer program product runs on a computer.
  • the program code can also be stored on a machine-readable carrier, for example.
  • exemplary embodiments include the computer program for performing one of the methods described herein, the computer program being stored on a machine-readable carrier.
  • an exemplary embodiment of the method according to the invention is therefore a computer program that has a program code for performing one of the methods described herein when the computer program runs on a computer.
  • a further exemplary embodiment of the method according to the invention is therefore a data carrier (or a digital storage medium or a computer-readable medium) on which the computer program for carrying out one of the methods described herein is recorded.
  • a further exemplary embodiment of the method according to the invention is therefore a data stream or a sequence of signals which represents the computer program for carrying out one of the methods described herein.
  • the data stream or the sequence of signals can be configured in this way, for example be to be transferred over a data communication link, for example over the Internet.
  • Another embodiment includes a processing device, such as a computer or programmable logic device, configured or adapted to perform any of the methods described herein.
  • a processing device such as a computer or programmable logic device, configured or adapted to perform any of the methods described herein.
  • Another embodiment includes a computer on which the computer program for performing one of the methods described herein is installed.
  • a further exemplary embodiment according to the invention comprises a device or a system which is designed to transmit a computer program for carrying out at least one of the methods described herein to a recipient.
  • the transmission can take place electronically or optically, for example.
  • the recipient may be a computer, mobile device, storage device, or similar device.
  • the device or the system can, for example, comprise a file server for transmission of the computer program to the recipient.
  • a programmable logic device e.g., a field programmable gate array, an FPGA
  • a field programmable gate array may cooperate with a microprocessor to perform any of the methods described herein.
  • the methods are performed on the part of any hardware device. This can be hardware that can be used universally, such as a computer processor (CPU), or hardware that is specific to the method, such as an ASIC.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Ausführungsbeispiele der Erfindung schaffen eine Testanordnung (101) zum Testen eines Testobjekts (104, 410), wie z. B. zum Testen eines technisches Gerätes oder eines indust- rielles Gerätes oder einer Komponente eines Gerätes oder einer Komponente mit einer Kommunikationsschnittstelle, beispielsweise mit einer drahtgebundenen oder drahtlosen Netzwerkschnittstelle und/oder mit einer Web-Oberfläche. Die Testanordnung (101) ist aus- gelegt, um auf Basis einer Interaktion mit dem Testobjekt (104) ein Modell (107) zu erstel- len, um einen oder mehrere Testfälle (102, 420, 440) unter Verwendung des Modells (107) zu erzeugen und um das Modell (107) des Testobjekts (104, 410) anhand von realen Test- ergebnisse (109), die auf den erzeugten Testfällen (102, 420, 440) basieren, zu verbessern.

Description

Eine Testanordnung und ein Verfahren zum Testen eines Testobjekts, und ein Computerprogramm zur Durchführung des Verfahrens
Beschreibung
Technisches Gebiet
Die Erfindung betrifft eine Testanordnung zum Testen eines Testobjekts. Die Erfindung kann beispielsweise eingesetzt werden, um Testobjekte oder technische Geräte auf Schwachstellen zu untersuchen. Darunter fallen unter anderem industrielle Automatisierungskomponenten, Internet-der-Dinge Geräte (Internet-of-Things-Geräte, loT-Geräte, lloT-Geräte) und Medizingeräte. Die Erfindung betrifft ein modellbasiertes Security-Testing für technische Geräte.
Technisches Problem
Technische Geräte erfüllen Aufgaben. Durch Angriffe können die technischen Geräte daran verhindert oder gehindert werden, ihre Aufgaben zu erfüllen. Die Angriffe, wie zum Beispiel virtuelle Angriffe oder Angriffe über das Netzwerk/Internet, nutzen dazu Schwachstellen des technischen Gerätes aus. Um die Angriffe zu verhindern, können die Schwachstellen entdeckt und behoben werden. Zur Entdeckung der Schwachstellen werden Sicherheits-Tests (Security-T ests) genutzt. Dabei testet eine T estumgebung oder ein „T est Environment“ (TE) das technische Gerät automatisiert als Gerät unter T est oder T estgegenstand oder „Subject under Test“ (SUT).
Technische Geräte werden selten vollumfänglich auf Schwachstellen getestet. Grund dafür ist zum einen die Komplexität der technischen Geräte, zum anderen die Tatsache, dass technische Geräte aus verschiedenen Komponenten zusammengesetzt sind. Diese Komponenten können von verschiedenen Zulieferern stammen und sind nicht immer in allen Details einsehbar.
Sofern die technische Geräte überhaupt getestet sind, erfolgt dies auf Grundlage von Erfahrungen aus früheren Tests. Diese Tests werden entweder manuell durch Menschen, zum Beispiel durch sogenannte „Penetration Tester“ bzw. Penetrations-Tester oder mittels Testumgebungen durchgeführt.
Manuelle Tests bedeuten einen hohen personellen Aufwand, insbesondere wenn die Tests regelmäßig durchgeführt werden sollen. Aus diesem Grund werden sie in der Praxis selten kontinuierlich bei allen Geräten unter Test oder Subjects under Test (SUT) durchgeführt.
Die Testfälle für automatisierte Tests können zum Beispiel anhand von Erfahrungen aus früheren Tests und Grammatiken erzeugt werden. Diese sind jedoch bis auf zufällige Eingabedaten statisch und berücksichtigen insbesondere nicht die internen Funktionsweisen des SlITs. Es wurde erkannt, dass die Ausfälle des SLITs nur als Ergebnis der Untersuchung dargestellt werden, jedoch nicht in die Erstellung neuer, spezialisierter Testfälle einfließen.
Es wurde festgestellt, dass die interne Funktionsweise des SUTs mittels eines Modells beschrieben werden kann. Dieses Modell beinhaltet alle Funktionalitäten des SUTs, nicht nur die Teile, die zur Erfüllung der Aufgaben des SUTs erforderlich sind. Es kann daher zur Konstruktion von Testfällen genutzt werden.
Bisherige Ansätze für das modellbasierte Testen von technischen Geräten setzen ein vollständiges Modell des SUTs voraus. Dieses Modell kann beispielsweise aus den Entwurfsdokumenten abgeleitet werden. Aus den oben genannten Gründen ist dieser Ansatz bei zusammengesetzten technischen Geräten nicht ohne Weiteres möglich. Beispiele für diese Ansätze sind die Arbeit von Bringmann et al. [1] und die Arbeit von Bauer et al. [2],
Eine manuelle Konstruktion des Modells ist sehr aufwendig und häufig auch nicht möglich. Auch bedeutet eine manuelle Konstruktion eines Modells einen hohen personellen Aufwand und es kann selten ein vollständiges Modell angegeben werden. Dies ist insbesondere dann der Fall, wenn einzelne Teile des Systems von Dritten zugekauft wurden.
Ansätze für eine Testumgebung für das automatisierte Testen von technischen Geräten wurden in verschiedenen Patenten festgehalten. Einige Ausführungsbeispiele beziehen sich auf die allgemeine Generierung von Testfällen auf Basis einer Grammatik und auf die Überwachung einer Rechteckwelle als Ausgabe der getesteten Komponente. Somit kann es überprüft werden, ob das untersuchte Gerät einen Fehlerzustand eingenommen hat oder ob allgemein ein Zustandswechsel durchgeführt wurde.
US 8,132,053 B2 und US 8,006,136 B2 beziehen sich auf das Testen eines Systems mit Software- und/oder Hardwarekomponenten. In den Ausführungsbeispielen wird eine Testumgebung bzw. ein Test-Framework vorgestellt, das Testfälle für ein zu prüfendes System anhand einer Grammatik erzeugt. Das Test- Framework prüft das System mit dem Testfall und erhält eine Antwort auf den Testfall von dem zu testenden System. Die Eingaben und Ausgaben werden dann mit den erwarteten Ergebnissen verglichen, um festzustellen, ob das zu testende System korrekt funktioniert.
US 8,433,542 B2 und US 9,026,394 B2 beziehen sich ebenso auf das Testen eines Systems mit Software- und/oder Hardwarekomponenten. Das Test- Framework der obengenannten Patente erzeugt Testfälle für ein zu prüfendes System anhand einer Grammatik. Das Test- Framework prüft das System mit dem Testfall und erhält eine Antwort auf den Testfall von dem zu testenden System. Die Eingaben und Ausgaben werden dann mit den erwarteten Ergebnissen verglichen. Die Daten können dann im Grammatiksystem interpretiert und/oder als Eingabe für ein Fehlerisolierungssystem verwendet werden. Damit kann es überprüft werden, ob das untersuchte Gerät einen Fehlerzustand eingenommen hat oder ob allgemein ein Zustandswechsel durchgeführt wurde.
Die verschiedenen Bestandteile, wie zum Beispiel eine Testfallgenerierung und/oder Überwachung, sind zudem zum Beispiel in dem gemeinsamen Patent US 9,400,725 B2 zusammengefasst. US 9,400,725 B2 bezieht sich allgemein auf ein automatisiertes Testen eines Systems mit Software- und/oder Hardwarekomponenten. Das Test- Framework erzeugt Testfälle für ein zu prüfendes System anhand einer Grammatik. Das Test-Framework prüft das System mit dem Testfall und erhält eine Antwort auf den Testfall von dem zu testenden System. Die Eingaben und Ausgaben werden dann mit den erwarteten Ergebnissen verglichen, um festzustellen, ob das zu testende System korrekt funktioniert. Insbesondere kann das zu prüfende System analysiert werden, um festzustellen, ob es in der Lage ist, Steueranweisungen und Eingangssignale ordnungsgemäß zu verarbeiten und/oder erwartete Ausgangssteuersignale und zusätzliche Steuer-/Rückmeldeinformationen zu erzeugen. Die Daten können dann im Grammatiksystem interpretiert und/oder als Eingabe für ein Fehlerisolierungssystem verwendet werden, um Anomalien im zu prüfenden System zu ermitteln. Die Aufgabe der vorliegenden Erfindung besteht darin, ein Konzept zum Test von Testobjekten zu schaffen, das einen verbesserten Kompromiss zwischen Testaufwand und Testumfang bzw. Test-Zuverlässigkeit liefert.
Diese Aufgabe wird durch eine Testanordnung oder Testumgebung (TE) nach Anspruch 1 , durch ein Verfahren nach Anspruch 43, oder durch ein Computerprogramm nach Anspruch 44 gelöst.
Zusammenfassung der Erfindung
Ausführungsbeispiele der Erfindung schaffen eine Testanordnung zum Testen eines Testobjekts, wie z. B. zum Testen eines technisches Gerätes oder eines industrielles Gerätes oder einer Komponente eines Gerätes oder einer Komponente mit einer Kommunikationsschnittstelle, beispielsweise mit einer drahtgebundenen oder drahtlosen Netzwerkschnittstelle und/oder mit einer Web-Oberfläche.
Die Testanordnung ist ausgelegt, um auf Basis einer Interaktion mit dem Testobjekt ein Modell zu erstellen, um einen oder mehrere Testfälle unter Verwendung des Modells zu erzeugen und um das Modell des Testobjekts anhand von realen Testergebnisse, die auf den erzeugten Testfällen basieren, zu verbessern.
Die Testanordnung (TE) erzeugt beispielsweise auf Basis von ihrer Interaktion mit dem Testgegenstand bzw. Testobjekt (SUT) aktiv und automatisiert ein Modell von dem SUT. Das Modell wird anschließend beispielsweise von der TE verwendet, um neue Testfälle gezielt zu erzeugen. Die erzeugten Testfälle oder Tests werden beispielsweise von der TE gegen das SUT ausgeführt. Die TE überprüft währenddessen und im Anschluss an den Test, ob das SUT seine Aufgabe erfüllt oder erfüllen kann. Dazu überwacht sie beispielsweise das SUT, überprüft dessen Ausgaben und setzt ebenfalls das Modell des SUTs ein. Das Modell des SUTs wird während der Tests fortlaufend aktualisiert. Ein besonderes technisches Merkmal ist beispielsweise, dass die TE aus der Interaktion mit einem intransparenten SUT automatisiert ein Modell erzeugt und dieses automatisiert für die adaptive Testfallerzeugung verwendet.
Die TE erstellt beispielsweise ein Anfangsmodell von dem SUT mithilfe von Interaktionen mit dem SUT. Anhand des Anfangsmodells erstellt die TE beispielsweise Testfälle. Die TE führt die Testfälle beispielsweise gegen das SUT aus, um reale Testergebnisse zu erzeugen. Das Modell wird beispielsweise anhand der Testergebnisse verbessert. Neue Testfälle werden beispielsweise fortlaufend anhand das neue Modell erstellt und das Modell des SLITs wird beispielsweise fortlaufend aktualisiert.
Die Wirkung einer automatisierten Ableitung eines Modells des SLITs ist beispielsweise, dass Wissen über das SUT abgeleitet wird, das vorher nicht explizit vorhanden war. Mit diesem zusätzlichen Wissen kann die TE beispielsweise effizienter und zielgerichteter neue Testfälle erzeugen. Damit kann der gesamte Test des SUTs effizienter und zielgerichteter durchgeführt werden. Zudem kann dieses Wissen beispielsweise dazu genutzt werden, um zu entscheiden, ob das Verhalten des SUTs eine Anomalie aufweist. Dies kann ein Indiz für eine Schwachstelle des SUTs sein.
Der wichtigste Vorteil ist beispielsweise, dass das Testen von Automatisierungskomponenten durch das automatisch erzeugte Modell effizienter und zielgerichteter durchgeführt werden kann. Somit erstellt die Testanordnung mehr und mehr Testfälle, die das Testobjekt möglichst vollumfänglich auf Schwachstellen testen.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um eine, mehrere oder keine auf einen erzeugten Testfall gegebene Antwort eines im Hinblick auf sein Verhalten unbekannten und/oder intransparenten Testobjekts über einen oder mehrere Kommunikationswege zu empfangen.
Die Testanordnung ist ausgebildet, um alle möglichen Antworten des Testobjekts zu detek- tieren. Durch einen möglichst umfangreichen Empfang der Antworten des Testobjekts wird das Modell des Testobjekts basierend auf den Testergebnissen genauer, obwohl das Testobjekt im Hinblick auf sein Verhalten unbekannt oder intransparent ist.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die Funktionsfähigkeit des Testobjekts oder die Funktionsfähigkeit einer oder mehrerer Funktionen des Testobjekts mittels einem oder mehreren Monitoren und/oder Überwachungsmodulen zu überprüfen.
Das Testobjekt kann auf einen Testfall oder auf eine Anfrage zusätzlich oder alternativ zu einer Antwort mit einer Verhaltensänderung reagieren. Diese Verhaltensänderung kann die Testanordnung beispielsweise mittels einem oder mehreren Monitoren und/oder Überwachungsmodulen überwachen. Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die empfangenen Antworten und/oder die Ergebnisse der Monitoren auszuwerten und anhand dieser Auswertung Testergebnisse zu erzeugen.
Alle auf einen Testfall gegebenen Verhaltensänderungen und/oder Antworten des Testobjekts werden beispielsweise unter einem Testergebnis zusammengefasst. Dadurch kann eine spätere Verarbeitung der Testergebnisse vereinfacht werden.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die Güte des Testfalls anhand des Testergebnisses und/oder anhand einer Wahrscheinlichkeit einer Fehlfunktion des mit dem Testfall getesteten Testobjekts zu bewerten.
Die Testanordnung simuliert beispielsweise virtuelle Angriffe gegen das technische Gerät oder das Testobjekt um Schwachstellen des Gerätes zu entdecken. Je mehr Schwachstellen ein Testfall der Testanordnung entdeckt, bzw. je höher die Wahrscheinlichkeit ist, dass ein Testfall eine Schwachstelle entdeckt, desto besser ist ein Testfall bzw. desto besser wird ein Testfall bewertet. Die Güte eines Testfalls ist zum Beispiel anhand der Anzahl der unerwarteten Fehlermeldungen und/oder der Fehlfunktionen messbar. Aufgrund der Bewertung können beispielsweise (z.B. bevorzugt) solche Testfälle (z.B. für eine tatsächliche Anwendung an dem Testobjekt) ausgewählt werden, die mit hoher Wahrscheinlichkeit Schwachstellen des Testobjekts aufdecken, wodurch die Test- Effizienz verbessert wird.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die Testergebnisse der Testfälle anhand des Modells vorauszusagen oder zu schätzen oderz. B. zu approximieren.
Die Testanordnung kann anhand des Modells die Testergebnisse eines Testfalls und somit die Güte des Testfalls voraussagen ohne den Testfall gegen das SUT auszuführen. Somit kann beispielweise durch geeignete Auswahl der tatsächlich ausgeführten Testfälle Testzeit gespart werden.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um selektiv die Testfälle, bei denen eine Fehlfunktion des Testobjekts oder eine Fehlfunktion einer oder mehreren Funktionen des Testobjekts vorausgesagt wurde, auszusuchen, und um das Testobjekt mit den ausgesuchten Testfälle zu testen, um Testfälle zu erzeugen, die möglichst viele Fehlfunktionen des Testobjekts als reales Testergebnis erzeugen.
Die Testanordnung kann anhand des Modells die Testergebnisse eines Testfalls und somit die Güte des Testfalls voraussagen. Dadurch soll die Testanordnung nicht alle Testfälle gegen das SUT ausführen. Mit einer Reduzierung der Anzahl der gegen das SUT ausgeführten Testfälle werden Ressourcen, wie z. B. Zeit gespart.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um unter Verwendung des Modells zu bestimmen, ob ein reales Testergebnis als anomal beurteilt wird.
Die Testanordnung kann anhand des Modells die Testergebnisse eines Testfalls voraussagen. Die Testergebnisse der ausgeführten Testfälle werden mit den erwarteten Ergebnissen verglichen. Bei einer Diskrepanz wird das Testergebnis als anomal beurteilt. Anomale Testergebnisse deuten auf Schwachstellen hin. Somit können beispielsweise als anormal beurteilte Testergebnisse selektiv oder bevorzugt (zum Beispiel markiert) an einen Benutzer der Testanordnung gemeldet bzw. ausgegeben werden.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das reale Testergebnis als anormal zu beurteilen, wenn das reale Testergebnis eine Fehlfunktion des Testobjekts oder eine Fehlfunktion einer oder mehreren Funktionen des Testobjekts anzeigt, oder wenn das reale Testergebnis von dem anhand des Modells vorausgesagten Testergebnis abweicht.
Die Testanordnung kann anhand des Modells die Testergebnisse eines Testfalls voraussagen. Die Testergebnisse der ausgeführten Testfälle werden mit den erwarteten Ergebnissen verglichen. Bei einer Diskrepanz zwischen einem realen Testergebnis und einem erwarteten Testergebnis oder bei einer Fehlfunktion des Testobjekts wird das Testergebnis als anomal beurteilt. Anomale Testergebnisse deuten auf Schwachstellen des Models und/oder des Testobjekts hin und sind beispielsweise bei einer Fehleranalyse besonders wertvoll.
Bei Ausführungsbeispielen umfasst das Modell des SLITs einen Zustandsautomat.
Der Umgang mit einem Zustandsautomat ist einfach, da die Anzahl der Zustände eines Zustandsautomaten oft relativ gering ist oder oft in einem gut verarbeitbaren Rahmen liegt, die Zustände voneinander unabhängig sind und der Übergang zwischen den Zuständen einer logischen Regel folgt. Es wird beispielsweise davon ausgegangen, dass sich das Testobjekt so lange in einem Zustand befindet, bis eine zustandsverändernde Anfrage ausgeführt wird.
Bei Ausführungsbeispielen umfasst ein Zustand des Zustandsautomaten zumindest einen Testfall, der zu dem Zustand führt, und zumindest ein daraus folgendes Testergebnis. Bei Ausführungsbeispielen ist die Testanordnung beispielsweise ausgelegt, um mittels einer Hash-Funktion einen Wert für einen Zustand des T estobjekts zu berechnen und um den Zustand mit dem berechneten Wert zu identifizieren.
Beispielsweise ist die Testanordnung ausgelegt, um den Zustandsautomaten, der das Modell des Testobjekts bildet, um einen neuen Zustand zu ergänzen, wenn dieser Zustand noch nicht vorhanden ist.
Eine Hashfunktion ist eine injektive Abbildung, die beispielsweise eine Eingabe mit unterschiedlichen Längen auf eine Zielmenge oder einen Hashwert, mit einer festen Länge abbildet. Die Länge des Hashwerts bleibt beispielsweise fest unabhängig von der Länge der Eingabewerte und/oder von der Länge der Testergebnisse. Ein Hashwert ist zur Anwendung als eine Identifikationsnummer gut geeignet und identifiziert beispielsweise einen Zustand in einer Speicherplatz-effizienten und dennoch typischerweise eindeutigen Form.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das Testobjekt in einen vorgegebenen Zustand zu bringen und um das in dem vorgegebenen Zustand befindlichen Testobjekt auf einen oder mehrere verschiedene Testfälle zu testen.
Beispielsweise ist die Testanordnung ausgelegt, um eine oder mehrere Zustandsveränderungen ausgehend von dem vorgegebenen Zustand zu provozieren und/oder zu identifizieren. So wird das Modell des SUTs um die neu identifizierten Zustandsveränderungen und/oder um die neu identifizierten Zustände ergänzt.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um zustandsverändernde Testfälle, die zu einer Zustandsänderung des Testobjekts führen, zu identifizieren und um basierend darauf das Modell zu aktualisieren.
Mit einer kontinuierlichen Aktualisierung des Modells erschafft die Testanordnung eine positive Rückkopplungsschleife. Durch ein verbessertes Modell wird die Anzahl der zustandsverändernden Testfälle erhöht. Eine Vermehrung der zustandsverändernden Testfälle führt zu einem besseren SUT-Modell.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um die zustandsverändernden Testfälle unter Verwendung einer Heuristik zu identifizieren. Die Heuristik ist ausgelegt, um eine Häufigkeit einer Ausführung eines Testfalls und/oder eine Häufigkeit der Identifizierung eines/des Testfalls als zustandsverändernden Testfall und/oder eine Kategorie oder einen Typ eines/des Testfalls zu berücksichtigen. Mithilfe von einer Heuristik kann die Testanordnung neue zustandsverändernde Testfälle effizient identifizieren. Die Statistiken über und/oder Erfahrungen mit früheren Testfällen können zur Entdeckung bzw. Identifizierung neuer zustandsverändernder Testfälle führen.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um zu beurteilen, ob ein Zustand ausreichend erforscht ist. Die Testanordnung ist ausgelegt, um neue Testfälle, die diesen Zustand hervorrufen, zu erzeugen, wenn der Zustand nicht ausreichend erforscht ist, oder um neue Testfälle mit einem großen Unterschied zu den bereits bekannten Testfällen zu erzeugen, wenn der Zustand ausreichend erforscht ist. In diesem Fall ist der Unterschied beispielsweise bevorzugt groß genug, um beispielsweise eine oder mehrere Zustandsveränderungen zu provozieren und/oder zu identifizieren.
Dadurch kann die Testanordnung systematisch jeden Zustand ausreichend erforschen. Ist ein Zustand mit genügend Testfällen getestet, wird die Testanordnung beispielsweise eine Zustandsveränderung provozieren und neue Testfälle für den neuen Zustand erzeugen.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um eine Entscheidung, ob bekannte Zustände weiter untersucht werden sollen oder ob neue Zustände aufgefunden werden sollen, als ein Mehrarmiger-Bandit-Problem zu modellieren, und um das Mehrarmiger- Bandit-Problem anhand eines Verfahrens des bestärkenden Lernens, wie z. B. das Obere- Vertrauens-Grenze Verfahren bzw. das Upper Confidence Bound (UCB) Verfahren, zu lösen um die Entscheidung zu treffen.
Es wurde erkannt, dass ein Mehrarmiger-Bandit-Problem das Dilemma zwischen der weiteren Untersuchung bekannter Zustände und der Suche nach neuen Zuständen gut beschreiben kann. Ein Vorteil des Mehrarmiger-Bandit-Problems ist, dass dieses Problem mathematisch mit verschiedenen Verfahren lösbar ist.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das Testobjekt mit einem Testfall wiederholt zu testen, um festzustellen ob sich das Testergebnis des Testfalles mit der Zeit ändert und um basierend darauf eine Zustandsveränderung zu identifizieren.
Somit kann die Testanordnung testen, ob die Zustände voneinander wirklich unabhängig sind und/oder ob die Zustände zeitabhängig sind. Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um Testfälle, mit denen das Testobjekt zwischen dem Testfall und dem wiederholten Testfall getestet wurde, als potenziell zustandsverändernden Testfälle zu identifizieren.
Die Testanordnung vermutet beispielsweise, dass die Zustände voneinander abhängig sind und bezeichnet alle ausgeführten Testfälle zwischen dem Testfall und dem wiederholten Testfall als potenziell zustandsverändernde Testfälle. Die potenziell zustandsverändernden Testfälle können beispielsweise durch die Testanordnung weiter untersucht werden.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um bei der Erzeugung der Testfälle ungültige und/oder unerwartete und/oder zufällige Eingaben zu erzeugen.
Die Testanordnung ist somit beispielsweise ausgebildet, um Schwachstellen des Testobjekts mithilfe von erzeugten Testfällen zu entdecken. Die Testanordnung ist beispielsweise erfolgreich, wenn sie Testfälle und/oder Eingaben findet, woran der Konstrukteur oder Designer des Testobjekts nicht gedacht hat, wie z. B. ungültige und/oder unerwartete und/oder zufällige Eingaben.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um bei der Erzeugung der Testfälle einen Mutationsalgorithmus zu verwenden, welcher neue Testfälle auf Basis alter Testfälle erzeugt. Somit können Testfälle beispielsweise sukzessive bzw. schrittweise weiterentwickelt werden, indem beispielsweise bei einer Mutation nur ein Teil eines Testfalls verändert wird.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um bei einer Mutation der Testfälle einen oder mehrere Algorithmen des maschinellen Lernens oder „machine learning algorithm“ zu verwenden.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um ausgehend von einem oder mehreren vordefinierten und/oder zufälligen Testfällen eine Mehrzahl von Zwischentestfällen, z. B. mittels einer Mutation zu erzeugen. Die Testanordnung ist ausgelegt, um den Zwischentestfällen jeweils einen Fitnesswert zuzuordnen, um die Zwischentestfälle abhängig von dem jeweiligen zugeordneten Fitnesswert auszusuchen und um die ausgesuchten Zwischentestfälle als neue Testfälle weiterzuverwenden.
Beispielsweise können z. B. die Zwischentestfälle mit den höchsten Fitnesswerten oder z.
B. die Zwischentestfälle mit einem Fitnesswert über einem vordefinierten Schwellenwert ausgesucht werden und als neue Testfälle weiterverwendet werden. Somit können beispielsweise Testfälle einerseits sukzessive verändert (z.B. nur teilweise bzw. in einzelnen Werten oder Teilmengen von Werten verändert) bzw. weiterentwickelt werden, und es können andererseits für die tatsächliche Testdurchführung solche Testfälle ausgewählt werden, die aufgrund ihres zugeordneten Fitnesswertes besonders fähig sind eine Fehlfunktion des Testobjekts zu verursachen.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um den Zwischentestfällen jeweils einen Fitnesswert anhand einer Wahrscheinlichkeit einer Fehlfunktion des mit dem Zwischentestfall getesteten Testobjekts zuzuordnen.
Die Testanordnung ist ausgebildet, um Schwachstellen des Testobjekts mithilfe von ausgewählten Zwischentestfällen zu entdecken. Die Zwischentestfälle werden anhand ihrer (z.B. erwarteten) Fähigkeit, eine Fehlfunktion des Testobjekts zu verursachen (die beispielsweise durch den Fitnesswert beschreiben wird), evaluiert. Dadurch werden möglichst viele Schwachstellen entdeckt.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um bei einer Bestimmung des Fitnesswerts einen oder mehrere Algorithmen des maschinellen Lernens zu verwenden.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um einen oder mehrere Algorithmen des maschinellen Lernens, wie Stützvektormaschine-Algorithmen, oder Support Vector Machine Algorithmen und/oder Zufallsbaum-Algorithmen, oder Random Tree Algorithmen und/oder neuronales Netz Algorithmen, zu verwenden.
Die Verwendung von bekannte Algorithmen vereinfacht die Verwendung von dem maschinellen Lernen Konzept. Bekannte Algorithmen sind einfach zu implementieren.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um den Algorithmus des maschinellen Lernens oder die Algorithmen des maschinellen Lernens anhand der Testergebnisse der ausgeführten Testfällen nachzutrainieren.
Ein fortlaufend lernender Algorithmus verbessert sich selbst mit der Zeit und bleibt immer auf dem neuesten Stand. Verbesserungen des Modells können somit ausgenutzt werden, beispielsweise zur Erzeugung neuer Testfälle und/oder zur Bewertung von Testergebnissen. Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um eine Sequenz von Testfällen auszuführen und deren Testergebnisse als eine Beobachtungssequenz für ein Training eines verdeckten Markovmodells (Hidden Markov Modells) zu verwenden, und um basierend auf einer Beobachtungssequenz Zustände eines Zustandsautomaten mit dem Hidden Markov Modell (HMM) zu schätzen oder zu approximieren.
Es wurde erkannt, dass das HMM beispielsweise für die Modellierung von Zuständen und Übergängen mit unterschiedlicher Wahrscheinlichkeit zwischen den Zuständen beispielsweise bei einem Testobjekt mit unbekanntem Verhalten gut geeignet ist.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das Testobjekt in die einzelnen Zustände des Hidden Markov Modells zu bringen und um pro Zustand mehrere Testfälle zu erzeugen, die das Testobjekt ausgehend von dem aktuellen Zustand in die anderen Zustände des Hidden Markov Modells bringen, um eine gute Pfadabdeckung des Hidden Markov Modells zu erreichen.
Eine gute Pfadabdeckung hilft der Testanordnung, die interne Funktionsweise des Testobjekts zu verstehen und dadurch bessere Testfälle zu erzeugen. Bei jedem Zustandsübergang können Fehler und dadurch potentiale Angriffspunkte vorkommen, die so identifiziert werden können.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um den wahrscheinlichsten Ausführungspfad eines Testfalls in dem Hidden Markov Modell durch einen Viterbi-Algo- rithmus zu berechnen, und um basierend darauf die Pfadabdeckung der Testfälle zu berechnen.
Durch den Viterbi-Algorithmus kann in einem HMM der Pfad berechnet werden, der am wahrscheinlichsten bei einer Ausführung eines Testfalls durch das Modell genommen wurde. Dieser Pfad approximiert den Ausführungspfad des SLITs und wird zur Quantifizierung des Verhaltens des SLITs genutzt, was wiederum zur Erzeugung neuer Testfällege- nutzt wird. Die Pfadabdeckung kann im Übrigen beispielswiese als Kriterium bzw. als Maß für die Güte des Tests bzw. Testfalls bzw. für die Testabdeckung verwendet werden.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um das Modell und/oder die generierten Testfälle immer weiter zu verfeinern. Die Testanordnung schafft somit beispielsweise eine positive Rückkopplungsschleife, bei der die neuen Testfälle das Modell verbessern und anhand des verbesserten Modells wiederum neue Testfälle erzeugt werden.
Die Testanordnung kann unterschiedliche Testobjekte, wie zum Beispiel Webanwendungen, Netzwerkprotokolle oder Netzwerkschnittstellen testen. Diese konkreten Beispiele werden folgend erläutert.
Bei Ausführungsbeispielen ist die Testanordnung ausgelegt, um einen oder mehrere Testfälle für eine Webanwendung zu erzeugen, und um die Antwort der Webanwendung zu empfangen und/oder auszuwerten.
Die Testanordnung kann ausgelegt sein, um den Testfall oder die Testfälle in Form von Eingaben in ein oder mehrere Eingabefelder der Webanwendung und/oder Aktivierung von einer oder mehreren Schaltflächen der Webanwendung und/oder Aktivierung von einem oder mehreren Links der Webanwendung zu erzeugen.
Die Testanordnung kann ausgelegt sein, um die Antwort der Webanwendung zu empfangen und/oder auszuwerten. Die Antwort der Webanwendung kann in Form von Aktivierung oder Deaktivierung von einem oder mehreren Eingabefeldern der Webanwendung und/oder Aktivierung oder Deaktivierung von einer oder mehreren Schaltflächen der Webanwendung und/oder Aktivierung oder Deaktivierung von einem oder mehreren Links der Webanwendung und/oder Zufügung oder Entfernung von einem oder mehreren Eingabefeldern und/oder einer oder mehreren Schaltflächen und/oder einem oder mehreren Links, und/oder Änderung von einem oder mehreren Texten oder Zahlen vorkommen.
Bei anderen Ausführungsbeispielen ist die Testanordnung ausgelegt, um einen oder mehrere Testfälle für ein Testobjekt, das ein Netzwerkprotokoll verwendet, zu erzeugen, und um die Antwort des Testobjekts zu empfangen und/oder auszuwerten.
Die Testanordnung kann ausgelegt sein, um den Testfall oder die Testfälle in Form von einer oder mehreren Eingaben in einer Sequenz von einem oder mehreren Netzwerkpaketen zu erzeugen.
Die Testanordnung kann ausgelegt sein, um die Antwort des Testobjekts in Form von einer Sequenz von einem oder mehreren Netzwerkpaketen und/oder in Form von Informationen bezüglich einer Codeabdeckung der Eingabe zu empfangen und/oder auszuwerten. Als Codeabdeckung bezeichnet man beispielsweise das Verhältnis an tatsächlich getroffenen Aussagen eines Tests gegenüber den theoretisch möglich treffbaren Aussagen, oder auch den Anteil der durchlaufenen (und damit getesteten) Software-Blöcke.
Die Testanordnung kann ausgelegt sein, um basierend auf den Testfällen und darauf basierenden Codeabdeckungen einen Zustandsautomat aufzubauen, um mittels einer Hash- Funktion einen Wert für einen Zustand des Testobjekts zu berechnen, und um den Zustand mit dem berechneten Wert zu identifizieren.
Die Testanordnung kann ausgelegt sein, um eine Sequenz der Kommunikation zwischen der Testanordnung und dem Testobjekt als eine Beobachtungssequenz für ein Training eines verborgenen bzw. verdeckten Markov-Modells (Hidden Markov Modells) zu verwenden, und um basierend auf der Beobachtungssequenz die Codeabdeckung mit dem Hidden Markov Modell zu schätzen oder zu approximieren.
Die Testanordnung kann ausgelegt sein, um das Testobjekt in die einzelnen Zustände des Hidden Markov Modells als Ausgangszustand zu bringen und um pro Zustand mehrere Testfälle zu erzeugen, die das Testobjekt ausgehend von dem aktuellen Zustand in die anderen Zustände des Hidden Markov Modells bringen, um eine gute Pfadabdeckung des Hidden Markov Modells zu erreichen.
Die Testanordnung kann ausgelegt sein, um den wahrscheinlichsten Ausführungspfad eines Testfalls in dem Hidden Markov Modell durch einen Viterbi-Algorithmus zu berechnen und um basierend darauf die Pfadabdeckung der Testfälle zu berechnen.
Bei weiteren Ausführungsbeispielen ist die Testanordnung ausgelegt, um Testfälle in Form von Eingaben eines Netzwerkpakets oder einer Sequenz von Netzwerkpaketen für eine Netzwerkschnittstelle eines Testobjekts zu erzeugen, und um die Funktionsfähigkeit des Testobjekts oder die Funktionsfähigkeit einer oder mehrerer Funktionen des Testobjekts mittels Monitoren auszuwerten.
Weitere Ausführungsbeispiele gemäß der vorliegenden Erfindung schaffen entsprechende Verfahren bzw. Computerprogramme.
Figurenkurzbeschreibung Ausführungsbeispiele gemäß der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert.
Fig. 1 zeigt eine schematische Darstellung eines Ablaufs eines Ausführungsbeispiels einer Testanordnung;
Fig. 2 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels einer positiven Rückkopplungsschleife;
Fig. 3 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels eines Netzwerkprotokolls mit einem Zugriff auf Informationen bezüglich einer Codeabdeckung;
Fig. 4 zeigt eine schematische Darstellung eines Ausführungsbeispiels eines evolutionären Algorithmus.
Detaillierte Beschreibung der Ausführunqsbeispiele gemäß den Figuren
Im Folgenden werden Ausführungsbeispiele mit Bezug auf die Figuren näher beschrieben. Außerdem sind Verfahrensschritte, die ein bestimmtes Merkmal einer Vorrichtung betreffen mit ebendiesem Merkmal der Vorrichtung austauschbar, was ebenso anders herum gilt.
Figur 1 zeigt eine schematische Darstellung eines Ablaufs 100 eines Ausführungsbeispiels einer Testanordnung (TE) 101. Die TE 101 ist mit einem Testobjekt (SUT) 104 über einen oder mehrere Kommunikationswege 103 verknüpft. Die TE 101 weist einen oder mehrere Monitoren 106 oder Überwachungsmodule 106 auf, und ist zusätzlich mit einem Modell 107 des Testobjekts 104 verknüpft.
Das Modell 107 des SLITs 104 wird bzw. wurde beispielsweise von der TE 101 auf Basis einer Interaktion 108 oder einer initialen Interaktion 108 mit dem Testobjekt 104 erstellt.
Die TE 101 ist ausgelegt, um eine oder mehrere Testfälle 102 anhand des Modells 104 zu erstellen und eine, mehrere oder keine auf den erzeugten Testfall 102 gegebenen Antwort 105 zu empfangen. Die TE 101 ist ferner ausgelegt, um die Funktionsfähigkeit einer oder mehrerer Funktionen des SLITs mittels einem oder mehreren Monitoren 106 zu überprüfen. Die empfangenen Antworten 105 und/oder die Ergebnisse der Monitoren 106 werden ausgewertet, um Testergebnisse 109 zu erstellen. Anhand der Testergebnisse 109 verbessert die TE 101 das Modell 107 des SLITs 104. Dadurch werden die neu generierten Testfälle 102 verbessert und die darauf gegebenen Ergebnisse 109 werden wiederum das Modell 107 verfeinert.
Mit anderen Worten stellt Figur 1 den schematischen Ablauf eines Ausführungsbeispiels dar. Die Testanordnung (TE) 101 generiert einen oder mehrere neue Testfälle 102 und schickt diese über einen Kommunikationsweg 103 an das Testobjekt (SUT) 104. Das SUT 104 reagiert daraufhin mit einer, mehreren oder keiner Antwort 105 über einen oder mehrere Kommunikationswege 103. Die TE 101 wertet die empfangenen Antworten 105 sowie die Ergebnisse der Monitoren 106 aus. Aus den gesendeten Testfällen 102, den empfangenen Antworten 105 und den Ergebnissen der Monitoren 106 wird das Modell 107 des SLITs 104 abgeleitet und beispielsweise ständig aktualisiert. Auf Basis des (gegebenenfalls verbesserten) Modells 107 sowie der Auswertung der empfangenen Antworten 105 und/oder der Ergebnisse der Monitoren 106 erzeugt die TE 101 einen oder mehrere neue Testfälle 102 und schickt diese wiederum an das SUT 104.
Die Testanordnung 101 simuliert mit den Testfällen 102 virtuelle Angriffe, um Schwachstellen des Testobjekts 104 zu entdecken und protokolliert zudem die Testfälle 102, die zu einer Anomalie im Verhalten des SUTs 104 geführt haben. Die Entscheidung, ob eine Anomalie vorliegt, wird beispielsweise auf Basis des Modells 107 getroffen. Durch die Nutzung des Modells 107 können die Sicherheits-Tests (Security-Tests) vollumfänglich durchgeführt werden.
Zudem erfolgt die Erstellung und Aktualisierung des Modells 107 automatisiert ohne die Notwendigkeit, manuell einzugreifen bzw. die interne Funktionalität des SUTs 104 analysieren zu müssen. Dadurch können Sicherheits-Tests (Security-Tests) mit weniger Aufwand durchgeführt werden. Dies ermöglicht eine höhere Testabdeckung zur Entdeckung oder Beseitigung von mehrere Schwachstellen und damit die Erhöhung der Robustheit gegenüber virtuellen Angriffen.
Die Testanordnung schafft eine positive Rückkopplungsschleife, bei der die neue Testfälle 102 das Modell 107 verbessern und anhand des verbesserten Modells 107 wiederum neue verbesserte Testfälle 102 erzeugt. Diese Rückkopplungsschleife wird noch in Figur 2 erläutert werden. Figur 2 zeigt ein Ablaufdiagramm eines Ausführungsbeispiels einer positiven Rückkopplungsschleife 200, die beispielsweise optional in Testanordnungen gemäß Ausführungsbeispielen der vorliegenden Erfindung eingesetzt werden kann. Die Rückkopplungsschleife 200 weist beispielsweise fünf Schritte auf.
Der erste Schritt 210 weist eine Ausführung einer Anfrage oder einen Testfall, wie z. B. der Testfall 102 in Figur 1 , auf. Der erste Schritt 210 ist beispielsweise mit dem zweiten Schritt 220 und dem fünften Schritt 250 verknüpft.
Der zweite Schritt 220 weist eine Zusammenfassung der Antworten, wie z. B. der Antwort 105 in Figur 1 , oder der Testergebnisse auf. Der zweite Schritt 220 ist beispielsweise mit dem ersten Schritt 210 und mit dem dritten Schritt 230 verknüpft.
Der dritte Schritt 230 weist eine Identifikation von zustandsverändernden Anfragen oder Testfälle auf. Der dritte Schritt 230 ist beispielsweise mit dem zweiten Schritt 220 und mit dem vierten Schritt 240 verknüpft.
Der vierte Schritt 240 weist eine Ableitung oder eine Verbesserung des Zustandsautomaten auf. Der vierte Schritt 240 ist beispielsweise mit dem dritten Schritt 230 und mit dem fünften Schritt 250 verknüpft.
Der fünfte Schritt 250 weist eine Auswahl der nächsten Anfrage oder des nächsten Testfalls, wie z. B. der Testfall 102 in Figur 1 , auf. Der fünfte Schritt 250 ist mit dem vierten Schritt 240 und mit dem ersten Schritt 210 verknüpft.
Die TE führt in dem ersten Schritt 210 einen Testfall oder eine Anfrage aus. Die Ausführung 210 des Testfalls provoziert ein Testergebnis, das in dem zweiten Schritt 220 aus einer, mehreren oder keiner Antwort und/oder einer Verhaltensänderung erzeugt oder zusammengefasst wird bzw. wurde. Die zustandsverändernden Testfälle werden in dem dritten Schritt 230 anhand der provozierten Testergebnissen identifiziert. Das Modell des SLITs oder der Zustandsautomat wird in dem vierten Schritt 240 mithilfe von den identifizierten zustandsverändernden Testfällen aktualisiert oder abgeleitet. In dem fünften Schritt 250 werden neue Testfälle anhand der schon ausgeführten Testfälle und mithilfe von dem aktualisierten Modell erzeugt. Die neu erzeugten Testfälle werden wiederum in dem ersten Schritt 210 ausgeführt und somit fängt die Rückkopplungsschleife 200 von vorne an. Bis eine aussagekräftige Menge von Anfragen oder Testfällen nicht erreicht wird, kann die TE noch keine fundierte Aussage über das Verhalten des Testobjekts treffen und haben die drei Schritte auf der rechten Seite der Darstellung noch keine Wirkung. Dieser Fall ist durch den gestrichelten Pfeil dargestellt.
Konkrete Umsetzungen
Die konkrete Umsetzung des oben genannten Lösungswegs kann auf verschiedene Arten erfolgen. Im Folgenden werden verschiedene beispielhafte Umsetzungen dargestellt. Dies ist keine abschließende Liste und insbesondere sind Kombinationen der Umsetzungen möglich. Die Verschiedenartigkeit der Beispiele illustriert, dass die Erfindung auf viele Arten umgesetzt werden kann.
Eine Umsetzung der Erfindung stellt ein sogenanntes „Fuzzing“ (Robustheits-Testen) einer Webanwendung auf Basis eines Zustandsautomaten dar bzw. umfasst ein Fuzzing. In diesem Fall entspricht das SUT einer Webanwendung, die auf einem technischen Gerät oder Testobjekt zur Verfügung gestellt wird, das Modell wird durch einen Zustandsautomaten gebildet und die Teststrategie basiert auf „Fuzzing“. „Fuzzing“ bezeichnet in diesem Fall das Einsetzen von vielen verschiedenen Werten und die Reaktion des SUTs auf diese, möglicherweise unerwarteten Werte. Im konkreten Fall einer Webanwendung kann dies beispielsweise die Eingabe von Sonderzeichen oder Programmcode, wie z. B. Java Script Code in ein Textfeld sein. In dem Fall dieser Umsetzung wird das SUT als sogenannte „Blackbox“ (also beispielsweise als ein geschlossenes System unter Vernachlässigung des inneren Aufbaus) betrachtet, es sind also keine Informationen über die Interna des SUTs bekannt. Ein Testfall besteht in dieser Umsetzung beispielsweise aus einer HTTP-Anfrage.
Das konkrete Vorgehen wird anhand Figur 2 veranschaulicht. Der Kreislauf beginnt in der Darstellung oben links. Zunächst wird beispielsweise die initiale Anfrage an die Webanwendung gesendet, es wird also beispielsweise die Startseite der Webanwendung aufgerufen. Bis eine aussagekräftigen Menge an Anfragen gestellt wurde, kann noch keine fundierte Aussage über das Verhalten der Webanwendung getroffen werden. Deshalb bleiben die drei Schritte auf der rechten Seite der Darstellung beispielsweise zunächst ohne Wirkung. Dieser Fall ist durch den gestrichelten Pfeil dargestellt. Auf Basis der abgefragten Startseite werden nun die nächsten Anfragen abgeleitet. So werden beispielsweise neu gefundene Hyperlinks gewählt oder Buttons betätigt. Die jeweiligen Antworten werden beispielsweise in sogenannte Antwortcluster zusammengefasst. Dabei werden beispielsweise ähnliche Antworten in einem Cluster oder in einer Gruppe zusammengefasst. Dies ist beispielsweise für Webseiten der Fall, die sich nur durch die aktuelle Uhrzeit unterscheiden, aber ansonsten inhaltlich identisch sind.
Bei der Untersuchung werden beispielsweise die gleichen Anfragen gezielt häufiger gestellt. Darüber ist es möglich festzustellen, ob sich die Antwort der Webanwendung auf die gleiche Anfrage mit der Zeit ändert. Sollte sich beispielsweise eine Antwort auf eine Anfrage von der vorherigen Antwort auf die gleiche Anfrage unterscheiden, wird beispielsweise davon ausgegangen, dass zwischen diesen beiden Anfragen ein interner Zustandsübergang der Webanwendung stattgefunden hat.
Anschaulich wird das beispielsweise bei einem Online-Shop. Habe ich noch kein Element in meinen Warenkorb gelegt und klicke dennoch auf „Mein Warenkorb“, erreiche ich eine Webseite, die meinen leeren Warenkorb anzeigt. Lege ich jedoch ein Element in meinen Warenkorb und ändere somit den internen Zustand der Webanwendung, erreiche ich bei der gleichen Anfrage nach meinem Warenkorb eine andere Antwort. Beispielsweise könnte nun die Möglichkeit bestehen, den Knopf, oder Button „Zur Kasse“ zu betätigen, was zuvor mit einem leeren Warenkorb nicht möglich war.
Alle Anfragen, die zwischen den beiden betrachteten Anfragen liegen, wie z. B. zwischen den zwei Aufrufen von der „Mein Warenkorb“ Seite, können ein Auslöser für die Zustandsveränderung sein bzw. als Auslöser für eine Zustandsveränderung identifiziert. Beispielsweise auf Basis von einer Heuristik werden diese zustandsverändernden Anfragen identifiziert. In diese Heuristik wird beispielsweise einbezogen, wie oft die Anfrage in der Vergangenheit bereits als zustandsverändernd identifiziert wurde, wie oft die Anfrage schon ausgeführt wurde, und der Typ der Antwort oder Nachricht, wie z. B. GET, POST.
Auf Basis der so erhaltenen Informationen wird der aktuelle Zustandsautomat erstellt oder verbessert. Dabei wird davon ausgegangen, dass sich die Webanwendung so lange in einem Zustand befindet, bis eine zustandsverändernde Anfrage ausgeführt wird.
Nun wird der Kreislauf weitergeführt. Es werden immer weiter mögliche Anfragen ausgewählt und der Zustandsautomat wird immer weiter verfeinert. Sind die über die Webseite erreichbaren Hyperlinks, Eingabefelder und Buttons erschöpft, übernimmt der Robustheitstest-Algorithmus bzw. Fuzzing-Algorithmus die Auswahl der nächsten Anfrage. Dafür werden nun beispielsweise verfügbare URL-Parameter und Eingabewerte eine große Auswahl von Werten ausprobiert. Die Reaktion der Webanwendung wird beispielsweise mit dem Zustandsautomaten abgeglichen. Verhält sich die Webanwendung beispielsweise anders als das Modell, wird dies als Anomalie bewertet, die auf eine Schwachstelle hindeuten kann.
Eine andere Umsetzung der Erfindung basiert ebenfalls auf einem Zustandsautomaten, hat als Ziel jedoch die Implementierung eines Netzwerkprotokolls. Ein Testfall besteht in dieser Umsetzung aus einer Sequenz von einem oder mehreren Netzwerkpaketen. Zudem wird in dieser Umsetzung vorausgesetzt, dass Zugriff auf Informationen bezüglich der Codeabdeckung einer bestimmten Eingabe vorliegt. Das bedeutet im konkreten Fall, dass die TE oder der Algorithmus nach der Eingabe einer bestimmten Sequenz an Netzwerkpaketen Informationen darüber bekommt, welche Codeblöcke das SUT als Reaktion auf diese Sequenz an Netzwerkpaketen durchlaufen hat. Diese Information wird verwendet um die Güte eines Testfalls zu bewerten. So wird beispielsweise ein Testfall, der viele neue Stellen im Code auslöst, mit einer hohen Güte bewertet. Der Ablauf dieses Beispiels wird in Figur 3 veranschaulicht.
Figur 3 zeigt ein Ablaufdiagramm 300 einer Implementierung eines Netzwerkprotokolls mit einem Zugriff auf Informationen bezüglich einer Codeabdeckung. Das Ablaufdiagramm 300 weist eine Schleife mit beispielsweise vier Schritten auf.
Der erste Schritt 310 weist beispielsweise eine Bereitstellung oder Ausführung einer Sequenz von Netzwerkpaketen oder eines Testfalls, wie z. B. der Testfall 102 in Figur 1 , auf. Der erste Schritt 310 ist mit dem zweiten Schritt 320 und dem vierten Schritt 340 verknüpft.
Der zweite Schritt 320 weist beispielsweise eine Berechnung des Verhaltens des SUTs oder eine Codeabdeckungsanalyse auf. Der zweite Schritt 320 ist beispielsweise mit dem ersten Schritt 310 und mit dem dritten Schritt 330 verknüpft.
Der dritte Schritt 330 weist beispielsweise eine Überprüfung und ggf. Aktualisierung des Zustandsautomaten auf. Der dritte Schritt 330 ist beispielsweise mit dem zweiten Schritt 320 und mit dem vierten Schritt 340 verknüpft. Der vierte Schritt 340 weist beispielsweise eine Auswahl der nächsten Sequenz von Netzwerkpaketen auf. Der vierte Schritt 340 ist beispielsweise mit dem dritten Schritt 330 und mit dem ersten Schritt 310 verknüpft.
Die TE führt in dem ersten Schritt 310 einen Testfall aus. Der Testfall besteht in dieser Umsetzung aus einer Sequenz von einem oder mehreren Netzwerkpaketen. Nach der Eingabe einer bestimmten Sequenz an Netzwerkpaketen (beispielsweise in das SUT) bekommt die TE (beispielsweise von dem SUT) Informationen darüber, welche Codeblöcke das SUT als Reaktion auf die Sequenz an Netzwerkpaketen durchlaufen hat. Anhand dieser Informationen oder dieser Codeabdeckung wird beispielsweise in dem zweiten Schritt 320 das Verhalten des SUTs analysiert oder berechnet. Diese Analyse führt beispielsweise in dem dritten Schritt 330 zu einer Überprüfung und ggf. Aktualisierung des Zustandsautomaten des SUT-Modells. Anhand des aktualisierten Modells wird beispielsweise in dem vierten Schritt 340 die nächsten Sequenz von Netzwerkpaketen erzeugt oder ausgewählt, die wiederum in dem ersten Schritt ausgeführt wird.
Das konkrete Vorgehen des Beispiels ist in Figur 3 dargestellt. Der Kreislauf beginnt hier auch oben links. Die initiale Sequenz von Netzwerkpaketen wird in diesem Fall von einem Startwert bzw. einem sogenannten „Seed“ vorgegeben. Dieser kann beispielsweise ein einzelnes gültiges Netzwerkpaket sein, eine Sequenz von Netzwerkpaketen oder auch eine leere Menge. Dieser Beginn wird also beispielsweise an das SUT gesendet und die Informationen über die Codeabdeckung werden erhalten. Auf Basis von dieser Codeabdeckung wird beispielsweise mittels einer Hash-Funktion ein Wert für das Verhalten des SUTs berechnet. Auf Basis dieses Verhaltens wird nun beispielsweise ein Zustandsautomat aufgebaut. Dabei wird beispielsweise solange davon ausgegangen, dass sich das System in einem Zustand befindet, bis ein dazu widersprüchliches Verhalten beobachtet wird. Dies basiert beispielsweise auf einem L*-Algorithmus.
Die Auswahl der nächsten Sequenz basiert auf einem sogenannten Startwert-Auswahl-Al- gorithmus bzw. „Seed-Selection-Algorithmus“. In dieser Auswahl ist beispielsweise auch ein Mutationsalgorithmus enthalten, welcher neue Testfälle auf Basis der alten Testfälle generiert und/oder ausführt. Zudem bezieht die Auswahl des nächsten Testfalles beispielsweise den Zustandsautomaten ein.
Ist beispielsweise ein Zustand noch nicht ausreichend erforscht, werden beispielsweise neue Sequenzen generiert, die genau diesen Zustand hervorrufen, um zu lernen, wie sich das SUT in diesem Zustand verhält. Sind alle aktuell bekannten Zustände ausreichend untersucht, werden beispielsweise neue Testfälle mit größerem Unterschied zu bereits bekannten Testfällen erzeugt. Diese sollen dazu beitragen, neue Zustände zu erreichen.
Alternativ kann die Entscheidung zwischen Exploitation und Exploration, d. h. ob bekannte Zustände weiter untersucht werden sollen oder ob neue Zustände gefunden werden sollen, als ein Mehrarmiger-Bandit-Problem (Multi-Armed-Bandit-Problem) modelliert werden. So können beispielsweise etablierte Verfahren aus dem Bestärkenden Lernen (Reinforcement Learning) wie der Obere-Vertrauensschwelle-Algorithmus (Upper Confidence Bound (UCB) Algorithmus) eingesetzt werden, um diese Entscheidung zu treffen.
Während der Tests wird das SUT ständig überwacht. Wird während der Tests beispielsweise ein Absturz des Programms festgestellt wird diese Information zusammen mit dem zuvor gesendeten Testfall abgespeichert.
Figur 3 kann auch eine weitere Umsetzung der Erfindung illustrieren, bei der die Codeabdeckung auf Basis eines verdeckten Markow-Modells (Hidden Markov Modell (HMM)) illustriert ist.
In der zuletzt genannten Umsetzung wurde beispielsweise vorausgesetzt, dass Zugriff auf Informationen zur Codeabdeckung möglich war. So kann das Verhalten des SUTs quantifiziert werden und zum Aufbau eines Zustandsautomaten verwendet werden. Eine Alternative hierzu ist die im Folgenden beschriebene Umsetzung. Dabei bleibt beispielsweise die Zielsetzung, das SUT, der Algorithmus zur Erstellung des Zustandsautomaten sowie die Mutation und Auswahl der nächsten Sequenz von Netzwerkpaketen gleich. Anders ist die Berechnung des Verhaltens des SUTs. Nun wird davon ausgegangen, dass die Informationen über die Codeabdeckung nicht mehr direkt zur Verfügung stehen. Deshalb wird diese Information ebenfalls über ein Modell approximiert. Als Modelltyp wird hierfür beispielsweise ein verdecktes Markow-Modell (Hidden Markov Modell (HMM)) eingesetzt.
Zu Beginn des Testprozesses werden beispielsweise die ersten Testfälle ohne den Einsatz eines Zustandsautomaten durchgeführt. Hierzu wird beispielsweise der oben beschriebene Startwert bzw. das oben beschriebene Seed und beispielsweise die zur Verfügung stehenden Mutationen verwendet. Der dabei entstehende Netzwerkverkehr wird beispielsweise verwendet, um das HMM zu trainieren. Dabei wird beispielsweise eine Sequenz von Netz- werkpaketen der Kommunikation zwischen dem Testgerät und dem SUT als eine Beobachtungssequenz für das HMM betrachtet. Eine Sequenz von Netzwerkpaketen bezeichnet bzw. beschreibt beispielsweise die Kommunikation zwischen einem TCP Verbindungsaufbau und einem TCP Verbindungsabbau. Jedes Netzwerkpaket wird dabei beispielsweise als eine einzelne Beobachtung angesehen, was beispielsweise in manchen Fällen den Einsatz eines multivariaten HMMs notwendig macht.
Eine gute Wahl für die Anzahl der intern verwendeten Zustände kann beispielsweise über das wiederholte Trainieren das HMMs mit unterschiedlicher Knotenanzahl und einer anschließenden Gütebewertung, z. B. über das Bayessche Informationskriterium getroffen werden. Das trainierte HMM stellt nun beispielsweise ein Modell der internen Abläufe des SUT s dar und kann aus diesem Grund beispielsweise wie folgt dafür verwendet werden um die Codeabdeckung zu approximieren. Beispielsweise kann in einem HMM der Pfad, der am wahrscheinlichsten bei der letzten Ausführung durch das Modell genommen wurde, durch den Viterbi-Algorithmus berechnet (oder abgeschätzt) werden. Dieser Pfad approximiert beispielsweise den Ausführungspfad des SUTs. Dadurch kann diese Information beispielsweise so verwendet werden, wie die Information über die Codeabdeckung in der vorherigen Umsetzung. Sie wird beispielsweise wieder zur Quantifizierung des Verhaltens des SUTs genutzt, was wiederum zur Erstellung oder Aktualisierung des Zustandsautomaten genutzt wird.
Die Auswahl der nächsten Sequenz von Netzwerkpaketen basiert ebenso auf dem sogenannten Startwert-Auswahl-Algorithmus bzw. Seed-Selection-Algorithmus. In dieser Auswahl ist beispielsweise auch ein Mutationsalgorithmus enthalten, welcher neue Testfälle auf Basis der alten Testfälle generiert und/oder ausführt. Dieser Algorithmus wird folgend erläutert.
Evolutionäre Testfallbestimmung gemäß Figur 4
Figur 4 zeigt eine schematische Darstellung eines Ausführungsbeispiels eines evolutionären Algorithmus 400, der beispielsweise einzeln oder in Verbindung mit den hierin beschriebenen Ausführungsbeispielen verwendet werden kann.
Eine Population der Testfälle 420 des Algorithmus 400 ist beispielsweise mit dem SUT 410 verknüpft. Der Algorithmus weist beispielsweise einen Algorithmus des maschinellen Lernens 460 und eine Schleife von der Population der Testfälle 420, einer Mutation 430, Nachwuchstestfälle oder „Offsprings“ 440 und einer Selektion 450 auf. In anderen Worten, es kann beispielsweise in der Schleife eine Population der Testfälle erzeugt werden, und es kann dann eine Mutation erfolgen, es können somit Nachwuchstestfälle erhalten werden und es kann dann eine Auswahl bzw. Selektion erfolgen.
Der Algorithmus des maschinellen Lernens 460 ist beispielsweise mit der Population der Testfälle 420, der Mutation 430 und der Selektion 450 verknüpft.
Die Population der Testfälle 420 werden beispielsweise gegen das SUT 410 ausgeführt, um Testergebnisse, zum Beispiel mithilfe von Monitoren, zu sammeln. Anhand der Testfälle 420 und der Testergebnisse wird beispielsweise der Algorithmus des maschinellen Lernens 460 trainiert.
Durch Mutation 430 wird beispielsweise der Algorithmus des maschinellen Lernens 460 anhand der Population der Testfälle 420 neue Testfälle, die sogenannten „Offsprings“ 440 erstellen. Jeder Testfall wird beispielsweise von dem Algorithmus des maschinellen Lernens 460 mittels eines Fitnesswerts bewertet. Anhand des Fitnesswerts wird beispielsweise eine neue Population der Testfälle selektiert 450, die wiederum gegen das SUT 410 ausgeführt wird, um Testergebnisse zu sammeln.
In anderen Worten, es wird beispielsweise der evolutionäre Algorithmus verwendet um neue Testfälle zu erzeugen. Dafür wird wieder von einem Startwert (Seed) ausgegangen, der bzw. das die erste Population der Evaluation darstellt. Nun werden aus den Individuen dieser Population durch Mutation neue Individuen erzeugt. Diese werden „Offspring“ bzw. Nachkomme genannt. Nun wird zu diesen Individuen im „Offspring“ (beispielsweise zu den Nachkommen) durch eine Fitnessfunktion jeweils ein Fitnesswert zugeordnet. Im Anschluss werden beispielsweise diejenigen Individuen mit den höchsten Fitnesswerten in die neue Generation der Population aufgenommen. Bei diesem Verfahren entspricht beispielsweise jedes Individuum einem Testfall für das Testverfahren. Die neue Generation an Testfällen wird beispielsweise gegen das SUT ausgeführt und die Reaktion beispielsweise durch Mo- nitore beobachtet. Diese Umsetzung der Erfindung besteht beispielsweise aus einer Kombination von einem evolutionären Algorithmus und einem Machinelles-Lernen-Algorithmus (Machine Learning (ML) Algorithmus). Als ML-Algorithmus kann beispielsweise eine Stützvektormaschine (Support Vector Machine (SVM)), ein Zufallsbaum (Random Tree (RT)) oder ein neuronales Netz (NN) verwendet werden.
In dieser Umsetzung kann z. B. die Netzwerkschnittstelle einer Automatisierungskomponente getestet werden. Die Testfälle bestehen beispielsweise aus einem Netzwerkpaket (oder mehreren Netzwerkpaketen). Grundsätzlich ist es beispielsweise auch möglich, den Ansatz so zu erweitern, dass ein Testfall aus einer Sequenz von Netzwerkpaketen besteht. Das Modell der Automatisierungskomponente wird beispielsweise durch den jeweiligen ML Algorithmus repräsentiert und modelliert beispielsweise das Verhalten der Automatisierungskomponente in Reaktion auf einen Testfall. Das Verhalten wird beispielsweise durch die jeweils ausgefallenen Monitoren beschrieben. Im Fall einer Automatisierungskomponente bestehen diese Monitore beispielsweise unter anderem aus der Überprüfung, ob die Automatisierungskomponente noch auf Ping-Anfragen reagiert und/oder ob der Webserver der Automatisierungskomponente noch erreichbar ist.
Der gewählte ML Algorithmus kann beispielsweise in dem oben genannten evolutionären Algorithmus zur Bestimmung des Fitnesswerts eingesetzt werden. Der ML Algorithmus wird beispielsweise so trainiert, dass er eine Funktion approximiert, die einen Testfall auf die Ausgaben der Monitoren abbildet. Er schätzt also beispielsweise, welche Monitoren bei einem gegebenen Testfall wahrscheinlich fehlschlagen werden.
Ein mögliches Ergebnis der Schätzung könnte sein, dass die Automatisierungskomponente nach Ausführung des Testfalls noch auf Ping reagiert, der Webserver aber nicht mehr erreichbar ist. Über diese Schätzung kann beispielsweise die Güte, also die Fitness, eines Testfalls bzw. eines „Individuums“ bestimmt werden. Je mehr Monitore durch den Testfall ausfallen (bzw. je mehr Ausfälle als wahrscheinlich bestimmt werden), desto höher ist die Güte. So kann also eine Vorhersage gemacht werden, ob (bzw. mit welcher erwarteten Wahrscheinlichkeit) der Testfall zu einem Ausfall der Monitoren führen wird. Dies ist beispielsweise gerade im Fall von Automatisierungskomponenten sinnvoll, da hier die Ausführung eines Testfalls relativ viel Zeit in Anspruch nimmt. Die Schätzung des ML Algorithmus zur wahrscheinlichen Reaktion der Automatisierungskomponente kann beispielsweise deutlich schneller berechnet werden. Trainiert wird der ML Algorithmus beispielsweise zunächst auf der Reaktion des SUTs auf die Testfälle, die sich in den Anfangswerten bzw. im „Seed“ befinden. Im Anschluss wird es beispielsweise immer weiter auf den tatsächlich ausgeführten Testfällen nachtrainiert. Hier liegen beispielsweise durch das anschließend gemessene Verhalten der Monitoren ebenfalls die notwendigen Bewertungen bzw. Markierungen bzw. „Labels“ für die Testfälle vor.
Zudem wirkt der ML Algorithmus beispielsweise auch auf die Mutation der Testfälle ein. Wie diese Einwirkung konkret aussieht, hängt beispielsweise von dem gewählten ML Algorithmus ab. Bei einem NN kann beispielsweise der Gradient berechnet werden, der in die Richtung eines (lokalen) Maximums der approximierten Funktion zeigt. Dieses lokale Maximum entspricht dann beispielsweise einem Testfall, der eine möglichst hohe Anzahl von Monitoren betreffen wird. Durch eine Anpassung der Testfälle entsprechend diesem Gradienten, können beispielsweise neue Testfälle erzeugt werden, die eine hohe Wahrscheinlichkeit dafür haben, viele Monitoren ausfallen zu lassen. Ähnlich ist es bei der SVM, auch hier können beispielsweise Vektoren berechnet werden, die auf die Testfälle zeigen, die eine hohe Anzahl von Monitoren ausfallen lassen.
Bei einem RT können keine Gradienten oder Vektoren berechnet werden, aber dennoch kann er für die Mutation verwendet werden. Durch die Nachverfolgung des Pfads, den ein Testfall durch den Baum genommen hat, können beispielsweise Rückschlüsse auf notwendige Änderungen in einem Testfall gezogen werden. So kann beispielsweise überprüft werden welche Entscheidungen im RT zu der Schätzung geführt haben, dass der Testfall nicht viele Monitore zum Ausfall bringen wird. Diese Entscheidungen basieren beispielsweise auf Schwellenwerten von bestimmten Eigenschaften des Testfalls. Nun können beispielsweise neue Testfälle erzeugt werden, die über bzw. unter diesen Schwellenwert kommen. Diese Testfälle haben dann beispielsweise eine höhere Wahrscheinlichkeit dafür, dass sie eine hohe Anzahl an Monitoren ausfallen lassen.
Wie es in Figur 4 dargestellt ist, beginnt der gesamte Prozess mit einem Startwert bzw. „Seed“, der beispielsweise als initiale Population eingesetzt wird. Die Testfälle dieser Population werden gegen das SUT ausgeführt und die Reaktionen beispielsweise der Monitore werden aufgenommen. So erhält der Algorithmus die Bewertungen bzw. Markierungen bzw. „Label“ für die Testfälle in der Population. Die Kombination aus Testfällen und zugehörigen Labels werden nun beispielsweise verwendet, um ein erstes Training des ML Algorithmus durchzuführen. Dieser wird im Anschluss beispielsweise verwendet um die Mutation und die Selektion durchzuführen. So entsteht beispielsweise eine neue Population, die wiederum gegen das SUT ausgeführt wird. Es werden beispielsweise wieder die Reaktionen der Monitore aufgenommen und der ML Algorithmus wird beispielsweise mit dem so neu erzeugten Datensatz nachtrainiert. So wird ein Robustheitstest-Prozess bzw. Fuzzing- Prozess etabliert, bei dem die Testfallerzeugung beispielsweise durch Mutation und die Auswahl von den erzeugten Testfällen durch einen ML Algorithmus unterstützt wird. Dieser ML Algorithmus stellt beispielsweise ein Modell des SUTs dar, indem er eine Funktion approximiert, die das Verhalten des SUTs in Reaktion auf einen Testfall beschreibt.
Alternative Ausführungsbeispiele
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Testanordnung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Testanordnung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei.
Obwohl manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung des entsprechenden Verfahrens darstellen, sodass ein Block oder ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist. Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden Vorrichtung dar. Einige oder alle der Verfahrensschritte können durch einen Hardware-Apparat (oder unter Verwendung eines Hardware-Apparats), ausgeführt werden. Bei einigen Ausführungsbeispielen können einige oder mehrere der wichtigsten Verfahrensschritte durch einen solchen Apparat ausgeführt werden.
Je nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele der Erfindung in Hardware oder in Software implementiert sein. Die Implementierung kann unter Verwendung eines digitalen Speichermediums, beispielsweise einer Floppy-Disk, einer DVD, einer Blu-ray Disc, einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen oder optischen Speichers durchgeführt werden, auf dem elektronisch lesbare Steuersignale gespeichert sind, die mit einem programmierbaren Computersystem derart Zusammenwirken können oder Zusammenwirken, dass das jeweilige Verfahren durchgeführt wird. Deshalb kann das digitale Speichermedium computerlesbar sein.
Manche Ausführungsbeispiele gemäß der Erfindung umfassen also einen Datenträger, der elektronisch lesbare Steuersignale aufweist, die in der Lage sind, mit einem programmierbaren Computersystem derart zusammenzuwirken, dass eines der hierin beschriebenen Verfahren durchgeführt wird.
Allgemein können Ausführungsbeispiele der vorliegenden Erfindung als Computerprogrammprodukt mit einem Programmcode implementiert sein, wobei der Programmcode dahingehend wirksam ist, eines der Verfahren durchzuführen, wenn das Computerprogrammprodukt auf einem Computer abläuft.
Der Programmcode kann beispielsweise auch auf einem maschinenlesbaren Träger gespeichert sein.
Andere Ausführungsbeispiele umfassen das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren, wobei das Computerprogramm auf einem maschinenlesbaren Träger gespeichert ist.
Mit anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm auf einem Computer abläuft.
Ein weiteres Ausführungsbeispiel der erfindungsgemäßen Verfahren ist somit ein Datenträger (oder ein digitales Speichermedium oder ein computerlesbares Medium), auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren aufgezeichnet ist.
Ein weiteres Ausführungsbeispiel des erfindungsgemäßen Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen, der bzw. die das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der Datenstrom oder die Sequenz von Signalen kann bzw. können beispielsweise dahingehend konfiguriert sein, über eine Datenkommunikationsverbindung, beispielsweise über das Internet, transferiert zu werden.
Ein weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung, beispielsweise einen Computer oder ein programmierbares Logikbauelement, die dahingehend konfiguriert oder angepasst ist, eines der hierin beschriebenen Verfahren durchzuführen.
Ein weiteres Ausführungsbeispiel umfasst einen Computer, auf dem das Computerprogramm zum Durchführen eines der hierin beschriebenen Verfahren installiert ist.
Ein weiteres Ausführungsbeispiel gemäß der Erfindung umfasst eine Vorrichtung oder ein System, die bzw. das ausgelegt ist, um ein Computerprogramm zur Durchführung zumindest eines der hierin beschriebenen Verfahren zu einem Empfänger zu übertragen. Die Übertragung kann beispielsweise elektronisch oder optisch erfolgen. Der Empfänger kann beispielsweise ein Computer, ein Mobil gerät, ein Speichergerät oder eine ähnliche Vorrichtung sein. Die Vorrichtung oder das System kann beispielsweise einen Datei-Server zur Übertragung des Computerprogramms zu dem Empfänger umfassen.
Bei manchen Ausführungsbeispielen kann ein programmierbares Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray, ein FPGA) dazu verwendet werden, manche oder alle Funktionalitäten der hierin beschriebenen Verfahren durchzuführen. Bei manchen Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray mit einem Mikroprozessor Zusammenwirken, um eines der hierin beschriebenen Verfahren durchzuführen. Allgemein werden die Verfahren bei einigen Ausführungsbeispielen seitens einer beliebigen Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare Hardware wie ein Computerprozessor (CPU) sein oder für das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.
Die oben beschriebenen Ausführungsbeispiele stellen lediglich eine Veranschaulichung der Prinzipien der vorliegenden Erfindung dar. Es versteht sich, dass Modifikationen und Variationen der hierin beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch den Schutzumfang der nachstehenden Patentansprüche und nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung und der Erläuterung der Ausführungsbeispiele hierin präsentiert wurden, beschränkt sei. Literatur
[1] Bringmann, Eckard, and Andreas Krämer. "Model-based testing of automotive sys- terns." 2008 1st international conference on software testing, verification, and validation. IEEE, 2008.
[2] Bauer, Thomas, et al. "Combining combinatorial and model-based test approaches for highly configurable safety-critical systems." Model-based Testing in Practice (2009): 9.

Claims

Patentansprüche Eine Testanordnung (101) zum Testen (210, 310) eines Testobjekts (104, 410), wobei die Testanordnung (101) ausgelegt ist, um auf Basis einer Interaktion (108) mit dem Testobjekt (104, 410) ein Modell (107) zu erstellen (240, 330), um einen oder mehrere Testfälle (102, 420, 440) unter Verwendung des Modells (107) zu erzeugen (250, 340, 430), um das Modell (107) des Testobjekts (104, 410) anhand von realen Testergebnisse (109), die auf den erzeugten Testfällen (102, 420, 440) basieren, zu verbessern. Die Testanordnung (101) gemäß Anspruch 1, wobei die Testanordnung (101) ausgelegt ist, um eine, mehrere oder keine auf einen erzeugten Testfall (102, 420, 440) gegebene Antwort eines im Hinblick auf sein Verhalten unbekannten und/oder intransparenten Testobjekts (104, 410) über einen oder mehrere Kommunikationswege (103) zu empfangen. Die Testanordnung (101) gemäß Anspruch 1 oder2, wobei die Testanordnung (101) ausgelegt ist, um die Funktionsfähigkeit des Testobjekts (101) oder die Funktionsfähigkeit einer oder mehrerer Funktionen des Testobjekts (101) mittels einem oder mehreren Monitoren (106) und/oder Überwachungsmodulen (106) zu überprüfen. Die Testanordnung (101) gemäß Anspruch 2 oder 3, wobei die Testanordnung (101) ausgelegt ist, um die empfangenen Antworten (105) und/oder die Ergebnisse der Monitoren (106) auszuwerten und anhand dieser Auswertung Testergebnisse (109) zu erzeugen (220, 320). Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 4, wobei die Testanordnung (101) ausgelegt ist, um die Güte des Testfalls (102, 420, 440) anhand des Testergebnisses (109) und/oder anhand einer Wahrscheinlichkeit einer Fehlfunktion des mit dem Testfall (102, 420, 440) getesteten Testobjekts (104, 410) zu bewerten. 6. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 5, wobei die Testanordnung (101) ausgelegt ist, um die Testergebnisse (109) der Testfälle (102, 420, 440) anhand des Modells (107) vorauszusagen (320) oder zu schätzen.
7. Die Testanordnung (101) gemäß Anspruch 6, wobei die Testanordnung (101) ausgelegt ist, um die Testfälle (102, 420, 440), bei denen eine Fehlfunktion des Testobjekts (104, 410) oder eine Fehlfunktion einer oder mehreren Funktionen des Testobjekts (104, 410) vorausgesagt (320) wurde, auszusuchen, und um das Testobjekt (104, 410) mit den ausgesuchten Testfälle (102, 420, 440) zu testen, um Testfälle (102, 420, 440) zu erzeugen, die möglichst viele Fehlfunktionen des Testobjekts (104, 410) als reales Testergebnis (109) erzeugen.
8. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 7, wobei die Testanordnung (101) ausgelegt ist, um unter Verwendung des Modells (107) zu bestimmen, ob ein reales Testergebnis (109) als anomal beurteilt (230, 320) wird.
9. Die Testanordnung (101) gemäß Anspruch 8, wobei die Testanordnung (101) ausgelegt ist, um das reale Testergebnis (102, 420, 440) als anormal zu beurteilen (230, 320), wenn das reale Testergebnis (109) eine Fehlfunktion des Testobjekts (104, 410) oder eine Fehlfunktion einer oder mehreren Funktionen des Testobjekts (104, 410) anzeigt, oder wenn das reale Testergebnis (109) von dem anhand des Modells (107) vorausgesagten Testergebnis (109) abweicht (230).
10. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 9, bei der das Modell (107) einen Zustandsautomat (107) umfasst.
11. Die Testanordnung (101) gemäß Anspruch 10, bei der ein Zustand des Zustandsautomaten (107) zumindest einen Testfall (102, 420, 440) und zumindest ein daraus folgendes Testergebnis (109) umfasst. Die Testanordnung (101) gemäß Anspruch 10 oder 11 , wobei die Testanordnung (101) ausgelegt ist, um mittels einer Hash-Funktion einen Wert für einen Zustand des Testobjekts (104, 410) zu berechnen, und um den Zustand mit dem berechneten Wert zu identifizieren. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 12, wobei die Testanordnung (101) ausgelegt ist, um das Testobjekt (104, 410) in einen vorgegebenen Zustand zu bringen und um das in dem vorgegebenen Zustand befindlichen Testobjekt (104, 410) auf einen oder mehrere verschiedene Testfälle (102, 420, 440) zu testen. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 13, wobei die Testanordnung (101) ausgelegt ist, um zustandsverändernde Testfälle (102, 420, 440), die zu einer Zustandsänderung des Testobjekts (104, 410) führen, zu identifizieren (230) und um basierend darauf das Modell (107) zu aktualisieren (240, 330). Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 14, wobei die Testanordnung (101) ausgelegt ist, um die zustandsverändernden Testfälle (102, 420, 440) unter Verwendung einer Heuristik zu identifizieren (230), wobei die Heuristik ausgelegt ist, um eine Häufigkeit einer Ausführung eines Testfalls (102, 420, 440) und/oder eine Häufigkeit der Identifizierung (230) eines/des Testfalls (102, 420, 440) als zustandsverändernden Testfall (102, 420, 440) und/oder eine Kategorie oder einen Typ eines/des Testfalls (102, 420, 440) zu berücksichtigen. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 15, wobei die Testanordnung (101) ausgelegt ist, um zu beurteilen, ob ein Zustand ausreichend erforscht ist, und um neue Testfälle (102, 420, 440), die diesen Zustand hervorrufen, zu erzeugen, wenn der Zustand nicht ausreichend erforscht ist, oder um neue Testfälle (102, 420, 440) mit einem großen Unterschied zu den bereits bekannten Testfällen (102, 420, 440) zu erzeugen, wenn der Zustand ausreichend erforscht ist. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 16, wobei die Testanordnung (101) ausgelegt ist, um eine Entscheidung, ob bekannte Zustände weiter untersucht werden sollen oder ob neue Zustände aufgefunden werden sollen, als ein M ehrarm iger- Bandit-Problem zu modellieren, und um das Mehrarmiger-Bandit-Problem anhand eines Verfahrens des bestärkenden Lernens zu lösen um die Entscheidung zu treffen. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 17, wobei die Testanordnung (101) ausgelegt ist, um das Testobjekt (104, 410) mit einem Testfall (102, 420, 440) wiederholt zu testen, um festzustellen ob sich das Testergebnis (109) des Testfalles (102, 420, 440) mit der Zeit ändert und um basierend darauf eine Zustandsveränderung zu identifizieren. Die Testanordnung (101) gemäß Anspruch 18, wobei die Testanordnung (101) ausgelegt ist, um Testfälle (102, 420, 440), mit denen das Testobjekt (104, 410) zwischen dem Testfall (102, 420, 440) und dem wiederholten Testfall (102, 420, 440) getestet wurde, als potenziell zustandsverändernde Testfälle (102, 420, 440) zu identifizieren (230). 20. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 19, wobei die Testanordnung (101) ausgelegt ist, um bei der Erzeugung der Testfälle (102, 420, 440) ungültige und/oder unerwartete und/oder zufällige Eingaben zu erzeugen (250, 340).
21. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 20, wobei die Testanordnung (101) ausgelegt ist, um bei der Erzeugung (250, 340) der Testfälle (102, 420, 440) einen Mutationsalgorithmus (430) zu verwenden, welcher neue Testfälle (102, 420, 440) auf Basis alter Testfälle (102, 420, 440) erzeugt.
22. Die Testanordnung (101) gemäß Anspruch 21 , wobei die Testanordnung (101) ausgelegt ist, um bei einer Mutation (430) der Testfälle (102, 420, 440) einen oder mehrere Algorithmen (460) des maschinellen Lernens zu verwenden.
23. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 22, wobei die Testanordnung (101) ausgelegt ist, um ausgehend von einem oder mehreren vordefinierten und/oder zufälligen Testfällen (102, 420, 440) eine Mehrzahl von Zwischentestfällen (440) zu erzeugen, um den Zwischentestfällen (440) jeweils einen Fitnesswert zuzuordnen, um die Zwischentestfälle (440) abhängig von dem jeweiligen zugeordneten Fitnesswert auszusuchen (450), und um die ausgesuchte Zwischentestfälle (440) als neue Testfälle (102, 420, 440) weiterzuverwenden.
24. Die Testanordnung (101) gemäß Anspruch 23, wobei die Testanordnung (101) ausgelegt ist, um den Zwischentestfällen (440) jeweils einen Fitnesswert anhand einer Wahrscheinlichkeit einer Fehlfunktion des mit dem Zwischentestfall (440) getesteten Testobjekts (102) zuzuordnen.
25. Die Testanordnung (101) gemäß Anspruch 23 oder 24, wobei die Testanordnung (101) ausgelegt ist, um bei einer Bestimmung des Fitnesswerts einen oder mehrere Algorithmen (460) des maschinellen Lernens zu verwenden. Die Testanordnung (101) gemäß einem der Ansprüche 22 bis 25, wobei die Testanordnung (101) ausgelegt ist, um einen oder mehrere Algorithmen (460) des maschinellen Lernens, wie Stützvektormaschine-Algorithmen und/oder Zufallsbaum-Algorithmen und/oder neuronales Netz Algorithmen, zu verwenden. Die Testanordnung (101) gemäß einem der Ansprüche 22 bis 26, wobei die Testanordnung (101) ausgelegt ist, um den Algorithmus (460) des maschinellen Lernens oder die Algorithmen (460) des maschinellen Lernens anhand der Testergebnisse (109) der ausgeführten Testfällen (102, 420, 440) nachzutrainieren. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 27, die ausgelegt ist, um eine Sequenz von Testfällen (102, 420, 440) auszuführen und deren Testergebnisse (109) als eine Beobachtungssequenz für ein Training eines Hidden Markov Modells zu verwenden, und um basierend auf einer Beobachtungssequenz Zustände eines Zustandsautomaten (107) mit dem Hidden Markov Modell (107) zu schätzen (320) oder zu approximieren (320). Die Testanordnung (101) gemäß Anspruch 28, die ausgelegt ist, um das Testobjekt (104, 410) in die einzelnen Zustände des Hidden Markov Modells (107) zu bringen und um pro Zustand mehrere Testfälle (102, 420, 440) zu erzeugen, die das Testobjekt (102) ausgehend von dem aktuellen Zustand in die anderen Zustände des Hidden Markov Modells (107) bringen, um eine gute Pfadabdeckung des Hidden Markov Modells (107) zu erreichen. Die Testanordnung (101) gemäß Anspruch 29, die ausgelegt ist, um den wahrscheinlichsten Ausführungspfad eines Testfalls in dem Hidden Markov Modell (107) durch einen Viterbi-Algorithmus zu berechnen, und um basierend darauf die Pfadabdeckung der Testfälle (102, 420, 440) zu berechnen. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 30, wobei die Testanordnung (101) ausgelegt ist, um das Modell (107) und/oder die generierten Testfälle (102, 420, 440) immer weiter zu verfeinern. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 31 , die ausgelegt ist, um einen oder mehrere Testfälle (102, 420, 440) für eine Webanwendung zu erzeugen, und um die Antwort (105) der Webanwendung zu empfangen und/oder auszuwerten (220, 320). Die Testanordnung (101) gemäß Anspruch 32, die ausgelegt ist, um den Testfall (102, 420, 440) oder die Testfälle (102, 420, 440) in Form von
Eingaben in eines oder mehreren Eingabefelder der Webanwendung und/oder
Aktivierung von einer oder mehreren Schaltflächen der Webanwendung und/oder
Aktivierung von einem oder mehreren Links der Webanwendung zu erzeugen. Die Testanordnung (101) gemäß Anspruch 32 oder 33, die ausgelegt ist, um die Antwort (105) der Webanwendung in Form von
Aktivierung oder Deaktivierung von einem oder mehreren Eingabefeldern der Webanwendung und/oder
Aktivierung oder Deaktivierung von einer oder mehreren Schaltflächen der Webanwendung und/oder
Aktivierung oder Deaktivierung von einem oder mehreren Links der Webanwendung und/oder
Zufügung oder Entfernung von einem oder mehreren Eingabefeldern und/oder einer oder mehreren Schaltflächen und/oder einem oder mehreren Links, und/oder Änderung von einem oder mehreren Texten oder Zahlen, zu empfangen und/oder auszuwerten (220, 320).
35. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 31 , die ausgelegt ist, um einen oder mehrere Testfälle (102, 420, 440) für ein Testobjekt (104, 410), das ein Netzwerkprotokoll verwendet, zu erzeugen, und um die Antwort (105) des Testobjekts (104, 410) zu empfangen und/oder auszuwerten (220, 320).
36. Die Testanordnung (101) gemäß Anspruch 35, die ausgelegt ist, um den Testfall (102, 420, 440) oder die Testfälle (102, 420, 440) in Form von einer oder mehreren Eingaben in einer Sequenz von einem oder mehreren Netzwerkpaketen zu erzeugen (250, 340, 430).
37. Die Testanordnung (101) gemäß Anspruch 35 oder 36, die ausgelegt ist, um die Antwort (105) des Testobjekts (104, 410) in Form von einer Sequenz von einem oder mehreren Netzwerkpaketen und/oder in Form von Informationen bezüglich einer Codeabdeckung der Eingabe zu empfangen und/oder auszuwerten (220, 320).
38. Die Testanordnung (101) gemäß Anspruch 37, die ausgelegt ist, um basierend auf den Testfällen (102, 420, 440) und darauf basierenden Codeabdeckungen einen Zustandsautomat (107) aufzubauen, um mittels einer Hash-Funktion einen Wert für einen Zustand des Testobjekts (104, 410) zu berechnen, und um den Zustand mit dem berechneten Wert zu identifizieren.
39. Die Testanordnung (101) gemäß Anspruch 37 oder 38, die ausgelegt ist, um eine Sequenz der Kommunikation zwischen der Testanordnung (101) und dem Testobjekt (104, 410) als eine Beobachtungssequenz für ein Training eines Hidden Markov Modells (107) zu verwenden, und um basierend auf der Beobachtungssequenz die Codeabdeckung mit dem Hidden Markov Modell (107) zu schätzen oder zu approximieren. Die Testanordnung (101) gemäß Anspruch 39, die ausgelegt ist, um das Testobjekt (104, 410) in die einzelnen Zustände des Hidden Markov Modells (107) als Ausgangszustand zu bringen und um pro Zustand mehrere Testfälle (102, 420, 440) zu erzeugen, die das Testobjekt (104, 410) ausgehend von dem aktuellen Zustand in die anderen Zustände des Hidden Markov Modells (107) bringen, um eine gute Pfadabdeckung des Hidden Markov Modells (107) zu erreichen. Die Testanordnung (101) gemäß Anspruch 40, die ausgelegt ist, um den wahrscheinlichsten Ausführungspfad eines Testfalls in dem Hidden Markov Modell (107) durch einen Viterbi-Algorithmus zu berechnen und um basierend darauf die Pfadabdeckung der Testfälle zu berechnen. Die Testanordnung (101) gemäß einem der Ansprüche 1 bis 31 , die ausgelegt ist, um Testfälle (102, 420, 440) in Form von Eingaben eines Netzwerkpakets oder einer Sequenz von Netzwerkpaketen für eine Netzwerkschnittstelle eines Testobjekts (104, 410) zu erzeugen, und um die Funktionsfähigkeit des Testobjekts (104, 410) oder die Funktionsfähigkeit einer oder mehrerer Funktionen des Testobjekts (104, 410) mittels Monitoren (106) auszuwerten. in Verfahren zum Testen eines Testobjekts (104, 410), mit folgenden Schritten:
Erstellen eines Modells (107) auf Basis einer Interaktion mit dem Testobjekt (104, 410),
Erzeugen eines oder mehrerer Testfälle (102, 420, 440) unter Verwendung des Modells (107),
Verbessen des Modells (107) des Testobjekts anhand von realen Testergebnisse (109), die auf den erzeugten Testfällen (102, 420, 440) basieren.
44. Ein Computerprogramm zur Durchführung des Verfahrens gemäß Anspruch 43, wenn das Computerprogramm auf einem Computer ausgeführt wird.
EP23702250.4A 2022-01-27 2023-01-24 Eine testanordnung und ein verfahren zum testen eines testobjekts, und ein computerprogramm zur durchführung des verfahrens Pending EP4470162A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022200928.2A DE102022200928A1 (de) 2022-01-27 2022-01-27 Eine Testanordnung und ein Verfahren zum Testen eines Testobjekts, und ein Computerprogramm zur Durchführung des Verfahrens
PCT/EP2023/051720 WO2023144158A1 (de) 2022-01-27 2023-01-24 Eine testanordnung und ein verfahren zum testen eines testobjekts, und ein computerprogramm zur durchführung des verfahrens

Publications (1)

Publication Number Publication Date
EP4470162A1 true EP4470162A1 (de) 2024-12-04

Family

ID=85122768

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23702250.4A Pending EP4470162A1 (de) 2022-01-27 2023-01-24 Eine testanordnung und ein verfahren zum testen eines testobjekts, und ein computerprogramm zur durchführung des verfahrens

Country Status (3)

Country Link
EP (1) EP4470162A1 (de)
DE (1) DE102022200928A1 (de)
WO (1) WO2023144158A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4530862A1 (de) * 2023-09-28 2025-04-02 Robert Bosch GmbH Automatisierte erzeugung von testcode zum testen von embedded software
CN119094407B (zh) * 2024-11-05 2025-01-24 合肥城市云数据中心股份有限公司 一种面向网络协议实现的差分测试方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8006136B2 (en) 2007-10-08 2011-08-23 Wurldtech Security Technologies Automatic grammar based fault detection and isolation
US8433542B2 (en) 2008-02-27 2013-04-30 Wurldtech Security Technologies Testing framework for control devices
US9026394B2 (en) 2007-10-08 2015-05-05 Wurldtech Security Technologies Testing and mitigation framework for networked devices
US8132053B2 (en) 2008-02-27 2012-03-06 Nathan John Walter Kube System and method for grammar based test planning
CN111123888B (zh) * 2019-12-19 2022-03-15 江苏中天互联科技有限公司 一种工控协议测试方法、系统及电子设备和存储介质

Also Published As

Publication number Publication date
WO2023144158A1 (de) 2023-08-03
DE102022200928A1 (de) 2023-07-27

Similar Documents

Publication Publication Date Title
DE102012102770B4 (de) System und Verfahren zur Fehlereingrenzung und Fehlerabschwächung basierend auf einer Netzwerkmodellierung
DE60005861T2 (de) Verfahren und system zur analyse von kontinuirlichen parameterdaten für diagnostik und reparaturen
DE69228986T2 (de) Durch hierarchisch verteilte wissenbasierte maschine ausgelöste wartungs-vorrichtung und -verfahren
DE69523588T2 (de) Gerät und methode zur ereigniskorrelation und problemmeldung
DE602005004997T2 (de) Diagnostisches Verfahren und System
DE60106799T2 (de) Probabilistische Diagnose, inbesondere für eingebettete Fernanwendungen
DE102022201746A1 (de) Verwaltung von rechenzentren mit maschinellem lernen
DE102004015504A1 (de) Verfahren und Vorrichtung zur diagnostischen Wahl eines Wartungskonzepts für ein komplexes System
EP1305677B1 (de) Verfahren zur ferndiagnose eines technologischen prozesses
DE102010052998A1 (de) Software-zentrierte Methodik für die Überprüfung und Bestätigung von Fehlermodellen
DE102004015503A1 (de) Verfahren und Vorrichtung zum Korrigieren diagnostischer Analysekonzepte in komplexen Systemen
EP1223709A2 (de) Verfahren und Vorrichtung zum rechnergestützten Überwachen eines Telekommunikationsnetzes
WO2021121695A1 (de) Verfahren, vorrichtung und system zur detektion von anomalen betriebszuständen eines geräts
DE102019001760A1 (de) Informationsverarbeitungsgerät, maschinelle lernvorrichtungund system
WO2023144158A1 (de) Eine testanordnung und ein verfahren zum testen eines testobjekts, und ein computerprogramm zur durchführung des verfahrens
WO2023041458A2 (de) Computerimplementierte verfahren, module und system zur anomalieerkennung in industriellen fertigungsprozessen
EP3340250B1 (de) Bauteilidentifikation bei der fehlerbehandlung von medizinischen geräten
DE102005027378B3 (de) Dynamische Priorisierung von Prüfschritten in der Werkstattdiagnose
EP2102723B1 (de) Verfahren und vorrichtung zum diagnostizieren von funktionen und fahrzeugsystemen
DE102004015501A1 (de) Verfahren und Vorrichtung für Wartbarkeit komplexer Systeme
DE102020115186A1 (de) Verfahren und System zur Verarbeitung von Fahrzeugtestdaten eines Fahrzeugs
DE102019210562A1 (de) Verfahren und Vorrichtung zum Prüfen von Software
DE102024139564A1 (de) Elastische kopplung zwischen digitalem zwilling und physischem artefakt
EP3764185A1 (de) Verfahren zum testen eines systems
DE102024120534A1 (de) Kontextbezogene ursachenanalyse für fahrzeugsoftwaresysteme

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240816

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)